Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Feb 24, 2011, at 1:36 PM, Hanno Schlichting wrote: On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy ele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! In general, I'd like to give the fixed release schedule a 6 month test drive. If it sucks we can go back to status quo or move forward with the latest and greatest. I cannot remember any Plone releases that only took 6 months - even when we tried hard. I'd usually expect a 50% overrun from any stated timeline, so while aiming for 6 months we can manage to do a release after 9 months. We'd have to aim for a 3-4 months cycle to actually be able to do two releases in a year. And I wouldn't really want to do more than two releases per year, or we risk getting too fragmented, diverging code bases and very short support lifecycles for each release (only the last 4.x release gets bugfixes at any given time according to our current policy). I think we could aim for a spring and an autumn release, expecting most people to be busy in summer vacations and around x-mas/new year. Hanno You're probably right. That's my over-eager under-estimation issue. ;) What I'm after is trying to reduce the penalty for missing the merge deadline. By that, I mean that once that deadline is missed, development tends to completely halt for months at a time before another last minute push at the next deadline. Maybe that's something we can fix with better back and forth from the FWT. Maybe it's just a fact of life. ;) Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Hi, at the risk of repeating myself: This all reminds me very much of handling submissions to scientific journals. They appear in regular intervals and have a review process in place to decide what goes in. One difference there, however, is how the review process is organized. Usually, you have one or several editors (think framework team) who receive submissions and do a first scan to see if a submission is within scope at all. If so, they typically ask one or several (three is quite common) peers to take a closer look and to provide a written review. Based on those review reports the editor(s) then decide about acceptance. So one major difference to our current process - if you compare the framework team to an editorial board - is that the FWT members would not need to do all the reviewing in detail but rather organize and judge the reviews. Who gets asked to provide a review is decided on a case-by-case basis and in practice adds up to many more than on the editorial board. Maybe such a model could work for us as well? I think this goes to Ross's point as well. Holding back my opinions on how whack-a-doodle the scientific journal process is in practice, I think the main thing I worry about here is getting people to do reviews: framework team members are hard enough. In addition they need to have some level of * quality* and be *consistent*. Ok ok so maybe I am dragging in my issues with scientific review process in the end :) How about something in between? I'm totally talking off the top of my head but what if each PLIP is required 4 reviews - 2 by FWT members (1 being the PLIP champion and 1 additional) and 2 by external parties, which can be chosen by the PLIP implementor. Then people can get plone street cred for doing good reviews, and eventually get rotated on to the core team who gets to eat cake and make big decisions. Hopefully by that time the stigma of suck about being on the FWT will be gone. Rotation could work in a million ways. I think/hope/wish upon a star that we can do this in a voluntary matter. e.g. if you are busy, call in sick for the month and just step back. If we are short on people, we call in backups and/or expand. Ideally we have people championing 1 or 2 PLIPs each and if your PLIP is in the hot seat then consider yourself required. There is some level of passion that can be tapped here as well - if you want a feature bad enough you'll find time to see it through the process. There is a perfect place for this to start: the myriad of PLIPs just sitting in SVN. If everyone picks and chooses through those PLIPs, big or small, and thinks that they care enough about the feature that they are willing to *personally* see it through the process, then we have an easy way to chop through the 30+ PLIPs marinating in meh sauce. Then we can spend time on calls discussing those borderline PLIPs that have limited or controversial support and let the slam dunk ideas just pass through to the implementation phase. Going back to Ross's question, I suggest we start by recruiting 3 more FWT members. We can get more at the Plone store later if needed. That's enough to keep the FWT calls sane (at any time 20% will be missing anyways) and be ready to handle the PLIP onslaught. To be honest I have no idea how recruiting actually works so if there is an actual process let's get started... yesterday. Totally spewing brain at this point so I'm open to other ideas/variations. In the meanwhile, I updated the original wiki to reflect 6 month cycle and feature freezes after all the feedback. Releases scheduled for spring and fall. Let's nail this last issue, compile, and see what the community core dumps back. Liz ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 2/26/11 9:22 PM, Ross Patterson wrote: Alec Mitchellale...@gmail.com writes: On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichtingha...@hannosch.eu wrote: On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddyele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! It seems likely that this process will require a also larger team for any given release (particularly given the historic attrition rate of team members over the course the review process), along with a reasonable mechanism for members to opt-out of a particular cycle if needed. Definitely. One of the larger motivations for this change is to be less impacted by FWT attrition. As we discussed it, the FWT would become more of a framework *pool* allowing members to get busy and then come back later. Have we spelled out the process for bringing in a new FWT member as needed? Hi, at the risk of repeating myself: This all reminds me very much of handling submissions to scientific journals. They appear in regular intervals and have a review process in place to decide what goes in. One difference there, however, is how the review process is organized. Usually, you have one or several editors (think framework team) who receive submissions and do a first scan to see if a submission is within scope at all. If so, they typically ask one or several (three is quite common) peers to take a closer look and to provide a written review. Based on those review reports the editor(s) then decide about acceptance. So one major difference to our current process - if you compare the framework team to an editorial board - is that the FWT members would not need to do all the reviewing in detail but rather organize and judge the reviews. Who gets asked to provide a review is decided on a case-by-case basis and in practice adds up to many more than on the editorial board. Maybe such a model could work for us as well? Raphael Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 2011-2-25 21:02, Elizabeth Leddy wrote: I cannot remember any Plone releases that only took 6 months - even when we tried hard. I'd usually expect a 50% overrun from any stated timeline, so while aiming for 6 months we can manage to do a release after 9 months. We'd have to aim for a 3-4 months cycle to actually be able to do two releases in a year. Excellent points. About how long would you say it takes to flush out the alphas and betas? It would be great to say 6 month cycle, feature freeze 4 months in or something specific like that. Realistically you can spend forever doing alphas and betas, since no matter what you say people never seem to start doing real testing until you declare something release critical or make a real release. It's almost tempting to just skip doing betas and go straight to release candidate when all PLIPs have been merged. 2 months for beta/release candidate state should suffice. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy ele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! Agreed! This has the potential to greatly improve our process and provide the larger community of developers and users with a more certainty about how and when things are happening in the shadowy world of framework decisions and release management. In general, I'd like to give the fixed release schedule a 6 month test drive. If it sucks we can go back to status quo or move forward with the latest and greatest. I cannot remember any Plone releases that only took 6 months - even when we tried hard. I'd usually expect a 50% overrun from any stated timeline, so while aiming for 6 months we can manage to do a release after 9 months. We'd have to aim for a 3-4 months cycle to actually be able to do two releases in a year. And I wouldn't really want to do more than two releases per year, or we risk getting too fragmented, diverging code bases and very short support lifecycles for each release (only the last 4.x release gets bugfixes at any given time according to our current policy). I think we could aim for a spring and an autumn release, expecting most people to be busy in summer vacations and around x-mas/new year. I agree strongly with this. A 3 month cycle seems really ambitious. While ambition may be a good thing here, we need to think about the consequences of such a short cycle. This could drastically shorten the support lifetime of any given release. Is that something we really want to do? It could also put a huge burden on release managers with respect to minor/bugfix releases (especially if we decide to support more of these 3-month releases at a time). We might be better off with the more realistic and practical goal of trying to achieve a true 6-month cycle. It seems likely that this process will require a also larger team for any given release (particularly given the historic attrition rate of team members over the course the review process), along with a reasonable mechanism for members to opt-out of a particular cycle if needed. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Alec Mitchell ale...@gmail.com writes: On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy ele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! It seems likely that this process will require a also larger team for any given release (particularly given the historic attrition rate of team members over the course the review process), along with a reasonable mechanism for members to opt-out of a particular cycle if needed. Definitely. One of the larger motivations for this change is to be less impacted by FWT attrition. As we discussed it, the FWT would become more of a framework *pool* allowing members to get busy and then come back later. Have we spelled out the process for bringing in a new FWT member as needed? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 26 February 2011 20:06, Alec Mitchell ale...@gmail.com wrote: On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy ele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! Agreed! This has the potential to greatly improve our process and provide the larger community of developers and users with a more certainty about how and when things are happening in the shadowy world of framework decisions and release management. +1 - I found myself nodding a lot reading that wiki page. I agree strongly with this. A 3 month cycle seems really ambitious. While ambition may be a good thing here, we need to think about the consequences of such a short cycle. This could drastically shorten the support lifetime of any given release. Is that something we really want to do? It could also put a huge burden on release managers with respect to minor/bugfix releases (especially if we decide to support more of these 3-month releases at a time). We might be better off with the more realistic and practical goal of trying to achieve a true 6-month cycle. +1 also - 6 months feels about right. Time tends to fly! Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
I cannot remember any Plone releases that only took 6 months - even when we tried hard. I'd usually expect a 50% overrun from any stated timeline, so while aiming for 6 months we can manage to do a release after 9 months. We'd have to aim for a 3-4 months cycle to actually be able to do two releases in a year. Excellent points. About how long would you say it takes to flush out the alphas and betas? It would be great to say 6 month cycle, feature freeze 4 months in or something specific like that. In this continuous cycle it would mean than someone can integrate 3 months into the cycle or right from the get go as long as it passes final review by feature freeze day. Perhaps this would also give a bit of motivation as well. It's a deadline for a release and missing it means 8 months in the tubes. I am new to the release process so I'm sure this is a bit naive but I gotta hope that with some retrospection we can actually plan these releases without having fake timelines. But maybe this isn't the project for that kinda thing. I bow down to the elders on this one. Liz And I wouldn't really want to do more than two releases per year, or we risk getting too fragmented, diverging code bases and very short support lifecycles for each release (only the last 4.x release gets bugfixes at any given time according to our current policy). I think we could aim for a spring and an autumn release, expecting most people to be busy in summer vacations and around x-mas/new year. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy ele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! In general, I'd like to give the fixed release schedule a 6 month test drive. If it sucks we can go back to status quo or move forward with the latest and greatest. I cannot remember any Plone releases that only took 6 months - even when we tried hard. I'd usually expect a 50% overrun from any stated timeline, so while aiming for 6 months we can manage to do a release after 9 months. We'd have to aim for a 3-4 months cycle to actually be able to do two releases in a year. And I wouldn't really want to do more than two releases per year, or we risk getting too fragmented, diverging code bases and very short support lifecycles for each release (only the last 4.x release gets bugfixes at any given time according to our current policy). I think we could aim for a spring and an autumn release, expecting most people to be busy in summer vacations and around x-mas/new year. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Hey guys - After the meeting I have drafted some documentation for the new PLIP Life Cycle as would be seem from an implementors perspective. I tried to be detailed so the process was clear and also came across a few questions (they are indicated with a number in brackets plus an explanation at the end). Would love to have some feedback on this, especially the questions at the end. Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess In general, I'd like to give the fixed release schedule a 6 month test drive. If it sucks we can go back to status quo or move forward with the latest and greatest. I still need to put together some sort of tracking spreadsheet but I don't think it's necessary until before the next meeting. There are a lot of PLIPS hanging out in the tracker from 2 years ago so we definitely need to do some flushing. Looking forward to your feedback! Liz ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 10 February 2011 04:00, Eric Steele ems...@psu.edu wrote: 1) Consider me +1000 on this 2) Let's plan on faster/regular/smaller releases 3) Review process should be a process of continuous feedback, not the stop doing things so we can maybe look at it over the next 6 weeks 4) We need to be able to adapt to ideas that happen in the run-up to a release (see Geir's discovery of other places contentlistings could be used) 4) 4.2 should be focused on getting events, collections, content listings, search results. These need to happen. 5) Let's chat about this on Tuesday +1 to all of that too :) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Wed, Feb 9, 2011 at 8:00 PM, Eric Steele ems...@psu.edu wrote: On Feb 9, 2011, at 10:49 PM, Ross Patterson wrote: Ross Patterson m...@rpatterson.net writes: Elizabeth Leddy ele...@umich.edu writes: Thanks for all the feedback guys! Curious what current team members think +1, though I expected to gather more contradicting perspectives before weighing in in. Ok, so Eric I think we're a go. Lets schedule another FWT meeting and hammer out the details. Liz, get ready! :-) Ross Yes, sorry I never managed to respond to this. I have 12 different theses sitting in my drafts folder and never quite managed to accurately capture what I wanted to say. Basically: 1) Consider me +1000 on this 2) Let's plan on faster/regular/smaller releases 3) Review process should be a process of continuous feedback, not the stop doing things so we can maybe look at it over the next 6 weeks 4) We need to be able to adapt to ideas that happen in the run-up to a release (see Geir's discovery of other places contentlistings could be used) 4) 4.2 should be focused on getting events, collections, content listings, search results. These need to happen. 5) Let's chat about this on Tuesday These all sound good to me, but I'd note that #4-2 is, in a sense, antithetical to 2, 3, and 4-1. If we want to have small fast releases with continuous review, then it's probably not a good idea to define in advance the new features that need to happen for a given release. To me, having small quick releases means that features only get into a release if they're ready in time for a scheduled alpha or similar, not because they are important. In this case the features are already nearly ready, so it's _probably_ a safe bet they'll be a part of 4.2, but if we start thinking of releases as bundles of specific features then we're heading right back to where we were. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Ross Patterson m...@rpatterson.net writes: Elizabeth Leddy ele...@umich.edu writes: Thanks for all the feedback guys! Curious what current team members think +1, though I expected to gather more contradicting perspectives before weighing in in. Ok, so Eric I think we're a go. Lets schedule another FWT meeting and hammer out the details. Liz, get ready! :-) Ross On Sun, Jan 16, 2011 at 11:44 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2011-1-16 22:46, Martin Aspeli wrote: I suspect they can be overcome by release managers setting target dates, asking people to contribute to a particular milestone date for a particular planned release, but not holding up a release if people slip. Many smaller deadlines can be better than fewer big ones. If you have many small deadlines they effectively become meaningless since people will just wait for the next one (to fly by). I've always tried to advocate a more continuous development pattern and I love Elizabeth's proposal. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Feb 9, 2011, at 10:49 PM, Ross Patterson wrote: Ross Patterson m...@rpatterson.net writes: Elizabeth Leddy ele...@umich.edu writes: Thanks for all the feedback guys! Curious what current team members think +1, though I expected to gather more contradicting perspectives before weighing in in. Ok, so Eric I think we're a go. Lets schedule another FWT meeting and hammer out the details. Liz, get ready! :-) Ross Yes, sorry I never managed to respond to this. I have 12 different theses sitting in my drafts folder and never quite managed to accurately capture what I wanted to say. Basically: 1) Consider me +1000 on this 2) Let's plan on faster/regular/smaller releases 3) Review process should be a process of continuous feedback, not the stop doing things so we can maybe look at it over the next 6 weeks 4) We need to be able to adapt to ideas that happen in the run-up to a release (see Geir's discovery of other places contentlistings could be used) 4) 4.2 should be focused on getting events, collections, content listings, search results. These need to happen. 5) Let's chat about this on Tuesday Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Thu, Jan 20, 2011 at 3:34 PM, Elizabeth Leddy ele...@umich.edu wrote: Thanks for all the feedback guys! Curious what current team members think Liz I agree that the deadline issue isn't a major one, since the release itself would provide a natural set of deadlines and being pushed to a later release in the series would no longer imply the level of uncertainty it does now. Overall, this looks like something definitely worth trying for a cycle or two. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Elizabeth Leddy ele...@umich.edu writes: Thanks for all the feedback guys! Curious what current team members think +1, though I expected to gather more contradicting perspectives before weighing in in. Ross On Sun, Jan 16, 2011 at 11:44 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2011-1-16 22:46, Martin Aspeli wrote: I suspect they can be overcome by release managers setting target dates, asking people to contribute to a particular milestone date for a particular planned release, but not holding up a release if people slip. Many smaller deadlines can be better than fewer big ones. If you have many small deadlines they effectively become meaningless since people will just wait for the next one (to fly by). I've always tried to advocate a more continuous development pattern and I love Elizabeth's proposal. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Reworking the PLIP Lifecycle | discussion
On 14-01-2011 22:24, Elizabeth Leddy wrote: Whaddup FWT - I would like to get a conversation going about reworking the PLIP process. We had some good conversations on IRC about making the process mor continuous so I want to formalize the discussion a bit. Here are my initial thoughts on how to revamp the process coupled with some reactions to the current process: Another comment from the sideline, not from the FWT. I think these are very sane ideas and will help us do what we need: Smaller releases more often! From a marketing perspective, Plone really needs to show that there is a lot happening, — and one of the most important ways of doing that is making releases. The deadline-model we are currently using do not seem to work well enough to keep the pace up, even with the awesome efforts we have seen from release managers. Martin's concerns are valid, but i believe they can be overcome, and IMO they are far outweighed bu the benefits of the new proposed model. -- Geir Bækholt www.jarn.com/baekholt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 16 January 2011 21:07, Geir Bækholt pl...@baekholt.com wrote: On 14-01-2011 22:24, Elizabeth Leddy wrote: Whaddup FWT - I would like to get a conversation going about reworking the PLIP process. We had some good conversations on IRC about making the process mor continuous so I want to formalize the discussion a bit. Here are my initial thoughts on how to revamp the process coupled with some reactions to the current process: Another comment from the sideline, not from the FWT. I think these are very sane ideas and will help us do what we need: Smaller releases more often! From a marketing perspective, Plone really needs to show that there is a lot happening, — and one of the most important ways of doing that is making releases. The deadline-model we are currently using do not seem to work well enough to keep the pace up, even with the awesome efforts we have seen from release managers. Martin's concerns are valid, but i believe they can be overcome, and IMO they are far outweighed bu the benefits of the new proposed model. I suspect they can be overcome by release managers setting target dates, asking people to contribute to a particular milestone date for a particular planned release, but not holding up a release if people slip. Many smaller deadlines can be better than fewer big ones. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 2011-1-16 22:46, Martin Aspeli wrote: I suspect they can be overcome by release managers setting target dates, asking people to contribute to a particular milestone date for a particular planned release, but not holding up a release if people slip. Many smaller deadlines can be better than fewer big ones. If you have many small deadlines they effectively become meaningless since people will just wait for the next one (to fly by). I've always tried to advocate a more continuous development pattern and I love Elizabeth's proposal. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Hi. Thanks for pushing out those thoughts to the mailing list. I'm not much on IRC lately, so I likely missed a lot of the discussions leading up to this. On Fri, Jan 14, 2011 at 10:24 PM, Elizabeth Leddy ele...@umich.edu wrote: In general, let's move away from the fixed timeline of announcing, gathering, reviewing plips and towards a continuous integration of new features. I very much like this. I think our deadline approach doesn't work out that well for us. It currently seems that no deadline we set is actually taking seriously and we happen to postpone the real ones for months afterwards. So I'm not all too motivated anymore to actually do things for a fake deadline anymore. It currently looks to me like we aren't able to ship the actual finished work for 4.1, because we are waiting and waiting for some work that isn't quite ready yet. I'd rather have earlier, faster and smaller releases for the 4.x series again. The minor feature releases ideally should be more time based than feature based. For the major releases like 4.0 and 5.0 we need to handle them differently, as certain types of features can only land in them for backwards compatibility concerns. Having a feature almost ready and then postponing it to the next major release means not shipping it for two to three years. That's a lot different from not shipping some small feature for another minor release and six months. Your notes on the actual process sound good to me in general, I trust the FWT to organize themselves ;) Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Hi Elizabeth, This is a little tl;dr for my current state of flu, but I wanted to make one point: I, for one, need deadlines to get around to doing things. Specific release dates and well-thought-out PLIP timetables really help me structure my work and get things done and plan. A slightly more cyclical approach may also allow for natural attrition and replacement of FWT members. Anyway, not necessarily disagreeing with you, but I feel these are important points. Martin On 14 January 2011 21:24, Elizabeth Leddy ele...@umich.edu wrote: Whaddup FWT - I would like to get a conversation going about reworking the PLIP process. We had some good conversations on IRC about making the process mor continuous so I want to formalize the discussion a bit. Here are my initial thoughts on how to revamp the process coupled with some reactions to the current process: In general, let's move away from the fixed timeline of announcing, gathering, reviewing plips and towards a continuous integration of new features. Allow plips to be submitted at any time. Initial reviews would then be done on a fix times basis (e.g every two weeks). Dev can than begin at any point after approval. The important thing here is to be responsive. I think we can make up for the deadline motivation by just responding quickly. Plips are then submitted for review when they are done, not by date (to prevent untested/half done features from coming in). Small plips will obviously get through this process faster and then won't get held up by larger plips. Set a fixed time to do an initial review of each plip. For example, after a plip is submitted for review we promise that X team members will look at the plip within X weeks. It seems messy but I think this would be much nicer than the current blech of reviewing 8 plips in one month (eek!). This also means that FWT members who are particularly busy can opt out of reviewing particular plips for a short amount of time without having a slow down impact on the review process. FWT discusses status of plips that are submitted, in review, etc... every X weeks - consistently!!! This way things are always moving in all aspects of the process. This also prevents the do we have a call today? issue. After initial reviews, if the plip is going to be merged, assign it to a release. Give the developer X amount of time to respond and clean up any remaining issues such that it will be ready for merge without holding tup the release. This way if there are a LOT of changes that need to happen, just assign it to the next release and let things get done properly without having to go through the whole process again. Final reviews would be a followup of suggested changes/bug fixes and final confirmation before merge. I found the review process very confusing this time and would find it helpful to define what exactly an initial/final review is and where/when it fits into the process. A clearly documented process in general would be really helpful for everyone I'm sure. I also suggest that we add more people to the team, even if its just in a sense that they only do reviews. Maybe these are official guest reviewers. These guest reviewers should be consistently participating and recognized. The consensus was that we wanted 3 reviews on every plip, which we didn't get with the current team. So let's fix it :) Somewhat related, I felt pretty uncomfortable voting on a plip which I did not personally review. If someone else did the initial review, then say I did the final review, I would have a much better opinion on the plip. If each plip gets 3 initial reviews, and then we have 2 OTHER people do the final review, we get 5 eyes on the plip and 5 votes on inclusion (5 also prevents ties). In order for the above to work well, I think the initial review discussion phase of each plip should have a product: a definitive list of exactly which bugs/tasks MUST to be completed to be merged (and what is nice to have). This is similar to the review process for a science paper. If they finish they tasks by date X correctly, then there is a 95% change it will be merged in release X. It's a lot easier to finish a feature with a tick list. This will also obviously require some sort of place to keep track of things but I don't see this as any huge overhead. The spreadsheet worked just fine for the current process and it would be a great jumping point for this. We could even make it public (gasp!) so that developers can see where their plip is at any time and how it's being received. I don't now if these changes have to affect the release cycle or not. Initially I don't think they need to but I can see how switching to a fixed time release schedule (Ubuntu style) could fit in nicely. The main issue I see with all this is the lack of deadline motivation but I really think that setting up a process where we promise to give timely, encouraging, clear feedback will offset that risk.
