Skip to content

How to contribute to DROID

Jump to bottom
Saurabh Parkhi edited this page Apr 11, 2023 · 6 revisions

Organisation

At the time of writing 10/06/2020,

  • github issues are prioritized in a spreadsheet, and are labelled on what our priorities are for the upcoming future ( HIGH / MEDIUM / LOW )

  • Please leave to the developers from The National Archives those labelled as to-be-done-by-tna.

  • If you want to start with something simple, not too technical, please consider easy-task labelled tasks. Some of them might be easy technically, but require a large amount of work, feel free to contribute even partially, any help is greatly appreciated.

  • Please avoid taking tasks already assigned, or ask first how you can help if you want, to avoid duplicating any existing work.

  • We organise our work in GitHub Kanban board

Making use of branches

We keep master branch up to date with the latest changes. At times, there is a need to release patches on an existing release. Sometimes it is not needed to do a full release including all the ongoing development, and other times, it may be quicker to fix a security issue using a patch on existing release. To be able to achieve that, we keep 2 main branches

  • master branch represents the latest code including any ongoing developments
  • Patch 6.6.x branch can be used as a main branch for any small increments over the latest main release version (6.6.0)
  • When working on a feature, we consciously make a decision whether something should be developed against a patch branch or master
  • Everything that is merged into patch master (6.6.x branch) is also subsequently merged to master however
  • Any development which may have a breaking change or otherwise deemed not fit for a patch is merged to master. such a change is NOT merged to patch.
  • Eventually, when a release happens from the master, the patch branch of previous version will be discarded (e.g. when 6.7 will be released, there won't be any further 6.6.x releases)

Implementation

  • Create a feature branch to implement a single feature as per the branching strategy (either from master or patch main) within the DROID repository or
  • Create a fork in your own space and do the implementation
  • Once the implementation is finished, open A PR and get someone to review it
  • Reviewers, once happy with the implementation may merge the changes into master

Definition of Done

when you submit a new PR for review, please ensure

  • acceptance tests are provided if needed
  • build is successful on Github actions (mvn clean install on all supported JDKs)
  • documentation is up to date
    • github readme for common features
    • wiki for developer guidance, process release, etc
    • GUI or CLI help when relevant
    • GUI user guide > new features if new significant features
  • behaviour between Command Line Interface and Graphic User Interface is consistent (they should offer the same features when possible)

for the reviewer

  • code reviewed
  • acceptance tests run locally if any provided
Clone this wiki locally