FOSSASIA Google Code-In Website 2018 https://gci18.fossasia.org
This is the repository for Fossasia's website for Google Code-In 2018, we at Fossasia intend to develop it collaboratively during the course of this competition by participating students themselves. Fork the repository before making changes and make sure you read Fossasia Best Practices
- All pull requests need to be associated to an issue.
- All PRs need to be assigned to the person working on it.
- If an issue cannot be completed in less than a day, it should be broken up into multiple issues.
- Make pull requests from your own forks (even if you have write rights to the repository, do not create new branches, develop on your own branches).
- State the actual change or enhancement in the commit message of PRs (do not just state “Fixes issue #123”).
- Add the issue number into the description (this helps to speed up reviews as reviewers can simply click to get more info in the issue itself).
- Write clear meaningful git commit messages (Do read http://chris.beams.io/posts/git-commit/).
- Match pull requests with issues and make sure your pull requests description contains GitHub’s special keyword references that automatically close the related issue when the pull request is merged. (More info at https://github.com/blog/1506-closing-issues-via-pull-requests).
- When you make very minor changes to a pull request of yours (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterwards so that you don’t have an absurd number of commits for a very small fix (Learn how to squash at https://davidwalsh.name/squash-commits-git).
- Add a screenshot if you changed anything in the UI of a project. When you’re submitting a pull request for a UI-related issue, please add a screenshot of your change or a link to a deployment where it can be tested out along with your pull request. It makes it much easier for the reviewers and helps to speed up the process. You’ll also get reviews quicker.
- Add a link to your deployment of the project, where reviewers can check out what you have changed (especially for smaller changes this is very helpful as the reviewer might not even need to set up the system itself and test it. Again this speeds up the review process a lot).
- Always ensure CI and tests are successful.
- Help to resolve merge conflicts (especially if there are several PRs at the same time, merge conflicts are common. Help the reviewers and solve merge conflicts to speed up the process.).
- Merging Pull Requests should only happen if at least two contributors reviewed the PR and approved it.