Slow bug reporting hindering project progress and future scaling

[wayneoutthere]

Description of the feature

User-friendly bug reporting tool/app built right into the OS and each app

Expected behavoir

As the project grows and more non-developer everyday users begin joining, it's paramount that there is a simple, friendly way for them to report bugs. I expect to be able to, from anywhere I am in my device, quickly and easily find a way to report bugs and request features. This could be done built into OS or as an app perhaps. Upon submission, the output could go to github maybe or to a central place where community volunteers correctly file the bugs for them. Also gives a chance to filter the bugs/feature requests in case there are duplicates.

Actual behavior

Instead of this tool, the user is expected to come to a bug-reporting page like this one and hope to understand how to file it. I am an example of a person who rarely reports because of this scary process.

[NeoTheThird]

I see the problem you're describing, but in my opinion it's also part of our mission to make users more comfortable with peeking behind the curtain and working closely with the developers. We can probably build an app that automatically generates the reports and walks the user through the process of posting it in the right place, but I'd strongly argue against creating another layer in between where users send reports to. Especially for bug reports, it's crucial for us to be able to communicate with the reporter. Creating a layer in between will take away that ability completely, slow the process down and create a lot of extra work for our volunteers.

[NeoTheThird]

Ok, i thought about this some more. I stand by my previous statement, users should report issues on github themselves.

But I see the problem you're describing, so it's probably really a good idea to build functionality to create the report automatically. I like your Flow-Chart, this could be a really nice feature. Of course we could put an option to select reporting bugs for core-apps as well. What i'd also like is for the report-generator to automatically attatch important logs, i can reuse some of my code from logviewer for that. Also, the app should present the user with a list of already confirmed issues for their device to reduce the risk of duplicate reports.

I think that could make it easier for the users, especially getting logs is probably a little intimidating, but in general, I think that is not too much to ask to report on GitHub, it's really just leaving a comment on a website.

Thoughts, @wayneoutthere?

[wayneoutthere]

Your comments are awesome. I fully agree. And we will in the community build and foster this important relationship. Absolutely it sucks that tech companies have hidden everything and involvement. I'm 100% in agreement. However, i'm not talking about that. what I'm talking about here is a super fast, super friendly want to make sure that more people are reporting bugs and filing feature requests. I am often outside and want to file a feature request that would be awesome. If I don't do it right then, it never happens. This is our 'hotline' to the developers. Perhaps we can simply put in a 'reply feature' so that when a developer gets this feature request or bug report they can send a quick reply or they can reach out to thank them. This is absolutely not to hinder what has been awesome but to enhance it. No other platform would have this amount of free information streaming in if done correctly and we would have an amazing amount of super valuable information more quickly.

[sverzegnassi]

The idea is very interesting. From the user perspective, it would bring much value and could result in a very nice flow. In this sense, it might be worth to spend some time on exploration and further discussion in the future.

Implementation of the idea, however - I want to be honest on this - might be less trivial than it could appear at first.

What I would expect, in the case of an app report, is:

1. I'm using e.g. Notes app, and I see a visual bug that makes the app less convenient
2. I press a specific combination of physical keys to invoke the 'bug reporter tool'
   • The tool automatically takes a screenshot of the current view
   • The tool is integrated with Mir, so it can automatically detect which is the top-most/focused application
   • The tool automatically includes information about OS version, app version and device (i.e. model, screen size, etc.)
3. There is a popup that ask me to fill: (1) a max. 140 chars bug description, and (2) steps for reproducing the bug
4. Press "Finish", I see a recap of the data that are going to be send on internet
5. I can confirm and authorize the data transfer, or cancel the bug reporting

I think this is the most ideal scenario; however, it already involves a lot of relations between different system components.

We might opt for having a separate app, which might be invoked from the Apps scope or the System indicator. Whatever will be the form of this tool, there are a few limitations that we might need to investigate and explore:

• Such tool would likely work only for projects that has a well-known upstream (i.e. Core Apps, Unity 8, and system components)
• Users might or might not want to send a screenshot of the app, in case the issue is reproducible with private/personal data
• Users might send reports in their own language, and not in English. This could make the tool less effective
• How to handle duplicate reports?
• A similar tool might act as an "engagement killer". We might need to rethink how users can follow the status of their reports and/or actively take part to the bug resolution progress.
• If no app crash is involved, we might have to rely on the same data that is available e.g. in LogViewer. Data might: (1) contain no relevant output; (2) contain personal information that we don't want to leak in no way.
• How to transfer collected data to our central issue tracker on GitHub, in a way that doesn't affect developers' workflow efficiency

These are just a few pitfalls that I can think of right now.
I am taking this seriously, since I do agree that it could be a game changer for us. The issues I listed: (1) don't need to be all resolved; (2) are not blockers, they all can anyway be solved or worked around.

What I'm trying to set up here is the trade-off between the efficacy level of the proposed solution, and the effort we might have to spend for reaching that level.

I'm definitely with you, @wayneoutthere !

P.S. "Draw it with a pen, take a photo [with your device]" is a great solution, that it makes already worth to spend some time on getting this tool done. Well thought! 👍

[Flohack74]

We can have an alternative channel for this, yes, as long as we can can identify the user, we do not want anonymous reports. This is not useful, and often abused as "you all suck" possibility. So if the App can have a verified email inside where we can come back with questions or ideas its good.

No comes the hard part, if we enter this data now automatically on behalf of the user, all further discussions including updates of status etc need to be relayed to the reporter, otherwise its too much fire and forget.

We can maybe use the Github API? I dont know, but then at least user needs to create a Github account, which would be in our favour of course ;)

[wayneoutthere]

The 'rules' for the tool should be:

1. make bug reporting brain-dead easy so more people do it quicker
2. make feature request submission clear, fast, and easy so more people share cool ideas quicker
3. open doors of communication with community and developers, not close them

I'm sure all of these can happen with enough smart minds on it. I"m just thinking about how many important bugs I haven't filed because I get intimidated by the process or the 'moment' disappears before I remember and then I get busy. I think it makes community involvement much greater this way, not less. Imagine if bugs get fixed quicker? Maybe when a bug is fixed the person who reported it can be notified? That would be incredible feeling of 'wow' for the user. "WOW! They actually listened to me!"

[wayneoutthere]

@NeoTheThird Oh, Jan. by the way, absolutely logs are the scariest part of it all. whenever someone says 'get a log' I go to the fireplace and stick one on and leave the bug reporting to someone else who can figure out a log file!

[userj]

@wayneoutthere that is a great flow chart. This is something we discussed in episode three of the audiocast. For a living example of what you described, check out the status.im app. You shake the device to report a bug, it gives the option of screenshot and the ability to draw on top of it.

In any case, bug reporting needs to be easy enough for anyone to do it. Also, I am concerned with over-reporting. Is there such thing? I report anything and everything. Sometimes I think someone will get annoyed. I wontbe offended , but that does mean there are unanswered questions.

The "wow they listened" thing shouldn't be that amazing. Communication is important on how bugs are triaged and what is likely to happen.

With features, people want to know why it wont be implemented if that is the case. We all have ideas and think they are awesome.

Lastly, this all sounds very heavy for those dealing with it. So, how can we make it more efficient? What do developers need more of that can make this a good experience for all parties?

[TronFortyTwo]

If I can enter this conversation, I'd like to share a design prospective that as a developer point of view I think could be good in the ratio effort/result.
The user should only see an abstract part of the process: which app, what, description, maybe some flag like 'share log' (which can retrive automatically the .log filw) or 'attach media'.
Then the app will handle the sending of the issue, with:

Easier way

In the app manifest file there should be the mantainer e-mail, so the app can compose an e-mail organizing the content the user put in, then it opens it with dekko ready to be sent. Quick.

Further developing: (fast--, result++)

The 'bug reporting app' or whatever's his name can have a list of specifics apps (i.e. the core apps) that have 'special' links: not only the manifest e-mail but for example: multiple or different e-mails, github pages where list an issue (idk in this field how much complex are to implement the github api), or something else.

Further work: (fast--, result++)

All of the previous, more that the app takes the information about the preferred issuing method of a foo app from the foo app itself (write in some way in the manifest file (more consistent but we need to tweak the click tools I think), or a dedicated file(faster) ).

[sverzegnassi]

• I do agree with Flo that we might want to discourage anonymous bug reports. And GitHub appears the more natural solution.

• IIRC, leveraging the click manifest should be already achievable. Extensions in form of x-something are already supported. We might use something like x-ubports-bugtracker, and specify that GitHub is the only supported platform for now.

• A few complications might appear when we start to support packaging formats different from click (afaik it's already on our road map). I'm not sure how this could scale with e.g. snap packages, or what it will be brought in future.

A reasonable, yet consistent, use flow might involve our current UBports Welcome app, which might evolve in a more capable "Welcome, Engaging, and Feedback Hub".

In that case, it seems reasonable to say that we will support only official UBports projects.
However, it would give us the opportunity to focus on a clear set of scenarios, and support the interactive process with more efficiency.

[NeoTheThird]

I'd approach it a lot simple for the beginning. In the system indicator (the rightmost one) there already is a button that opens the bugtracker (the shaking-the-device idea could be implemented later), let's point that to open the bug-reporting tool (I'd like for it to be part of the UBports App, since this was actually part of my initial idea for the app which i did not to implement back then because time was too short and later there were more urgent tasks, but another place would work as well). The tool will then walk you through waynes flow-chart and offer you the ability to attach pictures or screen shots. It will ask you what the nature of the problem is and will determine what logs might be helpful and add them automagically. Shouldn't be a lot of work to implement.

A reasonable, yet consistent, use flow might involve our current UBports Welcome app, which might evolve in a more capable "Welcome, Engaging, and Feedback Hub".

That was actually the original idea with the UBports Welcome App, so i second this motion.

A different approach to handle third-party bugtrackers would be to use the openstore page of the app to launch the bugreporter tool, since most apps already set a support link there. The openstore could then open the bug-tracking-tool using the url dispatcher, if it's a github issue tracker. Ofc apps that have a report-a-bug option can also use the dispatcher and pass the issue tracker url as an argument.

[nanu-c]

In the signal app is under preferences a button to upload the log to gist and showing the link. This is a neat tool.