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 <bdelacre...@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
