from:"Bertrand Delacretaz"

Hi,

On Fri, Dec 5, 2014 at 9:19 AM, Justin Mclean jus...@classsoftware.com wrote:
 ...The process is described here [1] which references [2] and
 best practise described here [3]...

Apart from not having vetoes on release votes, the only things that
the ASF requires about releases are captured in this excerpt from [1],
which defines several of the terms user later on the same page:

 An Apache release is a set of valid , signed , artifacts, voted on by
 the appropriate PMC and distributed on the ASF's official
 release infrastructure

[3] in particular is detailed recommendations for podlings during
incubation, I wouldn't put too much weight on it. PMCs are free to
handle the steps that allow them to fulfill the above requirements in
any way they see fit. The simpler the better IMO and it's also fine
for different release managers to work differently, from the ASF's
point of view.

 ...With few PMC members voting a single -1 or indication that that how
 someone will vote can basically acts as a veto

Does this PMC have trouble getting 4 people voting on a release? If
you get 4 votes, a -1 is definitely not a veto as per
http://www.apache.org/foundation/glossary.html#MajorityApproval

If you guys have trouble getting 4 voters, something's wrong. Either
there's not enough active PMC members, or people think voting +1 on a
release means they agree to have their head cut off if a bug is found
in it later. That's not the case, by far. Voting +1 on a release means
you think publishing it is progress towards your goals, and to the
best of your knowledge you think it complies with the above
requirements.

-Bertrand

 1. http://www.apache.org/dev/release-publishing.html
 2. http://www.apache.org/foundation/voting.html
 3. http://incubator.apache.org/guides/releasemanagement.html

Re: [TTH] vetoes get in the way

On Fri, Dec 5, 2014 at 10:01 AM, Erik de Bruin e...@ixsoftware.nl wrote:
 ...In this particular instance, Justin decided to discard 2 votes instead
 of carrying them over, which the majority of the participating PMC
 members were advocating...

Ok, I didn't study the details but I agree that you cannot carry over
votes from one release candidate to the next, for example, without
voters individually and explicitly indicating that you can do so. This
is one thing where you need to have a correct archive of who voted +1
on what.

Note that casting another +1 is actually less typing than saying yes
you can carry my vote over ;-)

-Bertrand

Re: [TTH] vetoes get in the way

On Friday, December 5, 2014, Jeffry Houser jef...@dot-com-it.com wrote:

 ...Could part of the problem we have too many projects under the Apache
Flex banner?
 Do other Apache projects have 9+ completely separated, but related,
projects?...

The key is not how many modules you are managing but whether those belong
to the same community.

To take an example that I'm familiar with, Apache Sling manages more than
100 modules [1] and releases them very regularly. That works fine.

Sometimes one needs to call for more PMC members to get enough votes on a
module that interests only few people, and when that became hard we just
went back to our list of committers and elected a bunch of them as PMC
members (which also means you look for new committers often, as people also
go). Because people care about the overall health of the project, they will
take the time to vote on releases even for modules that they're not really
interested in.

-Bertrand

[1] http://sling.apache.org/downloads.cgi

Re: [VOTE] Allow RC votes to carry over at any point in the release process

On Fri, Dec 5, 2014 at 5:25 PM, Jesse Nicholson
ascensionsyst...@gmail.com wrote:
 ...many of the leads here seem to double as adobe
 employees... which makes me feel that this is still very heavily controlled
 and owned by adobe for their own corporate interests

I suppose you did not realize how that kind of statement is received
by people who spend lots of energy to run this foundation in a way
that keeps our projects independent from corporate influences, as well
as by people who take great care of contributing to these projects in
a way that implements this independence.

As someone who's active on all sides of this, I am doubly hurt ;-)

But of course if you have actual concerns about corporate
independence, feel free to report them to this PMC or to a trusted
Apache Foundation Member or Director.

Anyway...welcome! And I'd recommend that you stay around for a bit
longer. IMO this project is currently in a crisis but there's positive
signs in the last few days that the atmosphere should get much better
soon!

-Bertrand

[TTH] vetoes get in the way

Hi,

I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
and I think allowing vetoes for most everything, as those guidelines
do, is calling for trouble.

The standard Apache voting process [1] specifies vetoes for commits only.

My recommendation would be to make those guidelines much simpler by
keeping just two voting modes as per [1]:

a) Majority approval,
http://www.apache.org/foundation/glossary.html#MajorityApproval
b) Lazy consensus,
http://www.apache.org/foundation/glossary.html#LazyConsensus (and move
to majority approval if there's a -1 there)

With c) possible vetoes for commits as per [1] - those must have a
clear technical justification to be considered valid.

And where a) applies to almost everything, and b) saves time while
allowing to move to a) if someone requests it with a -1.

Removing the right to veto allows things to move forward, driven by
the majority. It's no fun being in the minority, so in my experience
over time people learn to adapt their proposals to make them
acceptable, or make things more modular to cope with different views
of the world.

Again, you don't want to vote on each and every nitpick, but voting is
a useful tool to avoid endless discussions on things that have various
levels of importance for various people.

-Bertrand

[1] http://www.apache.org/foundation/voting.html

Re: [TTH] The old fart is back, aka let's fix this community ;-)

On Wed, Nov 26, 2014 at 10:06 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 ...I'm intentionally not subscribing to your private list at the moment...

FWIW, I have also subscribed to that list now, as I felt I didn't have
the complete picture.

-Bertrand

Re: [TTH] vetoes get in the way

On Thu, Dec 4, 2014 at 10:48 AM, Tom Chiverton t...@extravision.com wrote:
 ...I'm sure if we got
 to the point of voting on something, and there were a large fraction of -1
 (but more +1) we'd still take that as a signal to evaluate whatever it was
 more strongly...

That would be great, yes. And even a single -1 might trigger your
community health alarms, but with majority approval that doesn't block
things and you can move forward while hopefully keeping those alarms
in mind.

-Bertrand

Re: [TTH] vetoes get in the way

On Thu, Dec 4, 2014 at 9:14 AM, Harbs harbs.li...@gmail.com wrote:
 ...If you feel it should be changed anyway, I have no objections to that...

I havent checked if allowing vetoes for many things has caused
problems or not so far but I see a potential for creating blocking
problems, so fixing that now is probably a good idea.

-Bertrand

Re: [TTH] How to agree on International vs. US English...or similar things

On Thu, Dec 4, 2014 at 2:03 AM, Justin Mclean jus...@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] vetoes get in the way

On Thursday, December 4, 2014, OmPrakash Muppirala bigosma...@gmail.com
wrote:

 BTW, what does the TTH in the subject line strands for?

Trying To Help - I made that up a few days ago,
http://flex.markmail.org/thread/re2q3mxlzws76x26

-Bertrand

Re: [TTH] vetoes get in the way

Hi,

On Thu, Dec 4, 2014 at 6:28 PM, Alex Harui aha...@adobe.com wrote:
 ...the reason our guidelines require consensus for adding
 people is because of this document [1] and some advice from other
 experienced non-Flex Apache people that having consensus for adding folks
 is important...

I agree if consensus means widespread agreement but in this PMC's
guidelines it seems to mean unanimity. That meaning is definitely
against [1] where the first paragraph says one of the fundamental
aspects of accomplishing things within the Apache framework is doing
so by consensus.

The word consensus at [1] clearly points to the widespread agreement
variant of http://en.wiktionary.org/wiki/consensus. So by redefining
that in your guidelines you have created a variant of the standard
Apache understanding of that word, which can be confusing to
outsiders, like myself when I subscribed back to this list a few days
ago.

Back to vetoes - as I said, my recommendation is to take -1s into
account *at the community level* when voting in new committers for
example. So in general if someone says -1 try to find out what's
behind that and act accordingly. And usually don't proceed - but
there's no obligation for the PMC.

So that's different from formally allowing such -1 to block committer
election or other votes, releases etc. That gives people the power to
block things even without justification, with potentially bad
consequences on the project's well-being. You want things to move
forward, even if this means putting some PMC members in a minority
sometimes. If that sometimes becomes always the community should
address that, but sometimes is ok for the sake of moving on. When
things get difficult, veto power is a very powerful weapon for people
who want to show their disagreement or just block things for political
reasons. Too powerful actually, so [1] avoids vetoes for most
occurences of consensus (widespread agreement) building.

That's why I recommend following the standard Apache rules and
recommendations. at [1] And also, as I said, because Flex is a
relatively small PMC that can save energy by just sticking to the ASF
standard things, without having to spend much time discussing its own
variants.

But that's just my opinion, there's no obligation for you guys to
follow up on that. I just think it might avoid problems in the medium
and long term.

-Bertrand

[1] http://www.apache.org/foundation/voting.html

Re: [TTH] How to agree on International vs. US English...or similar things

On Thu, Dec 4, 2014 at 6:12 PM, Alex Harui aha...@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

Hi,

On Fri, Dec 5, 2014 at 8:15 AM, Harbs harbs.li...@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: The 'less-RC' process explained

2014-12-03 Thread Bertrand Delacretaz

Hi,

On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean jus...@classsoftware.com wrote:
 ...Perhaps some agreement or general agreement is a better term? You may 
 consider
 that an unnecessary distinction but I really think that the PMC as a whole 
 misses this
 rather important point about releases

I was going to comment on that - sticking to the ASF-wide voting
modes of http://www.apache.org/foundation/voting.html would IMO help
make sure everybody's on the same page.

That provides the following 3 options:

majority approval which is defined at
http://www.apache.org/foundation/glossary.html#MajorityApproval

veto, defined at http://www.apache.org/foundation/glossary.html#Veto
which only applies to commits

lazy consensus as per
http://www.apache.org/foundation/glossary.html#LazyConsensus

I suppose Flex can live with these options, you could then just use
these terms and refer to the above pages which are standard Apache
definitions, to spare yourself the burden of defining your own
variants.

-Bertrand

Re: The 'less-RC' process explained

2014-12-03 Thread Bertrand Delacretaz

On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean jus...@classsoftware.com wrote:
 ...I'll look at the changes and make some more edits later today if I some 
 time

Cool - so it looks like there's no need to discuss this further, until
Justin makes those edits and reports here that he's happy with the
result.

Justin, I'm happy to review that document as well once you're at that
point, from my point of view of making things as simple as possible
and sticking to the Apache-wide definitions of voting options listed
at http://www.apache.org/foundation/voting.html

-Bertrand

[TTH] How to agree on International vs. US English...or similar things

2014-12-03 Thread Bertrand Delacretaz

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

[TTH] The old fart is back, aka let's fix this community ;-)

Hi Flex community,

I had private discussions with both Justin and Alex in the last few
days, and as a former incubation mentor of this project it saddens me
to hear that you're having difficulties agreeing on things, so I'm
back here to try and help.

It's not uncommon in Apache projects to disagree, not at all...there's
some things on which people will never agree (especially in email)
although neither side is right or wrong. The usual answer is to make
things more modular, and I think the Apache HTTP server project is the
best example of that. Very modular!

I'll start another thread on the english vs. international language issue.
I'll use a [TTH] marker in those emails, as in trying to help ;-)

-Bertrand
(BTW I'm not the board member who's been trying to follow - I'm
intentionally not subscribing to your private list at the moment, even
though as an Apache member I could)

[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

On Wed, Nov 26, 2014 at 10:30 AM, Erik de Bruin e...@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

On Wed, Nov 26, 2014 at 11:43 AM, Erik de Bruin e...@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: [DISCUSS] modify project bylaws: default to Majority Approval for votes