Re: [Framework-Team] Re: PLIPs in Trac
On Jun 18, 2009, at 11:09 PM, Martin Aspeli wrote: Hanno Schlichting wrote: ... 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. Martin I have little to add to what Hanno and Martin have stated so well here. To me, what shortcomings the Trac-based approach may have are trivial enough for me to largely overlook and can be covered through some further integration work by the plone.org team and/or better documentation of the process. I've been getting a sense of frustration from new folks we've let into the system looking to help but are getting shot down with that's a feature request. While that may be the case, I really don't want to see these potential contributors feeling dismissed. Can we come up with some strong documentation on where the leap from feature request to PLIP lies? I'm sure you'll all get sick of hearing me say it, but this Plone has a very short timeline. While all major releases have had to find the fine balance of time between discussion, implementation, review, and releasing, it's even more of a struggle with this one. We currently have a 10 day window scheduled for PLIP discussion and voting. I'm inclined to stick to that, with a strong admonition to all involved that time required to complete the proposal is just as important a consideration as its technical merits. I'm not completely inflexible on that timeframe though. I already have a calendar started. I'll work on getting that filled out, published, and publicized ASAP. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs in Trac
On Jun 20, 2009, at 5:04 PM, Eric Steele wrote: I already have a calendar started. I'll work on getting that filled out, published, and publicized ASAP. actually, PLIP #246 was meant to introduce the possibility to set up the plone calendar using plone.org itself: keeping all relevant dates in event content within the roadmap section[*] would make it easy to publish a release calendar. using the provided view higher up the hierarchy could additionally be used to include sprints etc or simply all plone events. cheers, andi [*] http://plone.org/products/plone/roadmap/ -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2.2 released! -- http://plone.org/products/plone/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs in Trac
Eric Steele wrote: I have little to add to what Hanno and Martin have stated so well here. To me, what shortcomings the Trac-based approach may have are trivial enough for me to largely overlook and can be covered through some further integration work by the plone.org team and/or better documentation of the process. I've been getting a sense of frustration from new folks we've let into the system looking to help but are getting shot down with that's a feature request. While that may be the case, I really don't want to see these potential contributors feeling dismissed. Can we come up with some strong documentation on where the leap from feature request to PLIP lies? Eric, We've long lacked a process for average Plone users to make feature requests. But no longer! :-) I hope I've managed to document feature request vs. PLIP reasonably well now at: http://plone.org/documentation/faq/suggest-a-feature-for-plone Please feel free to suggest any ways to make this clearer, or to adapt anything from there onto the dev.plone.org/plone wiki space as needed. best, jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIPs in Trac
Hanno Schlichting 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. 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. 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
