Skip to content

Latest commit

 

History

History
183 lines (125 loc) · 9.05 KB

CONTRIBUTING.md

File metadata and controls

183 lines (125 loc) · 9.05 KB
Raw

Contributing

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

Here is how you can help

Table of contents:

Introduction

Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue or assessing patches and features.

Communication channels

Before you now get lost in the repository, here are a few starting points for you to check out. You might find that others have had similar questions or that your question rather belongs in one place than another.

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 conditions:

Issues and labels

Our bug tracker utilizes several labels to help organize and identify issues. Here's what they represent and how we use them:

  • breaking - the issue breaks the project
  • good first issues - very good issue to start contributing
  • help - we need help with this issue
  • priority: critical - critical priority issue
  • priority: high - high priority issue
  • priority: low - low priority issue
  • priority: medium - medium priority issue
  • release - will not show in CHANGELOG file (only for deploy PR)
  • status: abandoned - abandoned status
  • status: accepted - accepted status
  • status: available - available status
  • status: blocked - blocked status
  • status: completed - completed status
  • status: in progress - in progress status
  • status: on hold - on hold status
  • status: pending - pending status
  • status: review needed - to review status
  • type: bug - something is not working
  • type: duplicate - already exists
  • type: enhancement - new feature or request
  • type: invalid - this does not seem right
  • type: maintenance - used for maintenance
  • type: question - further information is requested
  • type: wontfix - this will not be worked on
  • work: chaotic - chaotic work to make it possible
  • work: complex - complex work to make it possible
  • work: complicated - complicated work to make it possible
  • work: obvious - obvious work to make it possible

For a complete look at our labels, see the project labels page.

Bug reports

A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful! Unclear issues with little explanations will be closed.

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 dev branch in the repository.

  3. Isolate the problem — create a reduced test case using Codepen.

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? Do other browsers show the bug differently? What would you expect to be the outcome? All these details will help people to fix any potential bugs. Just make sure to fill out the issue template.

Feature Requests

We like feature requests but make sure that it can be seen within the goals of the project and not just something you need individually. Also you should try and give as much examples and details about the new feature as possible. If you are requesting a component from the Material design guidelines, make sure to include a link to the component.

Code Examples

  • Issues without a Codepen (where applicable) will be closed or ignored.
  • Use this Codepen to illustrate your problem.

Pull requests

Good pull requests - patches, improvements, new features - are a fantastic help. Thanks for taking the time to contribute.

Please ask first before working on any significant pull request, otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.

Documentation

When contributing to Materialize's documentation, you should edit the documentation repository in materialize-angular-guide. Do not edit the gh-pages branch. That branch is generated from the documentation source files and is managed separately by the materialize-angular maintainers.

Submitting Your Pull Request

Adhering to the following process is the best way to get your work included in the project:

  1. Fork the project, clone your fork, and configure the remotes:

    # Clone your fork of the repo into the current directory
git clone https://github.com/<your-username>/materialize-angular.git
# Navigate to the newly cloned directory
cd materialize-angular
# Assign the original repo to a remote called "upstream"
git remote add upstream https://github.com/workylab/materialize-angular.git

  2. If you cloned a while ago, get the latest changes from upstream:

    git checkout dev
git pull upstream dev

  3. Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:

    git checkout -b <topic-branch-name>

  4. Commit your changes in logical chunks with messages written in english. Please adhere to these git commit message guidelines or your code is unlikely be merged into the main project.

  5. Locally merge (or rebase) the upstream development branch into your topic branch:

    git pull [--rebase] upstream dev

  6. Push your topic branch up to your fork:

    git push origin <topic-branch-name>

  7. Open a Pull Request with a clear title and description against the dev branch. Reference any open issue in the description so it is automatically linked. Try and keep your commit history clean and concise. Once you submit your pull request, CircleCI will automatically run your tests and will show a checkmark to show that all the tests have passed. Once this is done, we’ll review your tests and code and make comments if there are issues or things we think could be improved. Then once everything looks good we’ll merge the code in!

Translations

We're working in the documentation translation. Hopefully we will have soon and we will add the possibility of contribute with more translations :)

Testing Guide

CircleCI

WIP

License

IMPORTANT: By contributing your code, you agree to allow the project owners to license your work under the terms of the MIT License.