Hi everyone, I'm trying to gather some additions to the contributors page of the shindig site. I'd like to address a few issues that have come up with patches from non-committers. Here's what I have so far:
- Patches should be attached to the JIRA issue tracker. Patches sent via email will likely just be forgotten. - Patch must conform to style guides as specified by http://cwiki.apache.org/confluence/display/SHINDIGxSITE/Java+Style, http://cwiki.apache.org/confluence/display/SHINDIGxSITE/Javascript+Style, http://cwiki.apache.org/confluence/display/SHINDIGxSITE/PHP+Style, etc. Minor deviations are acceptable, at the discretion of the committer (who must resolve the deviations herself). If a commiter judges that a patch is too far off of the style guide, she may reject it. - Any new code paths should include corresponding unit tests. New classes with any non-trivial public methods (i.e. anything that actually does work) must provide a matching test case. No patch will be accepted without corresponding test coverage. There is currently an exception to this for javascript, pending a solid solution for running jsunit or similar tests. - All existing tests must pass after the patch is applied. If any tests fail, you must also patch the code that is now failing (either by updating the test, or modifying the code path as appropriate). If you need to make any major changes to other code that is not directly related to your change, please include notes to that effect in the JIRA ticket. If you're unsure of what to do, email shindig-dev@, or the component lead for the code you're patching. - Patches should be as small and focused as possible. The smaller they are, the easier it is to avoid conflicts and for committers to review them. - Patch should be against a relatively recent version of Shindig so as to avoid merge conflicts; ideally, the patch should be against HEAD at the time of creation. Committers will do our best to resolve any minor merge issues that occur between patch submission and commit time, though we may not be able to do this in the event of major conflicts. - Any changes in javascript with implications for server side functionality must be approved by all server-side language implementors. Committers are responsible for ensuring that appropriate language components are assigned to the issue so that they are properly tracked. - Committers must reference the issue when committing the patch. The ideal format is something like "Applying SHINDIG-XXX, submitted by <name of user that submitted it". This will allow automatic status updates for the associated JIRA tickets.
