Welcome to the LearnProgramming Mentoring Community on Github



LearnProgramming is an organization that grew out of the subreddit r/learnprogramming. Our aim is to provide a set of 'hackable' projects for beginners to contribute to in a open, encouraging atmosphere.

In many cases, it seems, new programmers feel daunted by the task of contributing to open source, they don't know what to do, how to write code that meets standards, or how to really contribute in an effective way to open source projects. This organization intends to provide a playground, staffed by the best and brightest self-elected members of the r/programming community, where the new open source contributor can cut their teeth; contributing to real projects used in the real world, without fear of reproach or denial due to their beginner status.



Frequently Asked Questions


Below are some basic steps to get you started with the Learn Programming Mentoring Community

  1. Learn how to use Git with GitHub. We suggest the following resources:

  2. Once you've familiarized yourself with git and github, fork the standards-and-practices repo and add yourself to members.md

  3. After adding yourself to the list you can submit a Pull Request back to the LPMC standards-and-practices repo

  4. At this point you should be familiar with the basic processes required to fork the projects you want to contribute to as well as requesting that code be pulled back to the project. All that is left now is to pick a project you want to work on and get started.

If you need help with any of the steps in this process, choosing or working on these projects, learning the languages, etc. feel free to contact any of the project leaders or mentors listed on the LPMC member list. A link to this list is in the section titled "List of members"

We also strongly encourage our members to join the IRC channel #lpmc on freenode.net. It enables us to provide quick feedback to answer your questions and a place for you to interact with other members.

The Learn Programming Mentoring Community is meant for beginners as a good place to start and really the whole point of the LPMC. We have people who are experienced who can help mentor you through the projects and help anyone who has little or no experience get started. Any questions you have about the process you can ask in our subreddit at r/lpmc or you can visit the IRC (internet relay chat) we have on freenode.net at #lpmc. We have various projects in different languages that are meant to be entry points for anyone to join in with. Some tasks will be easy for beginners and others will scale the difficulty up to give everyone a challenge.

For information on getting started please see the FAQ sections "What do I do if I'm new?" followed by "How do I start contributing?"
Most projects will have a list of needed updates, features, and bugfixes either in the issues for the project or listed as a todo item itself in the code. Have a look at the project you're interested in and see if you can implement those changes. If there is nothing listed but you want to add something or have found a bug, feel free to fork the project and add your updates. Once you're done, just submit your pull request back to the project.

Run the following commands in Git to update your local repository:

# Fetches any new changes from the original repo
git fetch upstream
# Merges any changes fetched into your working files
git merge upstream/master

If you are prompted to resolve merge conflicts, try the following command:

git mergetool

You can also consult the Git User's Manual - Resolving a Merge

After your repository has been updated, you can submit a pull request to merge your changes with the official project.

For basic git information and a walk through tutorial, checkout learn.github.

For an interactive tutorial on using git, try Code School - Try Git.

View the most recent list of members here LPMC Members list. Feel free to contact any of the mentors and/or project leaders if you have any questions regarding the LPMC or OSS projects.
For a list of FAQ and the most up to date info on LPMC, be sure to check out the wiki at /r/lpmc/wiki/index



General structure of the LearnProgramming Mentoring Community

Levels of Participation


The LearnProgramming Mentoring Community (LPMC) is structured in the following way:

1. Learners

These are programmers with little experience in contributing to OSS projects, though they may have prior experience programming. The primary goal of the LPMC for these individuals is to give a 'safe' place to contribute, without fear of out-of-hand rejection or any sort of ridicule. The primary interaction a learner has with the LPMC is through fork/pull requests. By the nature of the LPMC, the commit bit is only given out sparingly; since we want to encourage code review and learning-through-iteration.

2. Associates

These are former learners who have acheieved some degree of expertise on certain projects, and have demonstrated a consistent ability to contribute good code. Associates are, essentially, "graduated" Learners. They are thus introduced to new responsibilities and opportunities. In particular, for the projects they have demonstrated the most contributions too, they may be given the commit bit, and given the opportunity to review and accept/reject pull requests. Mentors are still responsible for doing the final merge for new associates, but over time the associate is given full pull-request administration duties.

3. Mentors

These are associates who have demonstrated through continued service to the LPMC that they have learned excellent FOSS development and contribution skills. They are intimately familiar with many, if not all, of the projects, and have shown themselves to be highly valued members of the LPMC. As with Associate status, these individuals are granted, for their efforts, more responsibility. They are given full access to merge any pull requests on any project.

4. Project Leaders

Thesea are mentors who demonstrate considerably deep knowledge about a given project. They are responsible for guiding the future of a project with their fellow Project Leaders. In particular, they are the ones who act as "Maintainers" in the traditional sense of the word. They may decide amongst themselves in the context of each project how best to guide it's development. Though it is the opinion of this document that they should favor a small, odd number of Project Leaders per project, and use a simple-majority voting system.

5. Chief Mentors

The Chief Mentors are a group of five individuals who have demonstrated dedication and skill within the community. They are elected from the group of mentors by all members of the community who are associates and up, and serve for life. These five people are responsible for the 'back-end' administrative tasks dealing with the Github organization, website administration, and similar. Otherwise, they are exactly Mentors. Over time, the number of Chief Mentors may increase to any odd number. This is to facilitate avoidance of ties in any votes they may need to take.

Filling multiple positions

Each individual may serve in multiple roles. Generally, if you are a Mentor, it is better to take the role of Learner in a project with which you are not familiar. Similarly, a Project Leader may be Project Leader of more than one (especially related) project.

Regarding Votes

In general, when a vote for some change is called for, it is a vote of all LPMC members _except_ Learners. The reasoning is thus. While any opinion from any Learner is valued and should be heard, it is the case that they are coming to this project with necessarily less contribution, and perhaps less knowledge, then any other member. To that end, it is more appropriate to allow those who have demonstrated contribution to be the decisionmakers, than it is to allow every learner to vote. On top of that, it is much more difficult to manage ensuring the veracity of every one of the (hopefully) many learner's identitys, so this allows some degree of assurance that people vote only once.

Actions of the Chief Mentors

Any action deemed 'controversial' by the Chief Mentors should be put to a vote. Over time, a list of known 'controversial' actions should be formed. An example may be the foreclosure of a dead project, the re-naming of a repo, etc. Essentially, any 'breaking change' on the level of administrative tasks (crucially, _not_ breaking changes in the feature of any project), should be put to a simple majority vote of the Chief Mentors.

Regarding Breaking Changes

Non-backwards compatible changes should be at the discretion of the project leaders. Often, when the breaking change is controversial, this document encourages the Project Leaders to put the decision to a vote of all contributors to the project.

Regarding Versioning

Unless there is a compelling reason to do otherwise, all LPMC projects should use the [SemVer](#) standard of versioning.

Regarding Design

Design and future direction, features, etc are to be managed by the Project Leaders in a way they see fit. All community members are encouraged to contribute to future feature ideas using the issue-tracker for the project, or other facility the Project Leader may have in place.

Regarding Design by Committee

In general, most decisions of a project are made by it's Project Leaders, and voting on features should only happen rarely, and ideally not make it past the Project Leaders. This document provides for community voting as a last resort, but such things are discouraged, as continued use is essentially design-by-committee, which is a recipe for disaster.

Regarding this document

Though it is written in a formal tone, this document should be taken informally in most respects except for regarding the ranking structure in "Levels of Participation" above. The only truly important thing this document does do and should be regarded is set up an ideal structure which we can all aim to implement. This document can and should be changed through pull requests, which should only be approved by the Chief Mentors after discussion and a vote.

Regarding the standards-and-practices repo

In general, this repo is administrated directly by the Chief Mentors, though as with all repos, everyone is encouraged to make pull requests regarding policy changes to it, or -- if they feel they cannot write the policy change appropriately -- to file an issue with a description of their suggestion which may then be crafted into a properly worded pull request. As with all LPMC repos, Pull Request rejection should always be paired with explanation as to why it was rejected, and -- if applicable -- what could be done to improve it for potential later acceptance.


How do I join?


1. Create an account on Github
If you already have one skip to step 2

2. Fork the standards-and-practices repo and add yourself onto the members list.

3. Commit your changes and do a Pull Request from your repo to the LPMC. We'll merge the request there after.

4. That's it! Welcome to the Learn Programming Mentoring Community.

Feel free to fork any of the projects below and get started. If you have any questions, message one of the mentors, visit us in our IRC channel #lpmc on freenode.net, or post it in our subreddit at r/lpmc. We will respond as soon as we can.

If you do not have a IRC client you can use the webchat client for freenode.net at Webchat IRC

Current Projects


For a list of current projects, visit LearnProgramming on Github