Write down pull request flow for maintainers#94
Conversation
It might be obvious to @dpshelio, but it's not to me.
There was a problem hiding this comment.
Pull request overview
This PR adds documentation about the pull request workflow and process for maintainers of the UCL open-source repository. The addition clarifies expectations around PR approval, merging responsibilities, and special considerations for business case changes.
Changes:
- Added a new "Pull request flow" section with maintainer guidelines
- Documented approval and merging workflow
- Specified labeling requirements for business case changes
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
CONTRIBUTING.md
Outdated
|
|
||
| (Information for maintainers) | ||
|
|
||
| - Changes by [pull request(https://github.com/UCL/open-source/pulls), at least one person from the open source team with commit rights will need to be involved. |
There was a problem hiding this comment.
What does "involve" mean here?
There was a problem hiding this comment.
"Involved" in the GitHub pull request sense: either the proponent or reviewer.
There was a problem hiding this comment.
Isn't that ("one of the maintainers of a repo being involved") always the case?
There was a problem hiding this comment.
I'm using the word like this...
There was a problem hiding this comment.
You might be right. Should I delete the fluff?
dpshelio
left a comment
dpshelio
left a comment
There was a problem hiding this comment.
I don't know how to express that better, in terms of people doing contribution that has or not write access to the repository.
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
samcunliffe
deleted the
sc/maintainer-rules-to-maximise-development-velocity
branch
It might be obvious to @dpshelio, but it's not to me.
#MaximiseDevelopmentVelocity 🚀 🚀