...
This section identifies the optimal steps community members can take to submit a changes or additions to the Solr code base. This can be new features, bug fixes optimizations of existing features, or tests of existing code to prove it works as advertised (and to make it more robust against possible future changes). Community members that don't have the time or resources to do everything outlined on this below should not be discouraged from submitting their ideas "as is" per "Yonik's Law of Patches" ...
| No Format |
|---|
A half-baked patch in Jira, with no documentation, no tests
and no backwards compatibility is better than no patch at all.
|
...
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 an a Jira issue. 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.
...
- All public classes and methods should have informative Javadoc comments.
- Code should be formatted according to Sun's conventions, with some exceptions:
- indent two spaces per level, not four. lines can be greater than 80 chars long, 132 is a common limit. Try to be reasonable for very long linesthe Google Java Style Guide. Configure your IDE accordingly.
- Contributions should pass existing unit tests.
- New unit tests should be provided to demonstrate bugs and fixes (http://www.junit.org).
...