Chapter 4 FIMS Governance

The FIMS Terms of Reference describes the high level organization of the FIMS Project. Additional details on roles and responsibilities are provided here.

4.1 Developers

Developers are expected to adhere to the principles and guidelines outlined within this handbook, including the Code of Conduct, Style Guide, Issue Tracking, and Test Case Template.

4.2 C++ developers

The C++ developer responsibilities include:

  • Writing the module code.
  • Creating documentation for the module and building the documentation in doxygen to ensure it is error-free.
  • Implementing the suite of required test cases in Google Test for the module.
  • Ensuring the module runs through the FIMS Github actions.

Once development of a bug fix or a new component of FIMS is complete, the developer should create a pull request according to the correct template and assign the issue tracking the completion of the bug fix and/or feature to the assigned review team. The developer must resolve any issues arising from the review and get confirmation from the review team before the pull request is merged into the upstream branch.

4.3 R developers

The R developers responsibilities include * Writing the Rcpp interface to the C++ code. * Writing Roxygen documentation for any R functions * Writing testthat() test cases for any R functionality * Ensuring the code passes the R CMD CHECK, styler, and any other automated checks.

Once these are complete, the developer should create a pull request according to the correct template and assign the issue tracking the completion of the bug fix and/or feature to the assigned review team. The developer must resolve any issues arising from the review and get confirmation from the review team before the pull request is merged into the upstream branch.

4.4 Reviewers

The reviewers are responsible for adhering to documented guidelines in the Code Review section. Reviewers should confirm that the new code is able to build and run within their own development environment as well as via the Github actions on the repository. Reviewers should clearly document which components of the code need to be improved to be accurate, comply with project guidelines and style, or do not work, in the pull request thread so that the developer knows what they need to fix.

4.5 Project Lead

The Project Lead is responsible for ensuring development and code review occur in a timely manner and according to project guidelines and standards. The Project Lead will triage issues and pull requests weekly and prompt involved parties to resolve outstanding issues and reviews. The Project Lead is also responsible for communicating project status via maintenance of the status dashboard.

4.6 Director Of Software Development

The Director of Software Development is responsible for the successful creation and delivery of the FIMS product to the end user by managing technical risks and opportunities; making key software design and implementation decisions with the development teams, scheduling of tasks, managing change requests, and guaranteeing quality of deliveries and educating the team on technical best practices.

4.7 Code of Conduct Adjudicator

The Code of Conduct Adjudicator is responsible for responding to allegations of Code of Conduct violations in an appropriate manner. This could include a conversation with the violator, his or her manager, up to and including expulsion from the FIMS development team. If the violator is an external collaborator, they can be banned from contributing to the FIMS Github resources in the future.

4.8 External Collaborators

External collaborators interested in contributing to FIMS development are required to fork the FIMS repository, make changes, and submit a pull request. However, collaborators are strongly encouraged to submit an issue via the main FIMS repository for discussion prior to forking. In general, forks are discouraged for development that is intended for integration into FIMS as it becomes difficult to keep track of multiple forks. If collaborators wish to use FIMS as a starting-point for a brand new project that they do not intend to merge back into the main branch, they can start a fork. However, if they intend to create a pull request, they should use a branch.

Pull requests from forks will be reviewed the same as a pull request submitted from a branch. Users will need to conform to the same standards and all contributions must pass the standard tests as well as provide tests that check the new feature.