Project Diversity Guidelines

[Marnie McCormack <ma...@googlemail.com>]

Hi All,

Some of you with long memories may recall previous threads about project
diversity.

At the end of one such debate, I put forward some ideas about what items
might benefit from some good practice guidelines (see below).

My special interest is Qpid, as I'll happy submit, and the discussion
previously raged about diversity measures for graduation. There was much
debate, and support for subjective assessment. All good stuff, but I'd like
to capture the kinds of best practices measures people used in that debate.

I'd like to pull some documentation together to flesh this out. *Would
anyone care to work with me on this, and then I'll bring it back here for
review/discussion/contribution ?* I was hoping for the gnarly wisdom of an
old-timer :-)

What do you think ?

Thanks & Regards,
Marnie

My previous post was:

Hi All,

I can definitely see the value in having rules that allow for discussion and
some subjective assessment of podlings by the IPMC.

I think some additional detail (best practice style ?) around what a diverse
community looks like from various angles would be really helpful for podling
projects. Some of the angles discussed recently came as a surprise to me and
it'd be good to see what other people's suggestions would be.

For example:

- Committer activity over a given period i.e. what should this look like,
how diverse should this be, what would a problematic position be, on
trunk/branches etc ?

- PMC make up. We've taken a slightly different approach to PMC composition
(no bar to entry beyond the committer bar, but on a committer requested
basis), thinking it applicable. Recent discussions have highlighted that the
PMC make up is perhaps more important than general committer composition on
a project and thus we should strive to make it diverse by encouraging
(nominating) committers on to the PMC for diversity reasons ?

- Code vs documentation weighting. Some projects have contributers whose
focus is specialised in a particular area like documentation. What do we
include when considering diversity from this perspective i.e. document
changes, svn commits, JIRAs created, release management tasks

- List contribution. I think this one is tricky to measure, as we all have
different ways of working. Some of us (me :-) speak a lot, others less so
but perhaps in a more precise fashion and are effective. We include list
contribution as one of the factors assessed before committer-ship. I'd have
hoped that would be enough, but maybe not all projects assess this in the
same way ?

In conclusion, I can see that no objective bar applies in some of these
areas. I do think that the IPMC (and others) views on what a good example
looks like or what some differing, but diverse, projects look like would be
helpful.

I've left out 'legally independent' (argh) but I thought that the idea of
salaried % was a good one.

Maybe there's some scope for a set of measures and a guide around the
must-haves & the nice-to-haves and some idea that you must not fail the
diversity check on more than x nice-to-haves ?

Re: Project Diversity Guidelines

[Marnie McCormack <ma...@googlemail.com>]

Hi Niclas,

Thanks for your feedback, sincerely. Appreciate the time taken.

I'm really not a process junkie and I'm definitely not trying to impose any
ideas here. This suggestion is really off the back of a few items coming up
during our previous graduation debate which were quite a surprise to us at
the time.

My view is that this kind of info might be a useful contribution, from the
pov of our podling and the other incubating projects.

Please don't all flame me at once, but the docs on the incubation process
are not always as detailed as they could be. This is an area I thought I
could help with (docs being a thing of mine).

I'll wait to see if anyone else has a view and then decide what next ! I'd
be happy to simply get the tuppence worth from our mentors instead if the
consensus is that this isn't a good idea .....

Thanks again,
Regards,
Marnie



On Wed, Sep 24, 2008 at 4:28 AM, Niclas Hedhman <ni...@hedhman.org> wrote:

> On Tue, Sep 23, 2008 at 11:45 PM, Marnie McCormack <
> marnie.mccormack@googlemail.com> wrote:
>
> > Hi All,
> >
> > Some of you with long memories may recall previous threads about project
> > diversity.
> >
> > At the end of one such debate, I put forward some ideas about what items
> > might benefit from some good practice guidelines (see below).
> >
> > My special interest is Qpid, as I'll happy submit, and the discussion
> > previously raged about diversity measures for graduation. There was much
> > debate, and support for subjective assessment. All good stuff, but I'd
> like
> > to capture the kinds of best practices measures people used in that
> debate.
> >
> > I'd like to pull some documentation together to flesh this out. *Would
> > anyone care to work with me on this, and then I'll bring it back here for
> > review/discussion/contribution ?* I was hoping for the gnarly wisdom of
> an
> > old-timer :-)
> >
> > What do you think ?
>
>
> *I* think that quite a lot of us don't want any more rules and guidelines,
> and are quite happy to have a subjective view on whether a podling is ready
> to graduate. The driving force, IMHO, should be that the Incubator PMC
> doesn't *want* podlings to hang around for long, and basically should push
> them into a graduatable state.
> From the podling's perspective, an important part is to have and keep
> active
> Mentors. If they are AWOL (which happens to all of us at times) yell and we
> will try to find new ones. If you can find other ASF committers and Members
> interested to participate in your mailing list discussions, then that would
> be an enormous help in my subjective view of readiness, as their word would
> weigh in heavily.
>
> As for more documentation; I am -0 on that, but I guess Craig and Martijn
> will probably jump at the opportunity ;o) Documents are hard to write and
> even harder to keep up-to-date.
>
>
> Cheers
> Niclas
>

Re: Project Diversity Guidelines

[Marnie McCormack <ma...@googlemail.com>]

Meant to add that I'm feeling a chill over the idea of more docs here, so
I'll be off back to Qpid and poll our mentors instead :-)

Thanks Niclas & Craig,
Marnie

On Mon, Sep 29, 2008 at 1:18 PM, Marnie McCormack <
marnie.mccormack@googlemail.com> wrote:

>  Hi Craig,
>
> <snip>
>  One thing that would help, especially in the case of qpid, is to document
> whether the committers feel that they are independent. That is, whether they
> would continue to contribute to the project on their own time even if their
> employer reassigned them to a different project.
> This is a great idea, and probably a more useful measure (in some ways)
> than simple employer disclosure. (Not that I have any desire to open up the
> suppurating sore that that discussion is !)
> We could list this on our graduation resolution, particularly where
> people's affiliation is not listed.
>
> Thanks for your input,
> Regards,
> Marnie
>
>>
>>>
>>>
>>> Cheers
>>> Niclas
>>>
>>
>> Craig L Russell
>> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>

Re: Project Diversity Guidelines

[Marnie McCormack <ma...@googlemail.com>]

Hi Craig,

<snip>
One thing that would help, especially in the case of qpid, is to document
whether the committers feel that they are independent. That is, whether they
would continue to contribute to the project on their own time even if their
employer reassigned them to a different project.
This is a great idea, and probably a more useful measure (in some ways) than
simple employer disclosure. (Not that I have any desire to open up the
suppurating sore that that discussion is !)
We could list this on our graduation resolution, particularly where people's
affiliation is not listed.

Thanks for your input,
Regards,
Marnie

>
>>
>>
>> Cheers
>> Niclas
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Project Diversity Guidelines

[Bertrand Delacretaz <bd...@apache.org>]

On Sun, Sep 28, 2008 at 6:28 AM, Craig L Russell <Cr...@sun.com> wrote:

> ...One thing that would help, especially in the case of qpid, is to document
> whether the committers feel that they are independent. That is, whether they
> would continue to contribute to the project on their own time even if their
> employer reassigned them to a different project....

Agree with that.

If the project includes a "why we think the project would survive if
X/Y stop being interested in the project" statement, backed by the
mentors, with their graduation proposal, that would help the incubator
PMC make up their mind.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Project Diversity Guidelines

[Craig L Russell <Cr...@Sun.COM>]

Hi Niclas,

On Sep 23, 2008, at 8:28 PM, Niclas Hedhman wrote:

> As for more documentation; I am -0 on that, but I guess Craig and  
> Martijn
> will probably jump at the opportunity ;o)

Well, thanks but no thanks. ;-)

My views are similar to yours. Diversity is a subjective thing, and  
every member of the incubator PMC probably has a different point of  
view. That's both good and bad, for good and bad reasons.

> Documents are hard to write and
> even harder to keep up-to-date.

+1

The thing that I would focus on is whether the project would survive  
if one or more of the participating entities in the project were to  
pull the plug, i.e. stop funding the developers. Having diversity,  
meaning independent committers, means that the project is more likely  
to survive the loss.

I think that Marnie brought up many good examples of evidence of  
participation, including participation in writing features, submitting  
bug reports, submitting patches, writing documentation, discussing and  
voting on potential new committers, voting on releases, discussing new  
features and bug reports. Given a list of participants, evaluating the  
diversity of these active participants is necessarily subjective.

One thing that would help, especially in the case of qpid, is to  
document whether the committers feel that they are independent. That  
is, whether they would continue to contribute to the project on their  
own time even if their employer reassigned them to a different project.

Craig
>
>
>
> Cheers
> Niclas

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Project Diversity Guidelines

[Niclas Hedhman <ni...@hedhman.org>]

On Tue, Sep 23, 2008 at 11:45 PM, Marnie McCormack <
marnie.mccormack@googlemail.com> wrote:

> Hi All,
>
> Some of you with long memories may recall previous threads about project
> diversity.
>
> At the end of one such debate, I put forward some ideas about what items
> might benefit from some good practice guidelines (see below).
>
> My special interest is Qpid, as I'll happy submit, and the discussion
> previously raged about diversity measures for graduation. There was much
> debate, and support for subjective assessment. All good stuff, but I'd like
> to capture the kinds of best practices measures people used in that debate.
>
> I'd like to pull some documentation together to flesh this out. *Would
> anyone care to work with me on this, and then I'll bring it back here for
> review/discussion/contribution ?* I was hoping for the gnarly wisdom of an
> old-timer :-)
>
> What do you think ?


*I* think that quite a lot of us don't want any more rules and guidelines,
and are quite happy to have a subjective view on whether a podling is ready
to graduate. The driving force, IMHO, should be that the Incubator PMC
doesn't *want* podlings to hang around for long, and basically should push
them into a graduatable state.
>From the podling's perspective, an important part is to have and keep active
Mentors. If they are AWOL (which happens to all of us at times) yell and we
will try to find new ones. If you can find other ASF committers and Members
interested to participate in your mailing list discussions, then that would
be an enormous help in my subjective view of readiness, as their word would
weigh in heavily.

As for more documentation; I am -0 on that, but I guess Craig and Martijn
will probably jump at the opportunity ;o) Documents are hard to write and
even harder to keep up-to-date.


Cheers
Niclas