Skip to content

Latest commit

 

History

History
106 lines (67 loc) · 4.47 KB

CONTRIBUTION_GUIDELINES.md

File metadata and controls

106 lines (67 loc) · 4.47 KB
Raw

Contribution Guidelines

We appreciate all the contributors and authors for their effors an time towards mainting this project. All the contributors are strongly encouraged to read this section prior to making any contribution.

General Points

  1. We have a very license that allows any individual or organization to replicate the code or educational or commercial purpose. That said, it is mandatory to have a copy of license bearing the names of (all) the original authors. Authors can be found in the Authors.txt file.

  2. We don't accept plagiarized, cribbed, and duplicated codes from other repositories, blogs, tutorials, and websites. However, the contributors can submit the codes that are translated from other languages to Go, provided there are no compilation issues. Also, the reference should be included atop the file.

  3. We don't accept modified or refactored code snippets from other repositories.

  4. The authors and maintainers work very hard for maintaining the code quality to the highest possible standards. Therefore, we would urge the contributors to adhere to the guidelines mentioned in this section.

Code Guidelines

  1. Please write comprehensive and robust tests that cover the changes you've made in your work.

  2. Write readable code – keep functions small and modular and name variables descriptively.

  3. Document your code thoroughly to make it easier to read for a beginner.

  4. Make sure all the existing tests pass.

Making Pull requests and Issues

  • Pull requests

  1. Please create a separate branch for each issue that you're working on. Do not make changes to the default branch (e.g. master, develop) of your fork.

  2. Tag the actual issue number by replacing #[issue_number] e.g. #42. This closes the issue when your PR is merged.

  3. Tag the actual issue author by replacing @[author] e.g. @issue_author. This brings the reporter of the issue into the conversation.

  4. More information on how add description to your Pull request here

  • Issues

Using the issue tracker

The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests, but please respect the following restrictions:

  • Please do not use the issue tracker for personal support requests (use Stack Overflow or IRC).

  • Please do not derail or troll issues. Keep the discussion on topic and respect the opinions of others.

Bug reports

A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!

Guidelines for bug reports:

  1. Use the GitHub issue search — check if the issue has already been reported.

  2. Check if the issue has been fixed — try to reproduce it using the latest master or development branch in the repository.

  3. Isolate the problem — create a reduced test case and a live example.

A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs.

Example:

Short and descriptive example bug report title

A summary of the issue and the browser/OS environment in which it occurs. If suitable, include the steps required to reproduce the bug.

  1. This is the first step
  2. This is the second step
  3. Further steps, etc.

<url> - a link to the reduced test case

Any other information you want to share that is relevant to the issue being reported. This might include the lines of code that you have identified as causing the bug, and potential solutions (and your opinions on their merits).

Feature requests

Feature requests are welcome. But take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible.

Naming Conventions

Please refer to this blog for naming the files and folders.