winglang/wing

Pull request workflow in contributing guide

Open

#2.039 geöffnet am 11. Apr. 2023

Auf GitHub ansehen
 (4 Kommentare) (1 Reaktion) (0 zugewiesene Personen)TypeScript (214 Forks)github user discovery
good first issue✨ enhancement👷‍♀️ contributor-experience📚 documentation

Repository-Metriken

Stars
 (5.385 Stars)
PR-Merge-Metriken
 (Keine gemergten PRs in 30 T)

Beschreibung

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.

Contributor Guide