Contributing to freeCodeCamp

Contribution Workflow

The contribution guidelines for freeCodeCamp can be found here.

Very welcoming of new contributors
Getting started with freeCodeCamp was actually pretty daunting because of its large code base and complicated steps to get all of its dependencies installed. However, since the documentation is very detailed, it is actually easy to start contributing. In addition, the community is generally very welcoming of new contributors. Many issues are tagged with help wanted and first-timer-only, which help contributors to identify issues that they can work on. There is also a contributor chat room for contributors to seek help. In addition, freeCodeCamp also provides a short description for the issue labels in this article, which is helpful for new contributors.
Useful template for issue and pull request description
Submitting an issue or pull request is also made easy with the template provided in the description box. The template serves as a guideline as to what to include when posting an issue or pull request. This makes it less daunting for first timer to make their first contribution, and also easier for moderators to review the pull request.
Single commit per pull request
Another interesting observation is that in freeCodeCamp, a pull request should only have a single commit. This will certainly make the commit history very clean but it comes with the downside that a big pull request could be difficult to review.

No detail is too small
Certain things that are considered minor like typos are often ignored and can pile up and actually be quite substantial and affect the user experience greatly. In freeCodeCamp, the moderators are not only welcoming of minor fixes, they are also very attentive to details such that a single missing space could get your pull requests blocked.
Be open to suggestions (both giving and accepting)
The best thing about open source is everybody pull their ideas together to create something greater.

Use help wanted or first-timers label
Currently, there is a d.FirstTimers label but it is rarely used. Creating and using these tags more often can make PowerPointLabs looks more welcoming of new contributors.
Open a public chat room for contributors
Currently, PowerPointLabs uses Slack for communication within the team. This means that public contributors have no avenue to seek help which may deter them from contributing.
Provide a template for issue and pull request
Having a template can ensure our issue and pull request include the neccessary information. A fixed style of description also makes it easier and faster to understand each issue and pull request.

Organize documentation so that information for contributors can be found in one place
Some of the information for contributors is in the github repo while some is in the forum. Putting all these information in one place or even create an indexing can make it easier for contributors to search for all these information. It also reduces the need for moderators to direct contributors to the appropriate place to look for the information everytime a new contributor joins the community.
Use squash when merging pull request instead of enforcing the one commit rule
Using the squash option when merging can achieve the same thing as enforcing one commit per pull request.