Update Governance and Contributing doc

[magdmartin]

See discussion in #2292

[thadguidry]

I see the following usage of the GitHub group

* Admin = Advisory Committee

* Contributor =  Org member Contributors

* Maintainers = currently not used.

* Outside Collaborators =  used for Weblate integration

I think we need to completely remove the mention of Advisory Committee from GitHub operations.
I think what we are really trying to frame up inside the Governance document is that:

• The role Admin on GitHub is a privileged role
• We want to have a documented decision process for voting folks into that Admin role
• In general, I think we want to say something like other projects do (take a look at the entire page for the Rust Compiler Team or Node.js for a good guideline):

I really like this note from Rustc Compiler Team:

Membership is both a recognition but also an obligation: compiler team members are generally expected to help with upkeep as well as doing reviews and other work.

I think something like this should be added somewhere:

• Individuals identified by the OpenRefine Steering/Advisory Committee who have made significant and valuable contributions to OpenRefine and its design may be added to the Admin team or Core Contributors team and given commit access to the project.

Furthermore, I personally really like the activities that Node.js lists and that we could borrow from

Activities taken into consideration include (but are not limited to) the quality of:

code commits and pull requests
documentation commits and pull requests
comments on issues and pull requests
contributions to the Node.js website
assistance provided to end users and novice contributors
participation in Working Groups
other participation in the wider Node.js community

If individuals making valuable contributions do not believe they have been considered for commit access, they may log an issue or contact a TSC (Technical Steering Committee) member directly.

[magdmartin]

ping @OpenRefine/contributors for your feedback on this draft

[wetneb]

Thanks for updating this. I agree there are still open questions about how we renew the list of people in each of those categories. We need to have discussions about this on the mailing lists and ask around for advice (for instance by looking at how it is done in other CS&S projects).

At the moment, only GitHub users who are in the admin group of the OpenRefine org can approve PRs and merge them. So as things stand this group should probably be mentioned in this document (and we need to think more about how people get in and out of this group).

Currently we try to invite contributors to the organization pretty early on, but that does not give them a lot of rights on the project though, they can essentially only tag issues (and wear an OpenRefine badge on their profile, which I guess adds some recognition). We need to think about how to make them progress to other responsibilities later on.

For this PR, I think we need to decide whether the PR should:

• update this document to reflect the current gouvernance, with all the holes we currently have in it (how do we elect people to positions?). In this case we should replace the // TO DO by formulations that are a bit cleaner (making it clear that we want to change them soon).
• or aim to only merge this once we are satisfied by the gouvernance model it describes. That would be nicer, but might take longer.

[wetneb]

Suggested change

	How to become an OpenRefine contributors? You will find more details in our [contributing guideline](https://github.com/OpenRefine/OpenRefine/blob/master/CONTRIBUTING.md)
	How to become an OpenRefine contributor? You will find more details in our [contributing guideline](https://github.com/OpenRefine/OpenRefine/blob/master/CONTRIBUTING.md)

[wetneb]

All contributors, regardless of their status, should submit pull requests in the vast majority of cases. At the moment, organization members do not have rights to commit to master directly - only admins can do that, and they should only do it in very rare cases (uncontroversial bureaucratic changes).

[tfmorris]

Yes, agreed. Please update to match wetneb's comment about the current practice

[wetneb]

This is still not clear enough but I'll open another PR to get this right.

[tfmorris]

The concept of "guest contributor" doesn't make much sense to me. I see basically two levels: contributors & committers. Admin should be separate from code-related stuff and small, with just a few day-to-day admins and a failsafe backup admin like CS&S.

Github has a much more fine grained permission structure than it did originally, so we should make use of those finegrained permissions to allow a bigger group of committers, for those who have demonstrated merit, while still keeping the list of people who can delete/rename repos and do other destructive things small.

As an aside, since I'm an organization owner, I have admin privs even though I'm not part of of the admins team. I guess I can add myself to make that more transparent.

[magdmartin]

I think it will more effective to discuss and resolve them in a call. Who would like to participate ? I think it would be more effective to discuss proposed changes in a call. I created a doodle to gather availability (between Jan 25 and 30 2021) https://doodle.com/poll/zisrtcbqpa7e6ggk?utm_source=poll&utm_medium=link

…

On Tue., Nov. 3, 2020, 1:03 p.m. Tom Morris, ***@***.***> wrote: The concept of "guest contributor" doesn't make much sense to me. I see basically two levels: contributors & committers. Admin should be separate from code-related stuff and small, with just a few day-to-day admins and a failsafe backup admin like CS&S. Github has a much more fine grained permission structure than it did originally, so we should make use of those finegrained permissions to allow a bigger group of committers, for those who have demonstrated merit, while still keeping the list of people who can delete/rename repos and do other destructive things small. As an aside, since I'm an organization owner, I have admin privs even though I'm not part of of the admins team. I guess I can add myself to make that more transparent. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATYHEAQXSM6TIHPHQZKES3SOBAYRANCNFSM4RUQW46Q> .

[magdmartin]

I will close the doodle pool in 3h from now. *--* *Martin Magdinier* +1 (514) 559 4563 On Fri, Jan 22, 2021 at 4:46 PM Martin Magdinier <[email protected]> wrote:

…

I think it will more effective to discuss and resolve them in a call. Who would like to participate ? I think it would be more effective to discuss proposed changes in a call. I created a doodle to gather availability (between Jan 25 and 30 2021) https://doodle.com/poll/zisrtcbqpa7e6ggk?utm_source=poll&utm_medium=link On Tue., Nov. 3, 2020, 1:03 p.m. Tom Morris, ***@***.***> wrote: > The concept of "guest contributor" doesn't make much sense to me. I see > basically two levels: contributors & committers. Admin should be separate > from code-related stuff and small, with just a few day-to-day admins and a > failsafe backup admin like CS&S. > > Github has a much more fine grained permission structure than it did > originally, so we should make use of those finegrained permissions to allow > a bigger group of committers, for those who have demonstrated merit, while > still keeping the list of people who can delete/rename repos and do other > destructive things small. > > As an aside, since I'm an organization owner, I have admin privs even > though I'm not part of of the admins team. I guess I can add myself to > make that more transparent. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#3198 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AATYHEAQXSM6TIHPHQZKES3SOBAYRANCNFSM4RUQW46Q> > . >

[magdmartin]

The call is scheduled for Wed Jan 27 at 5PM UTC. You can join using this link: https://meet.google.com/fnn-zgra-ado *--* *Martin Magdinier* +1 (514) 559 4563 On Mon, Jan 25, 2021 at 2:34 PM Martin Magdinier <[email protected]> wrote:

…

I will close the doodle pool in 3h from now. *--* *Martin Magdinier* +1 (514) 559 4563 On Fri, Jan 22, 2021 at 4:46 PM Martin Magdinier < ***@***.***> wrote: > I think it will more effective to discuss and resolve them in a call. Who > would like to participate ? > > I think it would be more effective to discuss proposed changes in a call. > I created a doodle to gather availability (between Jan 25 and 30 2021) > https://doodle.com/poll/zisrtcbqpa7e6ggk?utm_source=poll&utm_medium=link > > > On Tue., Nov. 3, 2020, 1:03 p.m. Tom Morris, ***@***.***> > wrote: > >> The concept of "guest contributor" doesn't make much sense to me. I see >> basically two levels: contributors & committers. Admin should be separate >> from code-related stuff and small, with just a few day-to-day admins and a >> failsafe backup admin like CS&S. >> >> Github has a much more fine grained permission structure than it did >> originally, so we should make use of those finegrained permissions to allow >> a bigger group of committers, for those who have demonstrated merit, while >> still keeping the list of people who can delete/rename repos and do other >> destructive things small. >> >> As an aside, since I'm an organization owner, I have admin privs even >> though I'm not part of of the admins team. I guess I can add myself to >> make that more transparent. >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <#3198 (comment)>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AATYHEAQXSM6TIHPHQZKES3SOBAYRANCNFSM4RUQW46Q> >> . >> >

[magdmartin]

I updated the document with today's discussion.

Next:

• Define how we are part of the advisory committee
• Define how we name the release manager
• Clarify who is Github owner how they are added/removed.
• Update the GitHub permission and especially the team/contributors to reflect this document

[wetneb]

I will open a follow-up PR to tidy up a few things, but for now this is a clear improvement over the previous state of this document, so let's get this finally merged.