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

[Martin Aspeli]

Hi Wichert,

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

True. That's why I say "necessary, but not sufficient". However, as 
we've talked about before, I would prefer a slightly more consultative 
approach in setting deadlines. Sometimes that's hard, because you almost 
have to force people into the discussion. However, if the FWT and the 
community feel they had some part in actually setting the deadline, 
they're more likely to respect it.

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

Couldn't agree more. :)

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

That's excellent! I think we should encourage more of that kind of thing.

>> 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 :)

Heh, my point was more that we should think about what Apple are doing 
with Snow Leopard: trimming the fat.

>>  - 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 don't say... ;-)

I think we all need to be doubly aware of who we're talking to when we 
have a community as diverse as this.

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

Yeah, this is very important. I think it does tend to happen around 
releases, but mainly because you and Limi do it.

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

Yep. I think this is something to aspire to rather than something we can 
do in absolute terms.

Still, not wanting to sound like a broken record, but there's no point 
in setting a deadline if (a) people don't have enough forewarning to get 
themselves organised; or (b) we don't encourage people to organised, but 
rather rely on the deadline to do that indirectly.

That means things like what you just did on plone-dev - setting a 
vision; and it means asking people when they expect to be working on 
something and giving them a say (though not a veto) on deadlines and 
schedules - within reason, of course.

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

I think there are two types of sprints: Those that are organised and 
those that are just for fun. We shouldn't (and can't) stop people from 
getting together and doing nothing useful at all. After all, we don't 
own them. But when it comes to things like adjusting release schedules, 
opening a window for travel scholarships and so on, we can probably 
demand certain types of sprints. Just something as simple as a stated 
goal, "by the end of this sprint we want to have achieved X" will help 
focus minds and measure success.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book