Get Involved

You don’t need to be a software developer to contribute to Apache Accumulo. To be successful, this project requires a huge range of different skills, levels of involvement, and degrees of technical expertise. So, if you want to get involved in Apache Accumulo, there is almost certainly a role for you.

We are looking for people to:

  • provide feedback
  • write or update documentation
  • help new users
  • recommend the project to others
  • test the code and report bugs
  • fix bugs
  • give us feedback on required features
  • write and update the software
  • create artwork
  • translate to different languages
  • anything you can see that needs doing

All of these contributions help to keep the project active and strengthen the community. The project team and the broader community will therefore welcome and encourage participation, and attempt to make it as easy as possible for people to get involved.

Want to get started now? Check out open issues labeled for “newbies”. If you need help, use the mailing list information below to reach out. If the issue you choose deals with code, you should read the developer’s guide section.

Mailing lists and chat

Your first engagement with the project should be to subscribe to our mailing lists. Apache Accumulo developers and community members hang out in the #accumulo channel on irc.freenode.net.

Contributor Guide

See the contributor guide for recommended practices in interacting with our source code. Take a look at Accumulo’s Ohloh page for an analysis of the code base.

Conferences and Meetups

Community Interaction

Learn about building open source communities.

Decision Making

The most important thing about engaging with any Apache project is that everyone is equal. All people with an opinion are entitled to express that opinion and, where appropriate, have it considered by the community.

To some, the idea of having to establish consensus in a large and distributed team sounds inefficient and frustrating. Don’t despair though, The Apache Way has a set of simple processes to ensure things proceed at a good pace.

In ASF projects we don’t like to vote. We reserve that for the few things that need official approval for legal or process reasons (e.g. a release or a new committer). Most of the time we work with the consensus building techniques documented below.

Lazy Consensus

Lazy consensus is the first, and possibly the most important, consensus building tool we have. Essentially, lazy consensus means that you don’t need to get explicit approval to proceed, but you need to be prepared to listen if someone objects.

Consensus Building

Sometimes, lazy consensus is not appropriate. In such cases, it is necessary to make a proposal to the mailing list and discuss options. There are mechanisms for quickly showing your support or otherwise for a proposal and building consensus amongst the community.

Once there is a consensus, people can proceed with the work under the lazy consensus model.

Voting

Occasionally a “feel” for consensus is not enough. Sometimes we need to have a measurable consensus. For example, when voting in new committers or to approve a release.