➕ Adding new members to the Github organization

[JamesAlfonse]

          Great catch on the members tagging. I would love to be able to directly tag anyone who has created an issue before, for example, or automatically welcome as member with limited perms a person who had done so. I wonder if there's a way to expand that feature? 

Originally posted by @tehchives in WhyDRS/Database#19 (comment)

[JamesAlfonse]

Continuing the conversation here, I found documentation on setting base permissions for members and how to adjust them. Here is a direct link to the current setup we have. Right off the bat, by default I don't think new members should be granted full access to Write permissions for Projects or have repository creation abilities. These permissions can be fine-tuned for each member as necessary and can be applied to specific repositories. I'd like to go through all the options one by one and follow principle of least privilege here; we should do this on our next team meeting. Once a proper baseline is established, I can work to setup a Github app that automatically sends an invite to users that create a new issue.

[JamesAlfonse]

Also, with default member permissions potentially being adjusted, we should consider how to ensure current members continue having the access that would be most beneficial to them. @JFWooten4 @tehchives

[tehchives]

Sounds perfect to me James, thanks so much. Tiered membership, with automatic invites sent to new folks participating, seems like the best route. I wonder if we could also send those basic invites to anyone commenting on an existing issue, as well? We could also have a static 'issue' where folks could go to comment specifically to get an invite, in that case. This would of course need to go alongside a limited permissions structure for entry members, focused on participation / discussion / suggestion rather than direct write access.

Since we're our scheduled meetings a bit more infrequently this month due to the holiday, maybe we can set a time to meet on this topic or we can hash it out here.

[JamesAlfonse]

I asked ChatGPT for recommendations and here's what it came back with. I'll go through each option below.

• Base permissions: ChatGPT recommended read options, though I didn't give it enough context to see all the options available. I'm attaching a screenshot below. I think it would make more sense to select "No permissions" here, which prevents cloning and pulling private repositories (I believe members would still have access to viewing the private repositories).

I

• Repository creation: Private is suggested here, although it doesn't seem to be an option without an active Github Enterprise Cloud subscription. I recommend disabling both options here for now.

• Repository forking: I don't see a need for having this enabled for private repos, and it's recommended to disallow this.

• Repository discussions: Its recommended to disallow this, and it's important to note that members with read-only access would have the ability to comment on open discussions. I'm on the fence about this, I could see this potentially being a roadblock for new members unable to start new discussions. Potentially a way around this is to create a "General" discussion in repositories and new discussions can be branched off from there if needed. I think this route would be the way to go, and to follow the recommendation.

• Projects base permissions: It's recommended to change to Read, but also in this instance ChatGPT didn't have the context of knowing about "No access" as an option. I don't believe it's necessary to give members access to private projects in the organization, so I think it makes sense going with "No access" here.

• Page creation: It's recommended to have the private option selected here, though that requires an active GitHub Enterprise Cloud subscription. I don't see a need for either public or private page creation, I think it makes sense to disable both.

• Integrated access requests: It's recommended to disallow this, and I don't see a need for it to be enabled.

[tehchives]

Sorry for my late reply - travel over holiday. Really appreciate the breakdown and your thoughts on the nuances when considering how best to find the middle ground between bringing more people in without creating security issues for the core features and discussions here. The concept of a general discussion thread that we could peel off of is also one I think has come up before - in some ways, when we migrate issues from the Discord conversations, a very similar thing is happening.

[JamesAlfonse]

Sorry for my late reply - travel over holiday. Really appreciate the breakdown and your thoughts on the nuances when considering how best to find the middle ground between bringing more people in without creating security issues for the core features and discussions here. The concept of a general discussion thread that we could peel off of is also one I think has come up before - in some ways, when we migrate issues from the Discord conversations, a very similar thing is happening.

Great! I can create a general discussion under the organization. There's also the question of if there should be a general discussion within certain repositories too. I think just a main general thread would work for now, but let me know if you think otherwise.

I'll leave this issue open for a few days to see if there's more feedback and proceed with the changes after Christmas.

[JamesAlfonse]

I made the adjustments and attached a screenshot of the new default member privileges. These changes can easily be reverted if needed, and a quick reminder that manual privilege adjustments can be made for each member. I also created a general discussion in case new members with minimal privileges would like to bring attention to something.

[JFWooten4]

On the original context from @tehchives, I love the idea of involving new GitHub contributors as growing members of the organization. Namely, we can sincerely foster permissionless involvement by mentioning any user on the platform—promoting an equal playing field and a respected venue for diverse opinions. Tangential to the discussion of new membership, but certainly a tidbit of the collaboration system which I appreciate enough to point out explicitly here and in that last comment mentioned above! No more chains of hierarchical managers to speak towards someone of influence.¹

For me, at least part of the nature of a permissionless system is that you can contribute without being an explicit "member." Along this train of thought, I have personally appreciated the experience of freely creating issues in repositories which affect me, despite the reality that I do not want to be an active participant in that project at the time for technical or logistical constraints. If I were invited as a member to every repository parent organization that I interacted with, then I would feel a little off-put just because that online association is traditionally reserved for formal working arrangements.³

Personally, here's a primitive, rough course of action I would appreciate off the top of my head:

Nothing super definitive, but this captures the main idea I'm trying to convey with encouraging both community involvement on the social (Discord) side and the technical workings of the GitHub repositories. Since Issues and PRs are by their nature more development-oriented, I will also transition most future WhyDRS/Taking-Stock guest discussions, e.g., into a Discussion forum which would avoid implication with a bot that implemented something like this.⁴

Specific User Permissions

This is where things get a little more hairy, and I generally align with James' suggestion towards a principle of least privilege. I've used this argument in the EDGNAR Next API comment, and (based on the final rule's diction) it seems like the Commission takes a similar stance on minimizing permissiveness to necessary scope by means of prudent cybersecurity.

Personally, I wouldn't mind opening a pull request to contribute to many of the repositories I'm less involved with.⁵ Moreover, it can really help auditability and debugging to do routine work on branches, especially when they touch work primarily done by others.⁶

All that to say, assigning write access will probably take a bit more tact, but it shouldn't be impossible. The transparent nature of these comments, their moderation, and user actions make it easy to swiftly catch any trusted user whose account might run afoul. And of course, the git history is a simple recovery process with assigned change histories which are trivially reversed.

Current Members

One note: I think we should require 2FA for write access. The present members without this enabled have not written to any repositories in some time. It should be simple to keep them in the organization while limiting them to the standard base permissions for the time being, until they choose to become more actively involved.

This also implicates the reality that there are presently five members of the organization despite the fact that a naive public view will only show two. This is because each member has their own choice to make their association with @WhyDRS public or not. Obviously, I'm a huge proponent of public declarations, but that's ultimately up to each member. Notwithstanding, I think we should be very careful about members with write access who choose to use a private association.

Next Steps

I know we've been broadly discussing the contribution schema for a while. Ideally, once we get this all worked out, a new DUNA Docs section could make it easy for new members to quickly parse. The above figure introduced the idea of a registry, which I think we'll need for assigning tokens. It's still an early idea which I'll flesh out in the token governance blog posts, but basically somewhere we can associate Discord/GitHub/Reddit/Lemmy usernames (including in aggregation) to a public wallet key.

Certainly much to discuss, and unfortunate that I won't be able to make the next meeting to chat live. My bad on this one, but I'm getting the physical infrastructure up for the IPFS recording sharing per WhyDRS/Taking-Stock#9. In the meantime, I'll defer and personally appreciate the searchability of the written word, which has the added benefit of allowing for contextual hyperlinks. :)

We have a unique opportunity to define a new decentralized nonprofit standard, quite possibly one aligned with Jersan's democratic principles:

I imagine a discussion platform kind of like Reddit / Lemmy, but where moderators are all democratically elected. This would ensure that the community always has the power to remove moderators that aren’t serving the interests of the community. In terms of how changes are made, I imagine an environment that combines the best features of Github and Wikipedia, in terms of how changes are made and decided upon and applied for everyone. That there would be standard processes in place for making suggestions and changes, but that the ultimate power rests in the hands of the community participants.
— @jergy2

Footnotes

1. That's called centralization! Compare with a targeted, considerate, and specific tagging of users as @JamesAlfonse implements through his work.² ↩

2. As an aside, thank you for putting your pronouns in your GitHub profile so that the last sentence was super easy to properly address! I'm all for inclusivity by means of personal identity, but I appreciate the explicit clarity of singular pronouns when applicable. ↩

3. At least outside of the explicitly open-source project world. That said, I do think the threshold for membership is generally set far too high (or even just making someone an external collaborator in a more permissioned legacy organization concerned over private billing settings). ↩

4. If we decide to build something like that and think it's a decent flow. I was thinking about this a bit lately after James ingeniously posted General Chat DUNA-docs#35 as a general ideation space. While I've previously used issues like 🤝 Chat with Kristen Shaughnessy Taking-Stock#18 as a place for guest chats, this could get a little confusing given the recent increasing scope of that repository. Frankly, I'd hate for more social communicative collaboration chats to get buried under increasing site-specific technical implementation Issues—hence the place for a distinct Discussion! Small idea, let me know. ↩

5. I've done this previously in Stylize the varibales Database#27. ↩

6. See, e.g., PRs requesting input from affected members or otherwise circling around on input for material changes in ✏ Small GitHub formatting optimizations for readability Taking-Stock#16 and 🗽 Migrate to segregated content license Taking-Stock#17. ↩

[JamesAlfonse]

@JFWooten4 Thank you for the thorough and well-thought out comment, I appreciate the detail as well as the diagram to help visualize potential paths for contributors.

On the original context from @tehchives, I love the idea of involving new GitHub contributors as growing members of the organization. Namely, we can sincerely foster permissionless involvement by mentioning any user on the platform—promoting an equal playing field and a respected venue for diverse opinions. Tangential to the discussion of new membership, but certainly a tidbit of the collaboration system which I appreciate enough to point out explicitly here and in that last comment mentioned above! No more chains of hierarchical managers to speak towards someone of influence.1

On the topic of mentioning users outside of the org, do you know if tagged individuals receive a notification and/or email for this by default? I believe @bobmahalo said he got an email from something he was mentioned in, but would love to confirm it.

For me, at least part of the nature of a permissionless system is that you can contribute without being an explicit "member." Along this train of thought, I have personally appreciated the experience of freely creating issues in repositories which affect me, despite the reality that I do not want to be an active participant in that project at the time for technical or logistical constraints. If I were invited as a member to every repository parent organization that I interacted with, then I would feel a little off-put just because that online association is traditionally reserved for formal working arrangements.3

This is a great point I had not considered. If a contributor wants to help without being listed as a member and feel some type of obligation, it would cause unnecessary friction sending them an invite.

Nothing super definitive, but this captures the main idea I'm trying to convey with encouraging both community involvement on the social (Discord) side and the technical workings of the GitHub repositories. Since Issues and PRs are by their nature more development-oriented, I will also transition most future WhyDRS/Taking-Stock guest discussions, e.g., into a Discussion forum which would avoid implication with a bot that implemented something like this.4

The flowchart is a great start, I just have one small tweak to the process. As to your previous point, we should get consent from contributors before sending an invite to the org or adding them to a "registry". Also, creating Taking Stock guest discussions instead of issues makes sense to me!

One note: I think we should require 2FA for write access. The present members without this enabled have not written to any repositories in some time. It should be simple to keep them in the organization while limiting them to the standard base permissions for the time being, until they choose to become more actively involved.

This also implicates the reality that there are presently five members of the organization despite the fact that a naive public view will only show two. This is because each member has their own choice to make their association with https://github.com/WhyDRS public or not. Obviously, I'm a huge proponent of public declarations, but that's ultimately up to each member. Notwithstanding, I think we should be very careful about members with write access who choose to use a private association.

100% behind enforcing 2FA for members with write access. I don't believe there's a way to do that automatically, it would need to be checked manually if someone has it enabled before they are granted the access. Also, it could theoretically be turned off right after, so that may be something to keep in mind to check periodically (or have an automation set up with alerts). As far as current members with write access, I did see a popup when making the permission changes notifying that making the change would affect all current members of the org. So we may have the correct permissions currently set up.

I know we've been broadly discussing the contribution schema for a while. Ideally, once we get this all worked out, a new DUNA Docs section could make it easy for new members to quickly parse. The above figure introduced the idea of a registry, which I think we'll need for assigning tokens. It's still an early idea which I'll flesh out in the token governance blog posts, but basically somewhere we can associate Discord/GitHub/Reddit/Lemmy usernames (including in aggregation) to a public wallet key.

Certainly much to discuss, and unfortunate that I won't be able to make the next meeting to chat live. My bad on this one, but I'm getting the physical infrastructure up for the IPFS recording sharing per WhyDRS/Taking-Stock#9. In the meantime, I'll defer and personally appreciate the searchability of the written word, which has the added benefit of allowing for contextual hyperlinks. :)

We have a unique opportunity to define a new decentralized nonprofit standard, quite possibly one aligned with Jersan's democratic principles:

I imagine a discussion platform kind of like Reddit / Lemmy, but where moderators are all democratically elected. This would ensure that the community always has the power to remove moderators that aren’t serving the interests of the community. In terms of how changes are made, I imagine an environment that combines the best features of Github and Wikipedia, in terms of how changes are made and decided upon and applied for everyone. That there would be standard processes in place for making suggestions and changes, but that the ultimate power rests in the hands of the community participants.
— @jergy2

I brought up your comment earlier during today's meeting, and would love to have the registry idea fleshed out. Do we create a new repository for it, or do we add it into the WhyDRS site? Do we split the registry into sections, and if so do we have it set up by repository? Just some initial questions I had, but I'm sure I'll come up with some more 😊

[JFWooten4]

Hi @JamesAlfonse, you bet - thank you for bringing up the important discussion point!

Outside Contributor Notifications 📨

By default, it's my understanding that GitHub does ping everyone by email right when they're mentioned. Personally, I turned this off relatively quickly, in preference for the local website inbox I check frequently. There are also options in settings to group all mentions into a daily or weekly digest. All of this really depends on the user's email inbox preferences, but TBH I find mentions quite effective given the user is active and actually part of the community.

Here are the official (and lengthy) docs on email notifications. They have some pretty neat inbuilt features like replying to an email to post a reply on an issue. If there's anything you want to highlight in the Wiki or somewhere else on the DUNA docs, I'd be happy to write something up on it. Like I said, I think the default behavior is great where community members who might not check GitHub every day receive an email about direct mentions or repository watching.¹

Adding New Contributors

Definitely with you on having members add themselves to the registry, organization, or anything listing them publicly like that. The nice thing is an invite can be easily ignored. It should be pretty simple to pair with a Discord DM or personalized message here welcoming them to the effort and extending a hand to join.

As for the registry, that would explicitly require PRs to add users in my mind. This is largely because the only person who can share a public key is the contributor who owns the private key for a wallet. Thus, it's every individual's responsibility to associate their address with their online handle(s).

2FA Group Config 🔐

Great edge case there for (accidentally) disabling 2FA after getting write access. This would certainly require some checking, and it'd be awesome if we could have a script do that for long-term management of growing contributors. Great idea, James!

As for the popup, I don't think we need to explicitly require it for all members, since we can configure users with base permissions to read only. As long as it's okay with @tehchives, I could, for example, move to downgrade one account with Admin access to the database which hasn't made any contributions to the org just yet. Just an idea, let me know what you think about the consensus formation around things like that, and I look forward to getting more members involved in the active development—especially ones with an inspiring history of open-source work!

Seems like it was an eventful meeting—listening through now and will comment in the Discord to keep the conversation in front of as many eyes as possible for now. For things that affect everyone, I try my best to really "advertise" any proposed changes and get clear consensus on future actions. One of the best things about the community, IMO, is that everyone really understands what's going on here, so we don't have to keep explaining the ownership primitives so key to our work.

Footnotes

1. E.g., community members can subscribe to new pushes or issues related to a specific repository. ↩

[tehchives]

The distinction John makes identifying how user accounts and public keys must be paired up is so crucial to the idea of a registry of users and contributors, since we must work backwards from having a useful tool for the governance structure that will be responsible for future decisions and maintenance. In the medium term a registry will allow users to check who is active in development and therefore in governance. In a long term it could be very handy to review profiles in such a registry when considering how to vote on a given proposal - checking into the history of an ideas supporters or detractors can provide such helpful context.

I also appreciate so much how ownership principles provide a narrative undercurrent native to those who spend time in our community. It can be seen not only in direct registration, but in advocating for custodial control of on-chain assets or in the reverence for group development of an open source platform.