You're probably looking at this page because you've clicked on the
learn how to report errors button on our website. Or you were just browsing the wiki here on our GitHub project. Either way: if you're new to GitHub and want to report something that is wrong with the S.A. Proto website, but are unsure what to do, you'll want to continue reading!
Suppose something is wrong with the website. Either it doesn't do what it's supposed to, it throws you an error in your face or there's something you wish to see different. You'll probably want to notify us, the developers of the website, (you may also know us as the Have You Tried Turning It Off And On Again committee) of the issue.
If you've gotten an error page (the
Houston, we have a problem! page) chances are we have already been notified as part of an automated system. We will receive an e-mail and take on the problem as soon as we are able. Unless the error page specifically mentions the we have not been notified, you can stop reading here and go back to what you were doing.
So you are at the point where you want to tell the us something is wrong. You may be asking yourself: why can't I just send an e-mail? You could! But by sending an e-mail it is difficult for us to keep track of the multiple tasks we have to pick-up. Either e-mails clutter our e-mail box until we have dealt with or we archive them to keep our inbox clean and forget to get back to them.
By using a separate system (which GitHub calls Issues) to keep track of things we have to do, we can optimize our workflow. There's also benefits for you. You'll be kept updated on your issue more efficiently and on a central place. This is especially helpful if you report more than one thing. And in the end, we can get to your issue faster. The only thing we ask of you is that you create a GitHub account and take a little time creating your issue.
You can create an issue by logging in to your GitHub account and heading over to our issue tracker. There's a large green
New issue button. Click it. Everything you need to worry about is the title and the comment.
In the title field, please provide a clear and concise summary of your issue. It should phrase the gist of your issue in one sentence. Good examples areCan not subscribe to an activity while sign-up is still open, Error occurs while trying to upload profile picture and Not all committee members are shown on committee page. Bad examples are Website gives error, Can not load page or Website's broken.
In the comment field you'll describe your issue in more detail. It's called a comment because there can be multiple for one issue. If we find something, or need additional information, we'll be commenting on your issue, and you can then again reply with another comment. The first comment on an issue needs to contain every piece of information we may need to solve the problem. Please already provide all information you can. If you don't, chances are we'll have to ask you again and resolving your issue takes more time than necessary.
Things to include when you're reporting on an problem are:
Using this information, we will be able to reproduce your problem to get to the issue. If we cannot reproduce the problem, we cannot fix it. If you're reporting on feedback (or what we call a feature request or question) things are a little different. Please make sure we know everything we need to know to assess and eventually implement your issue.
Please see this note for feature proposals.
As soon as you create a new issue (or comment on an existing one) we'll be notified via several channels. There's no need to send an e-mail stating that you've created an issue. Usually within a few hours we'll take a first look at your issue. We'll assign them to labels and a milestone, and wherever possible, already to one of the developers. You can see all of this on the right if your newly created issue. This will give you an indication of the status your issue. Any status change, or comment from us, will likely result in an e-mail from GitHub. This way you'll stay up to date on your issue!
At some point we will fix your issue. Usually this will be via a commit, or an update of the website code. You can see this update in your issue. When an issue is fixed, it will be closed. Please be aware that even if the issue is closed, you can still add new comments or even re-open the issue.
Please note that issues may not be fixed directly, or even within a few weeks. We need to prioritize issues since we cannot attend to all of them directly (we're also just students volunteering their time for one of Proto's committees). We'll usually take on bug reports, server issues and hardware issues first, after which we'll focus on feature requests. We see every new issue and will eventually look at each one, but please understand that we also have a full-time study to focus on. :)
Due to the number of feature proposals we get, we need to prioritize feature proposals. We will assign the label
feature-proposal for new proposals. Unless the feature is immediately promoted by the Have You Tried Turning It Off And On Again committee or the board of S.A. Proto, you need to collect likes from the association in order to make your feature proposal stand out from the other proposals.
You can collect likes by having others “thumbs up” your issue (you can do this by clicking on the smiley next to the issue and selecting the thumbs up, you need to be logged in to GitHub to do this). For now, we will prioritize feature proposals when they reach 20 “thumbs up”. You can distinguish a feature proposal slated for implementation by the
If, after reading this, you still have questions about issue tracking via GitHub please do ask us via e-mail, or by joining our channel #hyttioaoac-public on the S.A. Proto Slack.