incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: piling on
Date Mon, 31 Jul 2006 21:38:19 GMT
On 7/23/06, robert burrell donkin <robertburrelldonkin@gmail.com> wrote:
> On 7/22/06, Roy T. Fielding <fielding@gbiv.com> 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message