Re: Apache project bylaws
Reviving this thread. I've invited others to join in as well. As a reminder, the proposed changes are here: http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/%3cC e743d6a.14a96%25aha...@adobe.com%3e And my goal is not just to fix up the voting doc, but to try to define a default set of bylaws so projects don't have to, or have less to decide. -Alex On 10/4/13 11:25 AM, Doug Cutting cutt...@apache.org wrote: On Fri, Oct 4, 2013 at 9:55 AM, Alex Harui aha...@adobe.com wrote: Who is permitted to vote is, to some extent, a community-specific thing. However, the basic rule is that only PMC members have binding votes, and all others are either discouraged from voting (to keep the noise down) or else have their votes considered of an indicative or advisory nature only. I'd suggest dropping the bit about 'discouraged from voting' and replace 'advisory only' with simply 'advisory'. A non-PMC vote may be taken quite seriously or it might not be. The only points you need to make here is that non-PMC votes are not binding but are generally welcome. Unless otherwise specified by a project's bylaws, only [active members)(glossary.html#ActiveMembers) who have been active in the last 6 months may cast binding votes. A different definition of active member may also be set in a project's bylaws. I think that policy is less universal and I'd suggest not implying it was a default rule for all projects without bylaws. Some projects have periods of low activity and I'd expect votes of PMC members to still be considered valid even if they've not contributed for six months. For example, we want a low-activity project to be able to apply a few patches and make a release even if fewer than three PMC members were active in applying those patches over the last six months. My thinking here is that the definition of active includes other activities besides just applying changes to code so that even low-activity projects must have folks who count as active because they've at least filed board reports. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
OK, here is my next offering. The patch form is at [1] Some notes: -This offering has 3 new entries to glossary.html as well. -I was very tempted to move the Veto sections from Voting.html to Glossary and merge the Consensus Gauging through Silence section from Voting into Glossary. -I am also tempted to remove the empty section about Procedural Votes or Opinion Polls but I know you folks are looking for the minimum set of changes. -There are some sentences in Voting I'm not sure are accurate such as: 1) and all others are either discouraged from voting 2) procedural votes from developers and committers are sometimes considered binding... 3) Only votes by PMC members are considered binding on code-modification issues For #3, Can committers who are not PMC members have veto a code change? Thanks, -Alex [1] https://paste.apache.org/9uhY voting.mdtext Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Because one of the fundamental aspects of accomplishing things within the Apache framework is doing so by consensus, there obviously needs to be a way to tell whether it has been reached. This is done by voting. There are essentially five types of vote: 1. Code modifications (including voting to accept new code donations) 1. Package releases 1. Approving people (as Committer, PMC Member, PMC Chair) 1. Removing people (as Committer or PMC Member) 1. Procedural (including approval of project bylaws) Votes on procedural issues follow the common format of [majority approval](glossary.html#MajorityApproval) unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of [lazy consensus](#LazyConsensus) for a modifying factor.) Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a [veto](#Veto) , which cannot be overridden. Again, this model may be modified by a [lazy consensus](#LazyConsensus) declaration when the request for a vote is raised, but the full-stop nature of a negative vote is unchanged. Under normal (non-lazy consensus) conditions, the proposal requires three positive votes and no negative ones in order to pass; if it fails to garner the requisite amount of support, it doesn't -- and typically is either withdrawn, modified, or simply allowed to languish as an open issue until someone gets around to removing it. Votes on whether a package is ready to be released or not use yet a different mechanism: are there are least three binding votes in favour of the release? See more about this [below](#ReleaseVotes). Votes on approving people require [consensus approval](glossary.html#ConsensusApproval) approval. Votes on removing people require [consensus-but-one](glossary.html#ConsensusButOne). The voting process for adding people, removing people and procedural voting may be modified and further refined by project bylaws. If a project's bylaws do not specify an alternative voting process then the above process is assumed to apply. # Binding Votes # Who is permitted to vote is, to some extent, a community-specific thing. However, the basic rule is that only PMC members have binding votes, and all others are either discouraged from voting (to keep the noise down) or else have their votes considered of an indicative or advisory nature only. Unless otherwise specified by a project's bylaws, only [active members)(glossary.html#ActiveMembers) who have been active in the last 6 months may cast binding votes. A different definition of active member may also be set in a project's bylaws. That's the general rule. In actual fact, things tend to be a little looser, and procedural votes from developers and committers are sometimes considered binding if the voter has acquired enough merit and respect in the community. Only votes by PMC members are considered
Re: Apache project bylaws
IMO none of the new glossary entries are worth doing. Procedural votes are votes about bylaws and other rules which you will apply to self-govern, so they deserve an appropriate treatment. Discouraged from voting is perhaps too harsh a sentiment, what we want those people to know is their opinion carries no *formal* weight. Procedural votes are really reserved for PMC members, and it really doesn't make sense to comment that other voters sometimes hold binding votes here- that's something bylaws need to address if that sort of thing is desired. Code vetoes, or in fact vetoes of any kind, by default are reserved for PMC members, but again bylaws can change that. HTH On Oct 4, 2013, at 12:55 PM, Alex Harui aha...@adobe.com wrote: OK, here is my next offering. The patch form is at [1] Some notes: -This offering has 3 new entries to glossary.html as well. -I was very tempted to move the Veto sections from Voting.html to Glossary and merge the Consensus Gauging through Silence section from Voting into Glossary. -I am also tempted to remove the empty section about Procedural Votes or Opinion Polls but I know you folks are looking for the minimum set of changes. -There are some sentences in Voting I'm not sure are accurate such as: 1) and all others are either discouraged from voting 2) procedural votes from developers and committers are sometimes considered binding... 3) Only votes by PMC members are considered binding on code-modification issues For #3, Can committers who are not PMC members have veto a code change? Thanks, -Alex [1] https://paste.apache.org/9uhY voting.mdtext Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Because one of the fundamental aspects of accomplishing things within the Apache framework is doing so by consensus, there obviously needs to be a way to tell whether it has been reached. This is done by voting. There are essentially five types of vote: 1. Code modifications (including voting to accept new code donations) 1. Package releases 1. Approving people (as Committer, PMC Member, PMC Chair) 1. Removing people (as Committer or PMC Member) 1. Procedural (including approval of project bylaws) Votes on procedural issues follow the common format of [majority approval](glossary.html#MajorityApproval) unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of [lazy consensus](#LazyConsensus) for a modifying factor.) Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a [veto](#Veto) , which cannot be overridden. Again, this model may be modified by a [lazy consensus](#LazyConsensus) declaration when the request for a vote is raised, but the full-stop nature of a negative vote is unchanged. Under normal (non-lazy consensus) conditions, the proposal requires three positive votes and no negative ones in order to pass; if it fails to garner the requisite amount of support, it doesn't -- and typically is either withdrawn, modified, or simply allowed to languish as an open issue until someone gets around to removing it. Votes on whether a package is ready to be released or not use yet a different mechanism: are there are least three binding votes in favour of the release? See more about this [below](#ReleaseVotes). Votes on approving people require [consensus approval](glossary.html#ConsensusApproval) approval. Votes on removing people require [consensus-but-one](glossary.html#ConsensusButOne). The voting process for adding people, removing people and procedural voting may be modified and further refined by project bylaws. If a project's bylaws do not specify an alternative voting process then the above process is assumed to apply. # Binding Votes #
Re: Apache project bylaws
On Oct 3, 2013 12:52 PM, Joseph Schaefer joe_schae...@yahoo.com wrote: ... e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, Really, Joe? Why did you throw that in? I know what consensus voting is. I also know some PMCs allow vetoes when adding new members. That was the point of my prior email: you are right that committership is done by consensus across the ASF, but that doesn't strictly hold for PMC membership. I think Roy phrased it once as I am allowed to veto/refuse to work with that person. They are free to copy the codebase and establish a community of people willing to work with that person. Cheers, -g
Re: Apache project bylaws
Really, Greg? Can't you tell you're not using the same language I am, but I'm using the actual documentation? Please see http://www.apache.org/foundation/glossary#ConsensusApproval and see how it jives with what you are saying. Personnel votes are always subject to veto, even committership, when we're talking about the httpd project. On Oct 4, 2013, at 3:47 PM, Greg Stein gst...@gmail.com wrote: On Oct 3, 2013 12:52 PM, Joseph Schaefer joe_schae...@yahoo.com wrote: ... e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, Really, Joe? Why did you throw that in? I know what consensus voting is. I also know some PMCs allow vetoes when adding new members. That was the point of my prior email: you are right that committership is done by consensus across the ASF, but that doesn't strictly hold for PMC membership. I think Roy phrased it once as I am allowed to veto/refuse to work with that person. They are free to copy the codebase and establish a community of people willing to work with that person. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui aha...@adobe.com wrote: I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. I'm sure I haven't nailed it so feel free to comment. And I'm not quite sure how to do a table in mdtext. I'm off to sleep so I'll respond several hours from now. Thanks for reading... -Alex --- Updated voting.mdtext -- Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. At the Apache Software Foundation, two decisions must be made by a vote held on a project's mailing list. The two decisions are: 1. Code modifications, 1. Package releases Other decisions are commonly made via votes as well, but a project may draft by-laws or guidelines that describe variations to the voting processes described below. If a project does not draft by-laws or guidelines, it is assumed that any votes held to make any of the decisions listed below follow the processes described below. Many projects make the following decisions via voting: 1. Approving a new committer 1. Approving a new PMC member 1. Approving a new PMC Chair 1. Removing a committer 1. Removing a PMC member 1. Approving by-laws or guidelines or changes to by-laws or guidelines Many project by-laws and guidelines describe other decisions made via voting. Use of [lazy consensus](#LazyConsensus) is recommended for as many other decisions as possible. Here is a table of the default voting processes: table trthAction/ththApproval/ththDuration/th/tr trtdCode Modification/tdtd[lazy consensus](#LazyConsensus)/tdtd72 hours/td/tr trtdApprove Release/tdtd[majority](#Majority)/tdtd72 hours/td/tr trtdApprove New Committer/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr trtdApprove New PMC Member/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr trtdApprove New PMC Chair/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr trtdRemove Committer/tdtd[consensus-but-one](#ConsensusButOne)/tdtd72 hours/td/tr trtdRemove PMC Member/tdtd[consensus-but-one](#ConsensusButOne)/tdtd72 hours/td/tr trtdApprove/Change By-laws/Guidelines/tdtd[majority](#Majority)/tdtd72 hours/td/tr trtdApprove Donation/tdtd[consensus](#Consensus)/tdtd72 hours/td/tr # Binding Votes # Who is permitted to vote is, to some extent, a project-specific thing. However, the default rule is that for Code Modification, any committer's veto counts, but for all other decisions only PMC members have binding votes, and all others have their votes considered of an indicative or advisory nature only. By default, only active PMC members may cast votes. Project's can define their own definition of active, but the default definition is whether that member has sent an email on any Apache mailing list, made a change to any asset under Apache version control, or voted on any vote thread. This low bar is intended to cover mature projects that don't do much other than file quarterly reports. # Implications of Voting # In some cases and communities, the exercise of a vote carries some responsibilities that may not be immediately obvious. For example, in some cases a favourable vote carries the implied message 'I approve **and** I'm willing to help.' Also, an unfavourable vote may imply that 'I disapprove, but I have an alternative and will help with that alternative.' The tacit implications of voting should be spelt out in the community's guidelines.
Re: Apache project bylaws
On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting of the diff is messed up because of line wrapping by your email client. Please take the time to present such a costly-to-review patch in a way which accommodates your potential reviewers. I suggest posting a link to a persistent paste created using https://paste.apache.org. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/3/13 6:23 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be just words and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were right about the old version are retained and whether the things that were wrong have been removed, and new content appears to be right. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting of the diff is messed up because of line wrapping by your email client. Please take the time to present such a costly-to-review patch in a way which accommodates your potential reviewers. I suggest posting a link to a persistent paste created using https://paste.apache.org. And with the above disclaimer, instead of using paste.a.o, I propose to revise this document using CMS and/or SVN. That way we can track changes, and I can use color and
Re: Apache project bylaws
Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. On Oct 3, 2013, at 11:40 AM, Alex Harui aha...@adobe.com wrote: On 10/3/13 6:23 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be just words and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were right about the old version are retained and whether the things that were wrong have been removed, and new content appears to be right. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting of the diff is messed up because of line wrapping by your email client. Please take the time to present such a costly-to-review patch in a way which
Re: Apache project bylaws
For committership, that is typical. Most PMCs allow a veto for adding new members to the PMC. On Thu, Oct 3, 2013 at 10:48 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. On Oct 3, 2013, at 11:40 AM, Alex Harui aha...@adobe.com wrote: On 10/3/13 6:23 AM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui aha...@adobe.com wrote: On 10/2/13 12:58 PM, Marvin Humphrey mar...@rectangular.com wrote: Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. Well, small, incremental was hard to do given the significantly different information this document must now convey. I appreciate the labor you've put in, but what we have here is akin to a big patch on highly sensitive mission-critical code for which there are no tests. I hope we can find a less costly way to integrate your efforts. It is a big patch for sure, but I'm not sure I agree with equating it to code. It is probably always going to be just words and I'm not sure you can create tests. I think even laws don't have tests, they only have to survive the reviews of the approvers and are always subject to revision later. But hopefully the reviewers will think through whether the things they thought were right about the old version are retained and whether the things that were wrong have been removed, and new content appears to be right. I tried to keep as much as possible yet incorporate feedback from Doug and Roy. Even if it was wrong, people have been quoting from that document, referencing it and following its guidance for a long time. I'm quite irritated that something wrong has persisted for so long and has been used so many times as the basis for settling disputes. My take is that if that fundamental a document is wrong, something is dreadfully wrong with how hard-won wisdom gets handed down at the ASF. Let's step back for a moment and reassess what we're trying to accomplish. We're starting with a voting document which is apparently wrong and trying to make it quasi-authoritative. But when we're finished turd polishing, there will still be no boundaries demarcating where the authoritative stuff begins and ends. We have this problem with the Incubator website, too. It started off with buckets of poorly-thought-through text scooped out of mailing lists and dumped into version control. Years later, certain portions of it have been carefully wordsmithed or even negotiated under high heat; as a result, making a minor change has the potential to obliterate a great deal of other people's hard work. But from just looking at the surface, you can't tell what's garbage and what's crucial. Personally, I'm not eager to spend a lot of cycles negotiating large revisions to highly-utilized governance documentation under such a flawed regime. I'd rather that we limit ourselves to small tweaks, or if we're going to go all out, draw up a set of default bylaws which will in the future be set off from other documentation and subject to review-then-commit by some governing body charged with oversight. Some good points in there. I know you want to revise the incubator site and I wish you well on your efforts to do so because I agree it needs it., However I just want to change this one document, and it shouldn't require the restructuring of a site, so I want to separate the two efforts, although maybe this effort will influence yours. So how about this: I will go all out and rewrite this one document so it will demarcate what is authoritative and what isn't. And I will try to make it clear that the goal of the document is to define a set of default by-laws. And I will retain the entirety of the old document for historical reference. To do so, I will insert the rewrite at the beginning of the document after I get lazy consensus on the following text which will go at the very beginning. This document is under revision. The original can be found here (#link_to_original_further_down). All decision based on the original document remain valid and the original document remains valid until further notice. The text color of the original document has been changed to (brown) to help delineate the boundaries of the original content. All authoritative sections will be demarcated with: --this section is authoritative-- And end with: --end of authoritative section-- My understanding is that only the code-modification and release voting approval type is authoritative. Please correct me if I'm wrong. Below is my proposed version, and below it is the svn diff in case that makes it easier to see what changed. Most of the changes were made at the beginning. The formatting
Re: Apache project bylaws
The definitions are in a glossary somewhere, the more we denormalize the locations of our common understandings the harder it will be to maintain sanity over discussions. Projects don't need to be encouraged to write their own bylaws, most don't bother and that's proper. We don't need to spell every possible decision making process out in detail because they should have experienced the normal processes during incubation under competent mentorship. In other words I agree with Marvin that widespread changes to documents that have been widely referenced are not a good idea, no matter what the board happens to think today. Just clarify the actual issues before us, e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, so there's surely room for improvement. On Oct 3, 2013, at 12:44 PM, Alex Harui aha...@adobe.com wrote: On 10/3/13 8:48 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. Hmm. Maybe I'm reaching too far, but my hope was to put in this document a definition of consensus and a set of defaults for by-laws so that other new projects don't have as much if any work to do in defining their project-specific by-laws. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/3/13 8:48 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. Hmm. Maybe I'm reaching too far, but my hope was to put in this document a definition of consensus and a set of defaults for by-laws so that other new projects don't have as much if any work to do in defining their project-specific by-laws. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/3/13 9:51 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: The definitions are in a glossary somewhere, the more we denormalize the locations of our common understandings the harder it will be to maintain sanity over discussions. OK, found the glossary. I will try to leverage it more in the next revision. It will probably need to have consensus-but-one added to it. Projects don't need to be encouraged to write their own bylaws, most don't bother and that's proper. Unfortunately, new TLPs are all copying the same board resolution which dictates that we need to write bylaws. That's independent of this thread, but something that I also suggested changing. We don't need to spell every possible decision making process out in detail because they should have experienced the normal processes during incubation under competent mentorship. Well, maybe we got lucky but we got through incubation without any major conflicts about who should be added and didn't have to deal with removing anyone. I think there should be defaults for handling removals in the voting document. In other words I agree with Marvin that widespread changes to documents that have been widely referenced are not a good idea, no matter what the board happens to think today. Just clarify the actual issues before us, e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, so there's surely room for improvement. OK, I'll try again tonight. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
(Apologies if you get this twice. I'm having email issues) Doug, The thread on members@ was titled Committer Qualifications. I asked a question about the -1 vote on 9/7/13 and the reply I got was that committer voting does not have vetoes, and the document at [1] also seems to say that. The document at [1] also does not define consensus nor does it say that it must apply to committer votes. And, it might help to have a definition of consensus as definition 1b in [2] says that it does not require unanimity. [1] http://www.apache.org/foundation/voting.html [2] http://www.merriam-webster.com/dictionary/consensus Thanks, -Alex On 10/1/13 8:21 PM, Doug Cutting cutt...@apache.org wrote: Lots of people on this list are also on members@, and, so far, none have objected to my statements. If this continues, it would indicate a lack of controversy. Doug On Oct 1, 2013 7:36 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? I was informed by a member on Flex private and here [1] which you already responded to. Thanks, Justin 1. http://markmail.org/thread/chfagblj72cv7zrt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 11:13 PM, Alex Harui aha...@adobe.com wrote: The thread on members@ was titled Committer Qualifications. I asked a question about the -1 vote on 9/7/13 and the reply I got was that committer voting does not have vetoes, and the document at [1] also seems to say that. I followed up on that thread on members@, to get some clarity. This issue has come up before. I don't have time to search the archives now, but I recall that folks agreed then that the norm at Apache is consensus for committer additions. The mention of procedural votes on the voting page has been a source of confusion. I suspect it is meant to allude to release plans and the like. We should clarify that it isn't meant to refer to committer or PMC member votes, that those are generally subject to consensus votes. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi Doug, Sorry to be so picky, but my ultimate goal here is to save time for my project and all future graduating projects by avoiding as much thrashing on this kind of issue as possible. To me, agreeing on the norm is not the same as policy, especially policy that does not allow for exceptions. And again, to me, consensus != unanimity. And if it is policy then at least Struts is non-conforming: [1] Would this prior discussion also be on general@ or some other list? -Alex [1] http://struts.apache.org/dev/bylaws.html On 10/2/13 9:32 AM, Doug Cutting cutt...@apache.org wrote: On Tue, Oct 1, 2013 at 11:13 PM, Alex Harui aha...@adobe.com wrote: The thread on members@ was titled Committer Qualifications. I asked a question about the -1 vote on 9/7/13 and the reply I got was that committer voting does not have vetoes, and the document at [1] also seems to say that. I followed up on that thread on members@, to get some clarity. This issue has come up before. I don't have time to search the archives now, but I recall that folks agreed then that the norm at Apache is consensus for committer additions. The mention of procedural votes on the voting page has been a source of confusion. I suspect it is meant to allude to release plans and the like. We should clarify that it isn't meant to refer to committer or PMC member votes, that those are generally subject to consensus votes. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui aha...@adobe.com wrote: To me, agreeing on the norm is not the same as policy, especially policy that does not allow for exceptions. I agree. Establishing whether there is a norm is a useful first step. That's what I'm trying to take. Thus far I've seen noone disagree that consensus is most common for committer additions at Apache. I've also seen folks suggest that they prefer having norms than having explicit bylaws for their projects. I don't anticipate any policy being established as a result of this discussion, except perhaps better documenting what the assumed default is for projects that don't choose to have explicit bylaws. And again, to me, consensus != unanimity. This might be another case where better documentation would help. In my experience at Apache, consensus is equated with unanimity. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/2/13 10:09 AM, Doug Cutting cutt...@apache.org wrote: On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui aha...@adobe.com wrote: To me, agreeing on the norm is not the same as policy, especially policy that does not allow for exceptions. I agree. Establishing whether there is a norm is a useful first step. That's what I'm trying to take. Thus far I've seen noone disagree that consensus is most common for committer additions at Apache. I've also seen folks suggest that they prefer having norms than having explicit bylaws for their projects. I don't anticipate any policy being established as a result of this discussion, except perhaps better documenting what the assumed default is for projects that don't choose to have explicit bylaws. And again, to me, consensus != unanimity. This might be another case where better documentation would help. In my experience at Apache, consensus is equated with unanimity. In my tour of the internet since my last post and your reply, it does appear that most Apache-related information indicates that committer voting uses consensus and thus the Voting document [1] is out of date. I found this link as well [2]. I'd be tempted to replace the Voting document [1] with this [2], although I'm not sure I understand the difference between consensus and unanimous consensus. Your thoughts? [1] http://www.apache.org/foundation/voting.html [2] http://www.oss-watch.ac.uk/resources/meritocraticGovernanceVoting -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Wed, Oct 2, 2013 at 10:20 AM, Alex Harui aha...@adobe.com wrote: I'm not sure I understand the difference between consensus and unanimous consensus. Your thoughts? The difference seems to be the quorum requirement of 3 +1 votes in the case of consensus but not in unanimous consensus. They use unanimous consensus in that document only for removals. Removals at Apache are instead typically consensus-but-one (the person being removed) although some projects specify a 2/3 or 3/4 super-majority instead. Another discrepancy with standard Apache policy and that document is that they don't require 3 +1 votes for a release. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Oct 2, 2013, at 10:20 AM, Alex Harui wrote: On 10/2/13 10:09 AM, Doug Cutting cutt...@apache.org wrote: On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui aha...@adobe.com wrote: To me, agreeing on the norm is not the same as policy, especially policy that does not allow for exceptions. I agree. Establishing whether there is a norm is a useful first step. That's what I'm trying to take. Thus far I've seen noone disagree that consensus is most common for committer additions at Apache. I've also seen folks suggest that they prefer having norms than having explicit bylaws for their projects. I don't anticipate any policy being established as a result of this discussion, except perhaps better documenting what the assumed default is for projects that don't choose to have explicit bylaws. And again, to me, consensus != unanimity. This might be another case where better documentation would help. In my experience at Apache, consensus is equated with unanimity. In my tour of the internet since my last post and your reply, it does appear that most Apache-related information indicates that committer voting uses consensus and thus the Voting document [1] is out of date. It isn't out of date. It is just plain wrong. It does not reflect any of our projects, but rather presents an incomplete summary based on someone's personal experience. It is difficult to do better than that without having a universal set of project bylaws. Apache doesn't have a single set of project bylaws/guidelines because we want projects to be self-governing. Inherent in that notion of self-governing is that projects need to have the freedom to do some things differently based on the nature of the project or the particular set of individuals involved. By some things, I mean things that are not necessarily constrained by the ASF need to maintain corporate oversight (which is almost entirely encompassed by release votes and the procedure for naming someone to the PMC). Hence, we don't have a single policy for how or when to make someone a committer. That is supposed to be defined by the project. Most people just assume that there exists a magic set of bylaws that are adopted if a given project just doesn't care (like most don't care, until the shit hits the fan and it is too late). For those projects, we typically assume that they have adopted the HTTP Server Project Guidelines, since those were the originals: http://httpd.apache.org/dev/guidelines.html I found this link as well [2]. I'd be tempted to replace the Voting document [1] with this [2], although I'm not sure I understand the difference between consensus and unanimous consensus. Your thoughts? Consensus is that everyone who shares an opinion agrees to a common resolution (even if they do not personally prefer that resolution). Unanimity means that everyone present agrees (for a PMC discussing things in email, that means everyone listed on the roster must affirmatively agree). Hence, consensus decisions can be vetoed, as is clearly stated in the HTTP Server Project Guidelines, unless the project has decided to adopt some other set of bylaws. Roy [1] http://www.apache.org/foundation/voting.html [2] http://www.oss-watch.ac.uk/resources/meritocraticGovernanceVoting -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On 10/2/13 11:11 AM, Roy T. Fielding field...@gbiv.com wrote: On Oct 2, 2013, at 10:20 AM, Alex Harui wrote: On 10/2/13 10:09 AM, Doug Cutting cutt...@apache.org wrote: In my tour of the internet since my last post and your reply, it does appear that most Apache-related information indicates that committer voting uses consensus and thus the Voting document [1] is out of date. It isn't out of date. It is just plain wrong. It does not reflect any of our projects, but rather presents an incomplete summary based on someone's personal experience. I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? I'll try to get something out this evening. For me, it would have saved our project time to have [1] be more accurate and describe a set of default voting procedures in more detail. I'm also tempted to ask the board to approve a resolution to remove the requirement that graduating podlings create a set of by-laws, and waive the obligation for existing TLPs. It seem like it should be optional. Thanks, -Alex [1] http://www.apache.org/foundation/voting.html [2] http://httpd.apache.org/dev/guidelines.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Wed, Oct 2, 2013 at 11:11 AM, Roy T. Fielding field...@gbiv.com wrote: It isn't out of date. It is just plain wrong. It does not reflect any of our projects, but rather presents an incomplete summary based on someone's personal experience. It is difficult to do better than that without having a universal set of project bylaws. I'm not satisfied with that. Our documentation does not have to be as bad as it is. Having to trawl through the mailing list archives every few years to obtain clarification and re-educate a continuously evolving community is not scaling with time as the foundation grows and the activity of the early participants slowly wanes. Here are some ways which we might improve our docs: * Policy documents should be cleanly set apart from other documentation. * Policy documents should be review-then-commit. * Policy documents should use a more formal rhetorical mode than the conversational FAQ style which predominates at the ASF. Perhaps a pilot project to improve the Incubator's docs along those lines is in order, which, if successful, might serve as a template for improving docs at the foundation level. I volunteer to take point. Apache doesn't have a single set of project bylaws/guidelines because we want projects to be self-governing. Inherent in that notion of self-governing is that projects need to have the freedom to do some things differently based on the nature of the project or the particular set of individuals involved. By some things, I mean things that are not necessarily constrained by the ASF need to maintain corporate oversight (which is almost entirely encompassed by release votes and the procedure for naming someone to the PMC). Hence, we don't have a single policy for how or when to make someone a committer. That is supposed to be defined by the project. Most people just assume that there exists a magic set of bylaws that are adopted if a given project just doesn't care (like most don't care, until the shit hits the fan and it is too late). For those projects, we typically assume that they have adopted the HTTP Server Project Guidelines, since those were the originals: http://httpd.apache.org/dev/guidelines.html A fair bit of that is news to me -- and I'm the Incubator PMC chair and a voracious consumer of documentation. :( I'm not a fan of forcing projects to draft bylaws (most will do it badly because they have not had the experience of the Apache group which coalesced around the HTTPD project) but that's beside the point. I submit that a more effective mechanism for bequeathing Apache culture is needed. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui aha...@adobe.com wrote: I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. It would be so nice if we could write unit tests for governance docs to make sure that as they evolve they still solve all the old problems they were intended to address. I'm also tempted to ask the board to approve a resolution to remove the requirement that graduating podlings create a set of by-laws, and waive the obligation for existing TLPs. It seem like it should be optional. +1 for moving towards a situation where podlings MAY rather than MUST write bylaws. Dunno if a Board resolution is needed. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Wed, Oct 2, 2013 at 11:58 PM, Marvin Humphrey mar...@rectangular.comwrote: On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui aha...@adobe.com wrote: I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. It would be so nice if we could write unit tests for governance docs to make sure that as they evolve they still solve all the old problems they were intended to address. That's a really interesting perspective: governance rules as code, that can be unit tested. Heh I like that. -- Regards, -- Alex
Re: Apache project bylaws
On 2 October 2013 21:34, Alex Karasulu akaras...@apache.org wrote: On Wed, Oct 2, 2013 at 11:58 PM, Marvin Humphrey mar...@rectangular.comwrote: On Wed, Oct 2, 2013 at 11:35 AM, Alex Harui aha...@adobe.com wrote: I would like to propose a rewrite of [1] by borrowing heavily from [2] but making sure to emphasize that projects are allowed to have different rules for all of them (or is the code-commit veto required for all projects). Any objections to me trying to do that? Rather than a rewrite, I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. It would be so nice if we could write unit tests for governance docs to make sure that as they evolve they still solve all the old problems they were intended to address. That's a really interesting perspective: governance rules as code, that can be unit tested. Heh I like that. And how does one test that code is working correctly? One of the most important tests is to check it against the functional specification. In the case of governance docs, I think the functional spec. is a list of what the rules are intended to achieve. This information should be part of the document. Knowing what the rules are intended to achieve can help resolve ambiguities in the rules. -- Regards, -- Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Wed, Oct 2, 2013 at 3:30 PM, sebb seb...@gmail.com wrote: That's a really interesting perspective: governance rules as code, that can be unit tested. Heh I like that. And how does one test that code is working correctly? http://en.wikipedia.org/wiki/Cyc 30 years and going strong! Thanks, Roman. P.S. Sorry, couldn't resist ;-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc updated to mention this. Jordan Zimmerman On Sep 30, 2013, at 9:21 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I reckon that this is one of the initial steps of becoming a top-level project (TLP). See the board resolution that created your TLP: hereby is tasked with the creation of a set of bylaws to ... Thanks for clearing that up. Yes it was mentioned in the resolution, we should get to it then. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 7:50 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc updated to mention this. I hope that most projects won't bother. We need rules because we need a framework to resolve disagreements, but bylaws are really hard to get right and every little flaw is an opportunity to waste time arguing over legislative minutia. Projects which inherit as many well-exercised rules as possible from the foundation rather than creating their own rules ex nihilo get to spend less time debugging legalese. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
+1 to Marvin's I hope that most projects won't bother although there needs to be something a little more than a blank piece of paper. The best approach, IMHO, is to simply make it official that the project adopts the same byelaws as project x, y or z. Pick an established project that has a minimal set of stable byelaws and go on from there. Some projects like to refer to the original project pages, others make a local copy. Both approaches have their advantages. The important thing to note is that, in my experience there is very little that changes from one project to the next given that we try to minimize the number of rules we wrap a project in. Probably the only item I see regular disagreement between projects is how much merit is needed for committership and then PMC membership but even this should not be codified into the byelaws since projects tend to change the height of the barrier over time. All we need is a way to decide if someone is a committer/PMC member. Ross Ross Gardler (@rgardler) Senior Technology Evangelist Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation On 1 October 2013 08:13, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Oct 1, 2013 at 7:50 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Wow. I missed that. I'll work omit for Curator. I'd like to see the grad doc updated to mention this. I hope that most projects won't bother. We need rules because we need a framework to resolve disagreements, but bylaws are really hard to get right and every little flaw is an opportunity to waste time arguing over legislative minutia. Projects which inherit as many well-exercised rules as possible from the foundation rather than creating their own rules ex nihilo get to spend less time debugging legalese. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 5:28 PM, Ross Gardler rgard...@opendirective.com wrote: +1 to Marvin's I hope that most projects won't bother although there needs to be something a little more than a blank piece of paper. The best approach, IMHO, is to simply make it official that the project adopts the same byelaws as project x, y or z. Pick an established project that has a minimal set of stable byelaws and go on from there. Some projects like to refer to the original project pages, others make a local copy. Both approaches have their advantages. At Wicket we didn't bother to pick bylaws and from what I have seen in other communities we are better for it. Graduation from the incubator is a testament that the community acts as a meritocracy, and the bylaws of the foundation should be good for all graduated projects. As a community I think that Wicket developers never even bothered to look at the bylaws and just follow the established processes and guidances that trickle down from board@. Looking at httpd, they don't have explicit bylaws either–my google fu did not unearth any document at httpd.apache.org that constitutes bylaws. Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 8:59 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: At Wicket we didn't bother to pick bylaws and from what I have seen in other communities we are better for it. A huge +1 to that! Apache Bigtop falls into the very same category -- we'll get real bylaws when we really need them (hopefully never ;-)). Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, Thanks for the feedback, it's interesting to see that some project don't have bylaws. The whole reason this come about is because it's unclear what voting rules are the default when voting someone in as committer. See [1] (consensus) and [2] (majority). If -1 is a veto or not is sort of important thing to know, and which voting system is used actually changes how people vote. To solve any potential disputes bylaws are perhaps not required but the project at least needs to reach consensus on what voting system should be used. Just before or after graduation would be a good time to do this IMO. After looking at other project bylaws I also realised that we were missing/not discussed a few other reasonably important things like the term of the chair. Perhaps the option of having a boilerplate set of bylaws (taken from an existing project ) could be the default on graduation and then each project make their own by voting to modify them? Thanks, Justin 1. http://community.apache.org/newcommitter.html 2. http://www.apache.org/foundation/voting.html
Re: Apache project bylaws
Martijn Dashorst wrote: On Tue, Oct 1, 2013 at 5:28 PM, Ross Gardler rgard...@opendirective.com wrote: +1 to Marvin's I hope that most projects won't bother although there needs to be something a little more than a blank piece of paper. The best approach, IMHO, is to simply make it official that the project adopts the same byelaws as project x, y or z. Pick an established project that has a minimal set of stable byelaws and go on from there. Some projects like to refer to the original project pages, others make a local copy. Both approaches have their advantages. At Wicket we didn't bother to pick bylaws and from what I have seen in other communities we are better for it. Graduation from the incubator is a testament that the community acts as a meritocracy, and the bylaws of the foundation should be good for all graduated projects. As a community I think that Wicket developers never even bothered to look at the bylaws and just follow the established processes and guidances that trickle down from board@. Looking at httpd, they don't have explicit bylaws either–my google fu did not unearth any document at httpd.apache.org that constitutes bylaws. Many project call them guidelines. http://httpd.apache.org/dev/guidelines.html -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Tue, Oct 1, 2013 at 3:34 PM, Justin Mclean justinmcl...@gmail.com wrote: The whole reason this come about is because it's unclear what voting rules are the default when voting someone in as committer. See [1] (consensus) and [2] (majority). If -1 is a veto or not is sort of important thing to know, and which voting system is used actually changes how people vote. The default at Apache is that committers and PMC members are added by consensus. In nearly every project code changes are also by consensus while releases require 3 +1 votes from PMC members and more +1 votes than -1 votes. Projects that diverge from these should perhaps document that somewhere, but projects that conform to these probably don't need to. I see no discrepancy between the documents you cite. The first says that committer votes are by consensus, the second says that procedural votes are by majority, but doesn't define procedural and there's no implication that it includes committer votes. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, I see no discrepancy between the documents you cite. The first says that committer votes are by consensus, the second says that procedural votes are by majority, but doesn't define procedural and there's no implication that it includes committer votes. There was conversation on members@ in the last couple of days (which I'm unable to view) that came to the opposite conclusion, so there's some confusion/differing opinion on the matter. Context is that I was under the assumption that consensus was required to vote a committer in, other PMC members thought otherwise or were unsure. On looking into it, I found it does vary from project to project and that it didn't seem to be defined clearly anywhere if your project doesn't have bylaws/guidelines. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? Doug On Oct 1, 2013 6:06 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I see no discrepancy between the documents you cite. The first says that committer votes are by consensus, the second says that procedural votes are by majority, but doesn't define procedural and there's no implication that it includes committer votes. There was conversation on members@ in the last couple of days (which I'm unable to view) that came to the opposite conclusion, so there's some confusion/differing opinion on the matter. Context is that I was under the assumption that consensus was required to vote a committer in, other PMC members thought otherwise or were unsure. On looking into it, I found it does vary from project to project and that it didn't seem to be defined clearly anywhere if your project doesn't have bylaws/guidelines. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? I was informed by a member on Flex private and here [1] which you already responded to. Thanks, Justin 1. http://markmail.org/thread/chfagblj72cv7zrt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Lots of people on this list are also on members@, and, so far, none have objected to my statements. If this continues, it would indicate a lack of controversy. Doug On Oct 1, 2013 7:36 PM, Justin Mclean justinmcl...@gmail.com wrote: Hi, I don't find the discussion on members@ that comes to this conclusion. If you cannot see members@ how do you know this? I was informed by a member on Flex private and here [1] which you already responded to. Thanks, Justin 1. http://markmail.org/thread/chfagblj72cv7zrt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Apache project bylaws
Hi, Looks like one of the things that fell between the cracks when Apache Flex become a top level project was drafting up and accepting a set of bylaws. I see nothing about bylaws on the incubator website, including here [1] where I would expect it to be. Should the process on this page be updated? Are bylaws optional or should they be a required part of graduation? Thanks, Justin 1. http://incubator.apache.org/guides/graduation.html PS We're in the process of putting our bylaws together here. Still in very early draft form, suggestions and/or advice is welcome. https://cwiki.apache.org/confluence/display/FLEX/Draft+Bylaws - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Justin Mclean wrote: Hi, Looks like one of the things that fell between the cracks when Apache Flex become a top level project was drafting up and accepting a set of bylaws. I see nothing about bylaws on the incubator website, including here [1] where I would expect it to be. Should the process on this page be updated? Are bylaws optional or should they be a required part of graduation? I reckon that this is one of the initial steps of becoming a top-level project (TLP). See the board resolution that created your TLP: hereby is tasked with the creation of a set of bylaws to ... Review/adopt/adapt the bylaws of other projects that have gone before you. I reckon that it is beyond the Incubator. Yes the docs should mention that future task. -David Thanks, Justin 1. http://incubator.apache.org/guides/graduation.html PS We're in the process of putting our bylaws together here. Still in very early draft form, suggestions and/or advice is welcome. https://cwiki.apache.org/confluence/display/FLEX/Draft+Bylaws - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Hi, I reckon that this is one of the initial steps of becoming a top-level project (TLP). See the board resolution that created your TLP: hereby is tasked with the creation of a set of bylaws to ... Thanks for clearing that up. Yes it was mentioned in the resolution, we should get to it then. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
