[Framework-Team] PLIPs in Trac

[Hanno Schlichting]

Hi.

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
- Comments

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
process.
- 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.

Hanno

On Fri, Jun 19, 2009 at 12:48 AM, Matthew
Wilkes<matthew at matthewwilkes.co.uk> wrote:
> For Plone <4.0 we've put PLIPs on plone.org, this has the following
> advatanges:
> - Unique, relatively low number for each PLIP
> - Custom content type enforces PLIP structure
> - Workflow matches our process
>
> The disadvantage of it being on a different site has been raised, but I
> don't buy this.  How often do you want to look at the bugs and PLIPs for a
> release at the same time?  They have a completely different process.
>
> The current crop of PLIPs for 4.0 are very unstructured, only the ones
> copied verbatim from plone.org have seconders.  We're having to bodge
> workflow by assigning different milestones.  It's really suboptimal.