Re: Requesting clarification in ByLaw text.
On 22 Dec 2004, at 07:27, Greg Stein wrote: FWIW, I liked your phrase in another email about renaming the "PMC Bylaws" to something like "Standard Operating Rules" or somesuch. Tho my personal opinion is to just lose them and have one set of rules for all ASF PMCs. We haven't done that in the past because the idea has always been to let the PMCs figure out what is best for their community, rather than to the Board (i.e. the ASF) mandate a particular set of rules. +1 in addition, i suggest that communities be allowed documented deviations by consensus. in other words, the standard operating rules are there provided as defaults by the board by not mandated. individual communities with strong opinions or different needs would be allowed to agree and document deviations from them. IMHO this would offer the best of both worlds: new pmc's (or those just trying to discover a good model) would follow the standard operating procedures (by default) whereas any (healthy) pmc's who want to deviate from this model would be allowed to do this provided that these deviations are documented. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Requesting clarification in ByLaw text.
At 01:39 AM 12/22/2004, Niclas Hedhman wrote: >On Wednesday 22 December 2004 15:27, Greg Stein wrote: >> FWIW, I liked your phrase in another email about renaming the "PMC >> Bylaws" to something like "Standard Operating Rules" or somesuch. Tho >> my personal opinion is to just lose them and have one set of rules for >> all ASF PMCs. > >That would make *me* really happy and worthwhile, because until a few days >ago, I was under the impression that there were bearing to the "PMC Bylaws". > >I give you the ones I can find; > >http://ant.apache.org/bylaws.html >http://cocoon.apache.org/2.1/bylaws-addendum.html >http://gump.apache.org/bylaws.html >http://logging.apache.org/site/bylaws.html >http://struts.apache.org/bylaws.html >http://wiki.apache.org/excalibur/Bylaws In httpd we call such things 'Guidelines' and you can find them here; http://httpd.apache.org/dev/guidelines.html We used to have 'rules' but that was before the "Apache Group" (essentially, httpd project) evolved into the ASF corporate entity. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Requesting clarification in ByLaw text.
Greg Stein wrote: ... The HTTPD PMC never consults any "Bylaws". We don't really have them. We simply use the standard ASF voting rules used on any dev list. We know how to build consensus and we operate that way. There are *very* few cases where we call a vote to *force* a direction. Votes are used to examine whether consensus is present, rather than to make a decision. We had a long discussion on the PMC a few weeks ago where we stopped and called a vote. But that was mostly to try and figure out what the various opinions were -- to clarify things. The vote results didn't actually "stick". In the end, the group came up with a rough consensus and turned that over to Sander (the Chair) to take action with. Now, let me contrast that with behavior that I observed in the Avalon PMC. On many occasions, there were fractures in the consensus, so a vote was used to *force* a decision. "But we voted on it" was the refrain. Yah, great. The result wasn't a consensus, merely a vote result. With a true consensus, some few will agree to abide with the majority opinion. They know they're the odd person out, but respect the others and agree to back off. This didn't happen often in Avalon; the minority felt pushed around and disenfranchised and alienated. Eventually, they just left. The use of votes was a mechanism for forcing a direction. All that was needed was one more vote than the "other position", and people felt they had a mandate. Bleh. They just had a majority vote. Exactly. In fact our "voting" doc is called "Consensus Gauging through Voting". ^^^ ... > FWIW, I liked your phrase in another email about renaming the "PMC > Bylaws" to something like "Standard Operating Rules" or somesuch. Tho > my personal opinion is to just lose them and have one set of rules for > all ASF PMCs. We haven't done that in the past because the idea has > always been to let the PMCs figure out what is best for their > community, rather than to the Board (i.e. the ASF) mandate a > particular set of rules. At Forrest we decided to try and do the above, and David Crossley has been of great help in taking Stefano's and other Apache documents and putting them in a more coherent manner: http://www.apache.org/foundation/how-it-works.html http://www.apache.org/foundation/voting.html http://www.apache.org/dev/ (Trying to make these endless clarification and discussion threads into something more constructive) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Requesting clarification in ByLaw text.
On Wednesday 22 December 2004 15:27, Greg Stein wrote: > FWIW, I liked your phrase in another email about renaming the "PMC > Bylaws" to something like "Standard Operating Rules" or somesuch. Tho > my personal opinion is to just lose them and have one set of rules for > all ASF PMCs. That would make *me* really happy and worthwhile, because until a few days ago, I was under the impression that there were bearing to the "PMC Bylaws". I give you the ones I can find; http://ant.apache.org/bylaws.html http://cocoon.apache.org/2.1/bylaws-addendum.html http://gump.apache.org/bylaws.html http://logging.apache.org/site/bylaws.html http://struts.apache.org/bylaws.html http://wiki.apache.org/excalibur/Bylaws Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Requesting clarification in ByLaw text.
On Tue, Dec 21, 2004 at 08:48:59PM +0800, Niclas Hedhman wrote: >... > Now, section 6.3 in the ByLaws of the ASF doesn't rhyme entirely correctly > with the quotes from the IRC session. > > You said; The PMC is an artificial construct. > Section 6.3 forgets to mention that. In essence, the PMC is constructed by the Chair. The Chair defines how the PMC is gathered and its rules and policies. There is nothing in the ASF Bylaws that specify any of that stuff. Just that there will be a committee. The further connotation is that "it isn't real". To some extent, it really isn't since the Chair is free to change it as necessary. So. Take to the extreme, a PMC is ephemeral. But as I pointed out before, the Board has expectations of how a PMC is organized and run. If the Chair gets too wonky, or plays too loose with it, then there would be repercussions. My statement was merely an extrapolation to the extreme. Not a statement of the typical. > You said; Aaron IS the PMC. > Section 6.3 uses the wording "shall be primarily responsible for project(s) > managed by such committee" As I said in my other note, that phrase was from the point of view of the Board. The Board doesn't deal with the PMC as a whole. When we want to talk to the PMC, we talk to the Chair. > IANAL, and is not comfortable in trying to make the Section 6.3 clearer, but > I > beg those who a. understand the mechanics properly, b. capable of formulating > the language, c. has the authority to do so, to re-phrase into a more > accurate depictment of the PMC, its Chair vs its members. > > I mean, if the PMC is purely advisory, then write that. As mentioned above, when taken to the extreme, yes: it can be viewed as advisory. But that is not the *typical* situation. The typical is a consensus-run committee and the Chair is simply a normal voter. In healthy PMCs, you hardly ever notice that one of the people happens to have a funky "VP" behind his name. It really only surfaces when the Chair asks for assistance with putting together the quarterly reports to the Board. > This whole episode is also marred by "Project ByLaw", which I have been told > does not to exist (or do they? confusion!), yet is mentioned that the PMC is > tasked to establish them. Yah. It's a poor choice of wording since it leads to confusion with the ASF Bylaws. And it also connotes that they are the ultimate law, when (as Ken notes), they cannot actually countermand the directives of the Board or the restrictions of the ASF Bylaws. We have discussed on a number of occasions that we'd like to create a single set of "PMC Bylaws" which would apply to *all* PMCs, and then strike that text from the boilerplate TLP creation. Instead, we'd just have some docco on "here is how an ASF PMC normally operates". > And those established at Avalon seems partly being > contradictory to what Greg says (which I take as most authorative at this > juncture). I'm unclear on this part, so I'm not sure how to explain. By contradictory, do you mean their existence should not have happened? Assuming that was your point... no, they're fine. Many PMCs have explicit "Bylaws" which describe how the PMC operates. But there are a few issues with that: 1) as mentioned above, they are not the ultimate law 2) the term Bylaws can be confusing 3) in a properly functioning PMC, they are irrelevant (*) So their presence can be helpful to describe to newcomers how things work, but they need to be viewed in the proper context (and that description is typically lacking). (*) When I say irrelevant, let me describe a case in point: The HTTPD PMC never consults any "Bylaws". We don't really have them. We simply use the standard ASF voting rules used on any dev list. We know how to build consensus and we operate that way. There are *very* few cases where we call a vote to *force* a direction. Votes are used to examine whether consensus is present, rather than to make a decision. We had a long discussion on the PMC a few weeks ago where we stopped and called a vote. But that was mostly to try and figure out what the various opinions were -- to clarify things. The vote results didn't actually "stick". In the end, the group came up with a rough consensus and turned that over to Sander (the Chair) to take action with. Now, let me contrast that with behavior that I observed in the Avalon PMC. On many occasions, there were fractures in the consensus, so a vote was used to *force* a decision. "But we voted on it" was the refrain. Yah, great. The result wasn't a consensus, merely a vote result. With a true consensus, some few will agree to abide with the majority opinion. They know they're the odd person out, but respect the others and agree to back off. This didn't happen often in Avalon; the minority felt pushed around and disenfranchised and alienated. Eventually, they just left. The use of votes was a mechanism for forcing a direction. All tha
Re: Requesting clarification in ByLaw text.
On Tuesday 21 December 2004 20:48, Niclas Hedhman wrote: > This whole episode is also marred by "Project ByLaw", which I have been > told does not to exist (or do they? confusion!), yet is mentioned that the > PMC is Sorry, I missed a few words here. Should be; ... yet is mentioned in the Board Resolution forming Avalon, that the PMC is... -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Requesting clarification in ByLaw text.
On Tuesday 21 December 2004 17:03, Greg Stein wrote: > > (12:10:11) gstein: mcconnell: aaron *is* the PMC > > ((12:46:05) gstein: the members of the PMC is an artificial construct > > created by the Chair > You lost a lot of context there. Ok, agree, but I thought it being unnecessary to quote 71kB of IRC. ;o) And now I lost some more ;o) > And yes, the Chair defines the rules/procedures. And when they fail to > keep the project and community on track, then the Chair can change the > rules. Simple as that. > There have certainly been insinuations in this thread and others that > my positions or stances are "part of the problem." You're certainly > entitled to that point of view, but I'm similarly confident that I > have been acting in the best interests of the ASF in this matter, and > that I have the support of the Membership. Sure you have. You definately have *my* support (although not worth much, maybe a even negative worth) as Chairman of ASF. Now, section 6.3 in the ByLaws of the ASF doesn't rhyme entirely correctly with the quotes from the IRC session. You said; The PMC is an artificial construct. Section 6.3 forgets to mention that. You said; Aaron IS the PMC. Section 6.3 uses the wording "shall be primarily responsible for project(s) managed by such committee" IANAL, and is not comfortable in trying to make the Section 6.3 clearer, but I beg those who a. understand the mechanics properly, b. capable of formulating the language, c. has the authority to do so, to re-phrase into a more accurate depictment of the PMC, its Chair vs its members. I mean, if the PMC is purely advisory, then write that. This whole episode is also marred by "Project ByLaw", which I have been told does not to exist (or do they? confusion!), yet is mentioned that the PMC is tasked to establish them. And those established at Avalon seems partly being contradictory to what Greg says (which I take as most authorative at this juncture). Avalon bylaws are now no longer online, but let's look at an example of contradiction in the Excalibur TLP bylaws, passed by their PMC [1]; http://wiki.apache.org/excalibur/Bylaws Under 1.2.2.4 Project Management Committee, first paragraph, second sentence; The PMC is responsible to the board and the ASF for the management and oversight of the Apache Excalibur codebase. Well, apparently the PMC is not responsible and not authorative, only the PMC Chair. IMHO, these types of discrepancies are the true root of this thread. And instead of dismissing everything from my mouth at sight and being sick of me dragging this on, please take a moment and review my findings and move for a clarification of the PMC role (and the Chair), its responsibility and authority, and make that in writing to avoid any future misunderstandings elsewhere. And in the same go, ask the PMCs to review their "PMC Bylaws" (if they exist) whether they are in conflict with this clarified view. Cheers Niclas [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=698 -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
