[Framework-Team] Re: random thought: identify the components that lack owners

[Martin Aspeli]

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