...

Contributors should join the Solr mailing lists. In particular:

• the user list (to help others)
• The commit list (to see changes as they are made)
• The dev list (to join discussions of changes)
• The issues list (to track all JIRA issue changes)

...

• Get a copy of any email sent to one of the Lucene Solr lists from an address that is not subscribed and review it to see if it's spam or not
• Occasionally help people with particular difficulties unsubscribing to the mailing list.

If you'd like to volunteer to be the moderator of a mailing list, just contact listname-owner@luceneowner@solr... (ie: solrusers-user-owner@luceneowner@solr...)

Write/Improve User Documentation

...

This means that everyone can help improve the Reference Guide by editing these files and seeing your changes exactly as they will appear. Just like the source code, if your patch is approved a committer will have to pick it up. Some helpful instructions are in the ../solrdev-docs/solr-ref-guide/meta-docs. See particularly asciidoc-syntax.adoc and editing-toolsjekyll.adoc documents.

You can still comment on pages in the on-line version of the Reference Guide and that's certainly helpful. Contributing a documentation patch is even better. Even if you If you spot a weakness in the documentations, and don't know exactly what to say to improve it, ask on the user list and you'll probably get a lot of great responses – talking informally about how Solr works is something lots of people tend to have time for, but aggregating all of that info into concise cohesive documentation takes a little more work and patience so help is appreciated.

When to contribute to this Wiki instead of the Solr Ref Guide

If there is a patch in Jira that you think is really great, writing some "user guide" style docs about how it works (or is suppose supposed to work) in this wiki is a great way to help the patch get committed: It helps serve as a road map for what the "goal" of the issue is, what should be possible for users to do once the issue is resolved; it helps get people who may not understand the low level details get excited about the new functionality; and it can eventually evolve into the final documentation once the code is committed. (just make sure to link to the issue so people who find your wiki page first know it's not included in Solr's main code line yet).

...

Just because you may not have the time to write unit tests, or cleanup backwards compatibility issues, or add documentation, doesn't mean other people don't. Putting your patch out there allows other people to try it and possibly improve it. That said if you want to maximally increase the chances that your patch will get the attention it deserves, leave no stone unturned so that committers are more interested in your patch.

Getting the source code   ← ERIC SAYS THIS NEEDS REWORKING AFTER THE PROJECT SPLIT.

First of all, you need the Solr source code.

Get the source code on your local drive using http://lucenesolr.apache.org/solr/community.html#version-control.

To check out code from Git. (The repositories listed in the commands, below, use the Apache Git repository; however, a GitHub mirror is also available that is what MOST folks use. See Working with GitHub.)

# clone repository - for non-committers (read-only):
git clone http://gitbox.apache.org/repos/asf/lucene-solr.git

# clone repository - for committers (read/write):
git clone https://gitbox.apache.org/repos/asf/lucene-solr.git

# check out desired branch:
git checkout <branch>

The <branch> part of the command above needs to be replaced by something concrete - the "code line" you want to get. Examples, and how to interpret what they mean:

• mastermain: Working towards the eventual 9.0 release. This is the main center for development, it's not really a branch. Releases are never made from mastermain, they are only made from the stable development branch.
• branch_8x: The current stable development branch for the next stable 8.x version.
• branch_7x: The previous stable development branch for 7.x releases.
• lucene_solr_7_1: The branch from which 7.1.x versions are built. This is a minor release branch.
• branch_6x: The previous stable development branch for 6.x releases.
• releases/lucene-solr/7.1.0: When a new version is fully released, the branch_x_x branch is copied to a tag which represents the source code for that specific release.
• branch_6_6: When 7.0.0 was released and 6.x went into maintenance mode, all maintenance development moved to this branch, because it was the last minor release branch in the 6.x line. Only fixes for major bugs and security issues are made to versions in maintenance mode.
• branch_5_5: When 6.0.0 was released and 5.x went into maintenance mode, all maintenance development moved to this branch, because it was the last minor release branch in the 5.x line. Normally with the release of 7.0.0 all development would cease on the 5.x code, but a temporary exception was made for this branch because of a security issue, and version 5.5.5 was released *after* the 7.0.0 release to fix that problem.

...

Be sure that you are using an appropriate version of the JDK. Current master main branch requires Java 11 and branch_8x requires Java 8 (1.8.x).

Working with GitHub  ← ERIC SAYS MAYBE WE SHOULD JUST MOVE THIS UP AND ONLY TALK ABOUT THE SOLR 9 APPROACH...????

If you prefer you could use the GitHub mirror instead. Note that the drop-down lets you select "master" or "branch_7x" (among others). We accept GitHub Pull Requests (PR). To submit one, first fork the project, then make changes in a feature branch which you push to GitHub and use as the basis for the PR. PRs should be linked to a JIRA issue in the appropriate project here: Solr Jira or here: Lucene Jira. To link your PR to the Jira issue simply include the Jira issue id in the title of the PR (first create the Jira issue if one doesn't exist).

...

When making larger scale (please, try to keep your patches as small as humanly possible) changes, or when working in a team, you might want to be able to keep track of what you are doing locally. One way of doing so is to clone the lucene- solr repository and create a local branch to which you can commit all your work. Another way is using Github to create a fork of apache/lucene-solr and use that to commit code either individually or as a team. Once you are ready, you can send a pull request to lucene- solr after creating an issue on the lucene-solr Solr Jira and mentioning the jira issue number in the pull request.

...

Before you start, you should send a message to the Solr developer mailing list (Note: you have to subscribe before you can post), or file a bug in Jira. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements.

...