You are here to help on wow-actions projects? Awesome, feel welcome and read the following sections in order to know how to ask questions and how to work on something.
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, assessing changes, and helping you finalize your pull requests.
There are many ways to contribute, from improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into iCore projects itself.
All members of our community are expected to follow our Code of Conduct. Please make sure you are welcoming and friendly in all of our spaces.
We are using GitHub Issues for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn’t already exist.
Here are some notes on how to report the bug so we can fix it as fast as possible:
- Explain, as detailed as possible, how to reproduce the issue.
- Include what you expected to happen, as well as what actually happened.
- If it's a bug with the website, please include information on what browser version and operating system you are running.
- If it helps, feel free to attach a screenshot or video illustrating the issue.
- If you're having trouble with a specific build, please include a link to the build or job in question.
Contributions are welcome via Github pull requests. Each pull request should implement ONE feature or bugfix. If you want to add or fix more than one thing, submit more than one pull request.
The core team is monitoring for pull requests. We will review your pull request and either merge it, request changes to it, or close it with an explanation.
Before submitting a pull request, please make sure the following is done:
- Fork the repository and create your branch from master.
- If you’ve fixed a bug or added code that should be tested, add tests!
- Ensure the test suite passes.
- Format your code with code style corresponding to the project.
- Make sure your code lints.
Working on your first Pull Request? You can learn how from this free video series:
How to Contribute to an Open Source Project on GitHub
To help you get your feet wet and get you familiar with our contribution process, we have a list of good first issues that contain bugs that have a relatively limited scope. This is a great place to get started.
If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don’t accidentally duplicate your effort.
If somebody claims an issue but doesn’t follow up for more than two weeks, it’s fine to take it over but you should still leave a comment.
It is a recommended best practice to keep your changes as logically grouped as possible within individual commits. There is no limit to the number of commits any single Pull Request may have, and many contributors find it easier to review changes that are split across multiple commits.
$ git add my/changed/files
$ git commit
Note that multiple commits often get squashed when they are landed.
You are encouraged to use angular commit-message-format to write commit message. In this way, we could have a more trackable history and an automatically generated changelog.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>（1）type
Must 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 tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
- deps: Updates about dependencies
（2）scope
The scope could be anything specifying place of the commit change.
（3）subject
Use succinct words to describe what did you do in the commit change.
（4）body
Feel free to add more content in the body, if you think subject is not self-explanatory enough, such as what it is the purpose or reasons of you commit.
（5）footer
- If the commit is a Breaking Change, please note it clearly in this part.
- related issues, like
Closes #1, Closes #2, #3
Sample complete commit message:
fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
72 characters or so. That way, `git log` will show things
nicely even when it is indented.
Closes #392
BREAKING CHANGE:
Breaks foo.bar api, foo.baz should be used instead
Look at these files for more details.
If you are new to contributing to our projects, please try to do your best at conforming to these guidelines, but do not worry if you get something wrong. One of the existing contributors will help get things situated and the contributor landing the Pull Request will ensure that everything follows the project guidelines.
All the projects in wow-actions follow semantic versioning. We release patch versions for bugfixes, minor versions for new features, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance.
Every significant change is documented in the changelog file of a project.