Github Pull Request Policy

-— Edit conflict - other version: —- 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 included 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.

-— Edit conflict - your version: —- Here's a rough outline of the FreeBSD's de-facto policies towards github pull requests. They represent an alternate way to submit mature, ready to commit patches.

• 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.
• Code that still needs discussion or consensus building is not ready to submit to the project's github mirror as a pull request. Discussions and consensus building should happen in the appropriate project mailing list.
• Github pull requests to the project should not be used for discussion. If you'd like to use github as a tool to discuss or review changes, please do that with your own private account.
• 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), communicating with the domain experts or project mailing lists for review may speed the process.
• Pull requests that are for third party software should be submitted upstream first.
• 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 that rejected it was overlooked, the change will be backed out.
• Any pull request that isn't ready to go into the tree may be closed. Best effort attempts to redirect to bugzilla or a more appropriate location.
• Stale requests may be closed with a request for rebase and a new pull request.
• This is a best effort only service. The project will try make efforts to resolve 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.

Subject to change in the future as resources change and new tooling is created.

-— End of edit conflict —-