Figure out and document our change control process #17
Description
Since this document as a whole is expected to evolve over time, we should decide how we incorporate feedback and changes from others. Some of my initial thoughts:
- We should utilize the "code owners" feature to ensure that the necessary people at Bottle Rocket are involved in changes to our project standards. This is probably the iOS architects and Jedi.
- Simple bug fixes (PR's flagged as "bug") probably don't need as strict of a review process, since they shouldn't be changing actual standards. Small feature enhancements like adding additional links to content within the document are probably okay as well.
- How should we handle contributions from non-BR engineers? I expect this to be pretty rare, so maybe we handle that on a case-by-case basis.