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
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.
Below are some basic steps to get you started with the Learn Programming Mentoring Community
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.
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:
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.
The LearnProgramming Mentoring Community (LPMC) is structured in the following way:
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.
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.
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.
These 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.
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.
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.
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.
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.
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.
Unless there is a compelling reason to do otherwise, all LPMC projects should use the SemVer standard of versioning.
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.
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.
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.
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.
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
For a list of current projects, visit LearnProgramming on Github