<aside> ☝ This is a quick guide on how to make the project repository easy to work within via enforcing a couple standards.
</aside>
A clean repository doesn’t mean clean code. It means clean infrastructure – easy to read and well organized commits, solid continuous integration, and a sexy readme. Many undervalue these aspects of the repository, but it's a lot more improtant than people realize.
My favorite example of this is when in highs school, I turned in the exact same homework as my friend, except I typed mine in LaTex, and he typed his in Google Docs. I got 4% higher. The little things matter, not because it looks better, but because it shows that thought and effort was put into every single aspect of the work.
So when we want to show that we care about every aspect of the repository, our engineers are more motivated to maintain the same standard. But it also just makes it a lot easier to navigate and contribute. More importantly, it makes it easy for an engineer, two years later, to come back to the code and learn from it.
Pull requests are the heart of contributing to a repository. There's a simple workflow to follow with pull requests:
When an engineer is developing a feature and wants to run CI, but the feature is not ready to be merged, they should Draft **a pull request.
This will notify all viewers that the PR is still a work in progress (without the [WIP] prefix in the PR titles), and will prevent merging. This will still run CI tests!
Once the engineer is done implementing the feature, they can make sure the code works and all status checks are passing. Then, mark the pull request as "Ready for Review." Some simple standards when marking the PR as ready: