For Maintainers

Managing Issues

Issues fall into three categories: “Report a bug”, “Report a docs issue”, and “Feature request”. No one is set as the default assignee for any issue. All issues should have an assignee within 24 hours. If you do not see one, please add either yourself or the maintainer who you think is most qualified to handle the issue.

Managing Pull Requests

1. Comments and requests for changes should be polite and actionable.

2. Pull requests should be atomic. If not, ask the person who opened the request to break it down into multiple, smaller ones.

3. Resolve conflicts via rebase.

4. After approving a pull request, it should be “squashed and merged” with a descriptive, present-tense sentence as the title. Provide a description as appropriate.

Example of a good pull request: “#33: Make Linear Regression baseline optional for testing”.

• Title is a descriptive, present-tense sentence.

• Pull request is atomic: it is clear from the title that exactly one change is made.

Example of a bad pull request: “#12: Uncertainty merge”.

• Title is not sufficiently descriptive.

• Pull request is massive: many changes are introduced simultaneously. This should have been multiple smaller pull requests.