Getting Involved with Apache Subversion and the Community

Participate in the mailing lists

There are mailing lists you can join to discuss Subversion. These are an excellent source for users and contributors interested in having technical discussions, answering questions, or resolving potential issues for newcomers.

Promote Subversion

Help promote Subversion by using your blog, Twitter, Facebook, or submitting an article to your favorite local magazine. If you are a member of a different open source community, why not mention Subversion on their discussion forums or at conferences? If you love Subversion, don't hold back — speak up! The more developers use Subversion, the more bugs will be caught, the more features will be added, the more visible the project, and the more benefits the community will get.

Link to subversion.apache.org

The success of any open source project depends on the number of people who use the product and contribute back to the project. By linking to https://subversion.apache.org/, you increase the chances of a new user or contributor finding out about the project and joining the community.

File a bug report

Bug reports take little time to file and are very helpful to developers. This is one of the easiest contributions you can make. When you discover a problem with Subversion, please report it. Our preference as a community is to have you first report the bug to the users@subversion.apache.org mailing list so that other community members can provide some first-level help and triage. Often times there may already be a solution or answer to your problem.

Help us triage existing bug reports

Subversion gets a pretty steady stream of bug reports. While we do our best to validate each report as comes in, we can't possibly prevent every instance of duplicated bug reports, bugs that have been fixed without anybody noticing, and so on in our issue tracker. One way you can help us is by cruising through some of our issues in need of triage, reading the bug reports, and attempting to verify that the bug still exists in Subversion. If you discover some additional information along the way that you think will be useful to the developers, annotate the issue and share what you've learned.

Write a reproduction script

A well-written bug report is invaluable to developers. A reproduction recipe script, however, is worth a hundred well-written reports. Nothing helps developers understand what you were doing when something went wrong better than being able to do exactly that something themselves and see the same results. Unfortunately, many bug reports come in via the mailing list or issue tracker and offer only prose descriptions of the problem. So another excellent opportunity for contribution is to turn those prose reports into reliable, repeatable reproduction scripts, perhaps starting with a script template (unix template, windows template) and customizing it to match the report. This provides several benefits to the developers: you save the developer(s) the work of creating this script themselves; often, your script can be ported directly to Subversion's regression test suite so that the bug, once fixed, stays fixed; and having an additional set of eyes on the bug report can reveal unforeseen nuances such as the fact that the bug is specific to a particular dataset or only happens under some other specific circumstances.

Add a node to our build farm

Subversion has a large regression test suite that takes a non-trivial amount of time to run. Even though developers are encouraged to run these tests before committing changes, sometimes things fall through the cracks — "obvious" changes turn out not to be, platform-specific bugs crop up, etc. To help us catch these sorts of things, we employ a buildbot farm of machines continuously testing our codebase as it changes. So even if you can't personally take the time to actively test Subversion, if you have a computer with cycles to spare, please consider adding it as a node in our buildbot farm. We can always benefit from having our test suite executed continuously on additional operating systems and machine architectures.

Point to buildbot node configuration details here.

Submit a patch

The open-source adage "Patches welcome" may show up most frequently as a thread-killing retort to mailing list trolls, but at the heart of the statement are two quite genuine ideals: software code doesn't write itself, and projects generally really do want as many people as possible to help write that code. The Subversion project is no different. We've accepted and applied countless patch contributions, and we hope to always have a constant stream of them. If you're a developer able to contribute in this way, take a cruise through our Subversion Community Guide, specifically the sections regarding patch submissions and coding conventions, and come join the fun! We have a list of project ideas for those who are looking for a sizable project which can take several weeks or even several months to complete.

Help design new features

Larger features do not just get written when someone has the time and inclination to do so—they get designed first. The process involves discussions on the dev@ list, with reasonably detailed rationales and implementation plans fly across the room. (We often use our wiki to work on the proposed designs.) Participating in such a discussion is an excellent way for users to ensure that planned new features are designed from the very beginning to meet their use-cases and wishes, while for larger features holding such a discussion is key to establishing consensus before any coding takes place.

Convert a reproduction script into a regression test

Often, users or developers post a reproduction script when discussing a bug. One of the tasks involved in fixing the bug is to convert the script (typically a shell script or a batch script) into a Python test in Subversion's test suite. Sending a patch that implements an XFail ("eXpected to fail" until the bug has been fixed) test equivalent to the reproduction script is a very useful contribution, that both serves as a demonstration of the concrete fix sought and allows other contributors and developers to spend more time researching the cause of the bug and fixes thereto.

Become a committer and commit code directly

Developers with a long history of submitting high-quality patches can gain direct commit rights. This is obviously beneficial to the developer community — where quality developers are concerned, "the more, the merrier"! But never underestimate how valuable this experience can be to you personally and professionally.