Pull request workflow in contributing guide

Feature Spec

Pull requests are the primary mechanism we use to change something in Wing.

The pull requests topic now includes additional information:

• Who should review a pull request?
• Code review best practices
• Who is responsible to resolve conversations?
• Who is responsible to merge?
• Who can push code without a code review?
• Who should be assigned to a pull request? Ownership?
• Title and description
• Special labels (e.g. do-not-merge).
• Process for tracking and managing stale pull requests
• Indicating that a PR is WIP (draft)
• Request re-review
• Single feature/fix per PR
• Tests/README updates

Definition of ownership:

• They get it make all implementation decisions, including programming language, architecture, design, naming, everything!
• They need review for user experience decisions
• They need to maintain high test coverage

It also includes great stuff from:

https://github.com/monadahq/mona-kb/blob/main/docs/github-best-practices.md

Use Cases

Improve our pull request process

Implementation Notes

No response

Component

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.