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

[Martin Aspeli]

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)
> 
> 3) potential reviewers consider timelines for versions 3.2 and for  
> 3.3, and the date promised

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.
> 
> Critically:
> 
>   * the reviewing process, which can't be done without reviewers, is  
> clearer _before_ votes are cast.

That would be useful, I think, except that the review burden depends on 
what is accepted.

Also, voting has to be in two stages - 1) is the PLIP a good idea 2) is 
the implementation acceptable.

> A deferral need not reflect upon the value of a PLIP; review and  
> other factors are considered.

The value of the PLIP in any case deprecates over time as the codebase 
it was written for changes.

> Re flexibility of timeline etc. (the KSS discussion was interesting),  
> I'll step nearly all the way back, with just one comment:
> 
>   * a most thorough (least rushed) review will minimise the risk of a  
> change or addition to Plone adversely affecting an add-on product.

Of course, but this varies widely by PLIP too. In the end, we rely on 
some degree of trust between reviewers and implementers. I know some 
developers who's code I'd review in more detail than others, for example. :)

> (I think of <http://dev.plone.org/plone/changeset/18891> - that  
> wasn't PLIP-related, but it does highlight the value of widespread/ 
> thorough testing.)

I don't understand how this is relevant to the discussion?

> 
> =====
> Offer
> =====
> 
> I normally cringe at the idea of project management software (!)  
> especially in relation to software development, but a simple timeline  
> view of things might help you at the voting stage and beyond.
> 
> Visualise, in iCal (or Outlook 2007 or Mulberry or Mozilla Sunbird/ 
> Lightning or whatever):
> 
> |---- PLIP draft
> |--------- PLIP submission
> |-------------- PLIP review
> |------------------- schedule of named reviewer #1
> |---------------------------- schedule of named reviewer #2
> |---------------------------------------- Plone 3.2 release
> 
> or something like that; you make your own choices re iCalendar  
> subscriptions
> 
>   * in an ideal world, everything above the 'Plone 3.2 release' line  
> should be well towards the left hand side, and voting will be easy
> 
>   * in the real world (work, moving, life in general) some PLIP- 
> related lines will lean to the right, in which case voting may be  
> more circumspect.
> 
> I'm about to purchase Project X software, here are screen shots of  
> its 'web app':
> <http://www.projectx.com/Larger%20Image%20Pages/Enterhours.html>
> <http://www.projectx.com/Larger%20Image%20Pages/Reviewsubmit.html>
> 
> That alone isn't ground breaking, but as Project X is now CalDAV- 
> enabled it should be possible (easy?) to gain iCalendar views of things.
> 
> Within three, maybe four weeks I should have at my disposal a CalDAV  
> server (Apple iCal Server in Mac OS X Server 10.5) ...
> 
> 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.

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.

Martin