----- Original Message -----
From: "David Crossley" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 23, 2006 11:51 AM
Subject: Re: Community health
David Crossley wrote:
Thorsten Scherler wrote:
> David Crossley escribi??:
> > Ross Gardler wrote:
> > > However, there are more general community issues here as well, and
> > > I
> > > would like to look at them. Here are three community observations
> > > (and
> > > as far as I am concerned the really important part of this):
> > >
> > > 1) Some people seem to feel that the normal ASF meritocracy is not
> > > sufficient credit within Forrest. Why should Forrest be different
> > > from
> > > other ASF projects? Do we need to do something different?
>
> Hmm, what is your definition of normal?
See the end of my previous email in this thread.
In my copius spare time i plan to add a section
to our project guidelines to define exactly
how we currently acknowledge contributions.
Then we can discuss in a calm manner whether
any of that needs changing. Or hopefully each
one of us can fine-tune and edit that in
the normal opensource fashion.
Okay i have made an attempt to capture how we
currently do this. Not yet published to the site,
so look at your local copy.
cd site-author
svn up
forrest run
http://localhost:8888/guidelines.html#way
http://localhost:8888/guidelines.html#contribution
"Lazy approval" applies.
That looks pretty good to me and something I am happy
to go with as is.
The bullet points in #contribution are spot on and I
feel that these need to be followed as much as
possible. Quick response times in some of these points
are expecially important - like responding to and applying
patches. This may seem a chore to those that want to concentrate
on their own Forrest agendas and code code code, applying
other peoples patches distract attention from their own work
and can be off-putting.
My wife knows only too well that
when I deep in coding thought, that only something important is
worth getting me out of the zone. :)
Of the 12 Active Committers, probably about 7 of those are what I call at
the moment Currently Active Commiters, of those 7 I dont remember how many
are committing other contributors patches.
Is this enough do you think, considering the current speed of development of
0.8 and the need to support and patch 0.7 ?
Maybe, to reduce pressure of the busiest committers and to let them get on
with their own coding, maybe there should be an initial level of Committer
that is not a PMC member until such time as they would normally be voted in
as is current a Committer/PMC Member. This level of Committer only will
allow for more contributors to help by applying other peoples patches and
reduce the workload for others currently doing the job.
http://localhost:8888/guidelines.html#elect states already
<quote>
...However, there may be extraordinary cases where we want limited
work-related commit access (not also a PMC member)...
</quote>
Maybe the PMC should think about this NOT being 'extraordinary' but as a
'trial period' of Committership before full PMC Membership. Give
contributors the chance to gain this level of entry based on the rule that
their priority is sorting through JIRA and applying relevent patches.
This, of course, boils down to the trust factor, who would you trust that is
not already a Committer, to become one and have access to the repository
with ballsing up all the code and other committers/contributors work. By the
time someone gets to this level of trust, I guess is when you would vote for
them to become PMC/Committer in the first place.
Ah well, something to think about anyway. And yes, I have seen previous
discussions about this in the past and remember them well. Just a timely
reminder :)
Second point (hmm, so all the above is just one point!) , how about their
being hyperlinks to Contributors/Committers sites within the changes
document. Seeing a load of [TS] [RDG] [DC] etc all over the place is hardly
informing to the outsider.
So, at the end of all that ...
confirming my lazy non-binding +1
Gav...
-David
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.6/288 - Release Date: 22/03/2006