We want to encourage all students to get involved with the development of this course. The materials here are mostly developed and curated by the staff team but we admit that we may miss things, or occationally get them wrong. We've put together some guidelines that should help you get started with making contributions.
Thanks for helping improve this course for everyone!
If you've got a question or problem that you think others may have, then please read this first.
The GitHub issue tracker is our preferred channel for dealing with these questions. It keeps questions public and allows others to pitch in with potential solutions, it also means everything is documented for the future. This should not be used for personal questions or issues unfit for public discussion, in those instances we encourage you to email the member of staff responsible for this course.
Before submitting a new issue, use the GitHub search to see if it has already been submitted before. If it hasn't, then go ahead and create a new one. When creating a new issue, please spend some time creating an identifiable and specific title, then provide as much detail as possible in the main description.
Examples of bad titles:
- Problem with lab material for this week
- Question about the course
- Just a thought...
- Can't compile lab 4
Examples of good titles:
- Lecture 4 broken recommended reading link
- Assignment 3 submission of 30th Feburary is incorrect
- Lab 4 main.c stack overflow exception
Contributions are so greatfully received. If you've noticed an error, or would like to add additional resources then please use a pull request. To ensure your pull request is accepted as quickly as possible, please take a moment to check the following guidelines. Once a pull request has been submitted, it can be reviewed by fellow students and staff. When a staff member things it looks good, it'll be accepted and merged in.
- Ensure any added resources are properly cited like similar material. This may be adding a link to the resource on a slide, or appending a full citation to an assignment.
- If you're updating / correcting statistics then please provide a link to resources you used in your PR so we can ensure they're reliable.
Please squash your commits into either one, or a few well seperated commits. It's important that commits be atomic to keep the history clean. Below is a short guide on squashing commits into a clean history. Please read through and follow Chris Beams's - How to write a git commit message.
- Run
git log --oneline master..your-branch-name | wc -lto see how many commits there are on your branch. - Run
git rebase -i HEAD~#where # is the number of commits you have done on your branch. - Use the interactive rebase to edit your history. Unless you have good reason to keep more than one commit, it is best to mark the first commit with 'r' (reword) and the others with 's' (squash). This lets you keep the first commit only, but change the message.