Making a app for reporting problems

One of the biggest problem w, when comes to open source project or Linux distros,s that no one report problems etc,
but when comes to ubuntu we have launchpad and some tutorials on how to report problems.
From what I found is that

  1. The how-to page is too old and to crowded

  2. There is no web GUI native app for launchpad (and some users will not go on a webpage to post a problems especially when they are not technical

  3. when you have platforms la GitHub and gitlab , launchpad feels like you go back in time to 2000

I did want to make a webpage app snap for launchpad to feel more integrated but i don’t feel that that is enough

So here is a mocking up an interface app

My idea was this

-a tab with select your problem: video, audio, app etc

-then select your let’s say you choose an app (you will have all the apps instaled names) or some sort of I don’t find or know

-then post your problem, but in the background ,the app will take all the information of your os the specific app version etc for you.

What do you think?
Personally, I don’t have the knowledge to pull this off but I will try.

1 Like

I might phrase it differently: Lots of (manual) bug reports are too vague or incomplete to do anything with. Launchpad gets lots of bug reports every day. Many well-intentioned reporters simply lack the knowledge to understand the bug, and to clearly explain to a triager how to duplicate the behavior in a test environment.

I’m not sure how (essentially) moving the ubuntu-bug application into a GUI will help unskilled reporters improve their descriptions. One big problem is that they simply don’t know what to describe.

When these folks wind up in AskUbuntu, it’s often not a bug at all. Instead, it’s often a matter of undoing some unwise decision they made or some bad advice they followed from some random non-Ubuntu webpage.


If its

let’s update the how-to page when it comes to the reports. the same problem is with the How-to page old out of date and hard to understand for a new user that wants to help

Let’s find a solution and do something.

Over the last two or three months I’ve been involved in looking at what must now be almost 2000 old and untouched bug reports. Another conscientious user has also been doing the same with a similar number of reports. I doubt that we’ve even “scratched the surface” of the problem. I’ve always said that it’s not the number of bugs in Ubuntu (and its flavours) that are the problem but the number of bug reports.

Bug #3127 was raised during the Dapper development cycle and is still apparently a valid and current bug. It’s several years before my time with Ubuntu and not being from the “other” side of the world I’ve not taken a serious look at whether the report is still valid or not. I’m doing my best with the applications that I’ve taken on but let us find a way of dealing with the reports that we have rather than inventing a new way to deal with new reports.

Would the old reports get forgotten or relegated to being looked at much later than a report on any new system? In my experience many of those old reports are still valid as they still refer to bugs that have never been fixed.

ReportingBugs is a great resource for those with the time and patience to wade through the documentation but for a first time user it is far too much to deal with. I’ve seen far too many forum users told to report a bug without ever being told to check to see if the issue has already been reported. Many never manage a report. At best they often report a duplicate. :disappointed:

There is a real problem with the reporting of bugs and it does need to be addressed. I think Launchpad is fine as it is as long as meets the needs of those that that can actually fix bugs. Who decides what is best anyway, the person who reports a bug or the person who receives and works on a bug report?

A recent example of a very poor report (after being translated into English):

it does not detect wireless and the bluethoot is automatically deactivated

That’s all there was. May be that’s all the reporter thought was needed but what Ubuntu release or flavour did he or she refer to? What version of the kernel was installed|? Will any developer actually waste any time on looking to reproduce the issue on whatever release or flavour he/she has available for testing? I doubt it. :confused:

So to conclude, the following needs to happen:

  • Better quality bug reports need to be raised
  • Issues that can’t be fixed by Ubuntu need to be forwarded upstream
  • Requests for support or the reporting of one-time issues need to be dealt with quickly
  • Enhancement requests need to be separated from actual bugs
  • Reports need to be updated or closed when fixed
  • Out of date reports need to be removed

I think you can see where I’m coming from. The answer is procedural not inventing a new system which may just inherit the problems of the system that it replaces.


The person that makes a proper bug report! Why because they need to make it and in all the cases they don’t have code knowledge. You can see how many linux YouTubers report a problem on Launchpad vs github etc. I can tell you that less then 3% on Launchpad. Why? Because in all the time you need to know the app package name and then to manual find it because when you read the “how to report” after 1 min of reading you will give up.
P.S this is from my personal opinion. I’ve posted bugs on Launchpad from 2014 and i am now a qa engineer at ubuntu mate. Now i am learning code python, so until now no experience with code.

of which there are millions, I might add. :astonished:

I do think Ubuntu would benefit from an easily-accessible program bundled with Ubuntu to report bugs (and bugs only). Ideally, this should integrate with launchpad with API - Launchpad Help, so we’re not replacing launchpad, but rather making its functionality accessible to the masses. If well thought out, this can potentially walk the user through the process of replicating the bug. I think it helps to have more feedback than not enough. If anything, it will help Canonical and/or the appropriate upstream developers focus resources on what matters most.

However, before doing anything, we need to discuss what is wrong with our current system. That way, we can plan this out appropriately. @ian-weisser already mentioned several

Maybe have the user choose what their skill level is like this mockup I made: