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"
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 p
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
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 spellin
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 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 tang
Hi,
On Wed, Nov 26, 2014 at 10:28 AM, Harbs 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 eithe
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
wrote:
> Hi,
>
On Wed, Nov 26, 2014 at 10:30 AM, Erik de Bruin 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 discuss
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 ther
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 READ
On Wed, Nov 26, 2014 at 11:43 AM, Erik de Bruin 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
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 co
What, in your opinion, would adequately resolve this apparent catch-22?
EdB
On Wed, Nov 26, 2014 at 11:57 AM, Justin Mclean
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.
On 11/26/14, 2:57 AM, "Justin Mclean" 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)
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
15 matches
Mail list logo
