THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Contributing to BookKeeper doesn't just mean writing code. Helping new users on the mailing list, testing releases, and improving documentation are also welcome. In fact, proposing significant code change usually requires first gaining experience and credibility within the community by helping in other ways. This is also a guide to becoming an effective contributor.
| Table of Contents |
|---|
Overview
BookKeeper uses:
- JIRA to track logical issues, including bugs, tasks and improvements.
- Mailing Lists for proposing, planning, discussing changes
- Confluence for documentation
- Github pull requests or Review boards to manage the reviews and merge of specific code changes
That is, Mailing Lists are used for discussion and proposals, JIRA and Confluence are used to describe what should be fixed or changed and high-level approaches, and Pull Requests and Review Board describe how to implement the change in code.
Contributions
By Helping Other Users
Helping answer user questions on the user@bookkeeper.apache.org mailing list is the first way to contribute to BookKeeper. There are always many new BookKeeper users; taking a few minutes to help answer a question is very valuable community service.
Contributors should subscribe to this list and follow it in order to keep up to date on what's happing in BookKeeper. Answering questions is an excellent and visible way to help the community, which also demonstrates your expertise.
By Testing Releases
BookKeeper's release process is community-oriented, and members of the community can vote on new releases on the dev@bookkeeper.apache.org mailing list. BookKeeper users are encouraged to subscribe to this list to receive announcements (e.g the BookKeeper 4.3.1 release vote), and test their workloads on the newer release and provide feedback on any performance or correctness issues found in the newer release.
By Reviewing Changes
Changes to BookKeeper source code are proposed, reviewed and committed via Pull Request or Review Board (described later). Anyone can view and comment on active changes here. Reviewing others' changes is a good way to learn how the change process works and again exposure to activity in various parts of the code. You can help by reviewing the changes and asking questions or pointing out issues – as simple as typos or small issues of style.
Documentation Changes
To have us add a link to an external tutorial you wrote, simply email to dev@bookkeeper.apache.org.
To modify the built-in documentation, checkout the instructions on How to build website and documentation.
Preparing to Contribute Code Changes
Before proceeding to code changes, contributors should evaluate if the proposed change is likely to be relevant, new and actionable:
- Is it clear that code must change? Proposing a JIRA and pull request is appropriate only when a clear problem or change has been identified. If simply having trouble using BookKeeper, use the mailing list first, rather than considering filing a JIRA or proposing a change. When in doubt, email user@bookkeeper.apache.org first about the possible change.
- Search the user@bookkeeper.apache.org and dev@bookkeeper.apache.org mailing list archives for related discussions. Often, the problem has been discussed before, with a resolution that doesn't require a code change, or recording what kind of changes will not be accepted as a resolution.
- Search JIRA for existing issues: https://issues.apache.org/jira/browse/BOOKKEEPER
Type "bookkeeper [search terms]" at the top right search box. If a logically similar issue already exists, then contribute to the discussion on the existing JIRA and pull request first, instead of creating a new one. - Is the scope of the change matched to the contributor's level of experience? Anyone is qualified to suggest a typo fix, but refactoring recovery logic requires much more understanding of BookKeeper. Some changes require building up experience first (see above).
Code Review Criteria
(WIP)