Hi Jon,

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 insoluble problem.

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

Reply via email to