On 7/15/07, Eric Y. Kow <[EMAIL PROTECTED]> wrote:

And finally a silly opionated rant

I overlooked your rant until this morning.  It's a good rant though.

----------------------------------
Also, maybe those of us on the fringe (who are not busy drawing crazy
commutation diagrams) should invert our priorties.  Our efforts should
be spent bashing away at the bug tracker, finding *easy* things to fix
and getting rid of that stuff first.

I think you're right.  Whatever we're doing now, isn't working so
well.  It seems that everyone that is a contributor at the moment is
something else first and second and a darcs contributor third (or
worse?).  This probably has an impact on the amount of contributions.

It's an issue of bang for buck, similar to the idea that anything which
takes < 2 min should be done immediately because the time it takes to
put it on your todo list, or to keep recyling 'crap, I have to get
around to that' in your head is colossal with the two minutes it would
have taken to get it over with in the first place.  Having things rot in
our bug tracker is like a perpetual 'crap, I have to get around to
that'.  It also obscures away the true issues, drowning away the really
worrying stuff in a sort of noise.

Yes, increasing through put is probably a good thing at this point.
Regardless of how deep or tricky the problem really is.

Perhaps fixing the easy stuff will be better for darcs's popularity,
which will in turn inspire more people to become developers.  And
besides, new easy stuff to fix (and to train developers with) is a
highly renewable resource.  Just ask Zooko.

I keep hoping people from #haskell will take more interest and help
out.  Stefan the other day commented on the source and theory being
impenetrable to him in it's current state.  Making things more
accessible to new developers should probably be a meta goal for anyone
contributing to darcs at the moment.  And if you're thinking of
contributing, ignore conflictors and mergers.  They are going away and
they're not worth learning about (unless you find it interesting to
learn why they don't solve the problem).

(*) although as one redditor has already complained, we don't have
    a notion of priorities.

Perhaps we could use a "roadmap" and a big picture
guidance/documentation.  I don't see how it could hurt.

Jason
_______________________________________________
darcs-devel mailing list
darcs-devel@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-devel

Reply via email to