You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Justin Mclean <ju...@classsoftware.com> on 2018/09/10 03:57:54 UTC
Default project guidelines
Hi,
There been some discussion on bylaws/guidelines recently and it was suggest that the IPMC document a default set for projects to use. So I’ve come up with a default set of guidelines [1] using links to existing content when I could find it. I tried to make it as minimal as possible. Feedback and edits welcome.
Most of the project guidelines and bylaws include 2/3 Majority or even 2/3 lazy major for removal of PMC members or committers, but given that these terms are not defined in the Glossary I just went with consensus approval, there are (very) rare events and only the board can remove a PMC member.
There is a lot of confusion if the approval should be censuses or majority for adding or removing people in the various projects guidelines/bylaws. Consensus seem more common so I went with that - that may be wrong.
One other surprising thing is that most allow committers to veto code changes, strictly speaking I think it’s only PMC members who can do that but I can’t see that causing an issue as good reasons are required for a valid veto.
Thanks,
Justin
1. https://wiki.apache.org/incubator/DefaultProjectGuidelines
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Default project guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Thank you for such a short and informative article. I'll definitely link to
> it from Apache Ignite wiki space.
>
> What do you think about including a link to
> http://community.apache.org/newcommitter.html This page also gives a good
> level of understanding what should and should not a potential committer or
> PMC do.
I was trying to link to other policy rather than guidelines, but that is a good explanation of the process, it does however suggest that voting is required for new committers (it’s normally done that way but it’s not mandated). I note it also uses consensual voting (ie 3 +1 votes with no vetos) which is a little unclear if this is the default. This discussion has come up a few time(s) but the official docs still need to be updated. e.g. [1]
> I've also don't understand how the process of committer removal connected
> with principles:
> - Meritocracy
> - Merit does not expire
>
> How and when committer may be removed? Is it applicable to TLP projects?
Well hopefully very rarely or not at all, but there been a handful of cases where committer and PMC members have been removed. The majority of project bylaws / guidelines, created when a project becomes a TLP, do contain a way for it to happen. Some of them have incorrectly stated that the PMC can remove PMC members, when only the board can do that. That’s what started this whole thread.
But I think it is valid question should PMC actually be allowed to remove committers given merit shouldn’t expire?
Thanks,
Justin
1. https://lists.apache.org/thread.html/3c1a4887cc1b31bb85fcdbd0481d9f70895738740610aace15a7c9a3@1380595285@%3Cgeneral.incubator.apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Default project guidelines
Posted by Dmitriy Pavlov <dp...@gmail.com>.
Hi Justin,
Thank you for such a short and informative article. I'll definitely link to
it from Apache Ignite wiki space.
What do you think about including a link to
http://community.apache.org/newcommitter.html This page also gives a good
level of understanding what should and should not a potential committer or
PMC do.
I've also don't understand how the process of committer removal connected
with principles:
- Meritocracy
- Merit does not expire
How and when committer may be removed? Is it applicable to TLP projects?
Sincerely,
Dmitriy Pavlov
вс, 16 сент. 2018 г. в 10:20, Justin Mclean <ju...@classsoftware.com>:
> Hi,
>
> [1] being this link
> https://wiki.apache.org/incubator/DefaultProjectGuidelines <
> https://wiki.apache.org/incubator/DefaultProjectGuidelines> sorry I
> forgot to add it in the last email.
>
> Thanks,
> Justin
Re: Default project guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
[1] being this link https://wiki.apache.org/incubator/DefaultProjectGuidelines <https://wiki.apache.org/incubator/DefaultProjectGuidelines> sorry I forgot to add it in the last email.
Thanks,
Justin
Re: Default project guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
So does anyone have anything to add to this [1] before I post this to the board list as a suggestion for them to considered?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Default project guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Little off topic but I’ll bite. The context was that this is about giving a default set of rules to podlings so that they don’t copy and past other projects guidelines that are not in line with the Apache Way.
> In the case of on- and off-boarding members of the privileged ranks (which
> is about merit AND - though many ignore that aspect - personal likes and
> dislikes about the prospective member), this 'must have' leads more to
> lengthy threads and alienation of contributors, resulting in resentments to
> collaborate for the greater good than majority voting.
I’m actually slightly more concerned by majority voting as in extreme cases it means who/what's popular wins and the voices of minorities can be ignored and/or overruled. It requires less discussion but I’m not sure that those left out feel any better about that.
> Every time this 'we *must have* consensus about who gets onboarded' topic -
> in whatever way - is brought forward, my heart cringes as it will bring
> forth the voices that smell like dictatorship. Must have consensus can't go
> with dissenting viewpoints, majority voting can.
Perhaps you have a different view on consensus than I do, in my mind it doesn’t mean unanimous agreement and is far from one person making the decisions.
Sometimes consensus is easy and sometimes takes hard work to reach a point where all people can agree it’s the way forward and have all voices taken into consideration. [1] It more about the process [2] before the vote than the vote itself, in fact the outcome of the vote should just be a mere formality by the time it is called.
Most things don't require a formal vote with the exception of releases and voting in committer or PMC members, and even then I know of at least one project doesn’t use votes to grant committership. Each project sets it own criteria re committership and IMO some set their bar too high and others overlook slow continual contributions but that’s a different issue. (And one which the incubator has little say in other than for it’s podlings.)
If someone with ancestral ASF knowledge of which form of voting should be used when voting in committers/PMC members contributes to this thread and it is majority voting I have no issues with using it as the default. In practice I think it going to amount to the same thing i.e. if someone votes -1 with a good reason it will be taken onboard and discussed and hopefully a way forward found.
Thanks,
Justin
1. https://www.apache.org/foundation/voting.html#reasons-for-votes
2. https://community.apache.org/committers/consensusBuilding.html#consensus-building-is-not-voting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Default project guidelines
Posted by Pierre Smits <pi...@apache.org>.
Consensus is a 'potential' outcome, and more often than not regarded as the
'must have'y rule in projects of the ASF: we must have consensus on who
gets privileges to commit, to get PMC privileges...
Achieving consensus for each and every issue arising in a project (whether
it is in the incubator, a tlp, a podling or any other forum like board@ or
community-dev@) is a nice to have on non-code matters, but it should not be
made the goal.
In the case of on- and off-boarding members of the privileged ranks (which
is about merit AND - though many ignore that aspect - personal likes and
dislikes about the prospective member), this 'must have' leads more to
lengthy threads and alienation of contributors, resulting in resentments to
collaborate for the greater good than majority voting.
Every time this 'we *must have* consensus about who gets onboarded' topic -
in whatever way - is brought forward, my heart cringes as it will bring
forth the voices that smell like dictatorship. Must have consensus can't go
with dissenting viewpoints, majority voting can.
Best regards,
Pierre Smits
*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer
On Mon, Sep 10, 2018 at 8:10 AM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > There is a lot of confusion if the approval should be censuses or
> majority for adding or removing people in the various projects
> guidelines/bylaws. Consensus seem more common so I went with that - that
> may be wrong.
>
> Our docs are not clear on this either [1] states that consensus voting in
> only for code changes (unless stated otherwise) but the page makes no
> mention of what type of voting should be used for adding (or removing)
> committers or PMC members. However here [2] it seems that consensus voting
> is the norm. Other links also imply consensus voting, such as [3], but
> could be just confusing consensus with “consensus voting”. This page [4]
> mentions voting a lot but also neglects to say if it should be consensus or
> majority. Even projects like HTTP use the term consensus when talking about
> voting in PMC members and unanimous vote (an extreme form of consensus)
> when removing them [5].
>
> No wonder people don’t actually know.
>
> Practically it may not actually matter which is selected as a -1 usually
> come with a good reason and the out come will be the same, but it would be
> nice to know and have it applied consistently in our documentation.
>
> Thanks,
> Justin
>
> 1. https://www.apache.org/foundation/voting.html
> 2. https://www.apache.org/foundation/how-it-works.html#decision-making
> 3. http://www.apache.org/dev/pmc.html#newchair
> 4. http://www.apache.org/foundation/governance/pmcs.html
> 5. https://httpd.apache.org/dev/guidelines.html
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Default project guidelines
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> There is a lot of confusion if the approval should be censuses or majority for adding or removing people in the various projects guidelines/bylaws. Consensus seem more common so I went with that - that may be wrong.
Our docs are not clear on this either [1] states that consensus voting in only for code changes (unless stated otherwise) but the page makes no mention of what type of voting should be used for adding (or removing) committers or PMC members. However here [2] it seems that consensus voting is the norm. Other links also imply consensus voting, such as [3], but could be just confusing consensus with “consensus voting”. This page [4] mentions voting a lot but also neglects to say if it should be consensus or majority. Even projects like HTTP use the term consensus when talking about voting in PMC members and unanimous vote (an extreme form of consensus) when removing them [5].
No wonder people don’t actually know.
Practically it may not actually matter which is selected as a -1 usually come with a good reason and the out come will be the same, but it would be nice to know and have it applied consistently in our documentation.
Thanks,
Justin
1. https://www.apache.org/foundation/voting.html
2. https://www.apache.org/foundation/how-it-works.html#decision-making
3. http://www.apache.org/dev/pmc.html#newchair
4. http://www.apache.org/foundation/governance/pmcs.html
5. https://httpd.apache.org/dev/guidelines.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org