Emmanuel is correct, although he sounds (to me) a bit harsh.
It is ok to communicate any way you want via any channel you want (voice
or not). What is not ok is to make decisions that way. So if you use a
more interactive channel to speed up the exchange of ideas (many
projects use irc for instance) you need to bring that decision back to
the non-interactive mailing list where the ASF community build
consensus. The reason, mentioned by Emmanuel, is that communities are
strong when people feel included.
So minutes are great, but the phrasing should be more like: "discussed
the pros and cons of ...", "proposed to ...", etc and encourage the rest
of the community to provide comments, feedback, suggestions. If no
counter-proposals in a reasonable amount of time (typically 72 hours),
you can declare lazy consensus and move forward.
It's important to understand the motivation behind the ASF
rules/guidelines (aka the Apache Way). The idea is to increase
participation, encourage consensus and build strong and diverse communities.
Cheers,
Hadrian
On 04/23/2015 08:09 PM, Emmanuel Lécharny wrote:
Hi guys,
I understand that such meetings were most certainly the way the project
used to communicate before being accepted at Apache, but this has to stop.
At The ASF, if it's not on the mailing list, it does not exist. You have
to understand that such calls are excluding any committers who are not
on the same time zone, or at a convenient time zone. The very first day
you'll have a committer in Australia, such calls will simply not be
possible without excluding this comitter.
Bottom line : if you are to decide somthing for the project, use the
mailing list, nothing else. I know is less convenient, but this is The
Apache way. And, no, pusing minutes on the mailing list is clearly not
enough.
Thanks !
Le 23/04/15 19:54, Hal Lockhart a écrit :
Attendees
Hal Lockhart
Rich Levinson
David Lawrence
Pam Dragosh
Ajith Nair
Apache Migration
Status
Moved over PEPAPI code base. Combined with AT&T code. Put into GIT on Apache.
Next Steps
Need to rename packages to one uniform naming scheme. Need to decide what is
needed for first release. Make sure everything works with one loader.
Decided to create 0.9 release which contains PEPAPI over AT&T without
significant additions or changes except for the following:
Uniform package naming.
Remove developer names from source.
Single property loader.
A list of items to be added for release 1.0 was started:
Add bulk calls into AT&T API as in AzAPI.
Check with Oracle OES dev team whether "new" PEP is compatible with their use.
Integrate PIP code.
Discussion about updating AMF design.
Discussion about providing test attribute sources for testing PIPs.
Discussion about doing single vs. multiple development items in a single
checkout. Apache style seems to be one at a time.
Pam is investigating the Sentry project to see if OpenAz could be integrated
with it.
Hal
