How to Contribute to Path of Building Community

Updated

Path of Building Community is an open-source project, and its own site states that you do not have to be a programmer to contribute. The page lists three broad ways in: reporting issues, helping with documentation, and taking a look at the project's contribution information to see where your skills fit. If you want to help, the practical starting point is the project's GitHub presence and its contributor guidance rather than any in-app menu.

What the project says it needs

The site's own wording is direct: "This project is open source and needs your skills!" It then points readers to a page explaining how to help, with the reassurance that programming is not a requirement for contributing to issues or documentation.

That gives you two low-barrier tracks before any code:

  • Issues — reporting bugs, incorrect behaviour, or missing support for mechanics and items.
  • Documentation — improving or writing the explanatory material that surrounds the tool.

Where to start

The site's navigation includes a Contributors entry and a Report an issue entry, alongside a link to see the project on GitHub. Those are the entry points the project itself surfaces.

A sensible order of operations:

  1. Open the project on GitHub and read the contribution information the site links to.
  2. Check whether the problem or gap you noticed is already reported, so you add information rather than duplicate it.
  3. If it is new, file an issue with enough detail to reproduce or understand it.
  4. If it is documentation, propose the correction or addition through the same project channels.

The site does not spell out a separate sign-up flow or a non-GitHub submission form, so treat the GitHub project and its linked guidance as the canonical route.

What kinds of contributions are useful

Because Path of Building Community tracks a large and steadily updated surface area, useful reports tend to be specific. The site's own feature list shows the breadth of what is modelled, which is also the breadth of what can go wrong or be missing:

Area Examples named on the site
Mechanics Impale, Exposure, Elusive, Warcries and Exerted Attacks, Bonechill
Unique mechanics Timeless Jewels, Perquil's Toe, Thread of Hope, Split Personality
Skill mechanics Warcries and Brands, Awakened Spell Echo, Vaal Arc, Carrion Golem
Keystones The Agnostic, Crimson Dance, Eternal Youth, Glancing Blows, Imbalanced Guard
Alternative ailments Scorch, Brittle, Sap
Uniques "All uniques available," steadily updated, with most mods supported

If a mod, interaction, or unique behaves differently in the tool than in the game, that is exactly the kind of observation the issue tracker exists for. Documentation contributions matter for the same reason: the tool supports a lot, and explaining it clearly is separate work from implementing it.

A realistic example

Say you notice that a particular unique's modifier is not being applied the way you expect when you equip it in a gear set. A useful contribution is not "this unique is broken" but a short report containing the item, the modifier, what you expected, what the tool showed, and the steps you took. That is reproducible, and it does not require you to read or write any code. The same applies to a passive-tree interaction or an ailment calculation that looks off.

What to expect

The site describes the project as open source and community-driven, with uniques "steadily updated" and most of their mods supported. That phrasing implies ongoing work rather than a finished product, which is precisely why reports and documentation help. It does not promise response times, a review process, or a list of accepted contribution types beyond issues and documentation, so do not assume a particular turnaround or a formal onboarding path.

If you are unsure whether something counts as a bug or a documentation gap, the safest move is to check the project's contribution guidance first and then file it in whichever category fits best.