Formalizing a process for Crowd Research Collective GitHub Repositories

[markwhiting]

The problem

We have a new governance system, but using GitHub to execute that system introduces a need for defining aspects about permissions and practices. In particular, GitHub repositories have members with various permissions and we are yet to clarify how those permissions should be formalized. Additionally, GitHub does not do everything we need it to, so some parts of our process should be done by hand for the time being, and a particular set of actions for that should be specified.

My proposal

Formalize permissions in 2 levels:

1. Collective members should all have write access to this GitHub repository, allowing them to assign themselves to proposals, modify labels and milestones.
2. Admin users of this repository should become an operational group, the Collective Github Admin group. This will be initiated with @markwhiting, only because he has had this position while setting up this repository. Others can join through the operational group process.

Formalize practices as follows:

1. The repository should be set so that any modification to documents stored in it require a pull request. This is currently how it is set, but I wish to formalize that this should stay this way.
2. Those who are part of the collective but are not yet added to the collective group can fill out a form and will be granted access. This form will ask for details such as, email address, slack ID, and GitHub ID. The admin group will be tasked with then determining if the person is actually a member of the crowd research slack, and adding them to the collective group in GitHub in the case that they are.
3. Instructions on how to do the key governance activities in this repository should be maintained as part of the contributing documentation (related pull request to follow).
4. To the best of their abilities members of the collective and the admin group should adhere to the expectations of the governance documents in their use of Github. For example, if a proposal has broken consensus, any member of the community is able to add the appropriate label to that proposal, and it is only to be removed when the broken consensus is officially resolved.
5. No user will be given special capabilities, or be allowed to act outside of their capabilities without a formal process. For example, members of the admin group could not take any special administrative actions without a proposal.

Implications

The main implication of this proposal is that it removes uncertainty about who should have particular permission levels in this repository, and formalizes what members of those levels are allowed to do.

Contact

Mark Whiting is @markwhiting on GitHub and Slack.

---

Use comments to share your response or use emoji 👍 to show your support. To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.

[neilthemathguy]

BREAKING CONSENSUS

Let's stick to what we discussed in the past and during the meeting--- we will hold collective hangout to figure out operational steps and then collectively write a proposal. Let's do that.

Admin users of this repository should become an operational group, the Collective Github Admin group. This will be initiated with @markwhiting, only because he has had this position while setting up this repository.

Could you mention which position are you talking about here?

[markwhiting]

Sure.

Is there anything in particular you (or others) would like to add or change in this proposal? I'm not against a hangout at all, but I figure we can start working out what we want here too.

Which position are you talking about here

I'm just saying that I set up the repository so far and to do that, I needed admin privileges. I didn't mean to imply that this was an official position or anything like that. Instead I wanted to make it clear that it was not officiated yet, and that it should be.

[markwhiting]

For those following here, I'm aiming to schedule a mediation meeting for this. Please fill out this when2meet so we might find a time that works.

[qwertyone]

"No user will be given special capabilities, or be allowed to act outside of their capabilities without a formal process. For example, members of the admin group could not take any special administrative actions without a proposal."

These words need special attention and need to be some where. I see that the proposals are trying to form the governance system more solidly, @iceLearn CoC ties in here I think.

[markwhiting]

@qwertyone Yeah, I would assume this would be formalized in our definition of the relevant operational group.

[neilthemathguy]

The time window highlighted here is very short https://www.when2meet.com/?6549894-w6sP6

While this is the busiest time of the year, I'm happy to squeeze in a slot in my schedule. Let's extend the time dates till 6th.

Also, I want everyone to join this hangout, not just 1-2 people taking it over and synthesizing other people's thoughts to decide the process. Let's do it as we discussed while talking about #2 in the hangout

[markwhiting]

While I completely agree that this is a difficult time of year for many people (me included), I think we have never really managed to schedule a hangout to include everyone at any point during the year. I believe that the design of our consensus driven system was in part to help us avoid needing that.

Here's a new when2meet extended to the morning of the 10th because thats when the vote on this would be finished if we can't reach another solution.

[markwhiting]

Comment was removed to be in #2

[neilthemathguy]

Removed and Moved to #2

[neilthemathguy]

As discussed in the hangout---

GitHub has default roles Owner, Maintainers, and Members

We can restructure all GitHub repositories and the roles as follows:

1. Owner: Common account e.g. Crowd Research Collective (we can work out the operational details in a separate proposal)
2. Maintainers: People who are nominated through the governance processes in the review groups
3. Members: Everyone

Feel free to summarize other aspects.

[markwhiting]

Thanks.

In the meeting we discussed the use of GitHub projects to assist in running the proposal system.

Hence, this proposal is updated to concretely reflect:

1. Three types of members, executed through Github settings (Owner, Maintainer, and Member).
2. A practice of making all members of the collective at least at the level of Member in GitHub via the Collective team.
3. A practice of making teams with relevant permissions for other groups within the collective. These permissions will be determined for each group and members of that group will be added to the associated teams.
4. A pledge to continue to refine this mechanism, through, for example, testing features using GitHub projects, and automation scripts.

@neilthemathguy are you willing to regain consensus given these adjustments?

[neilthemathguy]

Yes, what are the next steps here?

Here are few ---

1. This week: List all the the accounts at one place. Complete the access logistics to already assigned groups this week.
2. This week: Formalize all the repositories based on Owner, Maintainers, and Members this week
3. Next week: Put the project feature in practice from next week.

[markwhiting]

@neilthemathguy

1. What do you mean by all the accounts? I think this should only apply to github, right? What other accounts are you thinking about?
2. We can't do the owner thing because thats not completely specified in this proposal. As we discussed that should be a separate proposal that outlines the details of that mechanism. I think the other users should be fine.
3. Agreed.

[neilthemathguy]

Thanks.

What do you mean by all the accounts? I think this should only apply to github, right? What other accounts are you thinking about?

As per past discussions: accounts include GitHub, Wiki, Any other tools, Servers, Third party extensions

We can't do the owner thing because thats not completely specified in this proposal. As we discussed that should be a separate proposal that outlines the details of that mechanism. I think the other users should be fine.

Let's update the proposal in order to address this point, it is very important and fundamental to this issue. I don't see need for a separate proposal, it can be easily added as a part of the proposal. Once that is addressed, we can revisit the decision on consensus.

[markwhiting]

I don't know all the accounts but the list you made seems fine, so I think that sounds ok.

I'm fine for us to update the proposal around this but as we said last time we chatted, I think it will take a bit more discussion to work out the potential impacts and a complete process for execution. Perhaps we can brainstorm this a bit more, later in the week?