C105 Mechanics of running an OS project

This turned into a discussion about how the Grouper project handles collaboration. The two projects are very similar and hopefully the following discussion points will help OpenRegistry to grow:

grouper was collaborative from the start
- 2 schools bristol and chicago
- cardiff, penn, duke
- Tom knew he needed this but there were no solutions out there
- Got something written that was missing pieces but was a start
- Penn had their own interests, it wasn't just right
- Penn doesn't typically do Open Source
- technology matched developer skills
- 1.6 is stable
- 2.0 is next major release
- release twice a year
- roadmap, not formal governance
- conference calls every other week
- Rob at Cardiff wanted to contribute it back
- SVN branches are different versions
- working on 2.0
- fix in 1.5 branch, merge that forward into 1.6 and 2.0 branch
- Trunk is development version
- Trunk changes throughout
- coarse roadmap, point of discussion twice a year
- figure out the target ahead of time, functionally
- if you have a change that might effect people who don't want, put in a switch in the config
  - 5 committers
  - motivated by not forcing people to move large pieces outside the project
- what do deployers want, not what do committers want
  - use case driven, motivated by a specific use case
  - avoid hypothetical, at least one happy customer
- feature branches? in a minor release
- important that someone consistently handle the merging
- each committer has their own area that they work on
  - web services, UI, complex internal API, LDAP, ESB, Documentation
- by and for the community
- Mechanics of adding new users - earn your way on
  - feed them some ideas to generate patches
  - do it through issue tracking Jira
  - attach patch files through Jira
  - our committers look at them
  - existing committers vote