Skip to content

Latest commit

 

History

History
77 lines (57 loc) · 3.04 KB

manifesto.rst

File metadata and controls

77 lines (57 loc) · 3.04 KB

Community Manifesto

Development

Although the project is still young, we are taking open sourcing seriously from the start- moving forward, all development and majority of our technical discussions will happen on Github.

Community

The project will have a core team. Team members are seen as the stewards of the project. These are people who can admit changes from anyone, and they bear the responsibility of answering questions, reviewing code, participating and guiding discussions and making sure the project is of high quality and useful.

We are open to admit new members to the core team- inside or outside of Twitter. There's no official process yet, but for the moment we will accept someone if the person has done substantial amount of work on the project, and the existing members unanimously approve the decision.

We welcome and encourage anyone to explore and experiment with the code base- to poke holes, play with it, and be creative. And let us know what you have made out of it and/or what you want from it.

We intend to follow the OSS Manifesto as much as possible.

Other than Github and all its tools, we also have an IRC (#pelikancache on freenode) and a mailing list on Google groups (pelikan-cache).

Flow

All development- bug fixes, features, refactoring- should start with an issue, where the goal(s), methods and scope are stated and discussed, followed by one or more branches/forks and pull requests. All issues will end with either a successful merge, closure without change (abandoned or answered), or an official stay to park the issue till better time.

An issue being ignored does happen, and when it does, we welcome those in the community to raise their voices and make themselves heard. Stay productive by keeping the core team honest.

Priorities

The core contributors are currently all Twitter employees, and thus this project is effectively Twitter-sponsored. We think our effort should be in line with this reality, and be as explicit and transparent about our priorities as possible. What this means in practice is the following:

  • Improvements that help Twitter's use cases are discussed, developed, and accepted with high priority.
  • We take a neutral stance toward other features and improvements- we welcome high quality, compatible changes according to the design philosophy and coding style guide of the project.
  • Patches that clearly harm and degrade performance and dependability of the project in Twitter's use cases will not be admitted, even though such patches may improve other scenarios.

We surely hope our core team members do not remain constant forever. If the composition of contributors change over time, we will re-evaluate the best strategy moving forward upon community request.

Acknowledgement

We were inspired by the Redis Manifesto and the OSS Manifesto