Charm Audit

Registered by Jorge Castro

Review all charm store charms for accurate descriptions, examples, ratings, metadata, icons, and embedded tests.

As the charm store redesign includes new features we need to review charms to ensure they take advantage of those features. In addition, we need to ensure the charm information exposed to users in charm searching is accurate, and helpful.

Blueprint information

Needs approval
Series goal:
Milestone target:
Completed by
Katherine Cox-Buday

Related branches


Reminder to talk about interfaces and locking those down

James just attended an amazing Charm School and went to try something but the README doesn't tell him how to use the charm.
Kirk is a sysadmin and is only willing to deploy something that is dogfooded, well-tested, and has the same quality requirements as the packages he deploys from main.
Robert is deciding which nosql database of the day he wants to deploy and wants to compare the charms for them so he can make an informed decision.
Lars hears his project is now in the charm store and he wants to make sure that his project is represented with the same TLC that he puts into it upstream.
Jason wants to know how many people are using his software that is in the charm store.
Cliff just deployed something from the charm store only to find that the information is out of date and doesn't know how to fix it.






- The new Charm store offers everything you need to chose which service to deploy, including built-in testing results, quality ratings, examples for deployment, and support status.

vUDS 1305 notes:
vUDS 1308 notes:
vUDS 1311 notes:


## Steps

In order to make it easier for people to participate, we've broken down the top downloaded charms from the charm store and broken out the tasks based on what needs to happen. If you are comfortable with hacking and writing tests, you can do that, if you are more comfortable writing READMEs, checking metadata, or even just running and learning Juju you can also chip in by running each of these charms through the wringer as we audit them. Here's how to get started.

- Check out the spreadsheet and pick your charm:
- `charm get foo` to get the charm.

### For ~charmers Reviewers

- Rereview the charm with the latest criteria:
- Rate the charm's features on <--- needs to be a charmer to need instructions for non-charmers too.
    - manage.u.c hasn't been updated with the new charm bullets, track these by hand for now:

### Things anyone can do:

- Ensure is accurate and has good example usage,
    - Use `charm add readme` to add a new README.ex with the new sections. Adapt the existing README to work inside this template.
- Ensure the description in metadata.yaml is correct and simple. Many of them are long copy and paste descriptions from websites that look terrible in the GUI.
- Ensure an icon is avilable and if not follow
- Write tests, and ensure they pass from juju test
    - Docs for getting started writing tests: TBD
- Check that the charm renders properly on
    - Especially check the description that is parsed from metadata.yaml.

## Final Check and Resubmission

- Must pass `charm proof` again, charm proof has been updated to the latest charm policies. If you can't fix a warning, file a bug on the charm and tag it "audit".
- Test the charm on as many providers as possible (this will be automated in the future). At a minimum test on local provider and put a comment in the notes section of the spread sheet.
- Submit work back into the charm store (


Work Items

Work items:
[marcoceppi] Send reminder email to list for people to subscribe to their charm bugs as maintainers: TODO
[marcoceppi] Ensure the charm tools subscribers thing runs on a regular basis: TODO
[curtis] Add 7 unmaintained charms to the top of the queue: DONE
[jorge] Add "file a bug if the interfaces don't match" as part of the review criteria: TODO

This blueprint contains Public information 
Everyone can see this information.