Hi!
Martin Aspeli wrote:
Christian Scholz wrote:
(sorry, hit send too soon)
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.
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.
I also think the process needs to be better documented. As stated
elsewhere I had no idea what submitting a PLIP means and I just
changed the WF state which apparently wasn't the right thing ;-)
It would be good to maybe have different documents for the parties
involved what they have to do plus a high level document with the
milestones.
Personally, I would prefer a single document, which is easier to keep up
to date. But we need to do this, definitely. I'm willing to help draft
this if Andi and Wichert can join me.
Maybe it should also be easier to find, e.g. at dev.plone.org (at least
with a link). BTW; dev.plone.org only give a directory listing right
now, maybe it should redirect to /plone ?
And of course this calendar should be in somebody's responsibility
(preferably somebody from the framework team or the release manager).
+1
(and if people want to use the Google Cal I am happy to hand it over. It
has some setup in terms of an HTML output via feedburner and might have
some Pipes for filtering soon, too).
-- Christian
--
Christian Scholz video blog: http://comlounge.tv
COM.lounge blog: http://mrtopf.de/blog
Luetticher Strasse 10 Skype: HerrTopf
52064 Aachen Homepage: http://comlounge.net
Tel: +49 241 400 730 0 E-Mail [EMAIL PROTECTED]
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
connect with me: http://mrtopf.de/connect
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
