The Basho Community
There are many components to a successful open source software project. Code (and code quality) is only the first of many, and lot of times it's not the most important (for better or for worse). A Community is built around the code to help foster its growth, maturity, and adoption. Like the code, it needs to evolve, and unless it's moving forward and being refined continuously, it ceases to be valuable.
Culture is most powerful when chosen intentionally. Let's choose what type of community we wish to be.
We've introduced the idea of "The Basho Community" as a releasable product. Why not approach community development like you would code? What if there were scheduled "releases" comprised of new "features" and "bug fixes"?
The idea is simple: every few months we cut a "new release" of the Basho Community. A release will be comprised of updates to how we communicate. The more detailed conversation can occur as Issues.
The goal is to periodically tag and release "versions" of The Basho Community. This tagging will signify specific objectives, both internal to Basho and external in our Community.
Each subsequent release will represent the evolution of the Community: new ways to share our code, new ways to communicate more clearly, process flaws will have been unearthed, and rectified. All of this moves the community forward and makes it a better place to work and play.
Finally, this will be a way for us to track the progression of the community over time and build the community in a more collaborative, transparent way. There are people all over the world contributing to the growth of the Basho Community in endless ways. This is an attempt at capturing and showcasing that growth.
Release Cycles and Versioning
Since community as code will be driven by feel over functionality, we probably won't get too in-depth with the versioning and release cycles. For now:
- A new release of The Basho Community will happen as significant changes to our communication processes occur
- Each new version will be a minor version increase as we make minor improvements (i.e. "v0.2" will follow "v0.1")
- A combination of new major programs and new processes may justify a major release (i.e. "v2.0" could follow "v1.6")
- Open an Issue as you have ideas for community improvement. These may be as general as requests for visibility (example) or as specific as request for coordinated improvements (example)
- Open a pull request with details on your ideas for improvement or corrections to existing information
- Someone with commit rights to the repo will discuss the details over the PR
You'll notice a detailed list of labels on our issues here (inspired by Docker). The major topics are broken out into 3 buckets:
- Capitalized - manually applied labels that indicate an important status
- requests - track requests for types of projects, from a how-to guide to a presentation
- status - gets people's attention and clarify who's running with what
Here is what they all mean:
Open Discussion- designed to be a conversation. This tag makes sense on early requests that need clarification of scope and community-centric discussions like organizational structure on GitHub itself
Next Release- a soft indication that this issue has a time limit target on it
Ending Soon- a hard indication that this issue is about to close (less than 2 weeks)
Taishi- a project; more on this at a later time
request/blog- request for a specific blog by Basho or Community members
request/demo- request for a demo project, prototype or similar work
request/event- request to host, sponsor or contribute a speaker to a specific community event
request/howto- request for a detailed, step-by-step how-to that is not already tracked in our documentation
request/maintainer- the need for a maintainer on an existing Basho Labs project
request/slides- the request for a new presentation or copy of a past presentation
status/0-triage- TBD; targeted to track progress of technical work
status/1-design-review- TBD; targeted to track progress of technical work
status/2-code-review- TBD; targeted to track progress of technical work
status/3-docs-review- TBD; targeted to track progress of technical work
status/4-merge- TBD; targeted to track progress of technical work
status/claimed- the idea that a community contributor can own the completion of a specific project
status/help-wanted- indicator that the
claimedproject needs a helping hand to keep it going
status/needs-attention- indicator that a project is getting stale and deserves more attention by us all
Maintainers / Thanks
This project began with Mark Phillips and was continued by me, Matt Brender. I would like to keep it in mind as we reflect on the next steps for the Open Source ecosystem that Riak is a part of. Please send your thoughts to firstname.lastname@example.org.
Thanks to those who have contributed in 2015:
- Daniel Dreier (https://github.com/danieldreier)
- Seth Thomas (https://github.com/cheeseplus)
- Lauren Rother (https://github.com/laurenrother)
Feel free to use this format in your own community.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at