├── LICENSE ├── README.md ├── code-of-conduct.md ├── events ├── community-comp-ricon15.md └── judges-template-ricon15.md ├── strategy ├── config-mgmt-strategy.md └── meetup-strategy.md └── templates ├── CONTRIBUTING-basho-labs.md └── CONTRIBUTING-basho.md /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2012-2015 Basho Technologies, Inc http://basho.com 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ##The Basho Community 2 | 3 | 4 | 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. 5 | 6 | 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](http://webchat.freenode.net/#riak), on the [riak-user list](http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com) or [in-person at meetups](http://www.meetup.com/pro/basho/). 7 | 8 | ### The Goal 9 | 10 | Culture is most powerful when chosen intentionally. Let's choose what type of community we wish to be. 11 | 12 | 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"? 13 | 14 | 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](https://github.com/basho-labs/the-riak-community/issues). 15 | 16 | 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. 17 | 18 | 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. 19 | 20 | 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. 21 | 22 | 23 | ### Release Cycles and Versioning 24 | 25 | 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: 26 | 27 | * A new release of The Basho Community will happen as significant changes to our communication processes occur 28 | * Each new version will be a minor version increase as we make minor improvements (i.e. "v0.2" will follow "v0.1") 29 | * A combination of new major programs and new processes may justify a major release (i.e. "v2.0" could follow "v1.6") 30 | 31 | ### Contributing 32 | 33 | 1. Open an [Issue](https://github.com/basho-labs/the-riak-community/issues) as you have ideas for community improvement. These may be as general as requests for visibility ([example](https://github.com/basho-labs/the-riak-community/issues/69)) or as specific as request for coordinated improvements ([example](https://github.com/basho-labs/the-riak-community/issues/71)) 34 | 2. Open a [pull request](https://github.com/basho-labs/the-riak-community/pull/new/master) with details on your ideas for improvement or corrections to existing information 35 | 3. Someone with commit rights to the repo will discuss the details over the PR 36 | 37 | #### Labels 38 | 39 | You'll notice a detailed list of labels on our issues here (inspired by Docker). The major topics are broken out into 3 buckets: 40 | 41 | * **Capitalized** - manually applied labels that indicate an important status 42 | * **requests** - track requests for types of projects, from a how-to guide to a presentation 43 | * **status** - gets people's attention and clarify who's running with what 44 | 45 | Here is what they all mean: 46 | 47 | * `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 48 | * `Next Release` - a soft indication that this issue has a time limit target on it 49 | * `Ending Soon` - a hard indication that this issue is about to close (less than 2 weeks) 50 | * `Taishi` - a project; more on this at a later time 51 | * `request/blog` - request for a specific blog by Basho or Community members 52 | * `request/demo` - request for a demo project, prototype or similar work 53 | * `request/event` - request to host, sponsor or contribute a speaker to a specific community event 54 | * `request/howto` - request for a detailed, step-by-step how-to that is not already tracked in our [documentation](https://github.com/basho/basho_docs) 55 | * `request/maintainer` - the need for a maintainer on an existing Basho Labs project 56 | * `request/slides` - the request for a new presentation or copy of a past presentation 57 | * `status/0-triage` - TBD; targeted to track progress of technical work 58 | * `status/1-design-review` - TBD; targeted to track progress of technical work 59 | * `status/2-code-review` - TBD; targeted to track progress of technical work 60 | * `status/3-docs-review` - TBD; targeted to track progress of technical work 61 | * `status/4-merge` - TBD; targeted to track progress of technical work 62 | * `status/claimed` - the idea that a community contributor can own the completion of a specific project 63 | * `status/help-wanted` - indicator that the `claimed` project needs a helping hand to keep it going 64 | * `status/needs-attention` - indicator that a project is getting stale and deserves more attention by us all 65 | 66 | ## Maintainers / Thanks 67 | This project began with [Mark Phillips](https://twitter.com/pharkmillups) and was continued by me, [Matt Brender](https://twitter.com/mjbrender). 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 [community@basho.com](mailto:community@basho.com). 68 | 69 | Thanks to those who have contributed in 2015: 70 | 71 | * Daniel Dreier () 72 | * Seth Thomas () 73 | * Lauren Rother () 74 | 75 | ## License 76 | 77 | Feel free to use this format in your own community. 78 | 79 | Licensed under the [Apache License](LICENSE), Version 2.0 (the "License"); 80 | you may not use this file except in compliance with the License. 81 | You may obtain a copy of the License at 82 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | #Code of Conduct 2 | 3 | As members of this Community, we recognize that our behavior is our choice and this choice will result in our culture. 4 | 5 | We are a mixture of professionals and volunteers from all over the world, working on every aspect of the mission - including mentorship, teaching, and connecting people. Because we come together from so many different places and positions, we would like a single document that sets communal expectations. 6 | 7 | This isn’t an exhaustive list of things that you can or can't do. Rather, take it in the spirit in which it’s intended - a guide to make it easier to enrich all of us and the technical communities in which we participate. 8 | 9 | 10 | ## Specific Conduct 11 | 12 | Participants are responsible for knowing and abiding by the following: 13 | 14 | * We **err on assuming contributors and users mean well**. This assumption enables us to discuss anything in the open in a mutually respectful way. 15 | * Whether you're a regular contributor or a newcomer, all members care about making this community a safe place for you and we've got your back. 16 | * We are committed to providing a friendly, safe, and welcoming environment for all, regardless of gender, sexual orientation, disability, ethnicity, religion, or similar personal characteristic. 17 | * We will exclude you from interaction if you insult, demean, or harass anyone. That is not welcome behavior. We interpret the term "harassment" as including the definition in the [Citizen Code of Conduct](http://citizencodeofconduct.org/); if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups. 18 | * Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops, event organizers, or any member of the Community team at Basho. 19 | * If you believe someone is violating the code of conduct, we ask that you report it by emailing [conduct@basho.com](mailto:conduct@basho.com). Your privacy will be respected. 20 | 21 | These notes help when discussing architecture: 22 | 23 | * Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. 24 | * We respect data. If you have solid ideas you want to experiment with, make a fork and see how it works. 25 | 26 | ## Additional Community Beliefs 27 | 28 | This Code of Conduct presents a summary of the shared values and “common sense” thinking in our community. The basic social ingredients that hold our project together include: 29 | 30 | * [Be considerate](#be-considerate) 31 | * [Be respectful](#be-respectful) 32 | * [Be collaborative](#be-collaborative) 33 | * [Be pragmatic](#be-pragmatic) 34 | * [Support others in the community](#support-others-in-the-community) 35 | * [Get support from others in the community](#get-support-from-others-in-the-community) 36 | 37 | This Code of Conduct reflects the agreed standards of behavior for members of our community, in any forum, mailing list, wiki, website, IRC channel, public meeting, or private correspondence within the context of Riak and its services. The community acts according to the standards written down in this Code of Conduct and will defend these standards for the benefit of the community. Leaders of any group, such as moderators of mailing lists, IRC channels, forums, etc., will exercise the right to suspend access to any person who persistently breaks our shared Code of Conduct. 38 | 39 | ###Be considerate 40 | 41 | Your actions and work will affect and be used by other people, and you in turn will depend on the work and actions of others. Any decision you make will affect other community members, and we expect you to take those consequences into account when making decisions. 42 | 43 | As a contributor, ensure that you give full credit for the work of others and bear in mind how your changes affect others. It is also expected that you try to follow the [community development guidelines](http://docs.basho.com/riak/latest/community/bugs/). 44 | 45 | As a user, remember that contributors work hard on their part and take great pride in it. If you are frustrated, your problems are more likely to be resolved if you can give accurate and well-mannered information to all concerned. 46 | 47 | ### Be respectful 48 | 49 | In order for the community to stay healthy, its members must feel comfortable and accepted. Treating one another with respect is absolutely necessary for this. In a disagreement, remember to assume that people mean well. 50 | 51 | We do not tolerate personal attacks, racism, sexism, or any other form of discrimination. Disagreement is inevitable, from time to time, but respect for the views of others will go a long way to winning respect for your own view. Respecting other people, their work, their contributions and assuming well-meaning motivation will make community members feel comfortable and safe and will result in motivation and productivity. 52 | 53 | We expect members of our community to be respectful when dealing with other contributors, users, and communities. Remember that we are an international project and that you may be unaware of important aspects of other cultures. 54 | 55 | ### Be collaborative 56 | 57 | Collaboration is about thinking of others. In order to avoid misunderstanding, try to be clear and concise when requesting help or giving it. Remember it is easy to misunderstand emails (especially when they are not written in your native language). Ask for clarifications if unsure how something is meant; remember the first rule — assume that people mean well. 58 | 59 | As a contributor, you should aim to collaborate with other community members, as well as with other communities that are interested in or depend on the work you do. Your work should be transparent and be fed back into the community when available, not just between releases. If you wish to work on something new in existing projects, keep those projects informed of your ideas and progress. 60 | 61 | It may not always be possible to reach consensus on the implementation of an idea, so don't feel obliged to achieve this before you begin. However, always ensure that you keep the outside world informed of your work, and publish it in a way that allows outsiders to test, discuss, and contribute to your efforts. 62 | 63 | Contributors on every project come and go. When you leave or disengage from the project, in whole or in part, you should do so with pride about what you have achieved and by acting responsibly towards others who come after you to continue the project. 64 | 65 | As a user, your feedback is important, as is its form. Poorly thought-out comments can cause pain and the demotivation of other community members, while a considerate discussion of problems can bring positive results. Your encouraging words work wonders. 66 | 67 | ### Be pragmatic 68 | 69 | We are a pragmatic community. We value tangible results over having the last word in a discussion. We defend our core values, but we don't let arguments about minor issues get in the way of achieving more important results. We are open to suggestions and welcome solutions regardless of their origin. 70 | 71 | When in doubt, we support a solution that helps getting things done over one that has theoretical merits but isn't being worked on. Use the tools and methods that help get the job done. Let decisions be taken by those who do the work. 72 | 73 | 74 | ### Support others in the community 75 | 76 | Our community is made strong by mutual respect, collaboration, and pragmatic, responsible behavior. Sometimes there are situations where this has to be defended and other community members need help. 77 | 78 | When problems arise, consider respectfully reminding those involved of our shared Code of Conduct as a first action. Just like bugs in code, we all occasionally make mistakes in our words and actions. When we make mistakes, we need to be told what we did, why it was a mistake, and how it can be done differently or better, as well as given a chance to learn and grow from our mistake. This Code of Conduct is a great resource for that. If someone tells you that you made a mistake, remember that we all make mistakes, learn from it, and do better next time. Try to resist the initial urge many of us feel to defend your words/actions as not a problem. 79 | 80 | Leaders are defined by their actions and can help set a good example by working to resolve issues in the spirit of this Code of Conduct before the situation escalates. 81 | 82 | If you witness others being treated poorly or abused, think first about how you can offer them support. If you feel that the situation is beyond your ability to help individually, go privately to the victim and ask if some form of official intervention is needed. Similarly you should support anyone who appears to be in danger of burning out, either through work-related stress or personal problems. 83 | 84 | 85 | ### Get support from others in the community 86 | 87 | Disagreements, political or technical, happen all the time. Our community is no exception to the rule. The goal is not to avoid disagreements or differing views, but to resolve them constructively. You should turn to the community to seek advice and to resolve disagreements and, where possible, consult the team most directly involved. 88 | 89 | Think deeply before turning a disagreement into a public dispute. If a dispute cannot be avoided, request mediation, trying to resolve differences in a less highly-emotional medium. If you do feel that you or your work is being attacked, take your time to breathe through before writing heated replies. Consider a 24-hour moratorium if emotional language is being used — a cooling off period is sometimes all that is needed. If you really want to go a different way, then we encourage you to publish your ideas and your work, so that it can be tried and tested. 90 | 91 | 92 | ## Thanks 93 | 94 | This document heavily borrows from the [KDE community](https://www.kde.org/code-of-conduct/) and [Rust](http://www.rust-lang.org/conduct.html). We're also influenced by the works of [Geek Feminism](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy), [the Ada Initiative](https://adainitiative.org/2014/02/howto-design-a-code-of-conduct-for-your-community/) and found some well-worded thoughts from [Django's guide](https://www.djangoproject.com/conduct/). 95 | 96 | -------------------------------------------------------------------------------- /events/community-comp-ricon15.md: -------------------------------------------------------------------------------- 1 | # RICON 2015 Community Competition 2 | We want to have a friendly, uplifting competition headed into RICON 2015 that improves our community. Whether you can [attend RICON](http://bit.ly/ricon15e) or will **participate remotely**, jump in and share with your community! 3 | 4 | The complete event is outlined at: http://bit.ly/ricon15comp 5 | 6 | This file covers specific questions judges will ask themselves as they compare entries for the Best Demo RICON 2015 award. **This is not a complete list**, but rather a guide to think through some of the important details. 7 | 8 | # Judging 9 | 10 | Considerations for the Best Demo RICON 2015. 11 | 12 | * **Completeness** - project checks off each of the points under *Objective* above 13 | 14 | * *Required* 15 | 16 | * Is data stored in a Basho product? 17 | 18 | * Can I GET data from the Basho product? 19 | 20 | * Is there an interface to see how the Basho product is used? 21 | 22 | * Is there a clear branching strategy with a deployable master? 23 | 24 | * *Best if* 25 | 26 | * Can I PUT new values into the demo? 27 | 28 | * Can I DELETE existing data from the demo? 29 | 30 | * Does it behave as documented during network partition? 31 | 32 | * Is there reasonable code abstractions? 33 | 34 | * Is there a reasonable level of security considerations taken? 35 | 36 | * **Documentation** - README.md (feel free to copy) and details on how it works 37 | 38 | * *Required* 39 | 40 | * Is the code on a public GitHub repo? 41 | 42 | * There is a README.md at the root of the project 43 | 44 | * README.md explains how to run the demo locally 45 | 46 | * README.md includes authors and license, [simliar to this repo](https://github.com/basho/riak-nodejs-client#license-and-authors) 47 | 48 | * *Best if* 49 | 50 | * Includes network diagram, [like this example](https://github.com/basho-labs/riak-mesos#director) 51 | 52 | * Manages features through Issues 53 | 54 | * The work was completed with empathy for new users 55 | 56 | * The work was completed with empathy for future maintainers 57 | 58 | * **Creativity** - Does it make us smile? That x-factor that you can’t put a number on 59 | 60 | * *Required* 61 | 62 | * Project has a name 63 | 64 | * *Best if* 65 | 66 | * The name makes us smile 67 | 68 | * The demo is unique 69 | 70 | * The demo is meaningful to new developers 71 | 72 | If you build a creative project with well-written documentation and don’t have it completed, you still can win over someone who completes something that has an empty README. -------------------------------------------------------------------------------- /events/judges-template-ricon15.md: -------------------------------------------------------------------------------- 1 | # Judge's Template - RICON 2015 Community Competition 2 | 3 | **How-to:** 4 | 5 | 1. Make a copy of this template for each demo you review 6 | 2. Check all boxes that apply 7 | 3. Do the math (or write code that will do it for you) 8 | 4. Have fun doing it! 9 | 10 | ---- 11 | 12 | | About |Details| 13 | |------------|-------| 14 | | **Demo:** || 15 | | **URL:** || 16 | 17 | Max points|Points awarded|Feature question|Notes 18 | :--------:|:------------:|----------------|----- 19 | |10 |_ |Completness? | 20 | |10 |_ |Documentation? | 21 | |10 |_ |Creativity? | 22 | 23 | ---- 24 | 25 | * **Completeness** - project checks off each of the points under *Objective* above 26 | 27 | - *Required* 28 | 29 | - [ ] Is data stored in a Basho product? 30 | 31 | - [ ] Can I GET data from the Basho product? 32 | 33 | - [ ] Is there an interface to see how the Basho product is used? 34 | 35 | - [ ] Is there a clear branching strategy with a deployable master? 36 | 37 | * *Best if* 38 | 39 | - [ ] Can I PUT new values into the demo? 40 | 41 | - [ ] Can I DELETE existing data from the demo? 42 | 43 | - [ ] Does it behave as documented during network partition? 44 | 45 | - [ ] Is there reasonable code abstractions? 46 | 47 | - [ ] Is there a reasonable level of security considerations taken? 48 | 49 | * **Documentation** - README.md (feel free to copy) and details on how it works 50 | 51 | * *Required* 52 | 53 | - [ ] Is the code on a public GitHub repo? 54 | 55 | - [ ] There is a README.md at the root of the project 56 | 57 | - [ ] README.md explains how to run the demo locally 58 | 59 | - [ ] README.md includes authors and license, [simliar to this repo](https://github.com/basho/riak-nodejs-client#license-and-authors) 60 | 61 | * *Best if* 62 | 63 | - [ ] Includes network diagram, [like this example](https://github.com/basho-labs/riak-mesos#director) 64 | 65 | - [ ] Manages features through Issues 66 | 67 | - [ ] The work was completed with empathy for new users 68 | 69 | - [ ] The work was completed with empathy for future maintainers 70 | 71 | * **Creativity** - Does it make us smile? That x-factor that you can’t put a number on 72 | 73 | * *Required* 74 | 75 | - [ ] Project has a name 76 | 77 | * *Best if* 78 | 79 | - [ ] The name makes us smile 80 | 81 | - [ ] The demo is unique 82 | 83 | - [ ] The demo is meaningful to new developers 84 | 85 | **Reminder:** If someone builds a creative project with well-written documentation and they do not have it completed, they still can win over someone who completes something that has an empty README. 86 | 87 | ## About the Event 88 | 89 | We want to have a friendly, uplifting competition headed into RICON 2015 that improves our community. Whether you can [attend RICON](http://bit.ly/ricon15e) or will **participate remotely**, jump in and share with your community! 90 | 91 | The complete event is outlined at: http://bit.ly/ricon15comp 92 | 93 | This file covers specific questions judges will ask themselves as they compare entries for the Best Demo RICON 2015 award. **This is not a complete list**, but rather a guide to think through some of the important details. -------------------------------------------------------------------------------- /strategy/config-mgmt-strategy.md: -------------------------------------------------------------------------------- 1 | # Config Mgmt Strategy 2 | 3 | At this time, configuration management (CM) code is a community "best effort" initiative. Maintaining these repositories that are useful for Basho product configuration will require a combination of clear guidelines and community collaboration. 4 | 5 | Here's where we think we're starting and some direction on where we go. We'd love for you to be part of the process. 6 | 7 | 8 | ### What we mean by Configuration Management 9 | 10 | Configuration management tools install packages, manage configuration files, control services, and otherwise define infrastructure state using code. 11 | These tools simplify installation and management of Riak. The basho-labs project includes code for managing Riak using [Chef](https://www.chef.io/), [Puppet](https://puppetlabs.com/) and [Ansible](http://www.ansible.com/). We (at Basho) see the automation and orchestration available through these products as core to infrastructure today. 12 | 13 | 14 | ### Our Goal [Beta - Open PRs or Issues to Discuss] 15 | 16 | We're starting with a focus on just Riak KV, our distributed database. 17 | 18 | We'd like to have a single system for all tools that tells you, the community member, how much Riak KV functionality is available by using it. Each toolset has its own terms and best practices. That's fine. What we would like to achieve is a common ground for definitions of Riak's functions in relation to these tools. 19 | 20 | We'll call each code base's compliance a **Riak management level** (RML). RMLs will have different levels that are clearly defined below as either **Basic**, **Intermediate** or **Advanced**. RMLs will be defined for each tool and each functional requirement. 21 | 22 | ### Community Supported Repos 23 | Here are the three repositories monitored by @mjbrender from the Developer Advocacy team. You can add other helpful repos that should be kept in consideration here. 24 | 25 | * **Chef** = https://github.com/basho-labs/riak-chef-cookbook 26 | * **Ansible** = https://github.com/basho-labs/ansible-riak 27 | * **Puppet** = https://github.com/basho-labs/puppet-riak 28 | 29 | 30 | ### Configuration Tool Riak Management Capabilities 31 | 32 | | Tool | **Ansible** | **Puppet** | **Chef** | 33 | |-------------------|---------------|--------------|--------| 34 | | **Status** 35 | | Public CI Status | [![Build Status](https://travis-ci.org/basho-labs/puppet-riak.svg?branch=master)](https://travis-ci.org/basho-labs/ansible-riak) | [![Build Status](https://travis-ci.org/basho-labs/puppet-riak.svg?branch=master)](https://travis-ci.org/basho-labs/puppet-riak) | [![Build Status](https://travis-ci.org/basho-labs/riak-chef-cookbook.svg?branch=master)](https://travis-ci.org/basho-labs/riak-chef-cookbook) 36 | | Latest Release | [![Ansible Galaxy](https://img.shields.io/ansible/role/8095.svg?maxAge=2592000)](https://galaxy.ansible.com/basho-labs/riak-kv/) | [![PuppetForge](http://img.shields.io/puppetforge/v/basholabs/riak.svg?style=flat-square)](https://forge.puppetlabs.com/garethr/docker) | [![Cookbook Version](http://img.shields.io/cookbook/v/riak.svg)](https://supermarket.getchef.com/cookbooks/riak) | 37 | | License | Apache-2.0 | Apache-2.0 | Apache-2.0 38 | | **Versions** 39 | | Supports Riak 1.x | yes | no | yes 40 | | Supports Riak 2.x | yes | yes | yes 41 | | Tool Version Requirement | Ansible 2.1+ | Puppet 3.7+ | Chef 11 42 | | **Installation** 43 | | System packages | yes | yes | yes 44 | | Riak EE S3 download | yes(?) | no | yes 45 | | Ad-hoc patches | yes(???) | no | yes 46 | | **Configuration** 47 | | riak.conf | all settings | all settings | all settings 48 | | advanced.conf | no | no | no (?) 49 | | OS performance settings | ??? | no | yes 50 | | **Management** 51 | | Create buckets | yes | no | no 52 | | Alter buckets | ??? | no | no 53 | | Create solr index | ??? | no | no 54 | | Create solr index using schema | ??? | no | no 55 | | Add solr schema | ??? | no | no 56 | | Manage secondary indexes | ??? | no | no 57 | | Set bucket properties | yes | no | no 58 | | Enable security | yes | no | ??? 59 | | Manage security | yes | no | ??? 60 | | Enable strong consistency | ??? | no | ??? 61 | | Manage strong consistency | ??? | no | ??? 62 | | Data Operation | Intermediate? | no | no 63 | | **Cluster Management** 64 | | Join Cluster | yes (?) | no | no 65 | | Discover Cluster | ??? | no | no 66 | | Leave Cluster | ??? | no | no 67 | | Rolling Restart | ??? | no | no 68 | | hands-off bootstrap | no | no | no | no 69 | | stage changes | no | no | no 70 | | **Multi-Datacenter** (Riak EE only) 71 | | Set Cluster Name | ??? | no (?) | no (?) 72 | | Connect | ??? | no (?) | no (?) 73 | | Sync | ??? | no (?) | no (?) 74 | | Configure Scheduling | ??? | no (?) | no (?) 75 | | Realtime Cascade | ??? | no (?) | no (?) 76 | | NAT | ??? | no (?) | no (?) 77 | | Performance Tuning| ??? | no (?) | no (?) 78 | | **Code Quality** 79 | | Unit tests | yes | yes | yes 80 | | VM-based Integration Tests | ???? | yes (beaker) | yes (test kitchen) 81 | 82 | 83 | ## Riak Installation Requirements 84 | 85 | ### Basic 86 | 87 | * Version 88 | 89 | * Latest (Hardcoded) 90 | 91 | * Start/stop service 92 | 93 | * OSS only 94 | 95 | * Install Location - Package Default 96 | 97 | ### Intermediate 98 | 99 | * Version 100 | 101 | * Latest by default, configurable 102 | 103 | * Riak EE (be able to download from S3 using a URL code) 104 | 105 | ### Advanced 106 | 107 | * Location - Custom 108 | 109 | * Version - Git / Source 110 | 111 | ## Riak Configuration Requirements 112 | 113 | ### Basic 114 | 115 | * Options in riak.conf 116 | 117 | * Node Name 118 | 119 | * Listen Address & Port 120 | 121 | * Ring Size 122 | 123 | * Distributed Cookie 124 | 125 | * Solr on/off 126 | 127 | * Custom riak.conf Template (include their own but change the node name, addresses etc) 128 | 129 | ### Intermediate 130 | 131 | * Options in riak.conf 132 | 133 | * AAE (On/Off) 134 | 135 | * SSL 136 | 137 | * Multi-Backend 138 | 139 | * Disk Locations 140 | 141 | * Include custom advanced.config 142 | 143 | ### Advanced 144 | 145 | * Options in riak.conf 146 | 147 | * All Options 148 | 149 | * Riak EE Options 150 | 151 | * All Options 152 | 153 | Note: Leverage OS level configuration options available with the CM tools to tune the OS 154 | 155 | ## Riak Data Operations Requirements 156 | 157 | ### Basic 158 | 159 | * Bucket 160 | 161 | * Set Props from JSON 162 | 163 | * Bucket Types 164 | 165 | * Create from JSON 166 | 167 | * Activate 168 | 169 | * Solr 170 | 171 | * Create Index 172 | 173 | ### Intermediate 174 | 175 | * Bucket 176 | 177 | * Set Props via API 178 | 179 | * n_val 180 | 181 | * allow_mult 182 | 183 | * search_index 184 | 185 | * Solr 186 | 187 | * Create Index using Schema 188 | 189 | * Add Schema 190 | 191 | ### Advanced 192 | 193 | * Secondary Indexes 194 | 195 | * Bucket Properties 196 | 197 | * Quorum 198 | 199 | * Hooks 200 | 201 | * Bucket Types 202 | 203 | * API for CRDT Types 204 | 205 | * Update 206 | 207 | * Security 208 | 209 | * Enable & Configure 210 | 211 | * Strong Consistancy 212 | 213 | * Enable & Configure 214 | 215 | 216 | ## Riak Cluster Operations Requirements 217 | 218 | ### Basic 219 | 220 | * Join Cluster 221 | 222 | ### Intermediate 223 | 224 | * Discover existing cluster using CM-native tooling 225 | 226 | * Leave Cluster 227 | 228 | * Rolling Restart 229 | 230 | ### Advanced 231 | 232 | * Bootstrap full cluster with no manual configuration steps 233 | 234 | * Group changes to multiple nodes and make one staged cluster plan to avoid unnecessary rebalancing 235 | 236 | * Provide ability to block cluster changes if rebalancing is already underway 237 | 238 | ## Riak Multi Data Center Operations 239 | 240 | ### Basic 241 | 242 | * MDC v3 243 | 244 | * Set Cluster Name 245 | 246 | ### Intermediate 247 | 248 | * MDC v3 249 | 250 | * Configure Address & Port 251 | 252 | * Connect 253 | 254 | * Realtime 255 | 256 | * Enable / Disable 257 | 258 | * Start / Stop 259 | 260 | * Full Sync 261 | 262 | * Enable / Disable 263 | 264 | * Start / Stop 265 | 266 | * Configure Scheduling 267 | 268 | ### Advanced 269 | 270 | * MDC v3 271 | 272 | * Realtime Cascade 273 | 274 | * NAT 275 | 276 | * Tuning 277 | 278 | ## Code Quality 279 | 280 | ### Basic 281 | 282 | * Example executable code 283 | 284 | * Automated tooling (rake, make, etc) to run: 285 | 286 | * Linting on core config management code 287 | 288 | * Any unit testing at all 289 | 290 | * Documentation or metadata should list supported platforms 291 | 292 | * Licensed with an OSI-approved open source license 293 | 294 | * Code is idempotent and fully converges in one run, unless technical limitations in the tooling or underlying software prevent it 295 | 296 | ### Intermediate 297 | 298 | * Code is versioned using semver 299 | 300 | * Automated tooling (rake, make, etc) to run: 301 | 302 | * Linting on config management code as well as validating any JSON, YAML, config files, etc. 303 | 304 | * Unit tests and/or VM-based integration tests (e.g. Beaker or Test Kitchen) with test coverage for major functionality 305 | 306 | * Publicly accessible CI system that runs linting and some level of unit and/or acceptance tests on pull requests prior to merges 307 | 308 | * All functionality implemented using abstractions native to the configuration management tool, not exec or similar 309 | 310 | * Where possible, code defaults to installing all software via system package management tools using package repositories 311 | 312 | * No manual steps needed to install any dependencies or configuration files before running CM tool 313 | 314 | ### Advanced 315 | 316 | * Publicly accessible CI infrastructure that runs both unit tests and acceptance tests for all supported platforms 317 | 318 | * If the configuration management tool has a ratings or approval system for modules, it should be approved. (e.g. Puppet Approved forge modules) 319 | -------------------------------------------------------------------------------- /strategy/meetup-strategy.md: -------------------------------------------------------------------------------- 1 | ## Meetup Strategy 2 | 3 | The goal of this document is to provide repeatable insight into how we execute on Meetups, both Basho as lead and Basho as a guest. You'll notice a distinct focus on **beginners** & **developers**. 4 | 5 | Let's go over our terms before mapping out the timeline. 6 | 7 | #### Types of Events 8 | 9 | |Meetups run by Basho|Visiting local Meetup|at Tier 1 event [in beta]| 10 | |--------|--------|----------| 11 | Lecture|Lecture|Annual Bashochat 12 | Hack Night|Hack Night|Private Briefing 13 | 14 | A **Lecture** is an event when we line up a speaker to talk for a majority of the event [45 min - 60 min] and focuses on sharing an expertise or an experience [Introduction to X or How We do Y]. 15 | 16 | A **Hack Night** is a format with a shorter speaking slot [10-20 minutes] and focuses on people coding together. 17 | 18 | A **Show and Tell** is where the host gives a brief introduction [5 minutes] and then passes the stage to 2 or more speakers who go into how they're building their application [15-20 minutes each]. Speakers are recommended to make the topic conversational in the sense that it has natural breaks in the talk track and "this is what we're doing, does this apply to you?" type of calls to action. The topic can dig into solving a particular distributed systems use case and a little about the how. Target a developer audience with appreciation for the beginner and advanced audience member (it's a tough balance, feel free to give a little to both). 19 | 20 | A **Tier 1** event is somewhere we have a booth and want to get a little something extra in our community efforts. These can be causal get-togethers or more formal briefings on product. We can also make an effort to attend or start a Meetup to overlap with events if we feel confident we can capture part of the audience's attention. This works well when done annually around a given event. 21 | 22 | #### Timelines 23 | To host one of these events smoothly, you should schedule a Meetup **3 weeks ahead of time**. 24 | 25 | #### Meetup Kits 26 | 27 | We want to standardize on a Meetup kit so events become easy to run through. These include: 28 | 29 | * Signage (usually a pop-up stand) 30 | * More than enough stickers 31 | * A unique giveaway (i.e. Basho pint glass, stress ball, bobbleheads) 32 | 33 | #### Budget 34 | 35 | We have between $200-$1,000 a month to support Meetup activities. Depending on the month, these funds could be allocated to between 3 to 5 events. We're looking for lightly budgeted lift here. 36 | 37 | **Options**: 38 | If you have a compelling, measurably-audience-grabbing idea for our Meetups, definitely share it. There are times that will be worth the extra effort and we're glad to get the idea. Open an Issue [here](https://github.com/basho-labs/the-riak-community/issues) or shoot me an [email](mailto:mbrender@basho.com). 39 | 40 | If you feel your local Meetup could benefit from more funds, you're welcome to work on local sponsorships that Meetup.com allows. 41 | 42 | 43 | ### 3+ Weeks Out 44 | 45 | * Post details to appropriate Meetup.com community 46 | * Ensure the venue is set correctly 47 | * Recommended settings: 48 | * A Tuesday-Thursday night 49 | * From 7:00pm - 9:00pm 50 | * Topic is descriptive (more on that later) 51 | * Description is detailed (more on that later) 52 | * Once details are filled in, use the Announcement feature to broadcast it 53 | 54 | Other tips: 55 | * Wait to use the Announcement feature until you have all details listed above complete 56 | 57 | ### 2 Weeks Out 58 | 59 | * If you haven't already, finalize settings and use the Announcement feature to broadcast it 60 | * Add your event to the latest [release notes](https://github.com/basho-labs/the-riak-community/tree/master/release-notes) 61 | * Announce the event on IRC, over Twitter and/or elsewhere (Reddit, LinkedIn) 62 | * Make sure to have whatever cables you'll need for the presentation 63 | * If you're using slides, open them up to [comment to the community alias](mailto:community@basho.com) which includes individuals who volunteered to help internally to Basho 64 | 65 | 66 | ### 1 Week Out 67 | 68 | * If you're using slides, they're due back to you this week 69 | * Send an email to the Meetup list as a last hurrah ([here's an example](https://docs.google.com/a/basho.com/document/d/1WgO8OV-6_FAMdZVhknlbQJr56ySOfm-3p9rJYh7M8us/edit?usp=sharing)) 70 | * Don't be shy about posting to your personal networks 71 | * Let us know [over Twitter](http://twitter.com/basho) and we're happy to RT 72 | * Confirm vendors are lined up for food & drink 73 | 74 | ### Day of 75 | 76 | * Setup signage provided at least 30 minutes early 77 | * Make sure entering the facility is clearly marked 78 | * Have a projector setup and a connection ready with your laptop 79 | * Be ready to *be the host* - smiling, welcoming, open to new attendees 80 | * Keep a tally of attendees and get business cards of people who would appreciate follow up 81 | * Keep an eye out for interested members who could help coordinate the event or speak in the future 82 | 83 | ### Day after 84 | 85 | * Send your results and other notes to [the community alias](mailto:community@basho.com) 86 | * Send follow-ups 87 | * Thank you's to those who contributed (speakers, sponsors) 88 | * Email to attendees with answers to open questions 89 | * Post notes to Meetup.com space -------------------------------------------------------------------------------- /templates/CONTRIBUTING-basho-labs.md: -------------------------------------------------------------------------------- 1 | #Notes 2 | Below is a default CONTRIBUTING.md file for all repositories under the [Basho Labs](https://github.com/basho-labs/) organization. It's best to keep the Contributing header identical - please open a PR if you think it should change! 3 | 4 | All How-to contribute sections are recommended to be updated with the maintainer's preferred text. 5 | 6 | ##Contributing 7 | 8 | This repository is **community supported**. We both appreciate and need your contribution to keep it stable. 9 | 10 | Every community supported project at Basho has a maintainer. $USERNAME is the maintainer here. For more on how to contribute, [take a look at the contribution process](#how-to-contribute). 11 | 12 | Thank you for being part of the community! We love you for it. 13 | 14 | ## How-to contribute 15 | 16 | ## How-to contribute to the .NET client 17 | Basho Labs repos survive because of community contribution. Here’s how to get started. 18 | 19 | **_IMPORTANT_**: This is an open source project licensed under the Apache 2.0 License. We encourage contributions to the project from the community. We ask that you keep in mind these considerations when planning your contribution. 20 | 21 | * Whether your contribution is for a bug fix or a feature request, **create an [Issue](https://github.com/basho/LINK TODO LINK/issues)** and let us know what you are thinking. 22 | * **For bugs**, if you have already found a fix, feel free to submit a Pull Request referencing the Issue you created. 23 | * **For feature requests**, we want to improve upon the library incrementally which means small changes at a time. In order ensure your PR can be reviewed in a timely manner, please keep PRs small, e.g. <10 files and <500 lines changed. If you think this is unrealistic, then mention that within the Issue and we can discuss it. 24 | 25 | Once you're ready to contribute code back to this repo, start with these steps: 26 | 27 | * Fork the appropriate sub-projects that are affected by your change 28 | * Create a topic branch for your change and checkout that branch 29 | `git checkout -b some-topic-branch` 30 | * Make your changes and run the test suite if one is provided (see below) 31 | * Commit your changes and push them to your fork 32 | * Open a pull request for the appropriate project 33 | * Contributors will review your pull request, suggest changes, and merge it when it’s ready and/or offer feedback 34 | * To report a bug or issue, please open a new issue against this repository 35 | 36 | You can [read the full guidelines for bug reporting and code contributions](http://docs.basho.com/riak/latest/community/bugs/) on the Riak Docs. 37 | 38 | And **thank you!** Your contribution is incredibly important to us. It'd be great for you to add it to a current or past community release note [here](https://github.com/basho-labs/the-riak-community/tree/master/release-notes). 39 | 40 | 41 | 42 | -------------------------------------------------------------------------------- /templates/CONTRIBUTING-basho.md: -------------------------------------------------------------------------------- 1 | #Notes 2 | Below is a default CONTRIBUTING.md file for all repositories under the [Basho](https://github.com/basho/) organization. It's best to keep the Contributing header identical - please open a PR if you think it should change! 3 | 4 | All How-to contribute sections are recommended to be updated with the maintainer's preferred text. 5 | 6 | ##Contributing 7 | 8 | This repo's maintainers are engineers at Basho and we welcome your contribution to the project! 9 | 10 | ### An honest disclaimer 11 | 12 | Due to our obsession with stability and our rich ecosystem of users, community updates on this repo take longer to review. 13 | 14 | The most helpful way to contribute is by reporting your experience through issues. Issues may not be updated while we review internally, but they're still incredibly appreciated. 15 | 16 | Pull requests take multiple engineers for verification and testing. If you're passionate enough to want to learn more on how you can get hands on in this process, reach out to [Matt](mailto:mbrender@basho.com), your developer advocate. 17 | 18 | Thank you for being part of the community! We love you for it. 19 | 20 | ## How-to contribute 21 | 22 | **_IMPORTANT_**: **Always** start by [opening an issue]() to notify the engineers maintaining this repo. PRs that do not begin as a conversation over an issue are not as likely to be merged. 23 | 24 | We encourages Issues and PRs to Riak from the community. Here’s how to get started. 25 | 26 | * Fork the appropriate sub-projects that are affected by your change. 27 | * Create a topic branch for your change and checkout that branch. 28 | `git checkout -b some-topic-branch` 29 | * Make your changes and run the test suite if one is provided. (see below) 30 | * Commit your changes and push them to your fork. 31 | * Open pull-requests for the appropriate projects. 32 | * Contributors will review your pull request, suggest changes, and merge it when it’s ready and/or offer feedback. 33 | * To report a bug or issue, please open a new issue against this repository. 34 | 35 | You can [read the full guidelines for bug reporting and code contributions](http://docs.basho.com/riak/latest/community/bugs/) on the Riak Docs. 36 | 37 | And **thank you!** Your contribution is incredibly important to us. --------------------------------------------------------------------------------