Jon Stahl wrote:
One of the symptoms of that is the fact that some of of key components
lack committed long-term maintainers. I think that's in part because we
haven't done a great job of articulating where we need more hands, and
how to get folks involved.
That's probably true. However, we need to have a model where we don't
have a single point of failure on any one contributor. We need to ensure
that our code is of a high enough quality that people other than those
who wrote it can pick it up and maintain it. That's judgement sits with
the framework team, of course.
On the plus side, I think we have a really excellent and fast-growing
pool of talent that is on the cusp of being able to make really great
contributions to the core, but we don't have a good, systematic approach
for bringing those folks in.
That's very true.
For example, I think we are missing a trick currently with the way we
manage maintenance releases. We do a good job of setting deadlines and
not missing them by too much. What we don't do, is build any sense of
urgency or importance around getting things done for those deadlines.
We give people windows to hit if they happen to have something "in
progress". This consists of one or two emails to the list. That's only
half the story though. We need to think much more constructively about
the process people go about in getting something going in the first
place, and encouraging that.
The sentiment right now is one of "well, tough" if you don't get
yourself organised for an arbitrarily set deadline. That's discouraging
to a lot of people, myself included. We need to ensure that people feel
valued and honoured for their contributions, whether it is in fixing
bugs or in proposing new features, and be constructive in our criticism
and "management" of those contributions. People's spare time is a
precious resource, and we shouldn't take it for granted.
I'd love to see this conversation continue. It is definitely not an
No, it's not. However, we will need concrete proposals for anything to
happen. I think we pretty much agree on where the pain points are.
Finding the energy to address them is much harder.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Framework-Team mailing list