-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: improve collaborator guide, doc fast-tracking process #17056
Conversation
* Add sections about first time contributions, code reviews and seeking consensus, waiting for approvals, testing and CI * Move paragraphs to more suitable sections * Update table of contents
16a4ffa
to
d5b3ce8
Compare
COLLABORATOR_GUIDE.md
Outdated
* Changes that revert commit(s) and/or fix regressions. | ||
|
||
When a pull request is deemed suitable to be fast-tracked, label it with | ||
`fast-track`. The pull request can be landed once more than 3 collaborators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number 3 here needs more discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm 👍 on fast-tracking everything that fixed a regression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would go with 2, and be more explicit:
The PR can be landed after 2 or more collaborators (excluding the author) have approved it.
cc @nodejs/tsc @nodejs/collaborators |
COLLABORATOR_GUIDE.md
Outdated
can be fast-tracked and may be landed after a shorter delay: | ||
|
||
* Trivial changes, for example, those fixing minor bugs or improving | ||
performance without affecting API or causing other wide-reaching impact. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm 👎 on considering improving performance as a fast-track issue. In my experience, it's the contrary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, personally I agree with @mcollina , I don't recall seeing a performance optimization PR being fast-tracked before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wording was added in c52e43d, a long, long time before my PR.
I’m okay with removing performance optimizations this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a topic for more general discussion, but at least for me the triviality of the change isn't usually a reason to fast-track. My experience is that no matter how trivial the change, there's always the possibility that someone disagrees or has nits.
For me the reason to fast-track is because it is actually beneficial, e.g.
- It's a fix we want to land in a release line
- It's a code-and-learn PR, and we want to give people a good first experience (and maybe even land on the day)
- It unbreaks CI on master
So for example if it fixes a regression but won't go into a release for a couple of weeks, what's the reason to fast-track? Same for small changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gibfahn I agree but these are just some examples, that's why we also need a rule about "n approvals to both the PR and the fast-tracking request". If a PR should not be fast-tracked, people can object to that fast-tracking request without objecting to the PR.
COLLABORATOR_GUIDE.md
Outdated
* Changes that revert commit(s) and/or fix regressions. | ||
|
||
When a pull request is deemed suitable to be fast-tracked, label it with | ||
`fast-track`. The pull request can be landed once more than 3 collaborators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm 👍 on fast-tracking everything that fixed a regression
COLLABORATOR_GUIDE.md
Outdated
|
||
### First Time Contributions | ||
|
||
Courtesy should **always** be shown to individuals submitting issues and pull |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really liked that it was the first sentence in this guide, just after the TOC. So IMHO it should stay there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm...I think we can just move the section up because this does not seem to be about "Accepting Modifications" anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a second thought, I don't think this paragraph should appear before explaining that "a collaborator can manage issues and pull request", it looks a bit surprising to start explaining "how you should do something" before even saying "you can do this now"
COLLABORATOR_GUIDE.md
Outdated
Purely additive changes (e.g. adding new events to EventEmitter | ||
implementations, adding new arguments to a method in a way that allows | ||
existing code to continue working without modification, or adding new | ||
properties to an options argument) are handled as semver-minor changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove handled as
COLLABORATOR_GUIDE.md
Outdated
given to providing an alternative Public API for that functionality before any | ||
breaking changes are made. | ||
See [Breaking Changes to Internal Elements](#breaking-changes-to-internal-elements) | ||
on how to handle that type of changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: that type
-> those types
(or changes -> change)
COLLABORATOR_GUIDE.md
Outdated
can be fast-tracked and may be landed after a shorter delay: | ||
|
||
* Trivial changes, for example, those fixing minor bugs or improving | ||
performance without affecting API or causing other wide-reaching impact. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a topic for more general discussion, but at least for me the triviality of the change isn't usually a reason to fast-track. My experience is that no matter how trivial the change, there's always the possibility that someone disagrees or has nits.
For me the reason to fast-track is because it is actually beneficial, e.g.
- It's a fix we want to land in a release line
- It's a code-and-learn PR, and we want to give people a good first experience (and maybe even land on the day)
- It unbreaks CI on master
So for example if it fixes a regression but won't go into a release for a couple of weeks, what's the reason to fast-track? Same for small changes.
COLLABORATOR_GUIDE.md
Outdated
Note that errors thrown, along with behaviors and APIs implemented by | ||
dependencies of Node.js (e.g. those originating from V8) are generally not | ||
under the control of Node.js and therefore *are not directly subject to this | ||
policy*. However, care should still be taken when landing updates to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're not subject to the deprecation policy, but they are still tagged semver-major
, still need the TSC signoffs, and still don't get backported to any release lines right? Why the move up to this section?
As a side note, it seems odd that this section doesn't mention that you have to put the semver-major
label on the PR (I know it wasn't there before). Maybe it's covered somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yes this seem to belong to the "Breaking Changes and Deprecations" section. Thanks for catching that.
@mcollina @addaleax @gibfahn @refack I've moved the paragraphs a bit, deleted the bug-fix and optimization examples, and changed the number of required approvals to 2 (I've taken a look into the recent fast-tracked PRs and I think 2 should be safe enough. We can always revert if someone objects later). PTAL. |
COLLABORATOR_GUIDE.md
Outdated
* Changes that revert commit(s) and/or fix regressions. | ||
|
||
When a pull request is deemed suitable to be fast-tracked, label it with | ||
`fast-track`. The pull request can be landed once more than 2 collaborators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be 2 or more
then. LGTM otherwise.
@tniessen Updated to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Landed as 0a1fba0, thanks! |
* Add sections about first time contributions, code reviews and seeking consensus, waiting for approvals, testing and CI * Move paragraphs to more suitable sections * Update table of contents * Document the fast-tracking process PR-URL: #17056 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
* Add sections about first time contributions, code reviews and seeking consensus, waiting for approvals, testing and CI * Move paragraphs to more suitable sections * Update table of contents * Document the fast-tracking process PR-URL: #17056 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
* Add sections about first time contributions, code reviews and seeking consensus, waiting for approvals, testing and CI * Move paragraphs to more suitable sections * Update table of contents * Document the fast-tracking process PR-URL: #17056 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
* Add sections about first time contributions, code reviews and seeking consensus, waiting for approvals, testing and CI * Move paragraphs to more suitable sections * Update table of contents * Document the fast-tracking process PR-URL: #17056 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
* Add sections about first time contributions, code reviews and seeking consensus, waiting for approvals, testing and CI * Move paragraphs to more suitable sections * Update table of contents * Document the fast-tracking process PR-URL: #17056 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
doc: reorganize collaborator guide
and seeking consensus, waiting for approvals, testing and CI
doc: document the fast-tracking process
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
doc