Hanno Schlichting wrote:
Where and how to manage PLIP's is both a matter of a defined process
and some software supporting this process.
One of the main driving reasons to move all Plone Core development
related information into Trac, was to have one place to manage and get
an overview of all relevant information. If we need to get an overview
of where Plone 3.3 currently is, we can only answer this based on the
status of certain tasks and bugs in Trac plus the information shown on
the plone.org/products/plone page. If you need to later find out what
small feature / plip or bug has been part of which release, it is
easier if all this information is in one place.
Now when it comes down to the exact software features of Trac vs. a
Plone content type, they are pretty much the same from what I can see:
- Notion of ownership of the plip by a user
- Assignment to a milestone / release
- Unique ID
- Short title
- Full text description
- Workflow state
What is different about these two:
- PSC has multiple text fields for various sub-headings, whereas Trac
only has one text field and the structure needs to be defined by a
template. The structure given by PSC has often been ignored, as
there's too many fields with unclear separation.
- PLIP's in PSC can only be edited by members of the plone core
development team, whereas tickets in Trac can be worked on by anyone
with collective write access.
- There's a more sophisticated specialized workflow in PSC for PLIP's
that doesn't match the reality. Usually I used to move things into the
appropriate stages all the time, but the workflow was largely unused
in practice. Since we upgraded to Trac 0.11, we can define a
specialized workflow in Trac as well, that could actually match our
- Trac has the ability to let users subscribe to tickets via the CC,
so you can get updates about the progress of a particular ticket.
Following this I don't see a clear win on the technical side for PSC,
but see Trac as more feature-rich and tailored to this particular
need. Another reason to move things out of Plone, has been the
particular slowness of plone.org. Commenting on PLIP's to cast votes
has been an utter pain in the past.
Now I do agree that what we have seen in terms of submitted "plip's"
in the last days is for the most part nothing that deserves this name.
however I don't see a software problem, but a problem in an undefined
or not-followed process here. What we have seen is for the most part
feature wishes, which at some points have been raised for the first
time in any community discussion.
The PLIP process used to be:
- If you have an idea, you discuss it on the plone-dev mailing list
- After the community has provided feedback and you got some positive
feedback, you proceed to write down a more detailed description of the
problem and the exact way you want to technically solve it
- You put this detailed text in as a PLIP into the designated spot
(which used to be PSC)
- The framework team sets a deadline on when they will evaluate the
PLIP's targeted for a specific release and the last date they accept
new contributions for evaluation
- ... and so on with a first feedback round on the general idea,
opportunities for polishing by the PLIP author and some more process
around actually doing the technical work and reviewing it
What has been missing for most recent tickets, is the entire community
discussion and feedback step. What has also been missing is a clearly
defined description of this process and a template to use for a PLIP
and a list of points that need to be addressed in it, to make
something a valid PLIP.
I think blaming a software for any of these last points isn't helpful.
Restricting the ability to add PLIP's to a smaller group in PSC has
helped to minimize some of the effects, but it's not a good solution
to restrict contribution in that way.
I wrote a big reply to Matt, and ditched it. +100 to everything you said. :)
I'd suggest that:
a) We now formally ask PLIP authors to write to the plone-dev list
(not this list!) announcing their PLIPs and asking for feedback. We can
use a convention like prefixing the subject with [PLIP]. Anyone PLIPs
that don't have this degree of commitments should be ignored straight away.
b) At the same time, the FWT can go and unassign the milestone for any
PLIP that is obviously a feature request or lacks detail. Just do that
with a comment explaining why. If the PLIP gets fleshed out (maybe
following a), we can always re-assign it.
c) We communicate a deadline for PLIP evaluation. We'll need to leave
a couple of weeks for this discussion/fleshing out to happen, I think.
But not too long. Two or maybe three weeks max, I reckon.
d) We get into the habit of sending reminders to plone-dev (and
possibly planet.plone.org for the important ones) when deadlines are
approaching. I think it needs to be part of the release manager's job to
send a "2 week" reminder, a "1 week" reminder and a "tomorrow!!!!"
reminder for each milestone date. I know this feels like baby sitting,
but trust me - it'll save a lot of gnashing of teeth later.
Finally, we *need* to be better to managing deadlines and dates. I for
one have too many calendars and a short memory. It all gets very confusing.
I would suggest that we set up one "Plone Release" calendar on Google
Calendar and add every deadline and target release date to this. We then
link to this prominently from dev.plone.org and in every FWT communique.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Framework-Team mailing list