[Sugar-devel] [IAEP] stepping down as maintainer
quozl at laptop.org
Sun Oct 24 23:31:31 EDT 2010
Fascinating fragment ...
On Sat, Oct 23, 2010 at 11:42:24PM -0500, David Farning wrote:
> Sugar Labs is lead by veto rather than vision. A _symptom_ is the
> development process. It it easy to have fix commited to Fedora or
> OLPC. It is hard to have a fix commited to Sugar Labs. When someone
> sends a useful fix to either OLPC or Fedora, a senior developer takes
> the patch, review it, fixes it up (if necessary) and thanks the
> contributor. This provides an incentive and on-ramp for less
> experienced developers to participate and contribute.
> Sugar Labs rejects most patches.
Seems to be a 90% chance, yes. ;-)
> Once a patch is technically correct, which can take several iterations
> for a new developer, it is forward to another developer for their vote
> of approval. The end result is that very few people bother to submit
> patches upstream.
Yes, you're on the right track here.
For other open source projects where I am maintainer, if a patch is
proposed which is nearly right, then I tend to merge it and correct it
rather than reject it. I'm often confused as to why Sugar maintainers
don't merge and correct rather than reject. I don't think it is due to
lack of time, since it can take longer to reply in detail than to merge
> The _disease_ is a marginalization of anyone who dissents. As a
> result no one is willing to take a risk. There is an unwritten
> checklist for participation.
In Australian culture, dissent is normal and anticipated, being embedded
with "fair go" and "underdog support" behaviours. Being a regular
dissenter is one of the reasons I enjoy reviewing patches. I'm not a
maintainer of any Sugar components. I don't get to merge the patch, but
I can still reduce the load on the maintainer by pointing out the
obvious ... giving the "underdog" contributor a "fair go", and treating
the maintainer as a "tall poppy" who isn't necessarily doing their job
More information about the Sugar-devel