Skip to content
This repository has been archived by the owner on Oct 6, 2021. It is now read-only.

Latest commit

 

History

History
61 lines (37 loc) · 5.81 KB

CONTRIBUTING.md

File metadata and controls

61 lines (37 loc) · 5.81 KB
Raw

Contributing to Silacak

How to contribute

In this project, we are heavily utilising GitHub features to document and signal any progress in the website development.

Finding or creating issues

Most contributions start from defining issues. Anyone can open an issue for discussion. You can head to this link for deep understanding about Issues. Specifically, you can start finding several Issues in our Issues tab. There are only two categories in Issues section, Open and Closed.

Open Issues

Open Issues are issues that need more attention and need to be resolved. Contributors should pick any of the Open Issues and start working on them.

Closed Issues

Closed Issues are issues that have been completed or doesn't need further action. Closed issues can be reopened if contributors find any issues related to it sometime in the future.

Please pay attention on every issue attribute. Every issue might be referenced by other contributors through Linked Pull Requests. If an issue has a linked pull request, that means the issue is currently being handled. To avoid working on the same issue, contributors were strongly encouraged to submit a draft pull request first when they start working on an issue.

For Beginners: good first issue label

As mentioned here, good first issue is a label feature from GitHub which created to help beginner contributors in contributing to an open-source project. good first issue informed us about the difficulty level of an issue. This means that an issue with good first issue label suits perfectly for contributors that would like to have their first contribution to an open-source project.

How to find issues with good first issue label:

  1. The easiest way is to go into the github.com/<owner>/<repository>/contribute link. In this case, you can go into this link. That link will list all of the issues with the good first issue label.
  2. Another way is to head over into the Issues section of the repository, then click the Labels section beside Milestones. There you can see a lot of labels for the issues in the repository. Then find and click the good first issue label.

Start working on issues

Before working on an issue, there are a few things that you need to pay attention to:

  1. Is there any other contributors working on it? You can try to find any existing pull requests before deciding to start working on the issue.
  2. To start working on it, ensure that you create a new branch from the main branch, then commit and push your changes as soon as possible no matter how small they are.
  3. Then create a new pull request while marking it as a draft pull request to signal the other contributors that it's a work in progress. This is necessary to signal the other contributors that there are work in progress for that particular issue.

Utilising Draft Pull Requests for Communication

Draft Pull Requests is a feature provided by GitHub as a means to communicate with contributors. When we create a Draft Pull Request, we can't merge it until it's marked as Ready for review. This is a better approach to use as a communication tool between contributors, and we can provide information that we are currently working on an issue.

Steps to creating a Draft Pull Request:

  1. Commit and push your new changes into the remote repository.
  2. Head over to the Pull requests section on your forked repository, hit New pull request. Hint-1
  3. Pick your forked repository for the head repository, and compare with the branch that you are having changes in. Hint-2
  4. Put a title and some description in your pull request, then pick Create draft pull request (like in the image below) and hit the green button. Hint-3
  5. Don't forget to mark your Draft Pull Request as Ready for review after you commit all of the changes.

FAQ

Why are we using English in our issues & PRs?

There are several reasons we're using English while communicating in GitHub Issues & PRs:

  1. It's more natural for software engineers to communicate in English because it involves many technical terms in English. Trying to translate them into Bahasa Indonesia posing a risk of miscommunication, while keeping them in English requires us to do a lot of italic formatting, according to PUEBI.
  2. It accustoms the contributors, which are mostly Indonesian, to communicate in English. It is important to increase our English reading and writing skills because the vast majority of the global open-source communities are using Engish as the main language.
  3. It makes this project easier to be recognised globally. So if we need to get more support from the global communities, they could easily understand what we are doing and help us out with their access and competence. e.g., providing us free credits for their services, advocating us to global leaders, or contributing directly to our codebase.