Skip to content
ghqc

Overview and timeline

Workflow diagram

workflow_summary

Posted QC commit timeline

Full Issue thread examples

Example 1: Both the Author and QCer push QC file changes

Full Issue Screenshot

Example 2: The Author pushes QC file changes and addresses QC feedback comments separately

Full Issue Screenshot

Timeline diagram

The diagram below outlines a general posted QC commit timeline pattern for ghqc Issues.

timeline

Initial QC commit

The Author always catalyzes QC with the initial qc commit. This “starting line” for the QCer is automatically generated in the metadata of the Issue body when it’s initialized via the “Assign QC file(s)” button in the Assign app.

The Assign app checks that the local and remote versions of the assigned QC files are in sync before allowing the user to proceed with Issue creation, setting the initial QC commit as the most recent remote commit.

Approved QC commit

The QCer gets the “last word” with the approved QC commit posted via the “Approve” button in the Status app.

The Status app checks that the Approver has the most recent remote version of the QC file and has pulled most recent posted QC commit. It also requires that the Approver doesn’t have any unsynced local changes before proceeding with Approval.

Posted commits

Collaborators are encouraged to post the commits that occur throughout the QC process via “QC notifications” to keep each other up to date.
Posting the commits between the initial and approved QC commits is not mandatory, but doing so helps to illustrate a timeline.

  • The QCer doesn’t have to commit in-line code comments - comments can be conveyed in other ways
  • Likewise, the Author doesn’t have to post QC notifications - script updates can be conveyed in other ways