If you have any questions the WoWAnalyzer Discord is the place to ask: https://wowanalyzer.com/discord

Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.

Installation instructions can be found here. It's a one-time thing and pretty quick.

If you're new to ES6, React or JSX, the About the programming language is a good introduction.

To learn more about our framework visit the The WoWAnalyzer framework page. Alternatively, you can go through the existing source with "find in files" and learn by examples or talk to us on Discord for shortcuts on how to approach what you want to do.

You don't need to to do anything special to add something for a spec. The real issue preventing specs from being developed is that in order to add a spec, you need to have the following 3 properties:

1. Know the spec well enough to create something useful
2. Know how to program well enough to implement the analysis
3. Have the time and motivation to do it

We have worked hard to provide you with many tools to make step 2 as easy as possible. Things such as calculating the downtime (Always Be Casting) and Cast Efficiency have been worked out so that it's a matter of only a few lines of configuration code to get them to work, but more advanced analysis such as the gains from a spec's specific mastery usually require custom code. But you don't worry about that yet; start small.

If you're looking for something to add to your spec you can check the issue list or check if your spec needs anything of the following:

• Add something that can not be analyzed, and that people are interested in (e.g. the value of your mastery)
• Add suggestions for common issues
  • Look at what other people look for when analyzing logs, and copy that analysis into the analyzer with appropriate suggestions
• Tune suggestion thresholds to give better advice (on-going)
• Add modules for trait performance
• Configure the cooldown tracker
• Fix issues with the GCD and cooldowns for the timeline (see your browser's console)

The most useful things to do are to add information that isn't yet easily available and to fine-tune the suggestions so that they give the best possible recommendations to people.

Make a feature branch git checkout -b my-new-feature. Start small. Try changing something to see things change (your browser should refresh automatically after automatically recompiling). If you verified everything is working, you're ready to go to the real stuff.

Looking into the Holy Paladin implementation is a great way to find out how to do things. This spec is usually the most up-to-date with the best practices in this project.

How to develop parts of the app is further explained in the following files:

• a-new-module.md: Information on how to create a module.

Continue reading below for more general contribution information.

When you are done with your changes, commit your work and then push your changes to your fork. To create a pull request, open the GitHub page for your fork and it be updated to show a button *Create pull request. Explain what you did, why you did it, and why it matters (although if you have to explain why you did what you did then you should probably include that as comments in your code). Your PR will be reviewed to find potential issues.

Remember to update the changelog if the changes made will be noticed by users.

We work on this project on a voluntary basis with busy schedules. Some days we have a lot of time available to work on it, other days we are very limited. This can lead to slower PR review times, so please bear with us. Our goal is to respond to small PRs within 24 hours, and anything else within 48 hours. Large or complex PRs may take longer to be reviewed as we wish to be thorough. We strive to never leave an action required on our end for more than 7 days. If you haven't heard anything by then, feel free to ping us as you deem appropriate.

If you're curious what GitHub name links to who on Discord see the CONTRIBUTORS file.

Please make small Pull Requests. One pull request per feature is preferred, which generally means 1 module per PR. Larger PRs may take a longer time to be reviewed and merged.

Our code review guidelines can be found here. TL;DR: Fix errors in the yarn start window, make sure your code is maintainable and doesn't have anything that could result in a bug or incorrect results.

It often helps to do a review pass on your own code after submitting a review. Fix things that you think are weird in hindsight, or leave a comment to explain certain choices (consider a comment in the code before placing one on GitHub).