flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject [TTH] How to agree on International vs. US English...or similar things
Date Wed, 03 Dec 2014 23:23:10 GMT
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

Mime
View raw message