##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.

If you’re looking to get more involved in our community, we’d love to have you. You can connect with your fellow members on IRC, on the riak-user list or in-person at meetups.

The Goal

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")

Contributing

1. 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)
2. Open a pull request with details on your ideas for improvement or corrections to existing information
3. Someone with commit rights to the repo will discuss the details over the PR

Labels

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 claimed project 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 [email protected].

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)

License

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