On 07/11/2013 08:14 AM, Marvin S. Addison wrote:
I'm a PMC chair, on two PMCs, and a member at the ASF, so I figured I'd
chime in.
I sincerely appreciate your thoughtful feedback.
It depends on the PMC, and what is being voted on. Most of the PMCs I'm
familiar with don't use lazy consensus for much.
Noted. It's simply a fact that the CAS project has worked on lazy
consensus for almost all decision making, both in development and
project governance. I know that kind of voting has risks, but the
simplicity and adherence to our current practice make it a net benefit.
Certainly. Do whatever works best for this project. Each way certainly
has its pros and cons.
There are a couple of other things I see below that differ from ASF
PMCs. While the PMC chair is appointed by the board, it generally isn't
a board member (unless the PMC is in trouble). The PMC generally
recommends their chair from amongst their membership, and in a vast
majority of cases the board accepts the recommendation.
This makes more sense and it's actually a better fit for the project. I
found the Apache documentation on the ASF and PMCs fairly confusing, so
this is clarifying.
Well it's one of those things that is probably more tradition than
anything else. The board has the authority to appoint a new PMC head of
their choosing at anytime. However, the board likes to let the PMCs self
govern, so they generally don't interfere. If the PMC is dysfunctional,
they will step in an appoint their own head (usually one of them) to get
things going again. That rarely happens. The almost always accept the
person nominated by the PMC. I should also point out that the PMC chair
does not have authority over the PMC. As chair I am responsible as the
liason between the PMC and the board (and infra as well), it let me on
the board email list without being a member (any member can be on the
board list if they want, but PMC/committers can't unless they are PMC
chair), some extra infrastructure permissions to manage committers
access, and I think technically corporate legal protection for me while
carrying out those tasks.
The other piece to point out is that voting happens via email, and
generally must take place over several days. If it didn't happen on
email, it didn't happen.
I will be sure to explicitly state that in the final proposal. We
loosely follow this, but it would be helpful to formalize. Also, I will
make a note about suggested time frames for votes. I'm familiar with the
72h period and that sounds reasonable.
I think it's usually worded as 72h minimum, so that the person calling
the vote can specify a longer time period. You can then adjust longer to
help accommodate for holidays or conferences a lot of people are at, or
even time of year. If I were to call a vote on a Friday, I'd probably
make it last until the following Tuesday, which exceeds 72h.
It's up to the PMC to
decide if committer == PMC. However, a PMC can unilaterally make a
committer, they require the board's approval for a new PMC member.
I'm proposing that a committer _is_ a PMC member for simplicity and
since it reflects project history where at times multiple committers
were on the steering committee. In any case we should note the
difference between an Apache PMC that requires board approval for
membership changes and what we're proposing here, which is a
self-sufficient group that controls its membership by election (other
than chair, which requires board approval).
M
Sounds good. Like I said, it's up to the PMC at the ASF. At the ASF the
PMC is the "owner" of the project. So some make committer != PMC so that
they can bring contributors in earlier, without them having an official
say in the direction of the project (releases, new people, etc). Some
would say you should consider make a contributor a committer after 3 of
their patches have been applied. Of course people can be made a
committer / PMC / member without ever committing code. Documentation,
support, testing, etc can all lead to committer / PMC / member.
So there is a lot of variability in all of this between the different
PMCs at the ASF. Overall, I do think it is a successful model to follow.
Your adaptations certainly make sense for this community and foundation.
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
