On 7/23/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 7/22/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

> On Jul 22, 2006, at 1:50 AM, robert burrell donkin wrote:
>
> > no change is necessary - the current policy is sufficient.


(no change in policy was meant - hopefully that was clear from the context)

> Well, no, the expectation is clearly being set that anyone can add
> themselves to the proposal on the wiki, and I for one vote to approve
> a proposal based on both the wiki and the emailed content.  If the
> emailed version is different from the wiki, then that will get a -1
> from me simply because they are inconsistent.


i agree that the problem is the expectation and not the policy

so let's fix the expectation

> > ATM the proposal on the wiki is not normative. the sponsor votes on
> > the
> > proposal as submitted to the list. this proposal contains a number
> > of names
> > proposed as initial committers. the sponsor votes to accept the
> > proposal
> > submitted including the list of initial committers. so, the list of
> > committers is specified by the proposer and approved by the sponsor.
>
> In theory, yes,  In practice, no.  A proposer should not be placed in
> the position of fighting a wiki-edit war for consistency when it is far
> easier for us to tell volunteers to be polite by asking the proposer
> for permission before editing *their* proposal.


+1

but again, this a problem with practice not policy.


> > what other goals would any new policy have in the area?
>
> Just a small bit of documentation for people preparing a proposal to
> inform them that they don't have to accept additional committers during
> the proposal process.


that would be my preferred solution. i just don't see why it needs to be
formal policy.

> There is a serious social disconnect here: people
> who are making a proposal are extremely sensitive about pissing us off,
> and will tend not to reject an added committer even when they know that
> person is not qualified or is deliberately attempting to steer the
> project in a direction that it may not want to go.
> We need the policy
> to protect new proposals from being unduly influenced by our already
> established mindset.

we don't need new policy which just re-iterates the old. what we need is
appropriate documentation describing how the process should work. (we also
need to clean out the cruft so that people can see what policy we actual
have but that's a slightly different issue.)

i've added some more documentation that i hope will help to address this issue.

http://incubator.apache.org/guides/proposal.html#template-initial-committers
http://incubator.apache.org/guides/participation.html (draft guide to
incubator netiquette)
http://incubator.apache.org/guides/proposal.html#developing

please review and suggest or patch improvements

if anyone feels that a policy reaffirmation is still necessary, then
please create a patch in JIRA and start a VOTE.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to