Skip to content

Latest commit

 

History

History
58 lines (37 loc) · 2.55 KB

CONTRIBUTING.md

File metadata and controls

58 lines (37 loc) · 2.55 KB
Raw

Contribution guidelines

Things to do

  1. Adhere to the Code of Conduct.
  2. Join the Attnam.com forums, say hello. Figure out the changes the community wants to see, check here as a starting point.
  3. Fix bugs before coding more bugs.
  4. Code new stuff while avoiding to code bugs.
  5. Release early and release often.
  6. Make experimental contributions while revising or deleting stuff that isn't working.

Awesome jobs

  • Fixing bugs and improving stability.
  • Coding new subsystems, for example bodypart mutation subsystem, new dangers for player characters.
  • Improving continuous integration and both cloud- and ground-based compiling systems for all supported platforms.
  • Scripting new dungeons and new places for players to go.
  • Commenting the code, document the danger system, weapon balance and combat system.

Forbidden jobs

  • Intentionally creating bugs.
  • Upsetting game balance.
  • Adding/modding weapons without knowing how the weapon system is balanced.
  • Adding content that breaches the Code of Conduct.
  • Telepathically communicating with Elpuri.

Commits, pull requests (PRs) and merging

Commit messages

Follow the guideline found here and you will be sweet.

Pull requests

There are two ways to do a pull request

  1. One way: Draft a pull request. Once it is ready to be reviewed/merged, change status from draft to actual PR.

  2. Another way: Make the pull request and prefix the title with [WIP] (work in progress) denoting that it is not ready to be merged. Once it is ready to be reviewed/merged, change prefix to [Ready].

Merging

There are also two ways to do this. Both ways are equally polite.

  1. Review the PR first. Someone other than the author should do this. If the PR is approved by another dev, then anyone else including the PR author can merge.

  2. Just merge the PR. The review step and merge step gets rolled into one. Only someone other than the author should do this.

Merging your own work

Sometimes it is necessary to merge your own work. Times when it is fine to merge your own work include:

  • Another dev approved your PR.
  • You are fixing any bug or fatal error, particularly one you authored.
  • You are trying to push a tag, i.e. trigger a release. Usually done by the release person, but could conceivably be done by anyone.
  • You are the only dev left on the project.