Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
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.
I'm hoping that plonenext can help a bit with that. If people make a new
release the release manager can include that in plonenext, which makes
it immediately available to people developing against that. I have long
wanted a way to motivate people to make releases when they are ready
instead of only when I send out a call for releases. I'm hoping
plonenext will help with that.
plonenext will definitely help with that, but that wasn't quite what I
meant. This still assumes that people are actually in the middle of
working on something that they want to release.
Now, of course that happens some of the time, when there are external
drivers, such as customer projects that spin off generic components.
However, we are not doing enough to get people to start working on
contributions in good time.
On past experience, there are a few things that make this happen:
- Setting a deadline. This is a necessary, but not a sufficient,
condition. No-one does anything unless there's a deadline. However, by
the time the deadline is set, it's usually too late to *start* working
on something, so something has to be in progress (conversely, the
deadline is too far in the future, it doesn't feel like a deadline and
gets forgotten about).
I think this is in danger of happening for 3.3. Ask how many people feel
like there's a deadline coming up, and ask how many people feel they
have a responsibility to get something done for that deadline. I suspect
you won't get many replies.
- Setting a shared vision. I think this is what Jon is talking about.
We have talked about (and have even put into practice) having loosely
defined "themes" for a release, e.g. 3.2 is the "eggs" release. These
discussions tend to be led by a few people, e.g. you (Wichert), Alex,
Hanno, me. I think possibly could have some conventions for making these
discussions happen, e.g. a way to propose and then discuss themes.
By the way, I suggest we call Plone 4.0 "Snow Plone" (like Snow Leopard,
geddit?).
- Following up. Ask people how they're getting on. Make them feel like
what they're doing actually matters to other people. Alex has done this
in the past, but this is a bit too ad-hoc. The framework team could
feasibly do this for submitted PLIPs, but there's often a need to do
this before we have PLIPs also. I think this process has to be informal,
but we should encourage more of it.
- Lavish praise. If someone does something for Plone out of their
spare time, be that to fix a bug, contribute a feature, do some
pre-release testing, or documentation, or whatever - make them
understand that their contributions are appreciated by the whole
community. If someone makes a mistake, don't shoot them down for it, but
rather try to be constructive and appreciate that their feelings
probably will be hurt if we revert their changes. Sometimes we have to,
of course, but the way in which that message is delivered is an
important determinant for whether that person contributes again.
- Sprints! Making the best use of sprints is vital. We tend to lurch
forward during a sprint. The ideal sprint, IMHO, is one that has a clear
goal (the Baarn sprints have been great like that) and an appropriate
mix of people who are motivated to work towards that goal. We then find
that 80% of the functionality gets completed at the sprint, and the
remaining 20% gets done later.
We've talked a bit about aligning releases to sprints. We should
probably do it the other way too: align sprints to releases, or at least
to desirable releases. For example, we could say that our aim is to have
a "UI Sprint" each year for each release, and a "Release sprint" just
before each release to squash bugs and tidy up loose ends, and then an
"R&D Sprint" once a year or so to try out crazy things.
I don't think that overly formalising sprints will help (or work), but
we can probably just structure what we have slightly better.
Cheers,
Martin
--
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
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
