quickstep-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: 5 things
Date Wed, 03 Aug 2016 21:33:42 GMT
See below, comments on specific points.

> On Aug 3, 2016, at 1:35 PM, J Patel <jmp.quickstep@gmail.com> wrote:
> All: Would love to hear your thoughts on a release. I'd like to propose mid
> to late November, which likely works out best given the semester cadence
> (yeah -- I know we are far skewed in the Committer to that, at least for
> now).

November seems a very long way off. Remember, a release is a good way to attract contributors,
and does not need to be “perfect” or a big splash in terms of marketing.

> 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.

> 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.

> 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

> 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.

Apache has a procedure for appointing members to the PMC[3]. You need to follow this.

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.


[1] http://www.apache.org/dev/pmc.html#pmc-removal <http://www.apache.org/dev/pmc.html#pmc-removal>

[2] http://www.apache.org/dev/pmc.html#newcommitter <http://www.apache.org/dev/pmc.html#newcommitter>

[3] http://www.apache.org/dev/pmc.html#newpmc <http://www.apache.org/dev/pmc.html#newpmc>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message