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

[Martin Aspeli]

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

+1

>>> 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.
> 
>> That said, having clear timelines is a good idea. Andreas did in fact 
>> publish an iCal file with the deadlines. I fear that doing project 
>> management on a per-PLIP basis adds more overhead than value, at least 
>> if people don't actually "live" the project management software and take 
>> the deadlines seriously. Given that we don't do this full-time and are 
>> at the mercy of other events from time to time, it's hard to make 
>> realistic and exact predictions about when a specific PLIP will be 
>> reviewed. Last year, I did virtually all of mine in a single evening.
> 
> I also did a Calendar with Google Calendar:
> 
> http://mrtopf.de/blog/plone/the-plone-release-calendar/
> 
> I am also playing around with Yahoo Pipes to create some filters etc. It 
> would definitely be good to have a synchronized calendar to see what 
> deadline (relevant to you) is coming up next. For me it would be the 
> date when the PLIPs should be ready, when implementation and when the 
> release is supposed to be released.
> 
> 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).
> 
> 
> -- Christian
> 


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