On Thu, Jun 18, 2009 at 4:47 PM, Hanno Schlichting<ha...@hannosch.eu> wrote: > 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.
One of the main reasons that I'm in agreement with Matthew on this is that I don't think major roadmap type decisions on which PLIPs ostensibly focus belong mixed in with bugs and random feature requests. Having the potential roadmap and its progress outlined within the software release system makes more sense than having it available exclusively in an issue tracker that no one besides developers bothers with (especially when it's cluttered with noise). > 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. I consider this a large advantage for PSC, and I think the results so far speak to that advantage. In PSC, it is painfully obvious to the creator/editor of a PLIP when their work is incomplete, because the ostensible requirements are a prominent part of the editing process. We don't have that with Trac. The structure provided by PSC may have been ignored (or left incomplete) at times, but never to the extent that we're seeing with Trac. > - 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. This is not a requirement, just a choice made in our deployment of PSC. It may in fact be a good choice, but it could easily be changed to allow collective committers or an even broader selection of users. > - 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. We have customizable workflows in Plone as well, I believe ;-) If the workflow is not correct, we can change it easily. It's certainly more correct than the complete lack of PLIP workflow in Trac currently. > - 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. This is certainly a big advantage for Trac and it may even outweigh many of the above disadvantages. Having to go back to the PLIP pages constantly to look for updates would be a major pain. > 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. I don't think you can reasonably say that Trac is more tailored to this particular need than the system developed specifically for this particular need. I gather that commenting was a pain mainly because of slowness in the system? That wasn't always the case, I wonder what has changed since the Plone 2.1 days of Plone.org to make it so much more painful. Beyond performance issues and automatic emails, is there any real difference in the commenting/voting process between the two? > 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 This has only rarely been the case. Often, PLIPs were written before feedback was solicited. > - 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 Not all successful PLIPs provide exact technical details, and they shouldn't all be expected to. The problems I'm seeing are not limited to lack of technical detail. They are the result of lack of effort and/or thought. > - 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. We have a bunch of so-called PLIPs in Trac, many of which were submitted by people who should really know better. Very few of them provide enough detail to evoke much in the way of meaningful discussion. While you obviously disagree, I think much of this can be attributed to the loss of explicit structural guidelines provided by the PSC edit form. We have had many good PLIPs in the past which were submitted with essentially no prior community discussion. Most of the few decent PLIPs I see for 4.0 happen to be those that have been subject to the least community discussion (e.g. https://dev.plone.org/plone/ticket/9300 https://dev.plone.org/plone/ticket/9292). OTOH, many of the PLIPs whose subjects have been discussed extensively within the community are the least detailed (perhaps because the authors think the subjects have been discussed enough to be obvious). The email from the framework team could have explicitly linked to some good example PLIPs from the past to make clear the importance of details and coverage. However, a lot of the submissions are coming from people who know exactly what a PLIP should look like (i.e. people reading this discussion). > 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. People seem to have forgotten what PLIPs look like and what they contain. While that's attributable in part to laziness on the part of PLIP authors and some lack of clarity with regard to requirements, I think the PSC system made it very clear what a PLIP should be and Trac certainly does not. It shouldn't be too much to expect everyone to thoroughly read the email, follow the links, figure out the format and requirements, and only then begin writing, but apparently it is. As a result making those requirements clear through software seems like a reasonable step. We've had a few bad/incomplete PLIPs in the past, but nothing like this. And I think it's dishonest to argue that the reason is that past framework teams have communicated requirements and process better, because I don't think there's much if any real evidence of that. Alec > On Fri, Jun 19, 2009 at 12:48 AM, Matthew > Wilkes<matt...@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. > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
