[Framework-Team] Re: Review process: suggestions, and an offer

Martin Aspeli optilude at gmx.net
Thu Feb 7 16:32:27 UTC 2008

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 also would like to have the PLIPs include more of the starting 
> process, e.g. usecase discussions etc. Also having the history of 
> submission, review notes etc. included might be good (or is this 
> actually the case? ;-))


>>> 3) potential reviewers consider timelines for versions 3.2 and for  
>>> 3.3, and the date promised
> I think we should have some time based deadline e.g. every 6 months 
> anyway. That way people know exactly when the next deadline is coming up 
> and they also know when the next one is should they not be able to meet it.
> It's only disappointing when there is not definite date set for the next 
> release. But I guess we agree that timespans like between 2.1 to 2.5 are 
> not what we want (plus the changes in that release and 3.0 have been too 
> big to comprehend by not so uptodate folks).

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

> And of course this calendar should be in somebody's responsibility 
> (preferably somebody from the framework team or the release manager).


> Having then a checklist of what that role has to do in the release 
> process might help, too (wiggy probably knows but somebody coming after 
> him probably does not know so well).



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

More information about the Framework-Team mailing list