In article <[EMAIL PROTECTED]>, "Stephen McConnell" <[EMAIL PROTECTED]> wrote: >... > (a) Both Leo's and Berin's text took the position that if anything was > wrong with what we put in place - the auto fallback is ASF procedures - > I see faults in this - firstly - there are no ASF fallback procedure - > and secondly - the very notion of falling back implies a lack of > confidence in our own procedures. At the end of the day the _only_ > fallback is the board. Our responsibility is to get this right so that > there is not need to consider a fallback - and to go beyond that a state > as such - i.e. an Avalon PMC decision is definitive - subject only to a > Board decision to overrule.
There is no fallback. The PMC Chair is an officer of the corporation. The PMC is a group of people to assist in the work of the ASF, nominally under the direction of the Chair. If the PMC (and more precisely, the Chair) makes a decision, then it is DONE. The Chair has full authority to act on behalf of the ASF within the guidelines that the Board has provided to that person. If the Chair does something, then it sticks. There are only two ways "out": one is if it can be shown they are not acting within the capacity the Board outlined for that officer. For example, the Chair goes and deletes the jakarta-commons archive. That is out of scope. Deleting the avalon archive? In scope. Bad, but in scope. The second out is for the Board to make changes. I think you guys are misunderstanding the role of the Chair and the PMC here. The "rules" that you set up are simply a mechanism that the Chair sets up to define how the PMC will get the work done. But it doesn't have any real binding as far as the ASF is concerned. They are very internal. And the Chair is quite a bit "larger" than you're thinking about. The rules could simply be "give me input, and I'll decide everything." Sort of a benevolent dictator. Of course, the ASF community and the Board would prefer a consensus-based approach, but that is only set up in the manner prescribed by the Chair. I've said it before, and I'll try to reiterate. The formalism at the ASF mostly exists at the Board level and between it and the ASF officers (the PMC chairs, primarily). Most of the formality that we have to deal with is simply because we are a non-profit, public charity and have to obey certain rules. At the PMC level and below, informality is perfectly fine. The need for "voting rules" exist simply as an easy way to gauge the consensus, when it isn't readily apparent. > (b) The second concern is something more personal and I don't have > immediate recommendations - but the issue is something I imagine is of > concern to Pete just as it is to me. The issue is about "closure". Ok, Don't look to the Board for closure. I might even say that the PMC doesn't have to deal with closure. What *is* important, is the prevention of further problems. Part of the reason that Avalon was voted in as a PMC is to provide a better and "closer" structure to the problem, than the Jakarta PMC was able to provide. The Avalon PMC can watch over the community and can step in when problems arise. >... > If we > are faced with a similar situation - we have a responsibility to close > issues that are put before us. I recognize that this maybe something > that needs to be dealt with after sorting out basic voting policies - > but its something I consider to be very important and central to the > notion of the PMC acting responsibly in the face of difficult > situations. Why is a "voting policy" so hard? Copy httpd.apache.org/dev/guidelines.html or the Jakarta guidelines or something, and leave it at that. What more is needed here? Get past this. Move on and work with the code. If and when a problem comes up, then it can be solved. There isn't a need to worry about it right now. There is *nothing* that is unsolvable, and having "rules" ahead of time will probably not change things one way or another. It isn't like people sit around coding with the rules stuck to their monitor. Or that they consult them before posting to the list. Or that they read the minutae before committing. For the most part, they should be a completely invisible item that new committers should read a few times until they are familiar with them. But usually, the new committer will probably just go "yah yah" because she's been living within the community for a long while already, and implicitly understands what the rules are trying to describe [about how the community operates]. "rules" are simply a description of existing behavior rather than a proscription of future behavior. Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
