Adding the detailed triage process #22393
Conversation
mkArtakMSFT
requested review from
DamianEdwards,
Pilchie,
ajcvickers,
danroth27,
davidfowl and
pranavkm
Pilchie
added
the
area-infrastructure
Pilchie
left a comment
Pilchie
left a comment
There was a problem hiding this comment.
Should we also mention other things people can try?
Discussions tab, Stack Overflow, CSS, etc?
Co-authored-by: Kevin Pilch <[email protected]>
Co-authored-by: Kevin Pilch <[email protected]>
Co-authored-by: Kevin Pilch <[email protected]>
| The feature teams should be able look through every single issue filed against this repository and be able to make a quick call regarding the nature of the issue. | ||
| We will first categorize the issues and further handle these depending on the category the issue is in. The subsections below reprsent these categories and the rules we apply for them during our triage meeting. | ||
|
|
||
| ### Feature requests |
There was a problem hiding this comment.
Once we start a release we're already largely committed for features (this should be called out here). As such the expectation for new feature requests should be backlog, to be reviewed at the start of the next release. It would only be pulled into next sprint planning if we thought it was higher priority than currently committed work. We'll almost certainly have to cut something else to accommodate it.
There was a problem hiding this comment.
We do reserve a lot of time for many deliverables, but we do leave time for stuff to come in. Based on this plan, we prioritize only a milestone ahead - so reasonable incoming feature requests are being evaluated each milestone and have potential to make into the next milestone.
There was a problem hiding this comment.
@Pilchie has that been your experience? When doing release planning with Andrew we costed out the major features for the release and cut what we didn't expect to fit. Even then we anticipate needing to cut more as we get closer to release. There's rarely room to add more significant features without cutting something else from the schedule. A few smaller ones might make it in.
We should be setting a clear expectation that most feature requests have to compete with the existing plan to make it in, and many of them won't make it in this release.
There was a problem hiding this comment.
I think we want to balance - we definitely pick "big rocks" for the release, and ensure that those fit. Assuming there is any wiggle room after those, we fit in smaller things that don't require as much collaboration with other teams between them. For those smaller things, I think it makes a lot of re-sense to re-check priorities on a regular basis. Our plans don't have to be 100% locked for a year at a time. With that said, I think there could be some wording here about the fact that many features won't make it into the current release.
There was a problem hiding this comment.
I think this is already addressed. We do explicitly say, that feature-requests can be moved to Backlog. I don't think we should be more explicit than that.
There was a problem hiding this comment.
That said, I would prefer to leave this as is.
|
Should this reference/be merged with https://github.com/dotnet/aspnetcore/blob/master/docs/IssueManagementPolicies.md ? |
@Pilchie, I think that one is for very specific purpose. I think it makes sense to clean that one up slightly, but we shouldn't mix those two. The reason is that we may choose to tweak our issue management policies but keep the triage process the same. |
Co-authored-by: Chris Ross <[email protected]>
Co-authored-by: Chris Ross <[email protected]>
Co-authored-by: Chris Ross <[email protected]>
Co-authored-by: Brennan <[email protected]>
Co-authored-by: Brennan <[email protected]>
|
Thanks @Pilchie, @Tratcher, @halter73 and @BrennanConroy! |
One of the goals of this writeup is to be able to refer to it from customer issues, when for example we choose to close it. It will make easy for us to justify certain actions we take in regards to issue management.
Also, this is aimed to resolve the problems I've talked about earlier, where we have too many incoming issues and majority are investigations. So this sets up the baseline for us to easily close some investigations, which have very scoped/limited impact or even are not real.