User Tools

Site Tools


2015:repo-documentation:merging-workflow

NSRC Repo Merging Workflow

Merging new features of content into an existing NSRC course isn't as simple a process as clicking a button on GitLab.
There are many things to be considered before new material can be accepted into a stable course.

  • Do any of the exercises violate assumptions about the order a course is generally delivered in. Does it assume Apache is installed for example when normally it's not installed until later in the course.
  • Is this course generally delivered in multiple languages? Does the material need to be translated before it can be accepted.
  • Does the material assume to high a level of skill on behalf of the students?
  • Does the material further the objectives of the course.
  • Does the material teach material which is current best practice.
    • Does the material meet the “If we saw this on a DEA would we be concerned” test
    • etc (please add at will)

To this end the MC, SME and EA for the course all need to sign off on every merge request more substantial than fixing a typo.

Here is a suggested process for ensuring that this happens in a consistant, repeatable, scalable manner.

  • The MC will have received notification of a Pull Request from a developer. This Pull Request will have a comments section.
    1. The MC will monitor the comments section of the Pull Request. If they have not seen comments from the SME and EA within a few days, they should email them to see if they are in a position to comment.
    2. In the case of Slide only changes. The MC, SME, EA should all view the content and assess it's suitabilty for inclusion into the course.
      - The MC, SME, EA will all place comments into the Pull Request. A comment of “APPROVED” from any of the three gatekeepers will signify that they are happy for the content to be merged. An “APPROVED” comment is required by all three gatekeepers before a merge can take place.
    3. If any gatekeeper does not feel they can approve a change they are under an obligation to either suggest how the material could be changed so that it can be accepted, or provide the original author a detailed rationale of why it's inclusion is inappropriate.
    4. In the case of submissions which involve Lab materials. Each of the gatekeepers should run through the lab exercises from a staring point which would be common to the majority of delivered courses. This starting point should be clearly documented (ie, Starting point Base Ubuntu 14.04 install, Basic NMM workshop ansible playbook, Labs 1,2,3,4 completed successfully).
    5. If any of the gatekeepers have comments or additional requests of the original author, these should be made in the Pull Request comments section to that the conversation can be recorded.
2015/repo-documentation/merging-workflow.txt · Last modified: 2016/02/03 05:04 (external edit)