| 1 |
On 03/12/2022 13.20, Michał Górny wrote: |
| 2 |
> On Sat, 2022-12-03 at 13:10 +0100, Florian Schmaus wrote: |
| 3 |
>> On 03/12/2022 12.34, Michał Górny wrote: |
| 4 |
>>> On Sat, 2022-12-03 at 11:42 +0100, Florian Schmaus wrote: |
| 5 |
>>>> On 03/12/2022 08.09, Michał Górny wrote: |
| 6 |
>>>>> Hi, |
| 7 |
>>>>> |
| 8 |
>>>>> I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug |
| 9 |
>>>>> states with a simple NEW state. Why? |
| 10 |
>>>>> |
| 11 |
>>>>> 1. Only a handful of developers actually uses these two statuses |
| 12 |
>>>>> in a meaningful way. |
| 13 |
>>>>> |
| 14 |
>>>>> 2. Some users are confused and demotivated by having their bugs stay |
| 15 |
>>>>> UNCONFIRMED for a long time. |
| 16 |
>>>> |
| 17 |
>>>> While I do not strictly oppose that change, I like the UNCONFIRMED / |
| 18 |
>>>> CONFIRMED states. |
| 19 |
>>>> |
| 20 |
>>>> I don't know how 1. is an argument for removing it. Quite the contrary, |
| 21 |
>>>> the statement itself says that the feature is used. Furthermore, it is |
| 22 |
>>>> not my observation that only a handful of developers use it. Most open |
| 23 |
>>>> bugs are in the CONF state [1], so I would conclude that most use the |
| 24 |
>>>> feature. Of course, that depends on your definition of "used in a |
| 25 |
>>>> meaningful way". For me, CONFIRMED was always about someone, usually a |
| 26 |
>>>> -dev, acknowledging that the bug reports a valid issue that needs to be |
| 27 |
>>>> addressed (either by Gentoo or upstream). Is that using it in a |
| 28 |
>>>> meaningful way? |
| 29 |
>>> |
| 30 |
>>> Does that imply that bugs that are UNCONFIRMED are not worth our effort? |
| 31 |
>> |
| 32 |
>> No, not all. Could you elaborate how you derive this implication? |
| 33 |
>> |
| 34 |
>> I had always assumed that UNCONFIRMED means that nobody (as in, no dev) |
| 35 |
>> looked at the issue report and vetted its validity. Nothing more, |
| 36 |
>> nothing less. |
| 37 |
>> |
| 38 |
> |
| 39 |
> I'm trying to understand what actual value this has. Unless it's data |
| 40 |
> for the sake of having data. |
| 41 |
|
| 42 |
That is a valid concern. |
| 43 |
|
| 44 |
I think having UNCONFIRMED / CONFIRMED *helps* the issue reporter, and |
| 45 |
other (affected) persons, to decide if they need to "chase" the issue's |
| 46 |
assigned entity. |
| 47 |
|
| 48 |
Assume looking at the open bugs list of a developer. If the developer |
| 49 |
has old bugs in UNCONFIRMED state, you may want to issue a friendly |
| 50 |
ping. Sure, strictly speaking, this would require all bugs to drop back |
| 51 |
to UNCONFIMRED when the bug assignee changes. But even without such an |
| 52 |
implicit mechanism, those two states provide some value. |
| 53 |
|
| 54 |
A similar case can be made for IN_PROGRESS. However, I see how one could |
| 55 |
argue that IN_PROGRESS provides more value than UNCONFIRMED / CONFIRMED. |
| 56 |
|
| 57 |
As I said, I do not strictly oppose this change. But since this is a |
| 58 |
RFC, I commented. :) |
| 59 |
|
| 60 |
Maybe it is just me being used to bug transition states being |
| 61 |
|
| 62 |
NEW / UNCONFIRMED → CONFIRMED → IN_PROGRESS → CLOSED |
| 63 |
|
| 64 |
(with intermediate states being optional) |
| 65 |
|
| 66 |
- Flow |
Archives