Am 23.02.2018 um 01:47 schrieb Eduard Braun:
Am 22.02.2018 um 02:25 schrieb Maren Hachmann:
Am 18.01.2018 um 21:30 schrieb Bryce Harrington:
Do we have a wiki page setup for discussing/brainstorming bug tracker ideas? Maybe that'd be a good starting point?
Now we have:
http://wiki.inkscape.org/wiki/index.php/Bug_Reporting_Workflow
Maren
Wow, nice!
- Thanks :) I hope it's going to help us move forward with that topic, although it's not really a fun/rewarding topic to start with, as it entrails a lot of work, has a high potential for too much discussion. Hopefully it's not going to be a lot of trial and error.
It reads a bit biased against Launchpad (which in many cases is justified but in others not really a platform issue but something we also need to figure out for whatever new service we might choose) but certainly catches the core points perfectly.
- As for the bias, I think that's because I was listing current problems, and our current platform is launchpad... So, of course, the problems will have to do a great deal with launchpad...
But the page is not static, you can improve the texts. I think it would be very beneficial if the people who are most affected by a change in that system (i.e. devs) would make their needs and wants clear, possibly on that page. It's good to have the vectors team thinking about bug filing templates and welcoming workflows and to have a documentation person write up a summary of issues, but we cannot reasonably do anything without devs.
I'm not sure where discussion is meant to happen going forward (discussion on Wiki talk pages seems to be non-existing in the Inkscape Wiki), but two items I think I settled with myself in the meantime are:
- Filing Inkscape bugs at https://gitlab.com/inkscape/inkscape/issues and creating a (curated) feature tracker as a separate project (e.g. https://gitlab.com/inkscape/inkscape-features/issues)%C2%A0 sounds like a good option. Having a separate project for features could allow to make use of GitLab's wiki features / simple markdown files / snippets / the repository itself to develop and visualize the ideas until they are in a ready state for developers to work on (which should be indicated by a tag)
- Importing bugs from Launchpad in an automated way does not make sense. One of the core points we're trying to solve is that the old tracker is flooded with unclear/incomplete/untriaged bugs - automatically migrating them to the new platform will make it even worse (by disconnecting the original authors) and achieve nothing but moving all platform issues we have with Launchpad, too. If we want to import old bugs it needs to be done manually (e.g. have the "Bug Triager" team from the sketch work on evaluating the old bugs starting at the high importance bugs working their way down
- a highly non-trivial and exhausting task).
- We'd need a whole hackfest *month* dedicated to it... And then, I'm afraid, nobody would come, it's not fun to sort through old bugs... And it's not a task that any one group can do alone - devs of all specializations, users, testers etc. would all be needed to help. Even if we could get 20 persons to work on it, there'd still be 240 bugs per person... 10 a day - mmh, that sounds almost doable. Bugathon, anyone?...
A possibility to gather help (make the "crowdsource triaging part" work) and to determine which bugs are still worth looking at might be to post automated messages at all bugs explaining the tracker is being closed down and all issues which still persist in the current Inkscape Version (give download links) should be re-evaluated (explain how to test) and submitted to the new "friendly feedback hub" for triaging (include guidelines on how to "write a good bug report").
- That would be another way to do it. Advantage: no or very little work for us and a 'clean slate', Disadvantage: lots of info lost, users annoyed (unless someone can explain it to users in a really, really good way).
Kind Regards, Maren
Best Regards, Eduard