Section 4 Maintaining Code

4.1 Packages and other Tools

4.1.1 Ownership

Each actively used package should be assigned a maintainer, who will be responsible for monitoring bug reports, feature requests, etc. submitted through Github or directly from users.

4.1.2 Issues

Submit any bugs, feature requests, etc in the “issues” section of Github repository for a package, even if you discuss the issue outside of this context, and even if you intend to implement an update yourself. The package maintainer will be responsible for triaging and delegating maintenance using the Github Issues interface.

Any code changes in response to a Github Issue should be noted in that issue (either linking to the commit or pull request). Pull requests that make significant changes should go through code review (see the section on reviewing code).

4.1.3 Minor Changes

Very minor changes may be pushed directly to the main branch of the Github repository packages. Err on the side of caution and submit an issue and pull request if you find yourself questioning whether your change counts as minor.

4.1.4 Sunsetting

Tools that are no longer in active use should be archived in Github (which makes them read-only). Tools that never got “off the ground” should be either archived or deleted, in consultation with the team at large.

4.2 One-off Code

In general, tickets (data requests, data updates, and schema updates) should not be “maintained”. If a ticket needs to be revised after being finalized, submit a new ticket and link it to the previous ticket when generating it and/or in the new ticket’s documentation.