Re: [Framework-Team] PLIPs in Trac
On Thu, Jun 18, 2009 at 4:47 PM, Hanno Schlichtingha...@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
[Framework-Team] PLIPs in Trac
Hi all, I'd like to open a public discussion on where tracs should be. As some of you may know, I'm very much against the PLIPs-in-trac system that has been implemented following out-of-band discussions last year. I think we need to make a proper decision, I'm not sure how that will happen, but if it'll stop me whinging either way. 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. Do others agree with me, or do you prefer trac? Despairingly yours, Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIPs in Trac
I'm in agreement that the plone.org system is preferable; however I think it's probably a little late to change this. It does seem like the PLIPs submitted so far are mostly unstructured feature requests. Even the better ones are pretty minimal. Alec On Thu, Jun 18, 2009 at 3:48 PM, Matthew Wilkesmatt...@matthewwilkes.co.uk wrote: Hi all, I'd like to open a public discussion on where tracs should be. As some of you may know, I'm very much against the PLIPs-in-trac system that has been implemented following out-of-band discussions last year. I think we need to make a proper decision, I'm not sure how that will happen, but if it'll stop me whinging either way. 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. Do others agree with me, or do you prefer trac? Despairingly yours, Matt ___ 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
Re: [Framework-Team] PLIPs in Trac
On Thu, Jun 18, 2009 at 11:48:24PM +0100, Matthew Wilkes wrote: Hi all, I'd like to open a public discussion on where tracs should be. As some of you may know, I'm very much against the PLIPs-in-trac system that has been implemented following out-of-band discussions last year. I think we need to make a proper decision, I'm not sure how that will happen, but if it'll stop me whinging either way. 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 I do not really mind either way. But I talked with Jean-Paul Ladage about this today and he is right in saying that end users wanting to know the future of Plone will look at the roadmap on plone.org and they will not be impressed: http://plone.org/products/plone/roadmap They will see a bunch of plips for 3.3, one for trunk, and then about 40 'Proposals being discussed'. Since some are apparently being discussed since 2005 these 40 proposals might as well be ignored as there is no guarantee or indication about when they might get included. This is not the sign of the healthy, active project that Plone still is. 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. Do others agree with me, or do you prefer trac? Despairingly yours, Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ Yes, we study economics, got to make the money make some kind of sense. - Geoff Mann ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIPs in Trac
On Fri, Jun 19, 2009 at 2:03 AM, Maurits van Reesmaur...@vanrees.org wrote: I do not really mind either way. But I talked with Jean-Paul Ladage about this today and he is right in saying that end users wanting to know the future of Plone will look at the roadmap on plone.org and they will not be impressed: http://plone.org/products/plone/roadmap The old roadmap is obviously supposed to be replaced by the Trac one from http://dev.plone.org/plone/roadmap. This was supposed to happen shortly after 3.3 is released. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
