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

[Wichert Akkerman]

Previously Martin Aspeli wrote:
> 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.

Sure. Perhaps my view is a bit slanted because I am always working in
several different things at any point in time.

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

Deadlines are one of those things that you can't live without even
though you don't like them.

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

I suspect there is a lot of shared vision, but that we are not very good
at writing it down. Partially because we are afraid to since it might
look more like a dictate, and partially because we have no good process
for it. I think emergent visions are fine, but I do think we need to
set some solid directions.

I just wrote down a few pages on directions that I think we need to look
at and mailed those to the developers list.

> By the way, I suggest we call Plone 4.0 "Snow Plone" (like Snow Leopard, 
> geddit?).

I don't get it.. The naming for Plone releases has always been a mystery
to me but luckily we never actually use those names anyway. I don't know
why we bother :)

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

I know I am not always the most subtle person out there. It might be a
cultural thing - we tend to be more direct here. You do touch on 
something important though: we have almost no after-merge process. There
is no process for Q&A testing, writing or updating documentation for
changes, getting press and praise out, etc. This is becoming more and
more critical now that there is a growing number of projects that share
some of the problem/solution space that Plone is in. An awful tool
with excellent documentation will almost always win over an awesome tool
with lousy documentation. We have come a long way, but we still have
many miles to go.

>  - 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 have tried to align releases with events last year. It doesn't work:
there are too many and occasionally to move as well. We do have an
alignment with this years Plone conference: a Plone 3.2 pre-release
(good marketing) and PLIP review for 3.3 (excellent discussion ground)

> I don't think that overly formalising sprints will help (or work), but 
> we can probably just structure what we have slightly better.

I feel we need better sprints: fewer people, smaller focus, try harder
to get people with the right experience and long-term availability in
and make sure we get people with outside expertise in.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.