From 597ad117e7a2934ef43c480ae8307a06d8662472 Mon Sep 17 00:00:00 2001 From: Francesco Novy Date: Thu, 27 Jun 2024 09:43:42 +0200 Subject: [PATCH 1/4] docs: Update triaging docs --- docs/triaging.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/triaging.md b/docs/triaging.md index cd0b1ea1aa65..9aaadce03407 100644 --- a/docs/triaging.md +++ b/docs/triaging.md @@ -43,6 +43,15 @@ categorize the issue as soon as possible. If an issue is hard to fix, an edge ca reply and put the issue in backlog. You may also encourage the user to contribute a PR themselves if we are unlikely to find time to resolve the issue ourselves anytime soon. +Additionally, triaging does not have to happen in one sitting. If you've investigated a reasonable amount of time into +triaging an issue, but have not yet found the root cause/a solution, you can always post an update in the issue about +what you've tried so far (and what worked/didn't work), and continue looking into the issue later/on another day. This +depends on the severity of the issue, of course - if something appears to be a critical issue potentially affecting lots +of users, we should prioritise fixing it even if it takes longer. + +If a ticket is in the Web SDK triaging queue, but should be handled by another team (e.g. Replay, Feedback, Profiling), +feel free to ping members of that team in a respective Slack channel to please take a look at the issue. + ### (Sentry Employees) How & when should I triage issues? Ideally, you can take some time every day in the morning to look over the triage queue and identify issues that you can From 6ece31dbd5811dd2cce16a0cb3233f90bf63aa9f Mon Sep 17 00:00:00 2001 From: Francesco Novy Date: Thu, 27 Jun 2024 10:01:07 +0200 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Andrei <168741329+andreiborza@users.noreply.github.com> --- docs/triaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/triaging.md b/docs/triaging.md index 9aaadce03407..ce25618313e5 100644 --- a/docs/triaging.md +++ b/docs/triaging.md @@ -43,7 +43,7 @@ categorize the issue as soon as possible. If an issue is hard to fix, an edge ca reply and put the issue in backlog. You may also encourage the user to contribute a PR themselves if we are unlikely to find time to resolve the issue ourselves anytime soon. -Additionally, triaging does not have to happen in one sitting. If you've investigated a reasonable amount of time into +Additionally, triaging does not have to happen in one sitting. If you've invested a reasonable amount of time into triaging an issue, but have not yet found the root cause/a solution, you can always post an update in the issue about what you've tried so far (and what worked/didn't work), and continue looking into the issue later/on another day. This depends on the severity of the issue, of course - if something appears to be a critical issue potentially affecting lots From 14939ac06176101927802440f116adc048d582fa Mon Sep 17 00:00:00 2001 From: Francesco Novy Date: Thu, 27 Jun 2024 12:36:39 +0200 Subject: [PATCH 3/4] Update docs/triaging.md --- docs/triaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/triaging.md b/docs/triaging.md index ce25618313e5..7bf333b24f20 100644 --- a/docs/triaging.md +++ b/docs/triaging.md @@ -46,7 +46,7 @@ find time to resolve the issue ourselves anytime soon. Additionally, triaging does not have to happen in one sitting. If you've invested a reasonable amount of time into triaging an issue, but have not yet found the root cause/a solution, you can always post an update in the issue about what you've tried so far (and what worked/didn't work), and continue looking into the issue later/on another day. This -depends on the severity of the issue, of course - if something appears to be a critical issue potentially affecting lots +depends on the severity of the issue, of course — if something appears to be a critical issue potentially affecting lots of users, we should prioritise fixing it even if it takes longer. If a ticket is in the Web SDK triaging queue, but should be handled by another team (e.g. Replay, Feedback, Profiling), From 1d15499e07c16b3a994b4f8ae4682c5f30a36b10 Mon Sep 17 00:00:00 2001 From: Francesco Novy Date: Thu, 27 Jun 2024 12:39:24 +0200 Subject: [PATCH 4/4] small tweak --- docs/triaging.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/triaging.md b/docs/triaging.md index 7bf333b24f20..31a8f4fd1f35 100644 --- a/docs/triaging.md +++ b/docs/triaging.md @@ -50,7 +50,9 @@ depends on the severity of the issue, of course — if something appears to be a of users, we should prioritise fixing it even if it takes longer. If a ticket is in the Web SDK triaging queue, but should be handled by another team (e.g. Replay, Feedback, Profiling), -feel free to ping members of that team in a respective Slack channel to please take a look at the issue. +feel free to ping members of that team in a respective Slack channel to please take a look at the issue. You should also +make sure to apply the correct package labels (e.g. `Package: Replay`, `Package: User Feedback`, +`Package: profiling-node`) to indicate what an issue is about. ### (Sentry Employees) How & when should I triage issues?