Skip to content

Latest commit

 

History

History
82 lines (55 loc) · 5.82 KB

CONTRIBUTING.md

File metadata and controls

82 lines (55 loc) · 5.82 KB
Raw

Contributing to Wink

Thank you for taking time to contribute. We are delighted to receive contributions from the community. For wink every contribution matters — whether you are reporting a bug, posting a question, submitting a pull request or updating the documentation.

Getting Started

  1. Fork the repository from github
  2. Develop your code changes
  3. Ensure that the API is properly documented
  4. Capture the logic in comments
  5. Ensure proper linting via npm run pretest
  6. Run tests using npm run test
  7. Make sure coverage either stays at the current levels or improves
  8. Commit your changes in compliance with commit guidelines
  9. Push to your fork
  10. Sign the CLA if you are contributing for the first time
  11. Finally, submit a pull request.

Code of Conduct

By contributing, you are expected to uphold wink’s code of conduct. In essence, each one of us should:

  1. respect fellow contributors, irrespective of their level of experience, race, religion, gender, sexual orientation, and age;
  2. collaborate constructively;
  3. never engage in any form of offense, harassment, insult, personal attack, provocation and/or use of inappropriate language;

Things to know

About Wink

Wink is a growing open source project focusing on Natural Language Processing, Machine Learning and Statistics. It contains multiple repositories or packages. All packages expose consistent and uniform APIs, thus minimizing the need to learn a new interface for each task. Do take out some time in understanding the structure of APIs, before attempting any enhancements. In wink, we prefer functions and closures over objects.

Like artisans, we too need a toolset and process to create beautiful software. The process is orchestrated by Travis CI in accordance to the configuration files present in each repository. The details and tools used are outlined below.

Linting

Well defined linting rules helps us in making code more consistent and avoid bugs. ESLint enforces these rules via its configuration file. This file is located in the root of each repository.

Documenting

We believe that the documentation must not only explain the API but also narrate the story of logic, algorithms and references used. Wink uses the JSDoc standard for API documentation and Literate-Programming Standards for documenting the logic using docker. The API documentation quality is measured using Inch CI and we expect that your contribution will improve or maintain the current levels.

Testing

Wink requires a test coverage of atleast > 99.5% and aims for 100%. Any new contribution must maintain the existing test coverage level. We use Chai, Mocha and Istanbul, Coveralls to run tests and determine coverage.

Committing

We follow commit guidelines from the Google's Angular Project, whose documentation is licensed under CC BY 4.0. See important excerpts for quick reference below:

Commit Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional. Any line of the commit message should not be longer 100 characters!

Type should be one of the following:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
  • revert: when you have to revert to an older commit. Ths subject should be the header of old commit and body should contain This reverts commit <hash>. Use git revert command to accomplish this.

Scope specifies the place of the commit change. You can use * when the change affects more than a single scope.

Subject must contain a crisp description of the change and it must (a) use the imperative, present tense: "change" not "changed" nor "changes", (b) not capitalize the first letter, and (c) not use period (.) at the end.

Body just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change.

Footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit closes. Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Contributor License Agreement (CLA)

The CLA is for your protection as well as the protection of GRAYPE and it’s licensees; it does not change your rights to use your own Contributions for any other purpose. Our CLA is a short and easy to understand agreement and can be signed using a simple click-through form. Please sign our Contributor License Agreement (CLA) before sending pull requests. It's a quick process, we promise!