[Framework-Team] Re: Review process: suggestions, and an offer
cs at comlounge.net
Thu Feb 7 15:26:20 UTC 2008
Martin Aspeli wrote:
> Hi Graham,
>> Excuse me chipping in, as an interested observer. Some suggestions,
>> and an offer...
> No excuses! Thanks for contributing!
>> Suggested order of things
>> Assuming that Plone 3.2 will be succeeded by 3.3:
>> 1) draft a PLIP
>> 2) state the realistic date when the PLIP will be ready for review
>> (ideally, avoiding a last minute schedule)
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 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).
> The problem with this is that people won't even do the PLIP work unless
> (a) they're at a sprint doing it or (b) there's a deadline looming.
> Everyone does lots of things, and core Plone PLIP work is only one
> responsibility/interest. The deadlines must come first, I think.
>> 4) willing reviewers associate themselves with both (i) the PLIP and
>> (ii) version 3.2 or 3.3 of Plone
>> 5) each reviewer states the realistic date when they expect to
>> complete their review (again, avoiding a last minute schedule)
>> 6) voters consider four things: the PLIP, the Plone version timeline
>> (s), the review team for the PLIP, and the reviewer's schedule
> Again, this is tricky since by the next version of Plone, your PLIP may
> need rewriting. For developers, targeting a specific Plone version is
> normally a lot easier.
>> 7) vote
>> 8) the PLIP is (a) accepted for 3.2, or (b) deferred for later
>> consideration (3.3 and beyond), or (c) rejected.
> This can happen as the outcome of the current process. I think the only
> difference is that the schedule is known in advance. This helps people
> plan and make sure their time is spent efficiently.
>> The word 'submit' appears nowhere above, slot that in wherever it's
>> most appropriate.
>> The offer
>> Allow use of our CalDAV server by people involved with PLIPs
>> * I suppose that equates to, accounts for the framework team, plus
>> accounts for PLIP submitters and reviewers who are not on 'the team'.
>> I can't _promise_ that -- I should clear it with management where I
>> work -- but I don't imagine any objection.
>> <http://centrim.mis.brighton.ac.uk/more/h/faq/icalendar> for a rough
>> list of iCalendar-savvy software.
> I'm not entirely sure the existing review process is defective. I think
> the execution of the process is more at fault here. I think it *could*
> be a problem if the team was completely overloaded with PLIPs, but in
> that case we should be seeing some reviewed PLIPs and some unreviewed
> ones. Right now, nothing is completely reviewed and only a few PLIPs
> have begun to be reviewed, from what I can see.
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
> 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:
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 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 cs at comlounge.net
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
connect with me: http://mrtopf.de/connect
More information about the Framework-Team