Hi Bertrand, Sounds good and easy, let's see how it will work... Thanks for your time digging into that :-) Frédéric THOMAS
> Date: Thu, 4 Dec 2014 00:23:10 +0100 > Subject: [TTH] How to agree on International vs. US English...or similar > things > From: bdelacre...@apache.org > To: dev@flex.apache.org > > Hi, > > Someone brought the following commits to my attention, asking how you > guys can solve such disagreements without endless discussions. > > ** Here's the story ** > > 1) Justin commits this to replace for example "utilize" with "utilise": > > https://github.com/apache/flex-utilities/commit/68e4e93ac70a61e31029f3d4601184ca90222878#diff-2e816ed51dd59a9bb0630ea81ecae78e > > 2) Later Alex mentions that you guys haven't agreed on International > English so far: > > http://markmail.org/message/b7nurawtxsgg32i2 > > 3) And later Alex commits to the same file replacing "utilise" with > phrasing that avoids using either form: > > https://github.com/apache/flex-utilities/commit/eb658e05f50be571877c1f5b6ef366bb8bc4ae4d#diff-2e816ed51dd59a9bb0630ea81ecae78e > > ** My analysis ** > > Using neutral phrasing is a creative move on Alex's part, but > unfortunately the core issue of which spelling to use hasn't been > solved, and bites you guys back later when Justin (IIRC) mentions the > issue isn't resolved and wants a decision on which spelling to use. > All this while others probably couldn't care less about one or the > other spelling and consider the whole thing a waste of time. > > So How can you guys come to agreement on using International vs. US > English, for example, without spending ages discussing it? > > At step 1), Alex could very well have vetoed the commit, as per [1], > with justification. Justin is then expected to revert it until a > decision is made. Commit vetoes are not shameful or rude, if used > sparingly and with proper technical justification. Alex thinks you > didn't agree on this, it feels important to him so he vetoes the > commit, no problem with that. > > A discussion will then usually happen, and if it's impossible to > agree, the Apache principles recommend a PMC vote - on your dev list > of course, there's no need for that to be private. The key to avoiding > an endless discussion is to express your opinion clearly (and > concisely if possible) and if a common opinion doesn't emerge suggest > a vote before the whole thing drags on for too long. I this case, If I > was on this PMC I'd just reply "I don't care, and if people disagree > let's have a vote on this" and then get out of the discussion. > > By default all votes follow the "majority approval" rule [2] so > assuming at least 3 PMC members vote you get a clear and documented > decision within 72 hours. > > Having votes about such trivial (to me) things is certainly not fun, > but we know that we cannot always agree in our projects, so having > such a way to resolve disagreements without spending ages on them > certainly helps the project progresses. > > The "majority approval" voting mode for almost everything (vetoes are > for commits only) helps move forward. It's not fun to have to accept a > decision that goes against your will if you're in the minority, but > that's how collaborative projects work. > > Please don't get into voting on each and every thing that happens, but > having a concise and documented set of guidelines for such things that > feel important to some PMC members helps avoiding rehashing things > every time they come up, so it's an effort that's needed for a project > to progress. If other PMC members don't feel those issues are > important, just stay out of the discussion and vote one way or another > when needed to allow things to move forward. > > Hope this helps. > > -Bertrand > > > [1] http://www.apache.org/foundation/voting.html > [2] http://www.apache.org/foundation/glossary.html#MajorityApproval
