14 Ways to Contribute to Solr without Being a Programming Genius or a Rock Star

Last week, the venerable Andy Lester posted his “14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star“. It’s a great list, and I highly encourage anyone with an interest in Open Source to read it — but I thought It might be particularly helpful for the readers of this blog to mention how each of these points apply to Solr.

Start listening

• Join a mailing list: solr-user@lucene is the main list for user related questions and discussion about how things work — it’s definitely the place to be to get the pulse of the community. If you’re interested in getting more involved in the development of Solr, you should subscribe to dev@lucene.
• Follow a blog: If you’re reading this, then presumably you already know about the Lucid Imagination Blog, but some other blogs (and blog aggregators) I personally check every day are Search Workings, the Solr-Lucene Zone @ DZone, and Planet Apache. (Planet Apache is an aggregator of blogs from all Apache committers, so many of the posts you find there won’t have anything to do with Solr, but it’s still a great resource.)
• Join an IRC channel: The #solr channel on freenode tends to have a decent number of people in it 24/7, mostly folks helping each other out with small questions and pointers to documentation. There’s also a (logged) #lucene-dev channel where some of the Lucene/Solr developers hang out for real time discussions about developing the internals.

Work with tickets

Solr uses issues.apache.org for tracking issues (ie: bugs and feature requests). Anyone can create a Jira account to create new issues, comment on existing issues, or upload patches.

• Diagnose a bug: It’s fairly common for users to submit bug reports with out enough detail for a developer to quickly grasp what the problem is. One way to help out is to review new bugs, and try to reproduce the problem — either using the steps provided if they are detailed enough, or by trying to figure out what steps might be needed using something like the Solr example configs & data. Even if you can’t diagnose where in the code the problem is, it can be very helpful if you post a comment that: confirms the problem is reproducible; or points out to the reporter what information you found lacking when trying to reproduce; or documenting specific steps other people can follow to reproduce the issue.
• Close fixed bugs: The standard procedure that tends to be followed with Solr is to “Resolve” issues once they have been committed, and “Close” them en-masse once they have been released. So strictly speaking, “Closing” fixed bugs isn’t something community members should try to do. The spirit of this suggestion still holds though: If you see an issue that you can confirm has already been fixed, either because of duplicate reports, or as a side effect of some other change, please comment in the issue with the details so a committer will know it can safely be resolved.

Working with code

Anyone interested in working with the Lucene/Solr code base should start by reading the How To Contribute page on the Solr wiki. It has all the info you need on getting started.

• Test a beta or release candidate: Even if you don’t understand Java code or how to compile it, you can always help us test out unreleased versions before they become official. Nightly Builds are available from our continuous integration server at all times, and release candidates are announced and discussed on the dev@lucene mailing list for at least 72 hours before they become official releases. Testing any of these and reporting back any errors you get, or oddities you see in the packaging or behavior of the code are very helpful.
• Fix a bug: Never be shy about submitting a patch that fixes a bug. Always remember Yonik’s Law Of Patches…
  

  A half-baked patch in Jira, with no documentation, no tests and no backwards compatibility is better than no patch at all.

• Write a test: Even if you have trouble understanding how to fix a bug, writing a Unit test that demonstrates the existence of a bug can help other developers understand the issue and save effort for the community as a whole. Likewise, writing tests for existing features demonstrating that they work helps protect us against bugs being introduced in the future, and can serve as an example of the functionality. If you are looking for existing code that could use more tests, the nightly builds include Clover test coverage reports to help see what code is (and isn’t) getting exercised by tests.
• Silence a compiler warning: Solr has more then it’s fair share of compiler warnings, mostly due to using raw types vs Java Generics. We can always use a hand whittling down the list by reviewing some these warnings to determine if they can be fixed by tweaking type signatures, or if they should be suppressed with an annotation.
• Add a comment: If you’re reading code that confuses you at first, but starts to make sense after you dig a little deeper, then submitingt a patch with a suggested comment explaining what you found will help make that code easier for others to understand in the future.

Contributions from users that do any of the above are always welcome. The best way to make these kinds of contributions is to checkout the trunk source code, make your changes, and then generate a patch file. Then create a new issue (unless one already exists) and attach your patch.

Work with documentation

Most Solr documentation for “end users” (ie: non developers) can be found on the Solr Wiki, which is publicly editable by anyone who creates an account. Fresh eyes are absolutely to helping identify deficiencies in documentation, so improvements are always welcome from new users interested in participating.

• Create an example: The canonical Solr example is included in Solr releases along with a tutorial walking new users through some of the basic features — but this tutorial barely scratches the surface of what Solr can do. Patches adding new information to the existing tutorial are always welcome, but equally valuable is when people publicly post their own examples of how they use Solr. Blog posts are great, but publicly available code/configs on sites like SourceForge or github are even better.

Work in the community

An unofficial motto of the Apache Software Foundation is “Community Over Code” — the most important way people can help out with Solr, is by participating in the community.

• Answer a question: Help answering questions on the solr-user mailing list and #solr IRC channel is always appreciated. Many people just need help understanding terminology and friendly pointers to the existing documentation.
• Write a blog post: Blogs, Articles, WebCasts and Conference presentations about Solr are always welcomed an encouraged.
• Improve a website: The entire Lucene website was recently converted to use the MarkDown based Apache CMS. Anyone can checkout the site source files, make suggested changes to the templates or content, and submit a patch with your suggestions. People with strong CSS, JavaScript, and UI Usability skills are also encouraged to contribute improvements to the Solr Admin UI.

I’ll leave it to Andy to sum up better then I could…

There are so many ways to contribute to open source if we look past the obvious steps of writing a new product feature. Everyone who uses open source can bring their skills to the community and help keep open source a vital part of computing.