Erik Huelsmann wrote:
> John/plasma's keywords-as-hash patch
> is a good example of how we currently are not stimulating patch
> contribution (IMO). Could (and should) the full committers be
> reviewing more patches and thus delegate more coding?
Being mentioned as part of this comment, I feel like I need to add my
thoughts. When I took up plasma's patch lo those many months ago
(goodness, it was Feb 2004!), I had no idea what I was in for. A lot of
the time that has passed since then was taken up by *me* not having
enough time to deal with it in a concerted push. I was also learning a
lot about how APR and a multilibrary program have to work; C is also not
my native language, and the project guidelines are fairly strict, so
that took some time too.
What would have helped me a lot was if someone could have reviewed the
proposed patches earlier, so that I would have performed a full rewrite
long before Max had to get involved (not that he isn't doing a very fine
job ;-). I took someone else's code and made it work with the current
code (for a sequence of values of "current"), but I was not made to
understand that the code as it existed needed more work. It wasn't a
matter of design (which survives pretty much unchanged from the original
discussion) but the strict nature of acceptable code.
There are itches that I still feel the need to scratch (see below), and
I'd like to continue to propose enhancements to the system. I am not
[that] discouraged, because I recognize that the project is better
because of the very tight reviews. But I found it very hard to interest
any core developer in even reviewing my patches, let alone aiding me in
improving them to the point where they could be considered for application.
I don't know if the core developers need to just set up a rotating
"reviewer" hat, where this week it would be one person's explicit task
to review patches and make suggestions. But having a patch review
depend on someone more experienced getting "interested" in the patch
doesn't work as well as it might on a simpler project.
In a more corporate environment, it would be appropriate to discuss a
mentoring scheme, where the newer developers would be explicitely
assisted in becoming more proficient with the project. I realize that
is not reasonable for an open source project, but I agree completely
with Erik that the current state isn't too open to new contributors.
Thanks for listening...
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Lanham, MD 20706
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Apr 26 22:08:10 2005