The developers of MarkUs use GitHub’s issue tracking system to handle all the bugs floating around our application. It is a very useful system for maintaining current and old bugs, requests for new features and represents the overall state and goals of MarkUs.
Unfortunately, our users do not have the chance to see this unless they try hunting it down themselves. I’m currently working on a feature to point our users to our bug tracker, providing them with easy access to the ability to view and report bugs at their convenience. Here is some sample UI that I’m brainstorming. I’ve come up with some rough drafts of UI that I will most likely use.
I’d like to add an icon that is placed in the header, providing users with access to it no matter which page they are viewing.
Once the icon is clicked, a modal dialog will open, disabling the rest of the webpage. The user will see the following options.
View current issues will point to the bug tracker. Reporting a new issue will point them to a blank issue form and requesting a new feature/enhancement will point to the same form but with the RFE label set already. All of these links will open new tabs and redirect to our tracker accordingly.
In order to file issues, you will need to have a GitHub account. Users might not be bothered to sign up (or even sign in), making this feature practically useless to them. Unfortunately, there is not much we can do with our given resources. Forcing them to use our tracker will help keep things centralized and in one place, rather than setting up some kind of form that sends out emails to mailing lists with the given bugs. Fortunately, the links redirect to logging in or creating a new account and then redirect back once done. If the user is willing to follow through, the login process is just a small, extra step and places the user back on track.
Another issue is the potential increase in duplicate bugs. Some people do not have time to read through our current issues and may just jump straight to reporting one. This is not too disruptive but adds to a teadious process for developers now having to close duplicate issues. I am hoping that the “View current issues” link will nudge users in that direction first but that will not always happen.
Finally, some issues are not in the application but in the way it was setup. These need to be directed to the course admin rather than to us. However, this is not always obvious so adding this feature might also cause an overflow of unnecessary bugs. This can be avoided by only displaying the links in the dialog when the user is an admin. When a grader or student is logged in, perhaps a simple message telling them to contact their course administrator/instructor might suffice.
This is what I have come up with but I am open to suggestions, please nitpick, modify and comment away!