-
Notifications
You must be signed in to change notification settings - Fork 33
Getting involved
This page is a strict sequel to Getting started. If you plan to contribute anything that goes into the repository (code, artwork, documentation) you have to take the Option 1: fork and clone path. It's also strongly recommended that you watch the repository so you'll get notified of new issues.
If you don't have a gut feeling yet for what this project is about, you might want to check out our philosophy, the homepage or the first few and last few posts of the forum thread.
Each of the sections below describes a way to get involved. The list isn't necessarily complete; if you find another way to get involved, please go ahead!
Simply by keeping the subject alive and sharing your enthousiasm, you can help to give the project additional momentum. There are two ways to be visibly present (apart from pushing something to the repository):
- Subscribe to http://forums.xkcd.com and join our thread.
- Join #redspider at irc.foonetic.net. Preferably log into the channel whenever your computer is on.
While using the software you may think of ways to make things better. Please let us know by filing an issue at the issue tracker. Always be as specific, as detailed and as complete as you can. See also Issues and milestones.
When you visit the issue tracker, there's a colourful list of tags in the left margin. If you click the green one that belongs to your platform (test-linux, test-osx or test-windows), you get a list of all issues where you can help out by testing something. Just read the issue thread to find out what has already been tested and what still needs to be checked. See also Issues and milestones and Testing.
We have a list of free ideas. You can try to implement one and push it to your fork. Before you start, check out our workflow guidelines.
Your ideas may inspire other participants even if you don't want to execute them yourself! See Communication channels.
Just branch from master, add your code and push to your fork (see Workflow).
If you're contributing code that you wrote previously and if that code wasn't written with platform-neutrality in mind, or if the contribution you're planning to make is very big, it's recommended that you post your intentions to the forum thread first. That way the others can help you make a plan.
Of course, communicating about your plans is always a good idea! See Communication channels.
Small contributions work best in practice. If you want to create something entirely new that is big, try to cut it into pieces first.
Meaning "two or more people working on the same branch in different forks of the repository during overlapping periods of time". See Workflow#collaboration. Consult GitHub Help for more information.
Somebody pushed a branch with a half-finished program to their fork... a year ago. That's frustrating for everyone involved, including the author. So if the author agrees, everyone will be grateful if you finish the job. See Workflow and the network graph for seemingly dead ends.
If you're working towards a concrete goal and you envision multiple concrete steps that need to be taken in order to reach that goal and a progress bar would seem appropriate, that calls for a milestone. This might for example be the case when you work on a relatively big plan. Only operators can create milestones, but if you're not an operator you can always write a description and ask an operator to create it for you. See Issues and milestones.
Warning: a big plan without all such concreteness can be very hard and take very long to complete. Try to do such things one piece at a time.