I second Scott's point about there being some need for more intense consideration/voting on significant issues, and Richard's note that lazy consensus is not used for much in other PMCs is a cautionary one.
A couple of observations about CAS operations having been on the old style Steering Committe. Firstly, CAS committers are impressive and they and the community are extremely dedicated to the product. At times though, it seemed disagreements were never really resolved but worked around by the community in some pragmatic way when there was an absence of a lazy consensus. This too is effective in preventing the blocking of the work of committers but not really subject to any consistent, predictable rules. Another effect, when the Steering Committee used to meet and conflicts were in the air, was some expectation that the chair would somehow resolve a topical impasse. This was likely not the right expectation but was indicative that some formal escalation/resolution to conflicts was necessary. It just seems escalation to some mechanism beyond the lazy consensus is inevitable, though perhaps undesirable as a day-to-day committer obstacle. It would be a shame if expediency led to something less than optimal such an entirely tactical CAS roadmap. Just my two cents, but +1 for the Apache-style PMC, agree that the chair should be more strictly a board liaison/admin type, but believe CAS needs a more rationalized way of identifying "important" conflicts and triggering a more official resolution and in extraordinary cases, a strategic direction. Cheers, Brian On Fri, Jul 12, 2013 at 11:16 AM, Richard Frovarp <richard.frov...@ndsu.edu>wrote: > 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: > brianxsav...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/**display/JSG/cas-dev<http://www.ja-sig.org/wiki/display/JSG/cas-dev> > -- 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
