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/11/26 10:17:14 UTC
[TTH] on the "international English" issue
Hi,
I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a
IMO that's a typical example where it's impossible to come up with a
"right" solution...people have various levels of concern for that
issue, ranging from exactly zero to "my customers say our stuff is
crap when they see that" which is very bad. So the longer you discuss
those things in email the worse it gets, in general, without anybody
being wrong...just different valid opinions that cannot be reconciled.
My recommendation would be to find a technical solution to what is a
rightful community issue - reduce the area on which you need to agree,
make things more modular so that people who care about this can work
on it while others can completely ignore it.
I have no idea how or where Flex handles these language translations
(*), but if it's possible to handle the language differences with
localization files, I suppose whoever cares about those things can
maintain their custom localization files, and the PMC can have a
majority vote on what language variant to use on the default
localization files.
I wouldn't care a bit about the exact spelling in README and other
similar "technical" files - IMO whoever does the work of writing them
is right, and I'd try to follow the existing style when modifying one
of them, but that's just best effort in my book. Spelling mistakes in
READMEs? That's a good way for emerging contributors to have something
to fix ;-)
Hope this helps, and happy to clarify where needed.
-Bertrand
(*) I'm still 99.7% clueless on Flex at the technical level...just
trying to help on community issues.
Re: [TTH] on the "international English" issue
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 26, 2014 at 10:30 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> ...can a vote also be (to
> put it bluntly): "[VOTE] stop being pains in the project's buttocks
> and leave the spelling/grammar issue well enough alone!"...
A PMC can make their own rules on such things, but IMO the best way to
end discussions is to stay out of them, maybe after a brief reply that
respectfully explains why.
OTOH if someone has a valid concern the project should attempt to
create space for that concern to be addressed. Asking people for a
concrete (and concise if possible) proposal that allows their concern
to be addressed is valid.
IIUC you guys have decided to allow vetoes on discussions such as this
localization thing, if that's correct I think that's a bad idea. The
reason why Apache best practices recommend majority votes on most
everything is to allow disagreement to exist. It feels bad to see your
ideas rejected sometimes when you're in the minority, but that usually
prompts people to come up with new proposals that are acceptable to
the majority, and those proposals are often better than the original
ones.
Reducing the area of friction is key, so back to Harbs list if I was
going to push for a language preference I'd try to attack the smallest
and most important parts first if agreeing on the whole thing looks
difficult.
-Bertrand
Re: [TTH] on the "international English" issue
Posted by Harbs <ha...@gmail.com>.
Very good question.
I see having an agreed upon method of killing discussions as a very positive move.
On Nov 26, 2014, at 11:30 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> A second question: would it be OK to call a vote to end a discussion?
> In other words: does a vote always have to be about something tangible
> - a paragraph in the Wiki, a release, etc. Or can a vote also be (to
> put it bluntly): "[VOTE] stop being pains in the project's buttocks
> and leave the spelling/grammar issue well enough alone!"
>
> EdB
>
Re: [TTH] on the "international English" issue
Posted by Erik de Bruin <er...@ixsoftware.nl>.
A second question: would it be OK to call a vote to end a discussion?
In other words: does a vote always have to be about something tangible
- a paragraph in the Wiki, a release, etc. Or can a vote also be (to
put it bluntly): "[VOTE] stop being pains in the project's buttocks
and leave the spelling/grammar issue well enough alone!"
EdB
On Wed, Nov 26, 2014 at 10:26 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> What is the Apache Way (tm) to 'agree to disagree'? When there are two
> opposing positions that are both right, but different enough not to be
> able to reach a compromise, what action might break the deadlock?
>
> A vote would result in one side 'losing', something we have been
> trying to avoid in this project ... to the point where a vote isn't
> called until there is a clear consensus in the DISCUSS thread. This
> makes the DISCUSS thread the de facto vote, but with an endless
> discussion added in. Is 'losing' votes just part of doing Open Source
> the Apache Way?
>
> EdB
>
>
>
> On Wed, Nov 26, 2014 at 10:17 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Hi,
>>
>> I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a
>>
>> IMO that's a typical example where it's impossible to come up with a
>> "right" solution...people have various levels of concern for that
>> issue, ranging from exactly zero to "my customers say our stuff is
>> crap when they see that" which is very bad. So the longer you discuss
>> those things in email the worse it gets, in general, without anybody
>> being wrong...just different valid opinions that cannot be reconciled.
>>
>> My recommendation would be to find a technical solution to what is a
>> rightful community issue - reduce the area on which you need to agree,
>> make things more modular so that people who care about this can work
>> on it while others can completely ignore it.
>>
>> I have no idea how or where Flex handles these language translations
>> (*), but if it's possible to handle the language differences with
>> localization files, I suppose whoever cares about those things can
>> maintain their custom localization files, and the PMC can have a
>> majority vote on what language variant to use on the default
>> localization files.
>>
>> I wouldn't care a bit about the exact spelling in README and other
>> similar "technical" files - IMO whoever does the work of writing them
>> is right, and I'd try to follow the existing style when modifying one
>> of them, but that's just best effort in my book. Spelling mistakes in
>> READMEs? That's a good way for emerging contributors to have something
>> to fix ;-)
>>
>> Hope this helps, and happy to clarify where needed.
>>
>> -Bertrand
>>
>> (*) I'm still 99.7% clueless on Flex at the technical level...just
>> trying to help on community issues.
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] on the "international English" issue
Posted by Erik de Bruin <er...@ixsoftware.nl>.
What is the Apache Way (tm) to 'agree to disagree'? When there are two
opposing positions that are both right, but different enough not to be
able to reach a compromise, what action might break the deadlock?
A vote would result in one side 'losing', something we have been
trying to avoid in this project ... to the point where a vote isn't
called until there is a clear consensus in the DISCUSS thread. This
makes the DISCUSS thread the de facto vote, but with an endless
discussion added in. Is 'losing' votes just part of doing Open Source
the Apache Way?
EdB
On Wed, Nov 26, 2014 at 10:17 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi,
>
> I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a
>
> IMO that's a typical example where it's impossible to come up with a
> "right" solution...people have various levels of concern for that
> issue, ranging from exactly zero to "my customers say our stuff is
> crap when they see that" which is very bad. So the longer you discuss
> those things in email the worse it gets, in general, without anybody
> being wrong...just different valid opinions that cannot be reconciled.
>
> My recommendation would be to find a technical solution to what is a
> rightful community issue - reduce the area on which you need to agree,
> make things more modular so that people who care about this can work
> on it while others can completely ignore it.
>
> I have no idea how or where Flex handles these language translations
> (*), but if it's possible to handle the language differences with
> localization files, I suppose whoever cares about those things can
> maintain their custom localization files, and the PMC can have a
> majority vote on what language variant to use on the default
> localization files.
>
> I wouldn't care a bit about the exact spelling in README and other
> similar "technical" files - IMO whoever does the work of writing them
> is right, and I'd try to follow the existing style when modifying one
> of them, but that's just best effort in my book. Spelling mistakes in
> READMEs? That's a good way for emerging contributors to have something
> to fix ;-)
>
> Hope this helps, and happy to clarify where needed.
>
> -Bertrand
>
> (*) I'm still 99.7% clueless on Flex at the technical level...just
> trying to help on community issues.
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] on the "international English" issue
Posted by Alex Harui <ah...@adobe.com>.
On 11/26/14, 2:57 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> Nowhere in the bylaws (that I can find) does it say that spelling
>> issues in documentation are release blockers.
>
>!00% correct and I'm against it.
>
>> If someone said they should be, that would be an opinion.
>
>Also correct , but:
>a) With the new no RC process, (which IMO basically require consensus to
>release) that means you can't even call a vote if someone objects to the
>current nightly.
The new “no RC” process doesn’t require consensus, that would mean
overriding an Apache policy. It just means that it is probably not wise to
call a vote until you are sure you have enough votes. If the discuss
thread indicates that one person is -1 and 3 others are +1, that’s good
enough.
>b) With the minimal number of people who vote usually means a single -1
>is usually enough to stop anything, even if that is for trivial reasons.
>c) A single -1 vote also usually stops a release as no one else tends to
>vote once that happens.
This is unfortunately true, and we still haven’t figured out how to
attract more reviewers. I have built ant scripts that automate the steps
to create an RC and other ant scripts that take you through the steps to
approve an RC in an attempt to make it easier for folks to do the review
and for the RM to respond to those reviews. The scripts could use
improvement, but maybe reducing the overhead of participating in a release
will get more folks to join in.
-Alex
Re: [TTH] on the "international English" issue
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> What, in your opinion, would adequately resolve this apparent catch-22?
Well the ideal solution would to have more PMC involvement on release votes, but I've no good ideas how to encourage PMC members to vote on releases.
Thanks,
Justin
Re: [TTH] on the "international English" issue
Posted by Erik de Bruin <er...@ixsoftware.nl>.
What, in your opinion, would adequately resolve this apparent catch-22?
EdB
On Wed, Nov 26, 2014 at 11:57 AM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
>> Nowhere in the bylaws (that I can find) does it say that spelling
>> issues in documentation are release blockers.
>
> !00% correct and I'm against it.
>
>> If someone said they should be, that would be an opinion.
>
> Also correct , but:
> a) With the new no RC process, (which IMO basically require consensus to release) that means you can't even call a vote if someone objects to the current nightly.
> b) With the minimal number of people who vote usually means a single -1 is usually enough to stop anything, even if that is for trivial reasons.
> c) A single -1 vote also usually stops a release as no one else tends to vote once that happens.
>
>> checked and that wouldn't amount to a veto for a release.
>
> Also correct releases can't be vetoed (but see above).
>
> Thanks,
> Justin
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] on the "international English" issue
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Nowhere in the bylaws (that I can find) does it say that spelling
> issues in documentation are release blockers.
!00% correct and I'm against it.
> If someone said they should be, that would be an opinion.
Also correct , but:
a) With the new no RC process, (which IMO basically require consensus to release) that means you can't even call a vote if someone objects to the current nightly.
b) With the minimal number of people who vote usually means a single -1 is usually enough to stop anything, even if that is for trivial reasons.
c) A single -1 vote also usually stops a release as no one else tends to vote once that happens.
> checked and that wouldn't amount to a veto for a release.
Also correct releases can't be vetoed (but see above).
Thanks,
Justin
Re: [TTH] on the "international English" issue
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Nov 26, 2014 at 11:43 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> ...That opinion might translate into
> a -1 vote, but I just checked and that wouldn't amount to a veto for a
> release....
I agree that releases cannot be vetoed.
OTOH someone can technically veto a commit that introduces a spelling
error somewhere, but it's usually quicker to just fix it.
-Bertrand
Re: [TTH] on the "international English" issue
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Justin,
> Most of the SDK (error messages and the like) are localised so there's nothing that needs to be done there - other than keep it up to date and add new locales where people can contribute. The current area of disagreement is actually very small and if the spelling issues in README and the like being release blockers are removed it's almost zero (and basically shouldn't be rarely an issue because of CTR).
Nowhere in the bylaws (that I can find) does it say that spelling
issues in documentation are release blockers. If someone said they
should be, that would be an opinion. That opinion might translate into
a -1 vote, but I just checked and that wouldn't amount to a veto for a
release. So, a majority of voters doesn't agree with that person, they
are by definition not release blockers, as the vote would pass and the
release would be approved.
There is no need to codify this, the process is already in place.
Also, by not making this an absolute rule, it leaves open the
possibility that a spelling error in some instances in some documents
might at some point constitute a release blocker, an option that I
think is vital.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [TTH] on the "international English" issue
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Thanks for stepping to to helping out Bertrand, sorry you need to spend time on this.
> My recommendation would be to find a technical solution to what is a rightful community issue
Most of the SDK (error messages and the like) are localised so there's nothing that needs to be done there - other than keep it up to date and add new locales where people can contribute. The current area of disagreement is actually very small and if the spelling issues in README and the like being release blockers are removed it's almost zero (and basically shouldn't be rarely an issue because of CTR).
> I wouldn't care a bit about the exact spelling in README and other similar "technical" files
+1 to that.
Thanks,
Justin
Re: [TTH] on the "international English" issue
Posted by Harbs <ha...@gmail.com>.
Personally, I’m more comfortable with broader consistency (in website, etc.), but I’m fine with this.
Since user facing text is all localized already, based on your suggestions, we can drop this whole discussion.
Thanks,
Harbs
On Nov 26, 2014, at 11:45 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> On Wed, Nov 26, 2014 at 10:28 AM, Harbs <ha...@gmail.com> wrote:
>> ...The way I understand your suggestion is like this:
>> We agree on variant “X”....
>
> I would only care about localizing text that is visible when people
> run a Flex application - dialogs, error messages etc.
>
> As for everything else, that's either technical (class names, APIs,
> javadocs etc.) or internal to the project (wiki, website) so IMO best
> effort for consistent wording within a page or file is good enough.
>
> -Bertrand
Re: [TTH] on the "international English" issue
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Nov 26, 2014 at 10:28 AM, Harbs <ha...@gmail.com> wrote:
> ...The way I understand your suggestion is like this:
> We agree on variant “X”....
I would only care about localizing text that is visible when people
run a Flex application - dialogs, error messages etc.
As for everything else, that's either technical (class names, APIs,
javadocs etc.) or internal to the project (wiki, website) so IMO best
effort for consistent wording within a page or file is good enough.
-Bertrand
Re: [TTH] on the "international English" issue
Posted by Harbs <ha...@gmail.com>.
Just to use Alex’s division of items in an attempt to make things clear:
1) Release package documents: README, RELEASE_NOTES, LICENSE, NOTICE,
CONTRIBUTING, etc.
2) API names (classes, properties, styles, etc)
3) ASDoc and JavaDoc comments (really, any comments that end up in user
documentation)
4) Written user documentation
5) Website
6) Wiki
7) Error messages in the tools
8) Text in the SDKs and Applications we release that show up in some GUI
The way I understand your suggestion is like this:
We agree on variant “X”.
1) Anything goes as long as it’s understandable as English, but there should be an attempt at keeping the wording consistent within a file.
2) Not sure.
3) Variant “X”.
4) Variant “X” with an option to localize for anyone who cares.
5) Ditto
6) Not sure.
7) Not sure.
8) Not an issue because it’s already localized.
Harbs
On Nov 26, 2014, at 11:17 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> Hi,
>
> I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a
>
> IMO that's a typical example where it's impossible to come up with a
> "right" solution...people have various levels of concern for that
> issue, ranging from exactly zero to "my customers say our stuff is
> crap when they see that" which is very bad. So the longer you discuss
> those things in email the worse it gets, in general, without anybody
> being wrong...just different valid opinions that cannot be reconciled.
>
> My recommendation would be to find a technical solution to what is a
> rightful community issue - reduce the area on which you need to agree,
> make things more modular so that people who care about this can work
> on it while others can completely ignore it.
>
> I have no idea how or where Flex handles these language translations
> (*), but if it's possible to handle the language differences with
> localization files, I suppose whoever cares about those things can
> maintain their custom localization files, and the PMC can have a
> majority vote on what language variant to use on the default
> localization files.
>
> I wouldn't care a bit about the exact spelling in README and other
> similar "technical" files - IMO whoever does the work of writing them
> is right, and I'd try to follow the existing style when modifying one
> of them, but that's just best effort in my book. Spelling mistakes in
> READMEs? That's a good way for emerging contributors to have something
> to fix ;-)
>
> Hope this helps, and happy to clarify where needed.
>
> -Bertrand
>
> (*) I'm still 99.7% clueless on Flex at the technical level...just
> trying to help on community issues.