Home - WoWAnalyzer/WoWAnalyzer GitHub Wiki
If you have any questions the WoWAnalyzer Discord is the place to ask: https://wowanalyzer.com/discord
Contributing to WoWA involves writing or editing code for the project. If you've never coded before, don't let that stop you! We have several long-time contributors that got their start coding on WoWA!
If you've never coded in JS/TS before and aren't sure what editor to use, VS Code is easy to set up and works well.
First, set up a local development environment. Detailed information can be found here. It's a one-time thing and pretty quick.
Make sure the spec you want to work on is enabled. If you can't load analysis for it, it is probably disabled. Follow these instructions to enable a spec.
After the spec is enabled, Update the Spellbook for your spec and make sure the core analysis works.
When the core analysis works, you can add custom analysis and new features. See the core tools for details.
We recommend that you work on a feature branch off of the main branch (which is named after the latest Retail expansion). Your git
tool should be able to create this.
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.
There are a few specs that are very consistently actively maintained:
- Brewmaster / Mistweaver Monk
- Havoc / Vengeance Demon Hunter
- Restoration / Feral Druid
- Beast Mastery Hunter
These all have years of development behind them, so they have a lot of features that can be examples for other spec analysis. They also cover many different play patterns:
- Brewmaster has lots of cooldown reduction effects as part of its core kit
- Resto and Mistweaver have lots of HoT effects to track, as well as healing "ramps" to evaluate
- Feral Druid has a mix of DoTs and builder/spender play
- Havoc focuses on maximizing debuff and cooldown windows, as well as general uptime
- BM Hunter is an uptime spec with many cooldown reset procs (not all of which can be tracked, unfortunately)
And don't forget: ask questions! Posting in #development
in Discord is a good way to get pointers and examples.
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. |