Skip to content
This repository has been archived by the owner on Apr 3, 2024. It is now read-only.

Development Rules and Guidelines

Erich Gubler edited this page Apr 1, 2014 · 1 revision

ModDamage Coding Project Standards

The purpose of this document is to standardize the development processes for ModDamage. It specifies procedures for the development, documentation, testing, and official release of the software in the official repository.

Software Development

  1. Requirements gathering and communication

    1. Continuous communication and integration of ModDamage users with those involved in its development shall be essential to its success. All software requirements adopted by the project must be entered into the Github issue tracker.
    2. Continuous integration in Jenkins.
  2. Coding and Unit/Integration Testing

    1. JavaDocs

      1. Constructors
      2. Method prologues
      3. All other public elements of the class
      4. Clearly-defined JavaDocs for constructors and method prologues and all other public elements of classes
    2. A requirement-driven testing framework in JUnit

    3. Preliminary documentation proposal of modified/added features.

    4. Uses the Java Code Conventions.

  3. Issue Tracking - “We believe in: rough consensus and running code.”

    1. All issues requiring a codebase modification to fix should be closed through the commit-based issue closing feature.
    2. Milestones for issues are to be set by senior members, however a consensus is required for milestone-related decisions.
  4. Promotion/Release Model

    1. To be considered for commission to non-experimental branches (i.e., Beta, Stable), a revision must pass the entire project’s JUnit test harness and meet all aforementioned code quality requirements. A senior member of the ModDamage development team must review and approve the modified codebase according to this criteria, as well as a senior member of the documentation team.
Clone this wiki locally