There are many hard requirements listed in the software practices doc (such as 24hr PR, 100% test coverage), but there are certainly a few guiding principles behind these requirements, such as improving collaboration, reducing single-developer repositories, improving standardization and reducing context-switching cognitive load.
Though it's easy to quibble about specifics, the overarching goals are hard to argue with and should be clearly enumerated at the top of the document. This would clarify the intent of the specific requirements, as "when someone looks at any given repo, this is what they should expect to see". It would also allow us to check back in periodically with the standards document to assess if it is effectively achieving the main goals and provide a framework for updating them.
There are many hard requirements listed in the software practices doc (such as 24hr PR, 100% test coverage), but there are certainly a few guiding principles behind these requirements, such as improving collaboration, reducing single-developer repositories, improving standardization and reducing context-switching cognitive load.
Though it's easy to quibble about specifics, the overarching goals are hard to argue with and should be clearly enumerated at the top of the document. This would clarify the intent of the specific requirements, as "when someone looks at any given repo, this is what they should expect to see". It would also allow us to check back in periodically with the standards document to assess if it is effectively achieving the main goals and provide a framework for updating them.