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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
