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. I know that when I > develop a new feature I like to focus solely on that and then move on. When > I have to go back and redo something I haven't looked at in a month I'm > likely to put it off and be grouchy about it. Let's help people stay focused > and follow through. > Again, these are just initial thoughts. Since this is my first time going > through the cycle I'm sure that many people have different perspectives. > Would love to hear thoughts, grips, ideas. > Liz > > _______________________________________________ > 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
