[darcs-users] growing the darcs team

[Jason Dagit]

On Mon, Sep 1, 2008 at 2:28 PM, Eric Y. Kow <eric.kow at gmail.com> wrote:

> Development model
> -----------------
> 1) David Roundy will be the maintainer of the new darcs
>   unstable repository.  This will be made available
>   shortly at http://darcs.net/unstable

How will this work if http://darcs.net/ is the stable repository?  Are
we going to endorse the usage of nested repositories?  I still feel
like this is a potentially dangerous feature.  Especially with issue27
still lurking.  Do we guarantee that darcs will not manipulate things
in the sub-repository?

> 2) Eric Kow will be the maintainer of the stable repository
>   http://darcs.net

Congratulations Eric!

> 3) Patches will typically flow from unstable into stable.  However, if
>   Eric feels that patch is obvious and not likely to require
>   discussion, he will apply it directly to stable.  For the moment,
>   Eric only considers code comments, documentation and test suite
>   modifications to be obvious.

Send in your haddock people!  Give Eric something to keep him busy :)

> 5) This has always been true, but it's worth stressing again.
>   *Everybody* is encouraged to review incoming patches.  This extra
>   review helps contributors because they get more than one
>   perspective on the code, and also because it helps patches to get
>   accepted faster.  Also, reviewing patches is one of the best ways
>   for you to to learn about darcs!

Hmm...I think we need a better solution here.  It's commonly said on
the mailing list that everybody should review patches, but it still
has never become a reality.  Thus, I'm skeptical that asserting it
again will help.  Here I outline the obstacles that I see in the way
of realizing this goal, then I give some potential fixes.

Problems:
--------------

1) I think the basic problem is that there is no motivation for people
lurking on the list to review patches.  I also think that the patches
which need the most review are the ones that require the greatest
effort to review.  This means that social loafing is even more likely.

2) Something I've experienced is that I tend to compartmentalize my
time for darcs hacking.  I may only be able to review patches, for
example, on Tuesday evenings.  Which means that the maintainer may
have already applied the patch by the time I even think about
reviewing it.  While I like there to be quick turn around on patch
application this is in conflict with the notion of giving people a
chance to review the patch.

3) The next problem I've seen with patch reviewing is that the mailing
list is in my opinion a bad forum for the discussion.  I would much
rather see us adopt a tracking based solution.

Suggestions:
------------------

1) I think people would respond well to fun but intangible rewards.
We could start with a thank you list every week or two weeks declaring
how many patches each person reviewed.  Karma based systems have also
become popular on social sites, maybe your karma is the number of
patches you've reviewed.  Going further, maybe there is some fun way
to spend karma.  We could apply this principle to other aspects of
contribution like, bug reports, bug tracker gardening, bug fixes, test
case or unit test contribution, etc.  We could also have the
maintainer prioritize the application of patches based on karma.
Contributors with higher karma get faster turn around, and hence more
motivation to review patches.  No punishments are allowed, only
bonuses and perks.  The idea is that people never feel penalized for
being a newcomer or casual contributor, but they can always increase
their influence and success by helping out.

2) I think that #2 and #3 are related.  I'm not a fan of heavy
technical solutions, but perhaps this is a good place to apply a
technological solution.  Some things I don't like about our current
model of patch acceptance:
a) Most email clients don't seem to send the patches in a way that the
average email client displays the contents.  This makes just a tiny
bit more annoying to see what's in the patch --> less likely to look
at patches.
b) Finding the discussions related to a patch requires the user to
search the mailing list or keep threads in their email client.
c) It's not always easy to tell what others are doing with respect to
a given patch.  Have they applied?  Do they accept or reject it?

Based on a, b and c, I would like us to adopt an official patch
tracking system.  In an ideal world this patch tracker could apply the
patches in the bundle directly to your maintainer repository, everyone
would agree that it's wonderful, it never has bugs and it always saves
you time, it tracks all the discussion about the patches, it groups
together superseding patch bundles, tells you who is still reviewing
the patch bundle, who wants to but hasn't started yet and different
people can vote up or down on patch bundles.  We should make patch
review more transparent, more organized and keep it simple.

Perhaps running a second instance of roundup that is just for patch
tracking wouldn't be a bad idea?  Maybe we need to modify darcs watch?
 I like that patches can be submitted via email and that they can be
commented on via email, these are great features, but I think we need
something that brings it all together and *tracks* the patches
w/feedback.  If I were maintainer I would want something like this.  I
simply wouldn't be able to track everything in just my email client.
This makes sense since my email client was designed with email in mind
not darcs.  I want to adopt a system with consensus and agreement.  I
don't believe in the current model therefore we already lack consensus
in the current system :)

> 6) Eric will also be serving as the new release manager.

So many hats!  What does a release manager do?  How can other
volunteers help you?

> 7) Darcs will now be switching to a new time-based release model
>   with new releases coming out every six months.  The first
>   release in this cycle will be in January 2009.  In the meantime,
>   we will work towards getting an intermediary release out to
>   fix bugs in 2.0.2 and to provide some performance improvements
>   through http pipelining.

This will be interesting.  I look forward to it as a positive change.

>  * Having a stable branch relieves some of the pressure for contributed
>   code to be perfect.  We know some developers feel that getting
>   patches into darcs is too difficult, and hope that having the
>   unstable branch can help some code become a part of darcs.  But let
>   us stress one point: we do not intend to give up on the rigorous
>   reviewing of patches, so please do be prepared to answer questions and
>   resubmit patches as usual!

I still wonder if it would be better to have three repositories,
darcs-core, darcs, and darcs-contrib.  The first repository contains
things specific to patch manipulation and defines and exports a safe,
but low level, API for repository modifications.  The darcs repository
would include all the infrastructure for commands, fetching patches,
and applying them through the darcs-core api.  Then in darcs-contrib
we would have scripts people have found useful, additional
documentation, suggested configurations and that sort of thing.
Perhaps darcs-contrib is not needed to make a binary package, but
darcs-core and darcs are certainly needed to build darcs.  Darcs-core
could be how we define a libdarcs.

In this model, darcs-core would be David's domain.  Patches must be
more rigorously reviewed and changes done here affect the semantics of
darcs.  Then in darcs, we can be looser and accept more things.  This
could be someone else's domain such as Eric or myself.  Then, finally
darcs-contrib could potentially have multiple maintainers and it's
pretty lax over all.  The purpose of darcs-contrib is just to pool
together miscellaneous contributions from the community at large and
things are use at your own risk.

>  * Time-based releases (in conjunction with quarterly darcs hacking
>   sprints) will force us to finish a small number of key goals at
>   a time.  Users will see more regular progress from the community,
>   and we will hopefully see them using our more recent work.

Yay!

> We hope you'll like these changes.  Please let us know what you think!

Gladly :)

> Thanks,
>
> David and Eric

Thank you!
Jason