Dear Julian, Your feedback is very welcome and valuable as usual. Comments inlined below, but overall I thought I was proposing that seems to be in line with the Apache governance model. If there are specific issues, would love if you can point it out in general and I can go work on it.
> In general, it is expected that to maintain > > membership in the Committer group, the developer must be active in the > > project in the preceding 6-month period. > > Procedures to allow committers and PMC members to “go emeritus” do > exist[1] but in my opinion they are solving a non-problem. > Great. Sounds like this part is ok then. > > PMC members can commit code directly to the main repository, but are > > generally advised to open a PR and allow another Committer to close the > PR. > > The role of the PMC (actually PPMC while Quickstep is incubating) is > solely governance. PPMC members should not have more rights than committers > where it comes to code. We don’t want to create two tiers of committers. > Good point -- will remove this distinction. > > > A Contributor can become a Committer by getting support from at least two > > existing Committers. It is expected that a Contributor will have > > demonstrated proficiency in understanding and working with the core > engine > > to become part of the Committer group. > > Per Apache rules committers are appointed by achieving consensus > (typically a vote) in the PMC[2]. > Got it. I read [2] as being general guidelines but not binding. It is okay to do this by consensus too over email. > > The PMC meets at least annually. Meetings are announced at least two > weeks > > in advance on the project developer list. Any Committer is welcome to > > propose agenda items for the meeting. The PMC chair consults the overall > > PMC to finalize the agenda. The meeting agenda must be finalized two days > > before the meeting and communicated on the project developer list. Agenda > > items can include, but is not limited to, voting for changes to the PMC, > > changes to the Committers group, and changes to the community governance > > document. Only existing PMC members can vote on motions. For a motion to > > carry, a majority of the votes that are cast must be in favor of the > > motion. Ties are broken by the PMC Chair. Proxies are permitted, and must > > be communicated to the PMC Chair prior to the meeting. > > Per Apache, the PMC meets continually… via email. I suppose the PMC could > have an annual meeting, but business such as appointing members does not > have to wait for that. > Agreed. I worded this carefully to say "at least" ; limit on the upper-bound. So, I'm not seeing a conflict there. > Apache has a procedure for appointing members to the PMC[3]. You need to > follow this. > I did get this part wrong. Nice catch! I should really propose simply following the guidelines there. I was hoping there was some way for the existing PPMC to agree on a proposed new PPMC member before emailing bo...@apache.org. So, perhaps what I have could be applied to getting consensus on a proposal within the Quickstep PPMC and then making a formal proposal. > Jignesh, As I said in a previous email, it’s good that you are thinking > about governance. But we are going to be at odds until you read & > understand the existing Apache governance. I think you need to take the > time to do this before proposing alternatives. The Apache governance is > well established and is proven. And considerable parts of it are mandatory. > If the above largely covers it, I'll work on making another round over the next few days. Agreed Julian about your point about me not fully understanding the governance. It is somewhat complicated, and in some cases information is a bit scattered. I am still learning about the Apache way, and very much appreciate your detailed input. Cheers, Jignesh
