You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/12/04 00:23:10 UTC
[TTH] How to agree on International vs. US English...or similar things
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
RE: [TTH] How to agree on International vs. US English...or similar
things
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
The way I see the decision for this works similar to how we code in the SDK. Follow the style and format of the existing file. So if you're modifying the SDK you would normally mimic the code style / format that is present in that file. Better to be consistent than have split styles.
-Mark
Re: [TTH] How to agree on International vs. US English...or similar things
Posted by Chris Martin <wi...@gmail.com>.
Bertrand was referring to the previous language on the guidelines wiki
page. After him bringing it up and many of us saw the problem with that as
well, Erik adjusted the page [1] on Dec 1 to switch from "Consensus" to
"Majority Approval".
[1]
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=34834174&selectedPageVersions=48&selectedPageVersions=47
On Fri, Dec 5, 2014 at 12:34 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Fri, Dec 5, 2014 at 8:15 AM, Harbs <ha...@gmail.com> wrote:
> >> ...So it's back to the discussion about vetoes being harmful.
> >
> > I don’t understand why you keep coming back to this point. No one
> (besides Justin)
> > ever suggested that releases could be vetoed...
>
> Ah sorry, I seemed to recollect
> https://cwiki.apache.org/confluence/display/FLEX/Guidelines mentioning
> that but I'm wrong, those guidelines clearly say that release votes
> use Majority Approval.
>
> I stand corrected, vetoes do not apply here, thanks!
>
> -Bertrand
>
Re: [TTH] How to agree on International vs. US English...or similar things
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Fri, Dec 5, 2014 at 8:15 AM, Harbs <ha...@gmail.com> wrote:
>> ...So it's back to the discussion about vetoes being harmful.
>
> I don’t understand why you keep coming back to this point. No one (besides Justin)
> ever suggested that releases could be vetoed...
Ah sorry, I seemed to recollect
https://cwiki.apache.org/confluence/display/FLEX/Guidelines mentioning
that but I'm wrong, those guidelines clearly say that release votes
use Majority Approval.
I stand corrected, vetoes do not apply here, thanks!
-Bertrand
Re: [TTH] How to agree on International vs. US English...or similar things
Posted by Harbs <ha...@gmail.com>.
Hi Bertrand,
> So it's back to the discussion about vetoes being harmful.
I don’t understand why you keep coming back to this point. No one (besides Justin) ever suggested that releases could be vetoed.
On Dec 5, 2014, at 8:50 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Thu, Dec 4, 2014 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
>> ...we decided to add a new “all caps” file called
>> “CONTRIBUTING" to our release packages. In examining the package, I found
>> the file was misspelled as “CONTRIBITING” and felt that because it was in
>> the top-level listing it would be worth spelling that correctly....
>
> This is a typical example of something that feels like a release
> blocker to some people, while others couldn't care less and will want
> to move forward.
>
> So it's back to the discussion about vetoes being harmful. If you
> allow them, people who care about this can block a release, even if
> the majority of the PMC doesn't want to delay a release for something
> that they see as a minor issue.
>
> That's where the Apache best practices say the majority is right, at
> the expense of disappointing the minority and for the benefit of
> projects moving forward faster by trusting the majority.
>
> -Bertrand
Re: [TTH] How to agree on International vs. US English...or similar things
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 4, 2014 at 6:12 PM, Alex Harui <ah...@adobe.com> wrote:
> ...we decided to add a new “all caps” file called
> “CONTRIBUTING" to our release packages. In examining the package, I found
> the file was misspelled as “CONTRIBITING” and felt that because it was in
> the top-level listing it would be worth spelling that correctly....
This is a typical example of something that feels like a release
blocker to some people, while others couldn't care less and will want
to move forward.
So it's back to the discussion about vetoes being harmful. If you
allow them, people who care about this can block a release, even if
the majority of the PMC doesn't want to delay a release for something
that they see as a minor issue.
That's where the Apache best practices say the majority is right, at
the expense of disappointing the minority and for the benefit of
projects moving forward faster by trusting the majority.
-Bertrand
Re: [TTH] How to agree on International vs. US English...or similar
things
Posted by Alex Harui <ah...@adobe.com>.
On 12/4/14, 5:51 AM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>On Thu, Dec 4, 2014 at 2:03 AM, Justin Mclean <ju...@classsoftware.com>
>wrote:
>> ...I'd just like it add that it only come up as an issue as some PMC
>>members considered spelling
>> issues a "blocker" for release candidates. I'm not sure if they still
>>consider that to be the case....
>
>Based on http://www.apache.org/foundation/voting.html you cannot have
>a blocker for a release - if the majority approval says the release
>should go out, it goes out.
>
>Now, of course, the PMC should strive to take -1 on release votes into
>account, but maybe they do that for the next release, especially if
>you release early and often or on a set cadence.
For more context, Justin is referring to two different incidents. The
first one was when we decided to add a new “all caps” file called
“CONTRIBUTING" to our release packages. In examining the package, I found
the file was misspelled as “CONTRIBITING” and felt that because it was in
the top-level listing it would be worth spelling that correctly. In the
second incident involving a different release, I discovered that “Apache”
was misspelled as “Apche”. To me, those are worth fixing before
releasing. So would any known misspelling of product names and people’s
names. We should fix obvious gaffes when we find them, and be respectful
to organizations and people. But if a less obvious spelling error gets
released and noticed later, no big deal, we just fix it for the next
release. Spelling errors are not all of equal importance.
It so happened in both incidents that enough folks agreed with me and thus
Justin was unable to get enough +1 votes to release that particular RC.
So I didn’t block it with a -1 vote. After all, the voting rules don’t
allow it. The simple fact was that more folks agreed with me.
That’s one of the reasons I like the new “less-RC” process. There is far
less overhead to fixing such a problem. I can now just fix the spelling
error I found before we get around to voting. Sure if someone made a last
minute change just before the RC was cut and vote started I might ask for
another RC if it is obvious or prominent, but that should be rare.
-Alex
Re: [TTH] How to agree on International vs. US English...or similar things
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Dec 4, 2014 at 2:03 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...I'd just like it add that it only come up as an issue as some PMC members considered spelling
> issues a "blocker" for release candidates. I'm not sure if they still consider that to be the case....
Based on http://www.apache.org/foundation/voting.html you cannot have
a blocker for a release - if the majority approval says the release
should go out, it goes out.
Now, of course, the PMC should strive to take -1 on release votes into
account, but maybe they do that for the next release, especially if
you release early and often or on a set cadence.
-Bertrand
Re: [TTH] How to agree on International vs. US English...or similar things
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Thanks for your time and analysis Bertrand.
I'd just like it add that it only come up as an issue as some PMC members considered spelling issues a "blocker" for release candidates. I'm not sure if they still consider that to be the case.
Thanks,
Justin
RE: [TTH] How to agree on International vs. US English...or similar
things
Posted by Frédéric THOMAS <we...@hotmail.com>.
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: bdelacretaz@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