1414-07-31

A Github Issues tip that will make your life easier and 4 GitHub tricks and facts

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:

5044f737-ec1e-4af5-ab52-1afaeafd1596

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.