Review of roles.md

[CharliePoole]

This describes all the roles and responsibilities. It is primarily based on the oss-watch Meritocratic governance model and will eventually be a part of our main governance doc.

https://github.com/nunit/governance/blob/master/notes/roles.md

@nunit/core-team Please comment - this one has a lot of meat.

[rprouse]

For future docs, it might be easier to review them as pull requests. Then we can comment on individual lines.

Overall, very well written and in line with our original discussions, so no major changes on my part. Just a few comments and spelling fixes,

Contributors

• supporting helping new users...
• programming - seems redundant with fixing bugs and adding features below
• should we link to the mailing lists mentioned?

Committers

• Each process project maintains a review process
• Should we say something about being a committer is not an obligation and that the team understands that the level of commitment can vary over time?

Project Leads

• recommended to have at leas least one more in
• referring major questrions questions of direction

Core Team

• The Core Team will conduct a regular review of software each project (I understand what you mean, but I am unsure about the wording)
• Do we require a quorum for core team votes, especially the various 2/3 votes?
• Or, do we set a time limit on votes in case we cannot reach quorum so that absent members cannot stall the process?
• Do we need to mention that other votes are 50%?

Core Team Chair

• A bit of a mouthful 😄 Maybe Organization Lead?
• Does the chair's casting vote act as a tie breaker even if it is 50/50 with their vote?

[CharliePoole]

I'll do future docs as PRs and probably do away with the drafts folder in that case. For this one, I will keep on as I started, since it's simplest.

I'm making most of the suggested changes. Further notes...

• The issue tracker is different for each project, so I can't link. I just said "for each project"

• The parts about voting are a bit vague because I planned to have something more detailed in a separate document or elsewhere in the main governance doc.. I think I would leave it vague here since this is only a section of a document. We should add a reference when we know where the reference is located.

• I think Organization Lead could work. Let's see what others have to say.

• I took the tie-breaking language out of the oss-watch document. I think that what is meant is that a tie vote goes to the side that the chair has voted for. My preference is to have an odd number of people all the time.

[OsirisTerje]

Organization Lead sounds workable.

About the voting: I see you mention consensus. I think that should be the primary choice, and not voting. Voting should only be used if there are really a blocked situation. Everyone on the core team should be people that are willing to work in a consensus manner. I found this wiki article good https://en.wikipedia.org/wiki/Consensus_decision-making. I feel that is how we have been working, for the years I have been involved at least.

For committers you write that a committer have write access to "one or more repositories". That makes up for sub-divisions of committers, is that ok? If someone is a committer on one project, is the same person a contributor or user on others, or should the role as committer apply to the NUnit organisation as a whole. I am not sure on this. Also, being a committer means one has more responsibility, and thus also more authority. Persons with this level (and of course also core team members), will have the respect not to cross the lines (going into the wrong repo), so could we not then just trust them, so as to avoid sub-groups?

[ChrisMaddock]

Again, on the whole this looks good.

• Organization Lead is fine by me.
• Can we detail the responsibility for reviewing pull requests? This is a committers role, correct?
• Perhaps a note about triaging other users bug reports would also be good (contributors, I assume) - that's a big time sink we can get behind on.

I assume the lists weren't intended to be exhaustive - but these are two big tasks we can currently fall behind on. 🙂

New committers can be nominated by any existing committer and must be approved by the individual project lead and confirmed by the Core Team.

Is this what we want? For example, I don't especially follow the adapter project, and wouldn't have much idea who regular contributors were. I'd want to defer to the project lead here. Perhaps the Core Teams role is solely to nudge if potential committers are being missed? Or was this instead written with the view that the Core Team may wish to veto a committer's appointment, in exceptional circumstances?

[CharliePoole]

@OsirisTerje I agree that consensus is what we want, both for the Core Team and for individual projects. I'll try to make that clarer in the "Decision Making" doc.

I see the "NUnit Project" as a aggregating several individual projects, any of which make their decisions as they wish, at least within some limits we might set. So this documentation is primarily about how NUnit as a whole (the organization or community) makes decisions. For that reason, I assume that committer authority is only given for individual projects and is not generally global.

One of the main goals in restructuring the project as we have done was to enable the creation of subgroups. In my view, we need something like 20 people working on all of our projects, divided into the different areas. If we were to continue with a smal number of people, as we are now, then I would agree that separate authority in different areas probably doesn't make sense. As it now stands, we don't really have separate project managers doing releases and I think having them is a prerequisite for growth.

I don't think having people specialize in different areas means that we don't trust them. It's just a way to focus the available people on particular projects. Once someone is a committer, we have always been willing to grant committership on additional projects when needed.

[CharliePoole]

@ChrisMaddock

Review of pull requests seems much more detailed than what is in this snippet. As I said in the beginning, I'm trying to get pieces of things reviewed, building up to the whole. I was thinking of the process of source code changes as a separate document.

There is also a serious question: does the Core Team want to impose the same PR requirements on every project? Or should it be just core projects, leaving the others to set up their own policy. For example, I'm currently not following a two-committers rule on the gui project, because of it's pre-production status.

Regarding "confirmation" by the Core Team - I was working from a document that said the "PMC" appointed all committers. That seemed too centralized for us, so I had the project lead do it with "confirmation" by the Core Team. As you suggest, I was thinking that this would generally be approved, with only rare vetoes in exceptional cases. Can you suggest some better language?

[ChrisMaddock]

There is also a serious question: does the Core Team want to impose the same PR requirements on every project? Or should it be just core projects, leaving the others to set up their own policy.

The latter sounds sensible to me.

That seemed too centralized for us, so I had the project lead do it with "confirmation" by the Core Team. As you suggest, I was thinking that this would generally be approved, with only rare vetoes in exceptional cases. Can you suggest some better language?

How about:

"New committers can be nominated by any existing committer and must be appointed by the individual project lead and approved by the Core Team."

Maybe this is splitting hairs though. 🙂

[CharliePoole]

@ChrisMaddock Used your language

[rprouse]

Much of this repeats what others have said above, but weighing in 😄

About the voting: I see you mention consensus.

I agree that we should try to continue to work by consensus, but I think voting should be covered in case we can't reach consensus. Hopefully it will seldom come to that.

For committers you write that a committer have write access to "one or more repositories". That makes up for sub-divisions of committers, is that ok?

That is the way we do it now. If we lock down master on all repos, I would be okay with extending contributor access to all repos. It might encourage committers to branch out and help out with more projects and it would be easier to administer one large team.

Can we detail the responsibility for reviewing pull requests?

I would prefer to leave this to a decision for each project. We could have a document recommending procedures, but each repo is different. We could add reviewing pull requests as a responsibility of committers though.

[CharliePoole]

@rprouse The structure I'm thinking of for the docs...

governance.md with references to projects.md (already under review) decisions.md (containing stuff like consensus and voting) code??.md (general process for accepting code, including any CLA) I think I'll actually embed the text from roles.md in the main document.

IMO, at the point where we are now, our greater need is to get some folks to become more specialized, at least to the point where they are willing to serve as a project leader and take the load off you. If we give this approach a good shot and it fails, then I think the fallback is to become one big team once again.

I'll add reviewing PRs as a committer responsibility as well as something that contributors can do.