Juju Contributor Onramp
[GOAL]
Complete past work items. Develop new work items based off feedback. Have future user feedback polls state contributing to Charms was straightforward and pleasant.
[RATIONALE]
We need to make it easy for new contributors to learn about Juju, understand Juju, get set up with Juju, and contribute to Juju charms. This is imperative to maintaining and growing the Juju community. Ultimately we need to make it easy for people to consume Juju technologies.
Blueprint information
- Status:
- Started
- Approver:
- Antonio Rosales
- Priority:
- Medium
- Drafter:
- Ubuntu Server
- Direction:
- Approved
- Assignee:
- Jorge Castro
- Definition:
- New
- Series goal:
- Accepted for saucy
- Implementation:
-
Started
- Milestone target:
- None
- Started by
- Antonio Rosales
- Completed by
Whiteboard
UDS 1303 Pad Data:
Pad: http://
Old spec: https:/
vUDS 1308 Notes: http://
Idea:
In regards to using other code hosting: mariusko_: Also maybe compare with how it is done with nodejs: "npm help publish" (https:/
[USER STORIES]
James is a sysadmin at a company and is interested in getting his charms into the store for convenience/peer review. He's got some internal stuff that he can keep seperate, but he doesn't want to maintain boring infrastructure charms on his own.
Kirk is deploying a charm but finds that it's missing a feature or needs a bugfix and he thinks he knows how to fix it.
Robert is a developer at a company who works on a database that is charmed up, he notices that the charm needs improvement to follow his project's recommended best practice, but isn't sure how to claim ownership of a charm.
Lars is used to github and is totally confused on how to get charms he's interested in.
Cliff submitted a fix to a charm two weeks ago and has no idea how to get someone to get his fix in.
[ASSUMPTIONS]
- Mims/Castro want to mirror how OpenStack does reviews and code contributions as well as their usage of LP Blueprints.
[RISKS]
- There's only so much simplification that can happen when it comes to submitting code.
- Poor response time leads people to believe that we don't want to help them.
- Workflow ties into the store, so we need to be careful on how we simplify this.
[IN SCOPE]
- Refining workflow for submission
- Measuring contributor metrics and enforcing a fast response time.
[OUT OF SCOPE]
[USER ACCEPTANCE]
[RELEASE NOTE/BLOG]
- We've made it easier than ever to contribute to charms with a new submission workflow.
[notes from cloudsprint 2013-05]
Low hanging fruit
Docs! Big issue to getting new contributors
Instructional videos will be a big help to resolving “How do I get going” for new people
“Contribute to this charm” on jujucharms.com
Better charm tools to help contributors (charm-helpers, charm-tools, charmsupport)
NO LOCAL PROVIDER FOR JUJU-CORE
Inhibitor for WebOps, charmers, community, and basically everyone
Work Items
Work items for ubuntu-13.05:
[jorge] : Highlight Places where people can contribute (https:/
Work items:
[jorge] : Lower the Barrier to entry (https:/
[jorge] Create Problem Tracker for issues found by users (https:/
Dependency tree
* Blueprints in grey have been implemented.
