Re: AW: Confirmed bug labels
On 29/10/2019 12:34, Matt Caswell wrote: > > > On 29/10/2019 12:24, Matthias St. Pierre wrote: >> >> It might be useful to add more reasons for why the issue is resolved. >> OTOH we should watch out that we don't create too many labels. >> >> "resolved: fixed" >> "resolved: answered" > > Not sure about the "resolved: fixed" one...most of the time where we > resolve an issue by fixing it, it gets closed automatically. Adding a > label probably doesn't add much. I suppose it might be useful in the > case where someone reports a bug that is *already* fixed in a later version. I found myself needing to use "resolved: answered" so I added it. Matt
Re: AW: Confirmed bug labels
I decided to change the 'issue: *' colors to a more 'yelling' cyan color making the untriaged issues more prominent, and use the more relaxed blue color for the 'triaged: *' labels instead. Also added an 'unresolved' label. Matthias On 29.10.19 13:38, Matt Caswell wrote: On 29/10/2019 12:37, Matthias St. Pierre wrote: The 'unresolved: *' labels could carry the same grey color as the 'resolved: *' labels. For the 'triaged: *' labels we need a new color. I can make a suggestion... Please do! Matt
Re: AW: Confirmed bug labels
On 29.10.19 13:34, Matt Caswell wrote: ... For the unresolved issues, an 'unresolved: *' label makes sense: "unresolved: " Possible reasons for marking something as unresolved: - The question is stale - no activity for a prolonged period - Off topic - the question is about something not directly related to OpenSSL - Unable to help - despite our best efforts we weren't able to figure out an answer - Lack of information - we requested information and it wasn't forthcoming Not sure if we would want a label for all of those or not. Matt Then I'll just add a simple 'unresolved' label without a reason and we can extend labels if needed.
Re: AW: Confirmed bug labels
On 29/10/2019 12:37, Matthias St. Pierre wrote: > The 'unresolved: *' labels could carry the same grey color as the > 'resolved: *' labels. > For the 'triaged: *' labels we need a new color. I can make a suggestion... Please do! Matt
Re: AW: Confirmed bug labels
The 'unresolved: *' labels could carry the same grey color as the 'resolved: *' labels. For the 'triaged: *' labels we need a new color. I can make a suggestion... Matthias
Re: AW: Confirmed bug labels
On 29/10/2019 12:24, Matthias St. Pierre wrote: > > > On 29.10.19 13:14, Matt Caswell wrote: >> Do we just need "triaged: bug" and "triaged: feature"? Or should we also >> have "triaged: documentation" and "triaged: question" (so that there is >> one for every corresponding "issue" label)? > > Yes, that makes sense. Then it is assured that the 'issue: *' labels are > set only for issues which have not been triaged yet. > > Note also that the 'triaged: bug', 'triaged: feature', and 'triaged: > documentation' > labels also make sense for pull request, in particular w.r.t. the > question whether > a pull request can be backported or not. > >> >> Bugs, features and documentation issues are resolved by >> fixing/implementing them, or marking them with a resolved label. Should >> we also have a "resolved: answered" label where we believe we have >> answered a question? Possibly also one where there has been no answer, >> but we're closing it because the question is stale? > > It might be useful to add more reasons for why the issue is resolved. > OTOH we should watch out that we don't create too many labels. > > "resolved: fixed" > "resolved: answered" Not sure about the "resolved: fixed" one...most of the time where we resolve an issue by fixing it, it gets closed automatically. Adding a label probably doesn't add much. I suppose it might be useful in the case where someone reports a bug that is *already* fixed in a later version. > ... > > For the unresolved issues, an 'unresolved: *' label makes sense: > > "unresolved: " Possible reasons for marking something as unresolved: - The question is stale - no activity for a prolonged period - Off topic - the question is about something not directly related to OpenSSL - Unable to help - despite our best efforts we weren't able to figure out an answer - Lack of information - we requested information and it wasn't forthcoming Not sure if we would want a label for all of those or not. Matt
Re: AW: Confirmed bug labels
On 29.10.19 13:14, Matt Caswell wrote: Do we just need "triaged: bug" and "triaged: feature"? Or should we also have "triaged: documentation" and "triaged: question" (so that there is one for every corresponding "issue" label)? Yes, that makes sense. Then it is assured that the 'issue: *' labels are set only for issues which have not been triaged yet. Note also that the 'triaged: bug', 'triaged: feature', and 'triaged: documentation' labels also make sense for pull request, in particular w.r.t. the question whether a pull request can be backported or not. Bugs, features and documentation issues are resolved by fixing/implementing them, or marking them with a resolved label. Should we also have a "resolved: answered" label where we believe we have answered a question? Possibly also one where there has been no answer, but we're closing it because the question is stale? It might be useful to add more reasons for why the issue is resolved. OTOH we should watch out that we don't create too many labels. "resolved: fixed" "resolved: answered" ... For the unresolved issues, an 'unresolved: *' label makes sense: "unresolved: " I updated the "closed: *" labels to say "resolved: *" instead. Ok, I already saw it :-)
Re: AW: Confirmed bug labels
On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: > A similar problem applies to 'issue: feature request'. Just having a > 'confirmed' label for bugs > wouldn't help in that case. > > So what do you think about adding a new 'triaged: *' family of labels, in > addition to 'issue: *'? > > 'triaged: bug' > 'triaged: feature' > etc. Do we just need "triaged: bug" and "triaged: feature"? Or should we also have "triaged: documentation" and "triaged: question" (so that there is one for every corresponding "issue" label)? Bugs, features and documentation issues are resolved by fixing/implementing them, or marking them with a resolved label. Should we also have a "resolved: answered" label where we believe we have answered a question? Possibly also one where there has been no answer, but we're closing it because the question is stale? I updated the "closed: *" labels to say "resolved: *" instead. Matt > > If this seems too verbose, then we could just omit the triaged prefix: > > 'bug' > 'feature' > etc. > > Matthias > >> -Ursprüngliche Nachricht- >> Von: openssl-project Im Auftrag von >> Matt Caswell >> Gesendet: Dienstag, 29. Oktober 2019 10:23 >> An: openssl-project@openssl.org >> Betreff: Confirmed bug labels >> >> Do we need a "confirmed bug" or similar label? I was looking at #10283 >> which is labelled with "issue: bug report". But this only tells us that >> the reporter thought it was a bug. I wanted to add a label confirming >> that it really is a bug...but nothing suitable seems to be there. >> >> Matt
Re: AW: Confirmed bug labels
Our replies overlapped. 'resolved: *' is even better than 'triaged: *'. On 29.10.19 12:57, Matthias St. Pierre wrote: Another idea just occurred to me: we could join the 'closed: *' labels with the 'triaged: *' labels: triaged: duplicate triaged: not a bug triaged: wont fix
Re: AW: Confirmed bug labels
On 29/10/2019 11:53, Matthias St. Pierre wrote: > > > On 29.10.19 12:41, Matt Caswell wrote: >> >> On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: >>> A similar problem applies to 'issue: feature request'. Just having a >>> 'confirmed' label for bugs >>> wouldn't help in that case. >>> >>> So what do you think about adding a new 'triaged: *' family of >>> labels, in addition to 'issue: *'? >>> >>> 'triaged: bug' >>> 'triaged: feature' >>> etc. >>> >>> If this seems too verbose, then we could just omit the triaged prefix: >>> >>> 'bug' >>> 'feature' >>> etc. >> Yes, this makes sense to me (and I prefer the more verbose versions). >> Should we remove the reporter label once its been triaged? It would be >> quite confusing if you had both the labels "issue: bug report" *and* >> "triaged: feature" (in the cases where someone reports something as a >> bug, but we see it as a feature request). > > I agree with you that it should be removed. > > > BTW: That's a similar question than your recent question whether > 'approval: done' should be removed when the 'ready to merge' > label is added. After sleeping a night over it, I would prefer if > the former were removed. If we would add the 'approval: ' prefix, > then it would be obvious why it makes sense: > > 'approval: review pending' > 'approval: omc review pending' > 'approval: done' > > ... 24h grace period ... > > 'approval: ready to merge' > > The transition diagram would be much easier to remember, in particular > for the case when an approval needs to be revoked because some change > was added (or even force-pushed) after approval. Yes - ok. That's a good argument. > > > >> Another issue I encountered was with the "closed: *" labels. "closed" >> doesn't quite seem right to me. Whether something is closed or open is >> somewhat independent of the states that those labels convey. For example >> we might want to label something as "not a bug" but leave it open for a >> little while to allow the reporter to respond or argue why it really >> should be treated as a bug. Similarly with "wont fix" and maybe even >> "duplicate". > > Actually the 'rejected: *' prefix would be the most appropriate. I just > hesitated > because it sounded so unfriendly. If you have a more friendly proposal, > I'd be > happy to hear about it. Otherwise I would just suggest to use it instead of > 'closed: *'. "rejected" isn't even quite right either. E.g. in the case of "wont fix" its not that we are disputing that what they've told us isn't true - just that we're not going to do anything about it. How about "resolved: *" instead? Matt
Re: AW: Confirmed bug labels
Another idea just occurred to me: we could join the 'closed: *' labels with the 'triaged: *' labels: triaged: duplicate triaged: not a bug triaged: wont fix On 29.10.19 12:53, Matthias St. Pierre wrote: On 29.10.19 12:41, Matt Caswell wrote: On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs wouldn't help in that case. So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? 'triaged: bug' 'triaged: feature' etc. If this seems too verbose, then we could just omit the triaged prefix: 'bug' 'feature' etc. Yes, this makes sense to me (and I prefer the more verbose versions). Should we remove the reporter label once its been triaged? It would be quite confusing if you had both the labels "issue: bug report" *and* "triaged: feature" (in the cases where someone reports something as a bug, but we see it as a feature request). I agree with you that it should be removed. BTW: That's a similar question than your recent question whether 'approval: done' should be removed when the 'ready to merge' label is added. After sleeping a night over it, I would prefer if the former were removed. If we would add the 'approval: ' prefix, then it would be obvious why it makes sense: 'approval: review pending' 'approval: omc review pending' 'approval: done' ... 24h grace period ... 'approval: ready to merge' The transition diagram would be much easier to remember, in particular for the case when an approval needs to be revoked because some change was added (or even force-pushed) after approval. Another issue I encountered was with the "closed: *" labels. "closed" doesn't quite seem right to me. Whether something is closed or open is somewhat independent of the states that those labels convey. For example we might want to label something as "not a bug" but leave it open for a little while to allow the reporter to respond or argue why it really should be treated as a bug. Similarly with "wont fix" and maybe even "duplicate". Actually the 'rejected: *' prefix would be the most appropriate. I just hesitated because it sounded so unfriendly. If you have a more friendly proposal, I'd be happy to hear about it. Otherwise I would just suggest to use it instead of 'closed: *'. Matthias
Re: AW: Confirmed bug labels
On 29.10.19 12:41, Matt Caswell wrote: On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs wouldn't help in that case. So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? 'triaged: bug' 'triaged: feature' etc. If this seems too verbose, then we could just omit the triaged prefix: 'bug' 'feature' etc. Yes, this makes sense to me (and I prefer the more verbose versions). Should we remove the reporter label once its been triaged? It would be quite confusing if you had both the labels "issue: bug report" *and* "triaged: feature" (in the cases where someone reports something as a bug, but we see it as a feature request). I agree with you that it should be removed. BTW: That's a similar question than your recent question whether 'approval: done' should be removed when the 'ready to merge' label is added. After sleeping a night over it, I would prefer if the former were removed. If we would add the 'approval: ' prefix, then it would be obvious why it makes sense: 'approval: review pending' 'approval: omc review pending' 'approval: done' ... 24h grace period ... 'approval: ready to merge' The transition diagram would be much easier to remember, in particular for the case when an approval needs to be revoked because some change was added (or even force-pushed) after approval. Another issue I encountered was with the "closed: *" labels. "closed" doesn't quite seem right to me. Whether something is closed or open is somewhat independent of the states that those labels convey. For example we might want to label something as "not a bug" but leave it open for a little while to allow the reporter to respond or argue why it really should be treated as a bug. Similarly with "wont fix" and maybe even "duplicate". Actually the 'rejected: *' prefix would be the most appropriate. I just hesitated because it sounded so unfriendly. If you have a more friendly proposal, I'd be happy to hear about it. Otherwise I would just suggest to use it instead of 'closed: *'. Matthias
Re: AW: Confirmed bug labels
On 29/10/2019 11:34, Dr. Matthias St. Pierre wrote: > A similar problem applies to 'issue: feature request'. Just having a > 'confirmed' label for bugs > wouldn't help in that case. > > So what do you think about adding a new 'triaged: *' family of labels, in > addition to 'issue: *'? > > 'triaged: bug' > 'triaged: feature' > etc. > > If this seems too verbose, then we could just omit the triaged prefix: > > 'bug' > 'feature' > etc. Yes, this makes sense to me (and I prefer the more verbose versions). Should we remove the reporter label once its been triaged? It would be quite confusing if you had both the labels "issue: bug report" *and* "triaged: feature" (in the cases where someone reports something as a bug, but we see it as a feature request). Another issue I encountered was with the "closed: *" labels. "closed" doesn't quite seem right to me. Whether something is closed or open is somewhat independent of the states that those labels convey. For example we might want to label something as "not a bug" but leave it open for a little while to allow the reporter to respond or argue why it really should be treated as a bug. Similarly with "wont fix" and maybe even "duplicate". Matt > > Matthias > >> -Ursprüngliche Nachricht- >> Von: openssl-project Im Auftrag von >> Matt Caswell >> Gesendet: Dienstag, 29. Oktober 2019 10:23 >> An: openssl-project@openssl.org >> Betreff: Confirmed bug labels >> >> Do we need a "confirmed bug" or similar label? I was looking at #10283 >> which is labelled with "issue: bug report". But this only tells us that >> the reporter thought it was a bug. I wanted to add a label confirming >> that it really is a bug...but nothing suitable seems to be there. >> >> Matt
AW: Confirmed bug labels
A similar problem applies to 'issue: feature request'. Just having a 'confirmed' label for bugs wouldn't help in that case. So what do you think about adding a new 'triaged: *' family of labels, in addition to 'issue: *'? 'triaged: bug' 'triaged: feature' etc. If this seems too verbose, then we could just omit the triaged prefix: 'bug' 'feature' etc. Matthias > -Ursprüngliche Nachricht- > Von: openssl-project Im Auftrag von > Matt Caswell > Gesendet: Dienstag, 29. Oktober 2019 10:23 > An: openssl-project@openssl.org > Betreff: Confirmed bug labels > > Do we need a "confirmed bug" or similar label? I was looking at #10283 > which is labelled with "issue: bug report". But this only tells us that > the reporter thought it was a bug. I wanted to add a label confirming > that it really is a bug...but nothing suitable seems to be there. > > Matt
