Developer Expectations - MegaMek/megamek GitHub Wiki

MegaMek developers are volunteers. We do this as a hobby and for our love of the game and universe. As developers we have don’t have rules but expectations of each other.

Expectations as a team

  • We are a team.
  • We are collaborative
  • We are all unique with our own unique experiences and we must respect that.
  • We each have our own coding experience level
  • We are respectful to our community of players, our mission statement, and each other.
  • As developers “we” represent the suite of programs.
  • We must remember we don’t work in a vacuum and our community and the BattleTech IP holders can see what we are doing and saying.

Code and Pull Requests (PRs)

  • Developers own their own PRs and the outcomes of their PRs. If an issue gets thru every effort should be made to resolve it in a timely matter.

  • Developers should expect to review other PRs and change requests.

  • Due to the maturity of the code base and varying time available available for other devs, PRs should be focused on one the specific issue or RFE. Small amounts of refactoring are expected.

  • Work around accessibility and large amounts of refactoring (via automatic IDE formatting) should be done as a separate pull request, and such pull requests should be clearly labeled.

  • It's expected that Developers be open to having these reviews. Both the reviewer and reviewed need to recognize there is often more than one way to do something and the best way for one isn’t always the best way for all.

  • If thru the process of reviewing PRs, a change request comes up the developer and reviewer should work together to come to agreement on the implementation. The reviewer should assume that a PR is a positive contribution unless there are substantial reasons to think otherwise; change requests should be reserved for critical matter. Examples of critical change request include:

    1. The PR will result in damaging the image of MegaMek or BattleTech.
    2. The PR will create conflicts in other parts of the suite.
    3. A bug fix or logic fix is needed
    4. The PR substantially violates MegaMek's Coding Style Guide or otherwise contains severe code deficiencies

The reviewed should assume that change requests aren't made lightly and make a good attempt at implementing them unless there is substantial reason not to. In the event of an impasse the PR will be moved to a Draft until a resolution is determined. Or one of the repository owners will decide.

Contributors and becoming a Developer

  • We do not accept requests to join the Dev team it is by invitation only.
  • To join the dev team contributors must have demonstrated all the above.
  • If a developer wants to invite someone to the dev team, it must be discussed by all and agreed by all.

Leaving the Development Team

  • We contribute when and how we can. But if a time comes that a developer can’t or no longer wants to contribute, they can withdraw and after a year of no contribution/communications they will become a Developer (Emeritus) and be moved to an outside contributor.
  • This decision must be agreed upon by a majority of active developers at that time.