I’m going to tighten this up a bit from my perspective:
I see a lot of interested-in-bugs folks in the help venues who don’t join the Bug Squad. Not sure why not.
I see a few folks who do join the bug squad not getting as much mentoring as they might like. Maybe they are hanging out in the wrong venue, maybe they are in the wrong time zone, maybe they are not asking for mentoring clearly enough.
I see a lot of casual users misusing Launchpad, not understanding the bug flow, and getting frustrated.
In the help forums, I see a lot of support gurus who also seem weak on Launchpad skills and bug flow; they cannot seem to help confirm bugs and don’t seem able (interested?) to triage confirmed bugs. When a user drops in to seek help with their bug, everybody gets frustrated.
Many of those observations seem biased toward training-based solutions. That’s admittedly my bias, I might be projecting a bit, and your mileage may vary.
I’m having a hard time responding to the comments in this thread because I feel as if we’re living in completely different worlds and talking past each other. With some help of @ian-weisser I got this practical observation:
Reporting and triaging bugs on launchpad is incredibly frustrating and seemingly useless if you’re not part of the Ubuntu bubble. Almost everyone I encounter in the community has the same sentiment, and most people just don’t bother anymore. In the rare cases where people do report a bug, it’s almost always a show-stopper bug for the reporter, resulting in even-more frustration.
I have tried to start conversations about Launchpad many times, I started a reddit thread about the future of launchpad two years ago that sparked some great discussion. I created a bug report clearly documenting the issues with a common workflow. The response back then was “we’ll implement git support and then we will have time for UX”. 2 years later we have git support, it’s badly documented, and not much has changed UX wise. The workflow from the bug report has even become worse because now you can have both git and bzr code repos.
If I take the fwupd issue as an example: there is so much that could improve in launchpad. Some examples:
Show the SRU process on top of the bug report with a “marker” that shows where it is in the SRU process for each release. Show the “what has to happen” at this moment for each release. The thread has a number of auto-generated answers that give some clues as to what needs to happen, but some of it is outdated, some of the builds failed, etc… I need to read the entire thread and manually merge all the information in the tread to figure out where it is in the process for each series. If the SRU process is really that fixed, then launchpad should be able to show where exactly it is in that process and what exactly failed.
Allow markdown. This would make the entire thread so much more readable and parse-able.
Support “invalidating” comments; automatically collapsing comments that don’t apply anymore: test-proposed requests that have been met etc…
@rbasak I appreciate the time you put into this. Feel free to ask me for more clarification or other stuff, but know that just figuring out what you want me to talk about is hard and saying it respectfully with 5 years of built-up launchpad frustrations in my head isn’t easy either.
I mean it’s up to Ian to reply but I can see that they’re, at least, not completely useless. Problems may be discovered by users who aren’t developers that the developers may never come across in their usage of the program, bug reports are a way of telling the developers that the problem exists, and allows the developer to respond as appropriate.
With SRUs, the verification-needed and verification-done tags help with seeing what needs to be done. Yes you have to be familiar with the SRU process but such is the nature of these things.
I’m not really sure how your comments will fundamentally solve problems with Ubuntu on Launchpad, really (imho) the issue is that we need more people learning how to triage bugs and we need devs willing to fix bugs. We can’t coerce people into volunteering(!) so there’s not an awful lot we can do other than keep reporting and triaging when we have time and being really patient! I agree with @ian-weisser that the main problem is probably training.
Also, it seems a bit meta, but have you filed your suggestions as bugs (asking them to be marked Wishlist)?
Of course we can’t coerce them, we need a carrot instead of a stick.
One of the fundamental issues is that it’s not fun to contribute. Launchpad is a big reason for that. As a result not many contribute and not many want to learn. There’s no use in teaching people if they don’t want to spend their free time doing the things you taught them…
The launchpad side of this solution means Improving launchpad UX so that people don’t need to be taught. If launchpad simply would show the SRU process on a timeline, and show where a bug is in that process, then drive-by-contributors could easily start participating in a meaningful way without needing to go through a bunch of documentation. Moreover, these people would feel empowered because they instantly see how the process works instead of feeling lost in this complex machine.
Look at the whole stackexchange network: they found a way to make Q&A fun, and they got a gigantic community as a result.
Yesterday another newbie installed Ubuntu 16.04 LTS after my recommendation. He was very
disappointed seeing this message during installation of ttf-mscorefonts-installer package.
Ubuntu developers should understand that annoying bugs should be fixed as fast as possible as Critical bugs. It does not matter that such bugs do not result in data loss. Such bugs makes negative reputation of whole Ubuntu. So they should be fixed.
How did your newbie friend install ttf-mscore fonts, as there is a dialog box that pops up asking if you accept the licensing of the font package, as it isn’t open source.
Using language with that tone is the fastest way to get everyone to ignore your bug, fwiw.
I’d like to echo what Ian Weisser said in his first reply here, specifically:
You CANNOT ‘force’ a developer to do anything at all. They are free. Most are volunteers.
You CAN increase the likelihood of getting a bug fixed by doing the following:
Learn the life cycle of a bug report.
Learn how to Triage a bug report. Bug triage is usually a community task, not a developer task.
Help police the bug reports to keep them on-topic toward Triage, assigned to the correct package, weeding the support requests into Answers, etc.
Remind many LTS users to test if their bug still exists in development release of Ubuntu. Many bugs are fixed but not backported (there’s a policy for this)
Patiently teach users about their systems, about the bug process, and how to do the detective work to reach Triaged.
If a bug is annoying you, you can always scratch your own itch and fix it yourself. That’s how I (and many others started). We can help you with the packaging side of things if you’re willing to put in the effort for the fix.
My point is: just saying “the Ubuntu developers need to fix this” will get you nowhere unless you can actually convince someone to look into it. If you do it yourself, it’s your timeline, and you can spend lots of time on it.
I did not mean to sound rude, unlike some. Maybe it’s because I do not have enough English vocabulary. But I never changed my personality, unlike Simon. The main rule “be nice” was broken. Thanks, @tsimonq2!
Therefore, I do not consider it possible to continue this discussion.
It’s useless. I do not have time to overcome the bureaucratic processes of the BugSquad.
I will continue to use Ubuntu, teach people how to use it, help novice users on AskUbuntu, report bugs to the LaunchPad and to upstreams.
