Christian Scholz wrote:
Martin Aspeli wrote:
Christian Scholz wrote:
To me it's unclear when coding should be happening. In practice it
might be in various ways. You might have a component already because
you needed it and want to get it into the core or you just have an
idea and only want to start coding once people think it's a good idea.
I think there are two modes:
1) Code already exists (e.g. a third party product) and the PLIP
submitter wants it improved and integrated into the core. In this
case, there's little code to write, except some integration code maybe.
2) New functionality or improvement to existing core-only
functionality. In this case, I don't think we should expect people to
write much code before the PLIP is reviewed and accepted in
principle, since otherwise they could be wasting their time.
I think so, too. The question is of course how much time is available
between PLIP submission and code submission. Maybe for #2 we need some
slightly different process where people should talk about their ideas
a bit sooner, e.g. before they write the PLIP or at least somewhat
before they submit it.
People can already do that: that is what the mailinglists, sprints and
irc are for. We also already have a separate decision point in the
release process where the basic concept and desirability of a PLIP is
decided upon. I am not convinced we need more process: complex processes
do not work in a project like Plone. I think we have all the parts that
we need to have already, but we just need to become better at using them
properly.
We have rough timescales, and 3.1 has (had?) a published release
date. However, that's no good when deadlines slip. We need to ensure
we hit a certain amount of work (code + QA) otherwise our releases
suck. The outside world is not going to look kindly on a release that
is "on time" to a deadline we arbitrarily set but which is majorly
buggy, completely underwhelming feature-wise or shoddily integrated.
I meant more that we should define (and document) the timespans
between releases are happening so everybody knows when the next chance
and deadline is. For 3.1 I know now, for the next releases I don't.
We can't do that until a single release becomes more predictable. The
3.0.x releases have been very predictable (every month around the 10th)
except for 3.0 where the summit complicated things. 3.0 slipped for
various reasons, and 3.1 which was completely designed to be simpler and
more predictable is already slipping by two weeks. As long as that
happens it is impossible to set useful schedules for releases beyond the
upcoming release.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
