Skip to content

Latest commit

 

History

History
129 lines (86 loc) · 5.46 KB

CONTRIBUTING.md

File metadata and controls

129 lines (86 loc) · 5.46 KB
Raw

Contributing to ng2-semantic-ui

Your contribution will be greatly appreciated, and will help ng2-semantic-ui get even better! As a contributor, here are the guidelines to follow:

Code of Conduct

Please read and follow the Code of Conduct.

Bug, Question or Problem?

For any usage questions you have, you can join Gitter to ask for help.

If you've found a bug, please submit an issue. Even better would be submitting a Pull Request with a fix.

Missing a Feature?

You can request a new feature by submitting an issue to the GitHub Repository. If you would like to implement a new feature, please submit an issue with a proposal for your work first, to be sure that it can be used. Please consider what kind of change it is:

  • For a Major Feature, first open an issue and outline your proposal so that it can be discussed. This will also allow better coordination of efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
  • Small Features can be crafted and directly submitted as a Pull Request.

Submission Guidelines

Submitting an Issue

Before you submit an issue, please search the issue tracker, as an issue for your problem may already exist and the discussion might inform you of readily available workarounds.

Ideally all issues are fixed as soon as possible, but before that can be done the bug must be confirmed. This is done by providing a minimal reproduction scenario using http://plunkr.co. You can fork the ng2-semantic-ui plunkr starter and use it as a starting point. Having a live, reproducible scenario provides a wealth of important information without needing to go back & forth to you with additional queries such as:

  • Angular version used
  • ng2-semantic-ui version used
  • 3rd-party libraries used, if any
  • Most importantly - a use-case that fails

A minimal reproduce scenario using http://plunkr.co allows quick confirmation of a bug (or coding problem) and also confirms that the right problem is being fixed. Issues filed that do not include this (or a standalone git repository demonstrating the problem) won't be looked at until they do.

You can file new issues by filling out the issue form.

Submitting a Pull Request

Before submitting a Pull Request (PR) consider the following guidelines:

  • Search the Github pull requests for an open or closed PR relating to your submission (to avoid duplicating effort).

  • Fork a copy of the repository to your own Github account - see Github guide

  • Make your changes in a new git branch:

    $ git checkout -b my-fix-branch master

  • Create your patch

  • Follow the Coding Rules, running the linter (npm run lint) to catch any errors

  • Commit your changes using a descriptive commit message that follows the commit message conventions

  • Push your branch to GitHub:

    $ git push origin my-fix-branch

  • In GitHub, send a pull request to ng2-semantic-ui:master

    • Create a new pull request
    • Select compare across forks
    • Set your repo and fix branch as the head fork to compare.

  • If changes are suggested:

    • Make the required updates
    • Ensure the changes follow the coding rules
    • Push your changes to GitHub.

Coding Rules

This project uses tslint to maintain a consistent code style. You can run npm run lint in the project directory to lint the code.

The primary rules followed by this library are:

  • 4 space indentation
  • Double quotes (") rather than single quotes (')
  • No whitespace for type definitions (e.g. example:string)
  • PascalCase for class names, interfaces & exported constants
    • Interfaces prefixed with I
  • camelCase for local variables (const)
    • Private fields prefixed with _
  • Label all class members with modifiers (including public)
  • Class member ordering, first to last:
    • static fields, instance fields, constructor, static methods, instance methods

Commit Messages

To maintain readability and easy understanding of commits, all messages (excluding body) should be of the format:

<type>(<scope>): <subject>

The scope is optional, if the commit addresses multiple things. Please try to keep messages under 100 characters.

Type

Must be one of the following:

  • chore: Changes to build scripts
  • docs: Changes to the documentation
  • demo: Changes to the demo app (that don't include updated documentation)
  • feat: New feature
  • fix: Bug fix
  • refactor: Code change that neither fixes a bug nor adds a feature
  • style: Changes that don't affect the code's meaning (formatting etc.)
  • test: Adding / updating tests

Scope

Scope is generally the name of the component that is being changed. If a commit affects multiple components, then omit the scope, and add it to the message body.