[Development] issue tracker rights

[Knoll Lars]

On 2/6/13 4:33 PM, "Mitch Curtis" <mitch.curtis at digia.com> wrote:

>On Wednesday, February 06, 2013 12:52:29 PM Frederik Gladhorn wrote:
>> Hello all,
>> 
>> yesterday we did a bug triaging and fixing day here in the Digia Oslo
>> office. While everyone always looks at the bugs a little bit, it is
>> sometimes good to actually go through them and figure out if they are
>>valid
>> and their priority so we know what to work on.
>> 
>> Traditionally we have been rather protective of our issues, allowing
>>people
>> to file reports in jira, but not let anyone re-open or close them.
>> I think it would be a good time to re-think our policies for bugs.
>> 
>> I would like to propose that everyone (with an account) gets the
>>ability to
>> create/close/re-open bugs. I don't think anyone will steal our bugs and
>>run
>> away with them. In addition one gets a notification for subscribed
>>bugs, so
>> it's easy to re-open a bug.
>> 
>> I am not sure what the best policy is about assigning priorities to
>>bugs,
>> should everyone be able to prioritize? Of course everyone has their bug
>>as
>> the most important thing in the world. We probably need to creat a good
>> guideline for this on the wiki.

I'm very much in favour of opening this up. I think the Qt Project can
only win with a more liberal policy here.
>
>It would be nice to have a feature where this stuff could be requested
>rather 
>than done immediately. The reason being that if a bug is mistakenly
>closed, it 
>won't show up in the filters that we use for evaluating our bugs for each
>release. If a bug is mistakenly reopened, it's not so bad, but it still
>adds 
>housekeeping overhead for whoever has to re-verify it, etc. Of course,
>someone 
>will still have to respond to the requests; perhaps the reporter is
>notified 
>upon requests to close and the reporter, assignee and user who closed the
>task 
>when something is requested to reopened. There would still need to be
>someone 
>who was notified regardless to account for the cases where the reporter
>is no 
>longer active in the community.

I don't think we should be afraid of someone closing a valid bug by
accident. It's a rare thing to happen in the first place. And small risk
completely outweighed by the better house keeping we get making the
important bugs more visible.
>
>> Another point is assignment. We have the default asignees, but these are
>> often maintainers and in some areas they won't be able to fix all bugs.
>> Probably everyone should be able to assign a bug to themselves at least
>> when it is unassigned.
>> I also think it's good to have unassigned bugs when no one will be
>>working
>> on them in the forseable future - those are up for grabs for everyone.
>
>This I definitely agree with. There's very little disadvantage to giving
>everyone assignment rights (or at least the "Assign To Me" button); the
>only 
>one I can think of is when someone is assigned a bug mistakenly. If
>someone 
>"steals" a task (rarely happens anyway AFAIK), the previous assignee will
>be 
>notified anyway.

We could limit this to be able to take unassigned bugs. Re-assigning
assigned tasks could be limited to Approvers.

Cheers,
Lars

>
>> Bug triaging is a good way to get new contributors involved. So in my
>> opinion we should try to encourage everyone to help out with the
>>cleanup of
>> our bug- tracker. Maybe we can even learn from KDE for example, where
>> regular bug triaging is working nicely.
>> (see for example http://techbase.kde.org/Contribute/Bugsquad )
>
>I think a lot of people are hesitant to contribute fixes because of all
>of the 
>setup required to contribute, also (yeah, it's easy once you are familiar
>with 
>it). This has probably been discussed before, but we would get way more
>fixes 
>(or at least head starts for fixes, since most patches are not fit for
>immediate 
>submission due to the absence of unit tests, etc.) if we could put a
>legal 
>notice somewhere obvious saying that any attachments uploaded imply
>signing of 
>the CLA?
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development