- Write charms
- Review new charms
- Triage charm bugs
- Mentor new charm contributors and users
[jorge] Jorge to take in changes from the community and update the wiki until the "real" juju.ubuntu.com launches.: DONE

* What does “oneiric” mean in “charm”
* Stable charms as of “some release date” + updates “cs:oneiric-stable” == cs:oneiric
* “latest” charms continue to go to cs:oneiric-latest
* whole release copied to new dev series
* Automated tests for backporting to all previous series “latest” pocket, also stable if charm is “NEW”
* series just means “we’ve seen this charm run on that release of Ubuntu”
* PLANS: oneiric releases when charm store backend is complete
* PLANS: precise release together with 12.04
* ACTIONS
- define implementation of backend service understanding “stable” vs. “latest”
- develop or identify tools for managing release (copy all branches to new stable, tagging, etc)

Why classify your charms?
1) Trust, safety net, tested, QA’ed, well known peer review by experienced charmers.
2) Self contained and won’t go away
3) Will get security and critical updates (similar to the distro)
Author needs to classify the “level” of a charm, is it a mess around “+junk” or is it something that you can push to production?
“These are the charms you don’t have to read”
some charms can provide an audit trail

Work Items:
[clint-fewbar] Update juju.u.c/Charms: DONE
[jorge] Jorge to take in changes from the community and update the wiki until the "real" juju.ubuntu.com launches.: DONE
[jorge] Talk to IS about how we can give community people write access so they can fix docs, document their interfaces, etc. without pwning juju.u.c.: DONE