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
   - 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?"
   - 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.

Framework-Team mailing list

Reply via email to