search

ubports / ubuntu-touch

Ubuntu Touch's issue inbox is now migrated to GitLab.
https://gitlab.com/ubports/ubuntu-touch
1.28k stars 110 forks source link

Improve bug reporting experience both for users and developers #371

Open wayneoutthere opened 6 years ago

wayneoutthere commented 6 years ago

bug_report_feature_request_tool_wot_171220

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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! :+1:

Flohack74 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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!

cyberpunkedu commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

cm-t commented 6 years ago

Hi,

Having a tool is probably a good thing for all the reasons you already said. I remember using apport (desktop) in my first bugs reports when didn't know what log file to add in my bug report.

It would even make more sense if it is a coreApp at least for the devel channel.

I think, before a tool is out, spending few time to build a page that links to bug report page of each sub-projects is a pretty good start.

For example, lot of you might have used this page, the avengers page, it was personnaly a starting point to many contributions. Those in the ubuntu app dev group might have seen this link posted many many times when someone was asking 'where to report this/that':

sverzegnassi commented 6 years ago

@cm-t I second that!

Currently, our bug reporting story is written around a unified bug tracker (ubports/ubuntu-touch)

It is meant to track:

While this might have helped with making the process more friction-less for new contributors, it has made things a bit more annoying for maintainers.

Specifically, we still use downstream bug trackers for our set of core applications; however, in a few cases ubports/ubuntu-touch is used and accepted as valid bug tracker.

I wonder if we could integrate with some tool offered by Probot. We've been briefly discussing about Stale, which is used by some successful project like Atom or Rails.

I suspect we might also need to write our own bot, to make easier to move bug reports across repositories.

e.g. /moveissue to ubports/camera-app

It would:

jonnius commented 6 years ago

It would:

Do not forget to reference the new issue inside the old one...

Flohack74 commented 6 years ago

I always use this: https://github-issue-mover.appspot.com/

advocatux commented 6 years ago

Helping users in Telegram or in the Forum, I've found that there are some users that don't want to have a GitHub account [*], and other users that want to but they doesn't speak English.

I'm thinking in something like reportbug functionality in Debian as a solution, and I think that's in line with @NeoTheThird proposal.

[*] Yesterday, after suggesting a user to file a bug in Github and told him he only needs to set a nickname, password & email, he literally told me: "I know. Email password nickname. Another combo to for forget just for stating a bug... And one thing why I wanna use UT is because of leaving less traces online... Just a general feeling". So that's the reality we're dealing with.

Flohack74 commented 6 years ago

Yeah but in the same moment thos people get annoyed when they are not notified about changes to the ticket, or when we have questions. Most of the anonymous reports need further clarification. So, if there is no contact address we would just delete those tickets. And maybe have no fix for a problem. Its that simple: If people are talking with us, we also want to talk to them. Thats social, thats conversation. I know that "leaving" traces is everybodys concern these days, but Github is really nothing that would abuse/spam people.

advocatux commented 6 years ago

I agree with you @Flohack74 I was just trying to tell my experience dealing with newbies.