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)
- A code contribution request comes in (following the instructions on the project wiki)
- Either someone internally or another Power Toy developer investigates and approves the check-in
- The Power Toy developer checks-in the code on the user’s behalf after
- 2 or 3 successful check-ins at the bug-fix level
- –or– after 1 significant feature request check-in
- –or– after lots of participation in the Power Toys forums, comments on the Issue Tracker, etc.
- 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?