Let's get rid of UNCONFIRMED/CONFIRMED

[Ben Cooksley]

On Wed, Feb 28, 2018 at 8:37 AM, Elvis Angelaccio
<elvis.angelaccio at kde.org> wrote:
> On martedì 27 febbraio 2018 16:08:44 CET, Ben Cooksley wrote:
>>
>> On Tue, Feb 27, 2018 at 11:32 PM, Elvis Angelaccio
>> <elvis.angelaccio at kde.org> wrote:
>>>
>>> Hi,
>>
>>
>> Hi Elvis,
>>
>>> recently we introduced a policy change in bugzilla and now every user has
>>> the power to change the status of any ticket.
>>>
>>> This is good (and consistent with phabricator) but there is a big
>>> downside:
>>> many people will open a new ticket and then mark it as CONFIRMED. This is
>>> annoying because now I get two mails instead of one.
>>
>>
>> This should be simple enough to fix if we prevent users who are not
>> members of the 'contributors' group from confirming their own bug
>> reports.
>> (Confirming your own reports isn't the type of triaging we were
>> looking for originally, so I see no issue with this).
>
>
> Hi Ben,
> this should fix this specific problem, yes. Is it also possible to prevent
> people from changing their own bugs from RESOLVED/NEEDSINFO to UNCONFIRMED?

Just curious - why would we want to prevent that?

If they've provided the information then the correct action would be
for them to reopen it so that someone can take a look. If further
information is needed then it can go back to NEEDSINFO.

I'd rather not restrict that as if people don't reopen them then it
would be quite easy for their response to get lost, which is quite
undesirable.

>
>>
>> Thoughts?
>>
>> If anyone tries to circumvent that control we'll suspend the involved
>> account(s) from Bugzilla.
>>
>>> There was already a proposal [1] to remove UNCONFIRMED and use NEW
>>> instead.
>>> I think now it's a good time to discuss it again.
>>>
>>> The UNCONFIRMED/CONFIRMED thing has little meaning, is confusing for
>>> users
>>> and for new triagers and we know that many developers never set this
>>> state.
>>>
>>> We don't have this problem with phabricator tasks because they can be
>>> either ...
>>
>>
>>
>

Cheers,
Ben