directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject [discussion] Lowering barrier for perspective committers
Date Thu, 06 Jul 2006 13:43:50 GMT
Hi all,


Over the past few weeks I've been thinking of ways in which we can
increase the participation of existing committers while attracting new
committers in a safe manner.


Our Problems
============

The number of active committers on Apache Directory Server is dwindling 
and we have many areas where a single developer has been working alone.
Some email threads have tried to address the issue of the lack of enough
committers in specific areas: see threads [0] & [1].  So we are
suffering mostly in the following areas:

o OSGi effort,
o Kerberos protocol development,
o Changepw protocol development,
o DHCP protocol development, and
o DNS protocol development.

Even the work being done on the LDAP protocol has too few people
involved.  Right now we have the following active LDAP committers:

Ersin Er
Emmanuel Lecharny
Stephan Zoerner
Alex Karasulu
Trustin Lee

(forgive me if I missed anyone)

We certainly need more people to be actively involved.  I see many
talented individuals that have been lurking, sometimes getting involved
to work on particular problems as they get the itch.  I'd like to
welcome these people and invite them to work on the core of the server
with us.  Sometimes we're finding it hard to keep up with the
contributions from these folks.  Some are very excited in working with
us and we often find our selves lacking the time to engage them.

As the PMC chair, I see these circumstances as warning signs.  They 
reflect a weakening community.


Possible Solutions
==================

Getting existing committers more involved and working on different parts
of the server is not so easy.  Knowledge transfer is needed to get them
and even others involved in parts of the server they are not accustomed
to.  For this I personally will start conducting some classes and
preparing materials for those interested in learning about the internals
of the server on some interactive medium.  The materials for these 
classes can also serve as a documentation update for our website so 
others can follow these trails.  It would be nice if other committers 
can also give some tutorials in their respective areas of expertise.

As for new committers, I think we need to lower the barrier for
committership while safely integrating these committers into our
committer base.  One key need is to provide the proper guidance while
reviewing their activity.  Up to now we've been getting several
contributions and many are just collecting up in JIRA.  Sometimes we
need a place for these people to work on new ideas like in a sandbox 
until they're ready to bring in their work into the main branches of 
development.  For this I propose a committer mentorship program while 
lowering the barrier of entry for new committers.

The idea is to use a review then commit (RTC) process on main branches 
of development for these new "probationary" committers (a.k.a. probies). 
  Commits to personal areas in the sandbox do not apply.  Hence any 
commit to main branches must be approved by a mentor.  The same rules 
apply for a veto.  A mentor has the responsibility to review the work of 
a probie in a timely fashion for this process to work however the probie 
can file the JIRA, apply approved patches and close it after the 
approval using their own steam.  This way we reduce the amount of work 
existing committers have to do on behalf of consistent contributors. 
Also the person with the itch can drive the change instead of being 
blocked waiting for a committer to get to their JIRA issues reviewed 
then applied.

Such a program gives regular contributors more power to affect the code 
base and creates a smoother path towards their becoming committers 
thanks to a lower barrier.


Possible Drawbacks
==================

o Needs some upfront initiative.
o More process to deal with?
o Will probies feel like second class committers? Are there social 
ramifications?
o Will this mean more work for existing committers?
o ... please add more here


Conclusions
===========

This idea is not exercised at the ASF in any project explicitly however 
some elements of it appear in various communities.  Usually communities 
at the ASF especially trust new committers that somewhat distrust 
themselves with code they are not familiar with.  A good new committer 
is someone who besides being consistent and active is careful enough to 
presume they are not always right, especially with changes to unfamiliar 
code.  Culturally, elements of such a process may unofficially be 
practiced at various projects within the ASF.  The problem with this 
approach is, the new committer is trusted yet expected to engage others 
if they are unsure of themselves.  This IMO puts a lot on the shoulders 
of new committers.

Considering our less than optimal situation, WRT the number of 
committers in this community, I think we need to formalize this process 
to facilitate more involvement from the contributor community at large. 
  Consider it a precaution against an active committer drought taken 
under extreme conditions.  I would like to vote on giving this process a 
try for a quarter to experiment and see how it works.

Hopefully formalizing this process under these circumstances will pull 
contributors on our periphery closer to the core team of active 
committers leading to a healthier community.


Thoughts? Comments?


Thanks,
Alex


-----

[0] http://www.mail-archive.com/dev@directory.apache.org/msg06255.html
[1] http://erudbery.notlong.com



Mime
View raw message