This Dashboard has been designed to be remotely easily managed by a group of co-learner through a public repository on GitHub. We intend to use Git as distributed a free and open source control system designed to handle everything from small community task to very large projects with speed and efficiency. If you currently do not know how to use Git (but we hope you can learn with us soon) the easiest way to have the latest version of the dashboard is directly download the .zip file on your device and open the page index.html in your browser.

The easiest way to get started would be to join one of our weekly hangouts. And for a quick view of the project's current priorities, please read the Distributed Roadmap page in the Peeragogy Handbook. Don't feel that you've got to read the whole handbook before jumping in. But, if you find a part you think you can improve, that's awesome.

If you want to hack and learning by doing Git and work directly from the Git command prompt.

The main difficulty with describing how to contribute to a project is that there are a huge number of variations on how it’s done. Because Git is very flexible, people can and do work together in many ways, and it’s problematic to describe how you should contribute – every project is a bit different. Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method.
The first variable is active contributor count – how many users will actively contributing code to this project, and how often? In many instances, we’ll have only one developers with a few commits a day, or possibly less. This is important because with more and more developers, we'll run into more issues with making sure the code applies cleanly and easily merged. Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied. How can we keep our code consistently up to date and your commits valid?
The next issue is your commit access. The workflow required in order to contribute to a project is much different if you have write access to the project than if you don’t. If you don’t have write access, how does the project prefer to accept contributed work? Does it even have a policy? How much work are you contributing at a time? How often do you contribute?
All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. We’ll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples.

Welcome aboard!!