The policy on issues is:
- Issues should be actionable items of work for the Committers or an outside contributor to execute on, and should describe an issue in a supported version of Lift.
- Non-committers should discuss issues on the Lift mailing list before opening a issue.
- All non-committer issues should have a link back to the mailing list discussion that led to opening the issue so the whole world can see why the issue came into being.
- All non-committer issues should be set to no milestone, no assignment and normal (or lower) priority unless a committer explicitly asked for assignment (that means they agreed to do the work).
- A committer may open a issue at whatever priority for whatever milestone and assign it to themselves.
- There should be very little discussion about issue in the issuing system. The discussion should take place on the Lift list so the discussion is available to a broader audience.
We will accept pull requests into the Lift codebase if the pull requests meet all of the following criteria:
- The request is for a currently supported version of Lift. (See SUPPORT.md.)
- The request handles an issue that has been discussed on the Lift mailing list and whose solution has been requested by the committers (and in general adheres to the spirit of the issue guidelines above).
- The contributor's signature is already in or added to /contributors.md file.
Note that only Lift committers can merge a pull request, and accepting or rejecting a pull request is entirely at the discretion of the Lift committers. By merging a pull request, the Lift committers are taking responsibility for maintaining that code, and there are many reasons why this might not be desirable for certain features. We will strive to communicate clearly why pull requests are not accepted if we decide not to accept them.