github.com/argoproj/argo-cd@v1.8.7/docs/bug_triage.md (about) 1 # Bug triage proposal for ArgoCD 2 3 ## Situation 4 5 Lots of issues on our issue tracker. Many of them not bugs, but questions, 6 or very environment related. It's easy to lose oversight. 7 8 Also, it's not obvious which bugs are important. Which bugs should be fixed 9 first? Can we make a new release with the current inventory of open bugs? 10 Is there still a bug that should make it to the new release? 11 12 ## Proposal 13 14 We should agree upon a common issue triage process. The process must be lean 15 and efficient, and should support us and the community looking into the GH 16 issue tracker at making the following decisions: 17 18 * Is it even a real bug? 19 * If it is a real bug, what is the current status of the bug (next to "open" or "closed")? 20 * How important is it to fix the bug? 21 * How urgent is it to fix the bug? 22 * Who will be working to fix the bug? 23 24 We need new methods to classify our bugs, at least into these categories: 25 26 * validity: Does the issue indeed represent a true bug 27 * severity: Denominates what impact the bug has 28 * priority: Denominates the urgency of the fix 29 30 ## Triage process 31 32 GH issue tracker provides us with the possibility to label issues. Using these 33 labels is not perfect, but should give a good start. Each new issue created in 34 our issue tracker should be correctly labeled during its lifecycle, so keeping 35 an overview would be simplified by the ability to filter for labels. 36 37 The triage process could be as follows: 38 39 1. A new bug issue is created by someone on the tracker 40 41 1. The first person of the core team to see it will start the triage by classifying 42 the issue (see below). This will indicate the creator that we have noticed the 43 issue, and that it's not "fire & forget" tracker. 44 45 1. Initial classification should be possible even when much of the information is 46 missing yet. In this case, the issue would be classified as such (see below). 47 Again, this indicates that someone has noticed the issue, and there is activity 48 in progress to get the required information. 49 50 1. Classification of the issue can change over its life-cycle. However, once the 51 issue has been initially classified correctly (that is, with something else than 52 the "placeholder" classification discussed above), changes to the classification 53 should be discussed first with the person who initially classified the issue. 54 55 ## Classification 56 57 We have introduced some new labels in the GH issue tracker for classifying the 58 bug issues. These labels are prefixed with the string `bug/`, and should be 59 applied to all new issues in our tracker. 60 61 ### Classification requires more information 62 63 If it is not yet possible to classify the bug, i.e. because more information is 64 required to correctly classify the bug, you should always set the label 65 `bug/in-triage` to make it clear that triage process has started but could not 66 yet be completed. 67 68 ### Issue type 69 70 If it's clear that a bug issue is not a bug, but a question or reach for support, 71 it should be marked as such: 72 73 * Remove any of the labels prefixed `bug/` that might be attached to the issue 74 * Remove the label `bug` from the issue 75 * Add the label `inquiry` to the issue 76 77 If the inquiry turns out to be something that should be covered by the docs, but 78 is not, the following actions should be taken: 79 80 * The title of the issue should be adapted that it will be clear that the bug 81 affects the docs, not the code 82 * The label `documentation` should be attached to the issue 83 84 If the issue is too confusing (can happen), another possibility is to close the 85 issue and create a new one as described in above (with a meaningful title and 86 the label `documentation` attached to it). 87 88 ### Validity 89 90 Some reported bugs may be invalid. It could be a user error, a misconfiguration 91 or something along these lines. If it is clear that the bug falls into one of 92 these categories: 93 94 * Remove any of the labels prefixed `bug/` that might be attached to the issue 95 * Add the label `invalid` to the issue 96 * Retain the `bug` label to the issue 97 * Close the issue 98 99 When closing the issue, it is important to let requester know why the issue 100 has been closed. The optimum would be to provide a solution to his request 101 in the comments of the issue, or at least pointers to possible solutions. 102 103 ### Regressions 104 105 Sometimes it happens that something that worked in a previous release does 106 not work now when it should still work. If this is the case, the following 107 actions should be done 108 109 * Add the label `regression` to the issue 110 * Continue with triage 111 112 ### Severity 113 114 It is important to find out how severe the impact of a bug is, and to label 115 the bug with this information. For this purpose, the following labels exist 116 in our tracker: 117 118 * `bug/severity:minor`: Bug has limited impact and maybe affects only an 119 edge-case. Core functionality is not affected, and there is no data loss 120 involved. Something might not work as expected. Example of these kind of 121 bugs could be a CLI command that is not working as expected, a glitch in 122 the UI, wrong documentation, etc. 123 124 * `bug/severity:major`: Malfunction in one of the core components, impacting 125 a majority of users or one of the core functionalities in ArgoCD. There is 126 no data loss involved, but for example a sync is not working due to a bug 127 in ArgoCD (and not due to user error), manifests fail to render, etc. 128 129 * `bug/severity:critical`: A critical bug in ArgoCD, possibly resulting in 130 data loss, integrity breach or severe degraded overall functionality. 131 132 ### Priority 133 134 The priority of an issue indicates how quickly the issue should be fixed and 135 released. This information should help us in deciding the target release for 136 the fix, and whether a bug would even justify a dedicated patch release. The 137 following labels can be used to classify bugs into their priority: 138 139 * `bug/priority:low`: Will be fixed without any specific target release. 140 141 * `bug/priority:medium`: Should be fixed in the minor or major release, which 142 ever comes first. 143 144 * `bug/priority:high`: Should be fixed with the next patch release. 145 146 * `bug/priority:urgent`: Should be fixed immediately and might even justify a 147 dedicated patch release. 148 149 The priority should be set according to the value of the fix and the attached 150 severity. This means. a bug with a severity of `minor` could still be classified 151 with priority `high`, when it is a *low hanging fruit* (i.e. the bug is easy to 152 fix with low effort) and contributes to overall user experience of ArgoCD. 153 154 Likewise, a bug classified with a severity of `major` could still have a 155 priority of `medium`, if there is a workaround available for the bug which 156 mitigates the effects of the bug to a bearable extend. 157 158 Bugs classified with a severity of `critical` most likely belong to either 159 the `urgent` priority, or to the `high` category when there is a workaround 160 available. 161 162 Bugs that have a `regression`label attached (see Regression above) should 163 usually be handled with higher priority, so those kind of issues will most 164 likely have a priority of `high` or `urgent` attached to it. 165 166 ## Summary 167 168 Applying a little discipline when working with our issue tracker could greatly 169 help us in making informed decision about which bugs to fix when. Also, it 170 would help us to get a clear view whether we can do for example a new minor 171 release without having forgot any outstanding issues that should make it into 172 that release. 173 174 If we are able to work with classification of bug issues, we might want to 175 extend the triage for enhancement proposals and PRs as well.