Skip to content

Latest commit

 

History

History
112 lines (82 loc) · 3.75 KB

background-bugs.md

File metadata and controls

112 lines (82 loc) · 3.75 KB

Feedback on Coursework

Bugs, questions and suggestions

This coursework is in its second year, though others will be new this year. The previous years students were very helpful, and we fixed a lot of bugs. However, other may remain. That is fine, and some level of imperfction is fine - you are all masters-level students.

Typical types of feedback I'm interested in on this (and all courseworks) are:

  • Questions: if something in the instructions is unclear, then it might be me who hasn't explained it well.

  • Bugs: there are likely to be parts of the specification or code that are flat-out wrong. Usually it will be obvious what I meant (e.g. typos in function names), but it is good to fix them.

  • Suggestions: sometimes there are better ways of explaining something, or helpful suggestions for making things work on particular platforms. It is good to share.

There are certain types of feedback I'm less interested in, specifically:

  • "This is too hard" : The first four courseworks are designed to encourage learning, not measure it. As a consequence, if you find it hard, that means there is something you really need to learn for the final two courseworks.

  • "This is too easy" : Some people will find one, or possibly all, of the first four courseworks quite easy. Beware - if you are able to rattle though the coding, it may mean you are not picking up some of the deeper concepts. Or maybe it is all too easy - good for you.

  • "This takes too long" : The first four courseworks are instructional, and will require many people to read things, look stuff up, and learn some new skills. The coursework is the learning, which includes both the actual time spent typing, but also the time spent learning new skills. That said, I have streamlined certain tasks for this year.

How to report a problem

In order of preference, your options are:

  1. Pull requests: If you know what the problem is, and know how to fix it, pull requests are greatly appreciated (don't worry if you don't know what that means).

  2. File an issue: you can report problems or ask questions on the issues page. This allows everyone to see it, so everyone can benefit.

  3. Ask me: asking questions in/after lectures is a good way of checking simple things.

The reason for emphasising the first two methods is that it is easier to manage, and everyone benefits from the updates. A reason I don't list email is because the first two methods will automatically email me anyway, but unlike an email othe people can see that the question has been asked (and may be able to answer it before me).

Bug reports and fixes are an important professional activity, so wherever possible I will attribute improvements to the people who suggest them.

When reporting bugs or asking questions, please think carefully about what you are asking, and make the context clear. Any questions which look like the following (all of which reflect single-sentence emails I've received in the past) will be pretty much ignored.

  • "It isn't clear what to do in exercise E3.1."

  • "Function X doesn't work. Is it broken?"

  • "My program crashes. Do you know why?"

  • "How fast should my function Y be?"

Please make sure that you have included enough context for someone else to help you, such as:

  • What were you trying to do?

  • What did you expect to happen?

  • What happened instead?

  • Were there any error messages?

  • What possible fixes have you already tried?

Not all of these will be appropriate in all circumstances, so use your discretion. A longer former discussion is How to Report Bugs Effectively