If you're reading this then you've already made a GitHub account and I've added you to the list of repository contributors! Great Job!
As a project contributor, you can:
Create, assign and follow issues created with the issue tracker.
Clone, Send a "Pull Request" and Fork this repository.
Create pages in this repository's Wiki
Pretty neat right? So what does all that mean?
Issues
Issues are the main way that we'll be tracking bugs and following who's working on what, when.
There are 8 different types of issues, here's a quick rundown:
information (orange)
Issues that are meant to be referenced by others for information, like this one!
bug (red)
Things that need to be fixed that nobody is currently working on,
duplicate (pale blue)
If somebody submits an issue that already exists, then it's marked as a duplicate.
enhancement (blue)
Project features that would be nice to have that increase the value of the product.
in-progress (green)
When you're working on an issue, add this issue type to the issue and assign it to yourself.
invalid (black)
I don't think we'll ever need this, but it's there
question (purple)
If you're not sure about something, it's probably best to send and email. Try not to use this.
to-do (yellow)
Everything that needs to be done.
Issues can have more than one type at a time. Each issue will eventually have one "assignee", someone who is in charge of the future of that issue.
When an issue is complete and no longer relevant to the project, it MUST be closed by the assignee.
When writing an issue, use GitHub Markdown to stylize your issue body and make it more readable.
Contributing
To actually get your code on this repository, you should know a little bit about how Git works. I would suggest reading up on it (there're TONS of articles out there about how to effectively use GitHub). If you're having trouble getting started though I would suggest reading this article by Lauren Orsini.
Next I would recommend using the GitHub GUI application. It helps make things like fetching and merge conflicts a little more manageable. You can get it for Mac here and for Windows here.
You can also use the Git command line commands if that's more your style. You can get that for all platforms here.
One thing you should understand is that you should NEVER push broken code to the repository. What does that mean? If you're working on something and your tests are failing or it just plain doesn't work on your machine yet DO NOT push that code to the repository. If you do, other team members might fetch that broken code and make changes to it, only to find it doesn't work. Then they spend a time looking for what it was in their code that broke it only to realize it was broken right from the start!
Also if you are not using the GitHub GUI application, it is best-practice to fetch new code and rebase your local master onto this BEFORE pushing to the repository to avoid merge conflicts. If none of that made sense to you, don't worry. It's not you, it's me.
If you have any questions or uncertainties, ASK! :)
Using the Wiki
This is an area I have little experience in. To access the Wiki, click that little book icon you see off to your right. It should be there. Then you can just click that big green "New Page" button and create the new page using their text-editing tools.
Interesting Articles
Feel free to edit this issue and post general GitHub links as you learn more about how to use GitHub!
Getting Started
If you're reading this then you've already made a GitHub account and I've added you to the list of repository contributors! Great Job!
As a project contributor, you can:
Pretty neat right? So what does all that mean?
Issues
Issues are the main way that we'll be tracking bugs and following who's working on what, when.
There are 8 different types of issues, here's a quick rundown:
Issues can have more than one type at a time. Each issue will eventually have one "assignee", someone who is in charge of the future of that issue.
When an issue is complete and no longer relevant to the project, it MUST be closed by the assignee.
When writing an issue, use GitHub Markdown to stylize your issue body and make it more readable.
Contributing
To actually get your code on this repository, you should know a little bit about how Git works. I would suggest reading up on it (there're TONS of articles out there about how to effectively use GitHub). If you're having trouble getting started though I would suggest reading this article by Lauren Orsini.
Next I would recommend using the GitHub GUI application. It helps make things like fetching and merge conflicts a little more manageable. You can get it for Mac here and for Windows here.
You can also use the Git command line commands if that's more your style. You can get that for all platforms here.
One thing you should understand is that you should NEVER push broken code to the repository. What does that mean? If you're working on something and your tests are failing or it just plain doesn't work on your machine yet DO NOT push that code to the repository. If you do, other team members might fetch that broken code and make changes to it, only to find it doesn't work. Then they spend a time looking for what it was in their code that broke it only to realize it was broken right from the start!
Also if you are not using the GitHub GUI application, it is best-practice to fetch new code and rebase your local master onto this BEFORE pushing to the repository to avoid merge conflicts. If none of that made sense to you, don't worry. It's not you, it's me.
If you have any questions or uncertainties, ASK! :)
Using the Wiki
This is an area I have little experience in. To access the Wiki, click that little book icon you see off to your right. It should be there. Then you can just click that big green "New Page" button and create the new page using their text-editing tools.
Interesting Articles
Feel free to edit this issue and post general GitHub links as you learn more about how to use GitHub!
Team Collaboration With GitHub