Add fast track #30
Add fast track #30
Conversation
guide-for-tag-members.md
Outdated
| @@ -52,6 +52,10 @@ We tend to look for issues like: | |||
|
|
|||
| Design reviews are generally requested by spec authors, spec editors or group chairs. The goal of a design review is to provide useful review feedback that aids the deisgn of the spec in question and to close the review issue once that feedback has been received and ideally acted upon. Requestors fill in one fo the templates (early design review, design review, or dispute resolution). These are initially marked as untriaged. TAG will triage these untriaged issues at least once a week during the regular plenary calls. Requestors will also be asked to create an explainer, fill in answers to the privacy & security questionnaire, and indicate that they have read the Design Principles document. The triage process involves assigning ideally 2+ people to work on the issue going forward, assigning labels as appropriate and assigning a **milestone**. In the design review repo we use milestones to indicate which week in the future we will discuss (and ideally try to resolve) this issue. Once assigned to a milestone (week), that issue will become part of the agenda for that week and will be assigned to a breakout based on who is assigned to the issue. During the breakout call, the issue will be discussed and progressed towards resolution. TAG members will write feedback on the issue and review comments and feedback that have been left on the issue, leave feedback on the issues for the spec in question, etc... We will look for signals that the feedback has been received and understood and ideally acted upon. When the members of a breakout group decide the issue can be closed, the issue is marked as "propose closed" (with a label). We will then review during the read-outs section of the plenary call for that week and take a decision to close and what resolution label to mark it with (e.g. resolution: satisfied). One of the owners of the issue will generally write a closing comment and close the issue. During this process it may sometimes be necessary to have more detailed discussions with the requestors of the review - e.g. by inviting them to a breakout. | |||
|
|
|||
| #### Fast Track | |||
|
|
|||
| Optionally, when a design review comes in, a TAG member may mark it as `fast track?` and alert other TAG members. Fast track reviews are reviews that would be proposed to not take up call time. It’s up to the TAG member proposing fast track status to indicate what outcome they think the review should have. E.g. “This doesn’t need a review. It’s a small change to a spec we’ve already reviewed with no architectural issues. Suggested outcome: Resolution: Satisfied”. They should also add themselves to the issue and add a “Fast track?” label. If it gets at least 2 indications of support (e.g. thumbs up on Slack) (over 1 week from the time it has been proposed) from any other TAG members then it can be closed. It’s up to whoever proposed this for fast rack to close it and to write a brief closing note into the issue, summarizing the reason it can be closed, and label it appropriately. If other TAG members object over the 2 day period, then it goes into the regular review cycle | |||
There was a problem hiding this comment.
| Optionally, when a design review comes in, a TAG member may mark it as `fast track?` and alert other TAG members. Fast track reviews are reviews that would be proposed to not take up call time. It’s up to the TAG member proposing fast track status to indicate what outcome they think the review should have. E.g. “This doesn’t need a review. It’s a small change to a spec we’ve already reviewed with no architectural issues. Suggested outcome: Resolution: Satisfied”. They should also add themselves to the issue and add a “Fast track?” label. If it gets at least 2 indications of support (e.g. thumbs up on Slack) (over 1 week from the time it has been proposed) from any other TAG members then it can be closed. It’s up to whoever proposed this for fast rack to close it and to write a brief closing note into the issue, summarizing the reason it can be closed, and label it appropriately. If other TAG members object over the 2 day period, then it goes into the regular review cycle | |
| Optionally, when a design review comes in, a TAG member may mark it as `fast track?` and alert other TAG members. Fast track reviews are reviews that would be proposed to not take up call time. It’s up to the TAG member proposing fast track status to indicate what outcome they think the review should have. E.g. “This doesn’t need a review. It’s a small change to a spec we’ve already reviewed with no architectural issues. Suggested outcome: Resolution: Satisfied”. They should also add themselves to the issue and add a “Fast track?” label. If it gets at least 2 indications of support (e.g. thumbs up on Slack) (over 1 week from the time it has been proposed) from any other TAG members then it can be closed. It’s up to whoever proposed this for fast rack to close it and to write a brief closing note into the issue, summarizing the reason it can be closed, and label it appropriately. If other TAG members object over the 1 week period, or it does not get sufficient support, then it goes into the regular review cycle. |
Co-authored-by: Peter Linss <peter@linss.com>
| proposing fast track status to indicate what outcome they think the | ||
| review should have. E.g. “This doesn’t need a review. It’s a small | ||
| change to a spec we’ve already reviewed with no architectural issues. | ||
| Suggested outcome: Resolution: Satisfied”. They should also add |
There was a problem hiding this comment.
Can we have "Suggested outcome: Resolution: Satisfied" as the default? It seems like pointless boilerplate, since in the vast majority of cases, if one is proposing that something is fast tracked it's because it's fine and we're satisfied.
| change to a spec we’ve already reviewed with no architectural issues. | ||
| Suggested outcome: Resolution: Satisfied”. They should also add | ||
| themselves to the issue and add a “Fast track?” label. If it gets at least | ||
| 2 indications of support (e.g. thumbs up on Slack) (over 1 week from the |
There was a problem hiding this comment.
Thinking more about it, one week basically renders fast track pointless, since we can add it to the next call and resolve much faster. This needs to be faster than the existing process to actually be "fast track".
There was a problem hiding this comment.
@cynthia thinks it needs to be longer than 1 week. So I think we need to resolve this. Maybe we need a "last call" step - something similar to "propose close" which can then can lead to an automatic closing after a grace period?
There was a problem hiding this comment.
I disagree that 1 week makes fast track pointless. The point of fast track is to not take up call time, and to resolve things faster than we typically resolve things. Our typical design reviews take a hell of a lot longer than a week.
There was a problem hiding this comment.
I support one week as well, otherwise we might miss someone raising points that might be hidden in what seems obvious but is not.
In most case where I see fast-track to happen, it won't be an issue.
| time it has been proposed) from any other TAG members then it can be | ||
| closed. It’s up to whoever proposed this for fast track to close it and to | ||
| write a brief closing note into the issue, summarizing the reason it can be | ||
| closed, and label it appropriately. If other TAG members object over the 2 |
There was a problem hiding this comment.
wait, is it one week or two days?
Co-authored-by: Lea Verou <lea@verou.me>
Co-authored-by: Lea Verou <lea@verou.me>
There was a problem hiding this comment.
Looks good to me, though we should resolve the inconsistency in the text re: one week or two days. Between the two, I think one week makes much more sense. Two business days is way too short, especially when you consider the way weekends and time zones interact.
| change to a spec we’ve already reviewed with no architectural issues. | ||
| Suggested outcome: Resolution: Satisfied”. They should also add | ||
| themselves to the issue and add a “Fast track?” label. If it gets at least | ||
| 2 indications of support (e.g. thumbs up on Slack) (over 1 week from the |
There was a problem hiding this comment.
I disagree that 1 week makes fast track pointless. The point of fast track is to not take up call time, and to resolve things faster than we typically resolve things. Our typical design reviews take a hell of a lot longer than a week.
| change to a spec we’ve already reviewed with no architectural issues. | ||
| Suggested outcome: Resolution: Satisfied”. They should also add | ||
| themselves to the issue and add a “Fast track?” label. If it gets at least | ||
| 2 indications of support (e.g. thumbs up on Slack) (over 1 week from the |
There was a problem hiding this comment.
I support one week as well, otherwise we might miss someone raising points that might be hidden in what seems obvious but is not.
In most case where I see fast-track to happen, it won't be an issue.
This tries to document the fast track design review process as has been discussed between TAG members.