William,
I have made some edits to the wiki on the Mechanisms for feedback
section to clean up the
language, based on some of the misunderstanding and to reflect the
discussion from the list
onto the wiki. Tried to keep it short, but can edit more in if required.
Carl.
William A. Rowe, Jr. wrote:
Carl Trieloff wrote:
But to the extent that ASF contributors offer productive growth and
formative input into the specification, the way this section is phrased
is not acceptable. If the contributor wish[es], and if under these terms
their contributions merits participation, that contributor should either
lead the ASF's direct involvement as the ASF spec liason (much as we've
done within the JCP) or as an individual contributor.
I would love this.
Glad to hear that, but until the proposal is revised it is simply a platitude.
I phrased that as an either-or or both, but we need to know from the spec
committee what would be acceptable.
I'm very concerned, though, that not one mentor has spoken up and added any
feedback on this objection...
Carl Trieloff wrote:
My question came down to this; if someone offers a patch, which then suggests
an improvement to the spec, does the ASL (which covers -everything- that is
offered to the ASF) adequately correspond to the RLA terms to satisfy the
spec committee? If so there's no issue; in fact it would be sufficient to
continue to accept contributions from ASF committers who have signed a CLA
to the effect that everything they offer is covered.
Now that I understand what you are getting at - I really like the idea.
no idea if it is possible, but worth looking into - seems like it might work.
We can work this with Cliff and see what we can come up during incubator
I'm a bit concerned about the project's apparent attitude "accept us and then
we'll work out the wrinkles, or not". Even copyrights are already assigned
as Apache Software Foundation when they are, in fact, not the ASF's yet. And
FWIW - copyright will become much simpler under the new practice; no more
individual file copyright notices, one collective NOTICE, one LICENSE file.
Most important, so I'll say this for the third time;
The specific statement "In the same spirit of Apache, if an individual has
shown understanding of the project and substantive contribution to the
specification, a vote based on technical merit and understanding of the goals
of the work can be initiated to have that parties Employer join the
specification working group."
has put off this effort on the wrong foot. I hope this is addressed now, and
not put off with some fuzzy "then we'll work out the details during incubation".
It's not complicated, folks. ASF projects consist of individuals. Adding
company affiliations after each of the initial committers names suggests, to
some, that the day they move on to another company their contribution to the
project ends. We understand why Cliff did so for himself (so that there would
be no misunderstanding that he has a vested interest, bravo), but that this
was propagated to the entire initial list of committers is very troubling.
The effort seems entirely too eager to brand the project as Apache, entirely
ready to defend the status quo or try to cite ASF policy back at any objectors,
and entirely uninterested in addressing a couple of things; how to start off
on the right foot as a collaboration of willing developers (not employers)
at the ASF. That's the sense of what I'm reading - I'm not saying it's so.
The enthusiasm is admirable, but the core issues need to be addressed before
incubation begins.
Address the crux of this please, the language of the spec feedback cycle and
the spec body, and then let's all move *forward* to incubating the effort?
The silence of the mentors on this makea me very concerned about their ability
to adequately shape the evolution of this community.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
