Just a few days ago Github announced their new update of Github Issues. You can see the updates with some screenshots from here. Also, please take a look at the new Deployment API if you haven’t already.
Move beyond the simple Issues
Starting at the same day something else were released, not by GitHub, but still connected to Issues. Let me show you, how you can use a chain of tools to make your GitHub Issues even more useful for your team.
The players:
A website
Imagine you have a website, that is hosted on Github, like this one, which is the code-base for input.mozilla.com.
A team/community
Let’s also imagine that you have a team or a community which is handling bug-requests. You have a designer and a programmer at least.
Users
Millions of people are browsing your website month after month and at least a couple of them will find something to complain about, right? 🙂 Let’s take this seriously – Every website owner wants to make the users happy for one reason or another and when a problem appears – it must be fixed in time. Right?
In short, we have a website with source hosted on GitHub and something happens and the team must fix it.
The process and how much time it takes to fix a bug
So, someone discovered a bug. Let’s say one of the L10n strings breaks the layout. Yes, it happens all the time, especially with those Cyrillic languages, right:
Let’s see the whole process step by step
Steps |
Time |
The user is trying to find a way to report the bug (contact-us section) |
2 mins |
The user sends an e-mail to the support – with a description of the bug – ‘your Russian version is broken. You have problems in the footer. Please fix it‘ |
2 mins |
The support guy assigns the bug to the dev team |
1 min |
A QA person is trying to reproduce the bug. Cannot reproduce. Works like a charm. Closing it! |
5 mins |
The same bug is reported again |
The QA is trying to get the information from the end-user – a screenshot, OS, browser version, screen resolution, plugins installed in the browser, etc |
25 mins |
Now we have everything (after teaching the user how to collect the information, again and again). the QA enters the bug into the GitHub Issues providing all information from the client + attaching a screenshot |
7 mins |
The Project Manager is assigning the task to a developer and to a milestone + adding labels of course. |
3 mins |
The developer fixes the issue |
it depends 🙂 |
Total: 45 mins + it depends |
Right now this is one of the most popular processes in the industry. Of course, there can be some improvements, but not like the one I will show you now.
What about if I told you there is a way to drastically decrease the time above: from 45 min to 15 or even less?!
Advice from experts – add visual feedback
Let’s see which of the processes we can optimize:
- Provide the user with a feedback widget for easy bug reporting: -2 mins
- Quicker feedback approach – just highlight the problem and hit a button: -1 min
- The QA will get all information he/she need automatically – browser version, OS, screen size, installed plugins, the url of the incident and a screenshot showing how the problem looks like on the user’s computer: (-5 + – 25)
- The issue is automatically pushed to Github (-1 min) and there is no need support guy to be part of the process: -1 min
- The issue is automatically assigned to a developer, responsible for that kind of issues (pre-configured), attached to the milestone and with the proper labels : -3 min
If you want to try working the visual feedback style, click here to learn more about Usersnap’s GitHub integration and here to read more about how we can save even more time
GitHub tricks and facts
1: Get extended statistics about any public Github project
One of the most common questions about github in StackOverflow and other sites is how you can count how many lines does a project have. I know it can be done with just one line under linux, but here’s a tool that can do even more: http://gitstats.sourceforge.net
See an example here – the stats for the linux kernel 2.6. Impressive isn’t it? You can get a history snapshot of the projects. It’s really cool!
2: Think about security
If you haven’t read this article called “How I hacked Github again”, please do. It contains a lot of interesting information
3: Discover what’s trending on Github today
If you want to discover what’s hot on GitHub based on your favorite language, follow this link: https://github.com/trending?l=javascript (just s/javascript/[your favorite language]/).
If you are eager to see more stats from GitHub and to play with some Big Data follow this link and have fun. You can try this one as well. It’s all about visualization.
Summary
Github Issues is getting better and better after every release. Using visual feedback tools like Usersnap and knowing more about the system will make you more efficient while having fun!
This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.
Resolve issues faster with visual bug reporting.
Simplify and reduce issue & bug reporting efforts with screen recordings, screenshots, and annotations.
And if you’re ready to try out a visual bug tracking and feedback solution, Usersnap offers a free trial. Sign up today or book a demo with our feedback specialists.