Document PR/change submission tips/guidelines

[cassidyjames]

Similar to #89, we should write down tips, guidelines, norms, etc. for submitting PRs to ROOST projects. We can start lightweight and expand over time. There are a bunch of good open source examples, but here is some selected prior art:

• GNOME Handbook: Change Submission
• The Open Source Way: Successfully communicating with an open source project
• elementary: Proposing Code Changes
• Kubernetes: Pull Request Process
• Node.js contributing pull requests
• Python: Making good PRs
• Zulip: Submitting a pull request

It may be worth covering some of the topics from #62 as well

[Shafiqha]

I'd like to take this one can pick it up once confirmed.

[cassidyjames]

@Shafiqha feel free to open a PR with a suggestion! I'd say to focus on being concise and not going into detail with the actual UI steps of opening a PR; instead, focus on what makes a good PR like the elementary guidelines do. Off the top of my head, some of the tips to cover:

• How the code contribution process works:
  • Start with an open issue. Ensure it's marked as "Ready" or has a clear consensus of how to solve it; if not, start there by commenting on the issue.
  • Iterate in your Git branch; the commit history can help a reviewer walk through your approach over time.
  • Test locally before submitting!
  • You can open a draft PR to inform others it's being worked on, but not ready for review.
  • Once submitted/marked ready, a maintainer or community member will review the PR; be available for follow-up questions or suggestions
• Other tips to follow
  • PR descriptions should be human-written
  • Small diff = best diff (break changes into small, individually-reviewable PRs when possible)
  • Only stack PRs on one another when absolutely necessary; it can lead to a lot of rebasing and re-reviewing if done too early/before there's consensus on the approach

I'm sure there's a lot more we could cover, but writing that all down would be a good start imho!