Skip to content

Home

Jump to bottom Edit New page
merrick edited this page Feb 12, 2012 · 18 revisions

The RapidSMS Community Mission

What is the mission of the RapidSMS community? What problems do you solve for whom? The steering committee will write this.

What is RapidSMS?

What is the product we are making to move towards our mission? The architecture lead, release manager, and feature champions will write this. The architecture lead will be the benevolent dictator on this item.

Here are our relevant community links:

What's the current status of development?

This section will be fleshed in and owned by the release manager.

There is no official release at this time. RapidSMS is currently in pre-alpha and our first release is considered a development release. Features and stability are not guaranteed or supported at this time - on the up side, if you're willing to jump in and help experiment, there's never been a better time to help determine the direction of the project.

In order to let ourselves rapidly make mistakes and learn from them, we are going to start off with 3, 1-month release cycles. These release cycles will be unstable alphas until the release managers decide otherwise, and may not contain many new features; the primary purpose of our first 3 releases is to teach us how to make releases as a community.

Our next release dates are:

  • July 1st, 2009
  • August 1st, 2009
  • September 1st, 2009
  • Release dates after September 1st will be decided by the release manager at that time in August.

h1. Getting involved with RapidSMS

How do new deployments start getting involved? What are the existing relationships between RapidSMS and deployment groups using it? Documentation team to get this written, with content assistance from support team.

h2. Communication forums

We have several canonical forms of communication. The complete list for this release is as follows:

h2. General participation values

  • Radical transparency. If it's not on github (as a wiki page, ticket, or commit), it doesn't count. If you have a great conversation over lunch and don't write anything down, that conversation never happened - you've got to tell everyone else for it to make a difference.
  • Release early, release often, and get public feedback on everything you release. (Get code check-ins reviewed, design suggestions discussed, governance choices commented upon, etc. - this ensures your work goes somewhere, not floating off into the aether.)
  • Ask forgiveness, not permission. A bad answer is often better than no answer or a good answer too late; if you're really lost, the answer is "flaming ponies."

h1. Roles

Each position-holder for this release is expected to hold meetings/office-hours for at least 30 minutes a week at a preannounced time, during which they will work on their area of responsibility. They are also expected to email a weekly status report to the rest of the community. Since this is the first time any of these positions will be held, emphasis is on defining the roles of each team and putting a procedure in place to select and train one's successors.

Roles for the first release have yet to be assigned. They are:

  • steering committee members (3) - ultimately responsible for the direction of the project, they make governance decisions when consensus can not otherwise be reached, as well as legal and financial decisions (which may be delegated).
  • architecture lead - responsible for keeping the architecture document (which needs to be written) and the interface specifications between various types of components maintained and useful.
  • release manager - maintains the features list; responsible for everything that goes into a release, including prioritizing features and deciding what features will be in or out of a particular release, when to release it, and who to release it to; also responsible for making sure developers get poked to work on their features and getting them resources they might need to do so. Has the final say on whether a patch/commit will be accepted. Owns the source repository.
  • feature champions (1 per major feature) - responsible for driving forward development on major features for a release. Can accept commits to the features they champion.
  • QA lead - responsible for encouraging others to find bugs; responsible for the quality of bugs in the ticket tracker, and accountable to the release manager for providing an up-to-date status report on how close a release is to the features list desired. Owns the ticket tracker.
  • documentation lead - responsible for creating and maintaining guides, tutorials, howtos, and any information on the wiki. Owns the wiki.
  • communications lead - responsible for keeping everyone in the community up to date on recent happenings, including ensuring that all groups submit weekly reports. Also responsible for marketing, outreach, newbie-welcoming, and serving as a PR point of contact for interested third parties. The wiki as a whole is owned by the communications lead.
  • support lead - responsible for gathering feedback from deployments and ensuring that the appropriate people take action on it; responsible for making sure deployments get appropriate responses for every piece of feedback they provide.
  • infrastructure lead - responsible for installing, upgrading, maintaining, monitoring, and provisioning IT resources (mailing list, wiki, etc.) to community members who need them. Owns the IRC channel.
Add a custom footer
Add a custom sidebar
Clone this wiki locally