[Framework-Team] Reworking the PLIP Lifecycle | discussion

[Elizabeth Leddy]

>
> Hi,
>
>
> at the risk of repeating myself: This all reminds me very much of
> handling submissions to scientific journals. They appear in regular
> intervals and have a review process in place to decide what goes in.
>
> One difference there, however, is how the review process is organized.
> Usually, you have one or several editors (think framework team) who receive
> submissions and do a first scan to see if a submission is within scope at
> all.
> If so, they typically ask one or several (three is quite common) peers
> to take a closer look and to provide a written review. Based on those
> review reports the editor(s) then decide about acceptance.
>
> So one major difference to our current process - if you compare the
> framework team to an editorial board - is that the FWT members would
> not need to do all the reviewing in detail but rather organize and
> judge the reviews. Who gets asked to provide a review is decided on
> a case-by-case basis and in practice adds up to many more than on
> the editorial board.
>
> Maybe such a model could work for us as well?
>

I think this goes to Ross's point as well. Holding back my opinions on how
whack-a-doodle the scientific journal process is in practice, I think the
main thing I worry about here is getting people to do reviews: framework
team members are hard enough. In addition they need to have some level of *
quality* and be *consistent*. Ok ok so maybe I am dragging in my issues with
scientific review process in the end :)

How about something in between? I'm totally talking off the top of my head
but what if each PLIP is required 4 reviews - 2 by FWT members (1 being the
PLIP champion and 1 additional) and 2 by external parties, which can be
chosen by the PLIP implementor. Then people can get plone street cred for
doing good reviews, and eventually get rotated on to the core team who gets
to eat cake and make big decisions. Hopefully by that time the "stigma of
suck" about being on the FWT will be gone.

Rotation could work in a million ways. I think/hope/wish upon a star that we
can do this in a voluntary matter. e.g. if you are busy, call in sick for
the month and just step back. If we are short on people, we call in backups
and/or expand. Ideally we have people championing 1 or 2 PLIPs each and if
your PLIP is in the hot seat then consider yourself required. There is some
level of passion that can be tapped here as well - if you want a feature bad
enough you'll find time to see it through the process.

There is a perfect place for this to start: the myriad of PLIPs just sitting
in SVN. If everyone picks and chooses through those PLIPs, big or small, and
thinks that they care enough about the feature that they are willing to
*personally* see it through the process, then we have an easy way to chop
through the 30+ PLIPs marinating in "meh" sauce. Then we can spend time on
calls discussing those borderline PLIPs that have limited or controversial
support and let the slam dunk ideas just pass through to the implementation
phase.

Going back to Ross's question, I suggest we start by recruiting 3 more FWT
members. We can get more at the Plone store later if needed. That's enough
to keep the FWT calls sane (at any time 20% will be missing anyways) and be
ready to handle the PLIP onslaught. To be honest I have no idea how
recruiting actually works so if there is an actual process let's get
started... yesterday.

Totally spewing brain at this point so I'm open to other ideas/variations.
In the meanwhile, I updated the original wiki to reflect 6 month cycle and
feature freezes after all the feedback. Releases scheduled for spring and
fall. Let's nail this last issue, compile, and see what the community core
dumps back.

Liz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20110228/ba050c8a/attachment-0002.html>