> -----Original Message-----
> From: Peter Neubauer [mailto:[EMAIL PROTECTED]
> Sent: 26 September 2004 11:06
> To: [EMAIL PROTECTED]
> Subject: RE: [VOTE] Stephen McConnell as a committer
>
> On Sun, 2004-09-26 at 08:24 +0900, David Leangen wrote:
> > I know I don't contribute much to the project. I am merely a user
that
> began
> > using Avalon recently. I hope to become a contributor to the
project,
> but
> > for now, I'm not. So, it's probably not really my place to make any
> comments
> > here.
>
> Thanks David for that reply. It is exactly that position that I am
> myself and that made me pull off this vote in the first place.
>
> As for users/non-committers being part of the community, at least
> 1.whoever can start a vote,even a user
> 2.whoever can vote, even a user
> 3.only votes from members of the "community" (which is to be defined,
> but I think in this case accepted committers) are counted. Which I
think
> highlights your point about who is counted part of the community.
Traditionally the ASF notions of a committer is someone who cuts code -
goes thought the cycle of submitting patches, get known by other
committers, and at some point gets voted in. Another view is to
consider community as the group of actively involved individuals that
have a stake in the success of a project. Perhaps breaking this out into
bullet points is a better idea:
* "actively involved" - mean that if your not actively involved
somehow the notion of yourself as a committed dissolves (I have
a mental model in mind that provides for some sort of half-life
principal where each year community members refresh the active
list - non-active members are tagged as dormant, and dormant
members drop of the end (and into the pages about project
history and acknowledgements)
* where "involvement" - is not limited to cutting code - for
example, contributing to product and project documentation,
providing assistance to other users, perhaps someone
representing company providing commercial support, training,
etc.
* and where "having a stake in project success" is the uniting
factor that when combined with qualification of activity -
establishes the specific rights within the community including
the right to binding vote, the right to veto, etc.
> The other question I think is relevant here is how long/much vetos are
> valid and why they are for lifetime right now, which can lead to
> inactive members of the community blocking progress because of old
> merits.
>
> It would be great if a project could be able to renew itself on it's
> own, and not, as it seems now, be forced to rebrand, refocus, restaff,
> relocate just to get on with some new thoughts on the same base
concept,
> as it is with Excalibur etc.. To me, it seems that this is a waste of
> effort and above all distracting for users that will have to keep
track
> of which new project the driving people are heading off to right now
> because the current project is blocking their thoughts, not on
technical
> grounds (which could lead to forking) but on political reasons.
Well - this one is tricky because it's a little loaded - but all the
same it's worth investigation. Looking at things from a pure procedural
point of view you have this thing called the PMC (Project Management
Committee). The PMC members are responsible for the active management of
a community. So in principal, the PMC can get in there and do active
management.
Cheers, Stephen.
> /peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
