How to participate in a GitHub open source project

In the recent year, open source projects are particularly hot, many technical conferences or forums are open source projects as the theme of the discussion, it is a trend. and GitHub as a well-known custodian of open source projects, no one knows, more and more individuals and companies have joined the large family of GitHub, for open source to do a humble effort. For individuals, the hosting of your project on GitHub does not mean that you are involved in the GitHub open source project, but that you open up your own projects and can download them freely.

So how do you get involved in GitHub's open source projects? I believe many people have this question, there are some uneven tutorials on the internet to teach you how to "pull Request", How to "Commit" and so on. But these tutorials are often not comprehensive enough or not fully correct, and getting you into a wrong way can be confusing. In view of this, the official GitHub team wrote a great article a few days ago contributing to open source on GitHub, which specializes in how to participate in GitHub's open source projects. Here is the translation of the original text.

The best way to participate in an open source project is to join the existing project you are using. There are more than 5 million open source projects on GitHub that involve technologies in various fields, like recipes, Html/css, Ruby, astrophysics, and so on. The guide will cover what you might be doing in a typical project and how to contribute to open source projects.

Find a Project

We recommend that you start with items that are already in use or are of interest. Here are a few great places for your reference:

• GitHub Explore: Popular and popular items.
  

• GitHub Stars: Projects that are by other people's star (referring to your own library).
  

• GitHub showcases: A way to search for related libraries.
  

• Layervault News: Front-end and design-related projects.
  

A typical project

Here are some of the factors you might encounter in the GitHub open source project.

The Community (community)

Projects typically have a community maintenance, consisting of other users of different roles (formal or informal):

• Owner: The user or organization that created the project and had the project on their GitHub account.
  

• Maintainers and collaborators (Maintainers and collaborators): Users who are committed to a project and contribute to the development of the project. Usually the owner and maintainer are the same user or organization, and they have write permissions to the project library.
  

• Contributor (Contributors): Each user who sends a pull request to the project and merges it into the project is a contributor.
  

• Community member (Community members): Users who frequently use and are very concerned about the project, are very active in discussing feature features and pull request.

The Docs (documentation)

Files that are present in the general project.

• Readme: almost all GitHub projects include a readme.md file. The Readme provides an overview of the project and details on how to use, build, and even contribute to a project.

• Contributing: project and Project maintainers are different, so the best way to contribute to each project will vary. Be sure to note that a document labeled contributing, the contributing document describes in detail the specifications that a maintainer of a project would like to see contributed patches or features should meet. This may contain areas to write what tests, code syntax specifications, or patch sets.

• License: A license file is, of course, a license to the project. A license of an open source project will tell the user what they can and cannot do (e.g. use, modify, republish), and tell the contributors what they allow others to do. There are many ways to add a license to an open source project, and you can read more about each license in choosealicense.com.

• documentation and Wikis: many large projects have not only one readme to guide people how to use their projects. In this case, you can usually find a link to another file or folder named "Docs" in the library.

In addition, the library may use GitHub wikis instead of documents.

Contribute to a project

Now that you have found the relevant information to understand the project, you can take some action below.

Create a topic

If you find a bug in the project you're working on (but you don't know how to fix it), or have a problem with the document or have questions about the project-then create a topic! It's very easy and generally you don't have to be the only person who has the problem, so other people might find your topic helpful. For more information about the topic, please check out our issues guide .

Topic Professional Tips

• Check the topic before the topic is under construction: the topic repeats no benefit to both parties, so search the entire open and closed topic to check if the problem you're having has been solved.
  

• Be sure to have a clear picture of your problems: what are the expected results? But what happened? Describe in detail how other people reproduce the problem.

• Reproduce the problem on a similar platform like Jsfiddle or Codepen and give the link to the demo of the problem.
  

• Contains some system-related details, such as what browser, library, or operating system and version number are used.
  

• Put your error output or log on your topic or in the gist. If posted in the topic, please surround it with three anti-quotes so that it ``` can be well presented to you.

Pull Request

If you can fix bugs or add features yourself-great, please send a pull request! Make sure you have read any documentation about contributing and need to understand license and have already signed the CLA (if needed). Once you have submitted a pull request, the maintainer will compare your branch to the existing branch to decide whether to merge (that is, pull in) your changes.

Pull Request Professional Tips

• Fork the project library and clone it locally. Connect locally to the original ' upstream ' library by adding a remote way. Always change from ' upstream ' to keep the library up-to-date so that when you submit pull request, there is little likelihood of a merge conflict. Click here to see more guidance details.
  

• Create a separate branch for your edits.

• Be sure to be aware of the problems that arise and how to reproduce the problem or why your feature is helpful. Then the same should be understood to make some changes to what steps.
  

• It's better to test it. Run your changes on any existing tests (if they exist) and create new tests if necessary. Regardless of whether the test is not present, make sure that your changes do not break the existing project.
  

• If your changes include HTML/CSS, please include the changes before and after the change. Drag and drop your picture into the body of your pull request.
  

• Do your best to do more in the style of the project. This may mean using indents, semicolons, or annotations that are different from your own GitHub library, but this makes it easier for maintainers to merge and make it easier for others to understand and maintain later.

Open Pull Requests

Once you open a pull request, there will be a discussion about the changes you have made. Other contributors and users may be involved, but ultimately the maintainer decides. You may be asked to make some changes to your pull request, and if so, add more commits to your branch and push them-they will automatically be added to the existing pull request.

If your pull request is merged-that's great! If not, it's not a big deal, maybe it's not the change the project maintainers expect to see, or they're already working on the bug or feature. This can happen, so our advice is to give feedback on the results received, make further efforts and then pull the request out again-or create your own open source project.

How to participate in a GitHub open source project