doc: clarify triage comitments #45267
Conversation
Signed-off-by: Michael Dawson <mdawson@devrus.com>
|
Review requested:
|
nodejs-github-bot
added
c++
mhdawson
force-pushed
the
triage-comitments
branch
from
9051f1a to
05dbd2d
Compare
| Normally your report will be acknowledged within 5 days, and you'll receive | ||
| a more detailed response to your report within 10 days indicating the | ||
| next steps in handling your submission. These timelines may extend when | ||
| our triage volunteers are away on holiday, particularly at the end of the | ||
| year. |
There was a problem hiding this comment.
"are away on holiday" is...basically..."whenever we say we're not available'....This makes the whole response-time guarantee far less meaningful.
Looking at Python's security document, Chromium's, Ruby's... none of them seem to supply a specific response-time guarantee. I think we should just remove the guarantee entirely or replace it with a vague "will respond promptly" or "will respond in a reasonable time frame".
There was a problem hiding this comment.
SGTM to remove the time commitments altogether.
|
my view: the new commitment text reflects the real posible reasons behind a potential delay in response, aligning to what an open source project could commit at the best. |
|
@nodejs/security-triage |
|
I personally prefer setting some kind of expectation so that people know that it won't be immediate and with the addition it's clear that there will also be times when we can't meet the 5/10 days. |
I think a better approach is an auto-reply to submitted reports with that information. "Thank you for submitting your report. We aim to reply with an initial assessment within 5 days excluding weekends and holidays." That gets the information to the specific person that needs it at the specific time when they need it. That's better, IMO, then adding it to a document they are likely to not read or even know about at all. |
(Although to be clear: I'm not blocking this. This is entirely up to the security triage team as far as I'm concerned, and you are on the security triage team and I am not. So, it's your call.) |
|
So I agree an auto respond makes sense in addition to this landing. Don't know though if we have any autoresponders but would be happy if somebody wanted to set one up for this. I do see that as a separate effort though and so it should not block the PR itself. |
|
@nodejs/security-triage it would be good to hear from more members |
|
@mcollina you ok with this landing? |
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
Landed in da44fd8 |
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: nodejs#45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
When I landed this, I forgot to also update https://hackerone.com/nodejs/policy but now I've done that too. |
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Signed-off-by: Michael Dawson <mdawson@devrus.com> PR-URL: #45267 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
No description provided.