Github Pull Request Policy

Here's a rough outline of the FreeBSD's de-facto policies towards github pull requests.

• Github pull requests should be made for mature code that's ready to commit. The pull request should include a description of the problem being solved as well as a commit message that meets the FreeBSD project's standards.
• Github pull requests should not be used for discussion. If you'd like to use github as a tool to discuss changes, you can do that with your own private account. Phabricator remains the project's preferred review tool, though not required review tool.
• Incomplete code that's submitted may be converted into a bugzilla request at the discretion of the project.
• When nobody can be found to review the change, it will be converted to a bugzilla request.
• When the domain experts would rather work with another tool, a pull request will be converted to that other tool.
• Pull requests older than 18 months will be converted to bugzilla items to not lose them.
• When making pull requests that are non-trivial (trivial changes include adding new devices to a driver, fixing spelling, correcting minor bugs in non-critical systems), it's strongly recommended that the domain experts be sought out to review and take ownership of the request.
• Pull requests that are for software include in FreeBSD that have upstream sources should be submitted there first. Incorrectly submitted changes will receive a redirect and closed.
• If there's a code review in phabricator, it takes precedence over the pull request. Even after the fact. If the consensus is 'no' in the review, the change won't be pulled. If the change is pulled and it's pointed out a phabricator was overlooked, the change will be backed out.
• Issues unresolved on github after about a month will result in the pull request being transitioned to bugzilla or closed at the discretion of the project.
• Best Effort Only. The project will make efforts to look at the pull requests from time to time. We make no timeliness guarantees at this time. Github pull requests remain an experimental feature of the project and may not get the time and attention of more mature efforts. If the submitter doesn't hear anything in a timely fashion, they are encouraged to solicit reviews or feedback from the appropriate mailing list.