Developer Escalation Model for Power Toy projects on CodePlex

The current CodePlex design provides an all-or-nothing access model to the source control repository.  Either I give users full access to check in their code contributions or I (or another project developer) check-in the code on their behalf. 

Before we begin, here’s a brief overivew of the different users on CodePlex, so you’ll have appropriate context for this blog entry.

• Anonymous – anyone can download source code, releases, etc
• Registered user – can open work items, leave comments on the wiki and other bugs
• Developer – has full access to the source control repository, wiki access, close bugs
• Coordinator – project admin, does everything a developer can do, but also can create releases

Here are the pros and cons of both approaches as I see them apply to our Power Toys efforts.  (Note: our Power Toy FY07 goals will be posted shortly, so soon it will be clear what we’re trying to achieve here.)  Also note that for other open shared source projects (maybe even some of our future power toys), these pros and cons could / will be totally different.  

Members-only – no one has access to the source

• Pro:  The Power Toy developers approve everything, ensuring high quality check-ins, no build breaks or broken mainline functionality.
• Pro:  No one can check-in without a Power Toy developer knowing about it before the check-in goes through
• Con:  There’s a cost to the Power Toy developers to monitor everything, do check-ins on the contributors behalf, and so forth.  This cost implies a longer turnaround time to get your contributions checked-in.
• Con:  A precedence is set that the Power Toy developers will do everything on the user’s behalf, where what we want really is to have the community control the project’s direction.

Free-for-all – everyone has full access to the source

• Pro:  Less overhead for community contributors to check-in, implying a faster check-in turnaround.
• Pro:  The community begins building a reputation / credibility system, where bad check-ins discourage future check-ins (I hope!) and good check-ins encourage more check-ins
• Con:  Giving anyone full access to anything should make any administrator (or Coordinator in CodePlex-speak) feel nervous
• Con:  May need to remove someone as a developer if they do something malicious or continuously check-in bad code.  My thought here is I would rather make it more challenging to become a developer; rather than making it easier to get kicked out as one.  

My blogger-sense is telling me I need to have more of an in-between moderation model.

Gatekeeper – anyone can check-in, but the coordinator and/or a developer must approve the check-in

• Break out the current “developer” access role into “Developer” and “Contributor”.  Developer has full access, just like they have today, but a Contributor cannot check in until either a dev or coordinator approves the check-in.
• Slightly-less overhead for the Power Toy developer than the Members-only approach, since coordinators can check-in directly
• Power Toy developers get a heads-up to incoming check-ins

Since CodePlex doesn’t have this notion of Developer versus a random contributor (and I’m not trying to imply this is a limitation of CodePlex – this is just my “wag” at a model that works for my team and our goals), I’m trying to solve my all-or-nothing dilemma by introducing for the time-being an Developer Escalation Model.

Power Toy Developer Escalation Model?

The million dollar question- How does one become a developer on a Power Toy CodePlex project?

My current thoughts are (and please let me know if you agree / disagree – it’s your community too)

1. A code contribution request comes in (following the instructions on the project wiki)
2. Either someone internally or another Power Toy developer investigates and approves the check-in
3. The Power Toy developer checks-in the code on the user’s behalf after
   1. 2 or 3 successful check-ins at the bug-fix level 
   2. –or– after 1 significant feature request check-in
   3. –or– after lots of participation in the Power Toys forums, comments on the Issue Tracker, etc.
4. the power toy coordinator grants the user with developer rights. 

Also, if someone is just going to contribute 1 check-in ever, I probably don’t want to make him/her a full developer.  I want the list of developers for the project to be viewed as an “active” list of developers.   It also feels unnatural to grant people full developer access for the rest of time if they are just going to make one check-in.

So, for those who have been at collaborative-development longer than I have (which for me has been 1 month now), am I on track or am I totally missing the forest for the trees by over-engineering this entire process?

Thoughts?

Comments

• Anonymous
  June 13, 2006
  Ideally there should be a warm body making sure the build works and that the unit tests are still valid; which most closely sounds like the Gatekeeper or the members-only models.
  
  I'm not a big fan of the free-for-all model.  I believe a project should be "owned" by someone (or a small group of busy people).   Falling back to a free-for-all model when no one has the cycles for "ownership" is better than no project at all, though.
  
  Based on your descriptions, I'm liking the Gatekeeper model; where contributors have increasing levels of responsibility that they're willing to accept and able to fulfil.  To lessen the admin of delegating these responsibilities, a point system could be put into place.  Someone willing to contribute could be given approval-only check-in rights.  Each bug-free contribution could provide the addition of varying number of points to their reputation--quantity decided upon by the reviewer(s).  At certain point levels these contributors could be offered new responsibilities (in increasing order of points required): approval-free check-in rights, reviewer rights, delegation rights, etc.  This expands on the contributor-to-developer path you've described to add the ability for an "owner" to hand-off or delegate ownership based upon quantifiable attributes (reputation).
  
  This concept is reasonably simple.  Shoehorning it CodePlex's current implementation may make it far more complicated though.  But, it's clear from your post that there's a need to evolve CodePlex (and maybe the underlining Team Server)
• Anonymous
  June 13, 2006
  > Testing is the ultimate "You broke it and I'm telling!"
  
  Whereas some of your colleagues are the ultimate "It's going to stay broken and I'm telling."
  
  Sorry to deviate from your thread but I just noticed how much more useful Power Toys can be.
  
  When Visual Studio 2005 generates rc files that it can't even compile, customers have to learn how to edit the rc files by hand.  Your colleagues have promised (twice) that this bug will remain in the next version of Visual Studio.  So for at least 5 years, everyone who creates a new Visual Studio project, if they're not targeting Japanese only, will have to edit the rc file at least once per project and change a nonexistent symbol SUBLANG_ENGLISH_NEUTRAL to SUBLANG_ENGLISH_US.  This is the kind of thing that could be automated by a Power Toy, right?  Do you have authority to overcome your colleagues' decisions about "won't fix"?
  
  When Visual Studio 2005 generates buggy code that violates MSDN instructions on the way a window procedure should be coded (GetMessage etc.), could this be overcome by a Power Toy?  This has an additional problem besides being "won't fix" for current, next, and previous versions of Visual Studio.  Developers who read MSDN or the blogs of some of your other colleagues can usually figure out how to do about 33% of the necessary fixes.  If they do so, it can be pretty hard for a Power Toy to figure out what's been done and perform the other 67%.
  
  Of course some things can't be fixed by Power Toys at all.  When Visual Studio 2005 generates buggy code for DllMain, then if anyone (Power Toy or human) fixes the HANDLE to be an HINSTANCE then Visual Studio gives error messages.  Seems to me that this one isn't just a "won't fix" but is also a "can't fix".
  
  Anyway it's broken, I'm telling, and your colleagues are telling that it won't be fixed.
• Anonymous
  June 13, 2006
  I actively work on 2 open source projects and think the free for all model works just fine. If someone wants developer (checkin/commit) access, they should submit a patch or two to a project owner. The project owner applies the patch in a local copy and verifies that it all works, and then checks it in (if they like it). Once the project owner feels comfortable with the contributors work, they grant the contributer developer access. How long they wait until granting access is really up to the owner - depending on how much time they have to keep testing & applying patches on the contributors behalf, and how much tight control they want to keep over the project. I would think 1-3 patches. I find that trying to keep tight control just adds friction to the process and discourages people from contributing.
  One thing that is important for a (near) free for all model is some sort of contributor guideline documentation. This should state what is expected from each contribution (coding style, testing strategy, deliverables, etc). It is also helpful to have a roadmap, and/or project philosophy so that everyone understands the intended scope of the project (so that you don't get well-meaning developers contributing features that aren't really desired).
• Anonymous
  June 13, 2006
  Your Gatekeeper is pretty much like the way WebKit handles contributions (which I like pretty much): every patch is attached to a bug report, needs to be reviewed (even the patches that come from the core team) and are checked-in by dedicated submitters. This would require read-only access to the repository which seems to be missing on CodePlex right now though.
  
  And I like to Joshua Flanagan on the point that tight control discourages people from contributing to projects: it ensures that the quality stays at a certain level and teaches good practices; contributor guidelines are an implied requirement for any more-than-a-few-lines-of-code project :]
• Anonymous
  June 13, 2006
  Just wanted to quickly respond to the "read-only access to the repository missing functionality" comment.  If i recall correctly, TFS doesn't allow for read-only access to source control, so CodePlex provides the Source Control tab where anyone anonymously can download the sources through the web client.
  
  Thanks for the comments and Keep them coming!  The most helpful comments are those from people who are currently contributing to an open source community, but i'm also very interested in comments/opinions from those who haven't contributed to an open source community, but are interested in participating in our Power Toy community in some form.  I want your experience with our power toys on codeplex to be as easy as possible, regardless of your collaborative-development experience.