On 2/6/13 4:33 PM, "Mitch Curtis" <[email protected]> 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 >[email protected] >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
