Chapter 5 Co-coordinated Workstreams (R&D and DataOps/DevOps)

5.1 Specific Workflows

• mixed_methods_workflow: Integration of QUAL + QUAN mixed methods research. Co-coordinated by R&D and DataOps.
• quant_workflow: Supports the research and operations value streams. Co-coordinated by R&D and DataOps.

5.2 Manage Research Repository Including Readme.md

• Value Streams: Research, Development, Operations
• Workstreams: All
• Workflow: Coordinate work each quarter via story maps to ensure progress on each grant and tests of specific aims.
• Video

Teams Channel Link

Research Repo for R21: R21DA042198

Research Repo for R01: 1R01DA046651

Research Repo for IIR: I01HX002521

1. Ensure research repo including readme.md is current.
2. Plan user stories and workflows to meet deadlines.
3. Direct & co-coordinate research, development, operations:
   • Workflows
   • Meetings
   • Sprints
4. Ensure progress on research repository for each with:
   • Datafeeds
   • R Notebooks
   • Analyses for tests of specific aims
5. Report Progress (see 5.2).

5.3 Report progress for R21, R01, IIR grants

• Value Streams: Research, Development, Operations
• Workstreams: All
• Workflow: Coordinate work each quarter via user story maps to ensure progress on each grant and tests of specific aims.
• Video

Teams Channel Link

Research Repo for R21: R21DA042198

Research Repo for R01: 1R01DA046651

Research Repo for IIR: I01HX002521

1. Enlist Readme.md for each grant to manage all people, platforms and deadlines.
2. Review the grant & clarify what was already reported in the last progress report.
3. Coordinate across all workstreams, PI, & Statistician to map our analytic with user story maps.
4. Produce enrollment tables.
   *See Team PSD 3.0 Manual 6.6 - includes sending provider survey.
5. Draft a new progress report combining the information above.
6. Coordinate with PI to get approval and submit.

Below is the flow of reporting for each grant:

NIH R21DA042198 Participatory System Dynamics for Evidence-based Addiction and Mental Healthcare

1. Check R21 Readme to manage all people, platforms, and deadlines.
2. Review the previous year VA Palo Alto RDIS Report.
3. Submit Va Palo Alto RDIS in June.

NIH 1R01DA046651 Participatory System Dynamics vs Audit and Feedback A Cluster Randomized Trial of Mechanisms of Implementation Change to Expand Reach of Evidence-based Addiction and Mental Health Care

1. Check R01 Readme to manage all people, platforms, and deadlines.
2. Submit VA Palo Alto RDIS in February.
3. Submit PAVIR Progress Report by November 1st & coordinate eRA submission NIH November 15th.

VA I01HX002521 Participatory System Dynamics vs Usual Quality Improvement: Is Staff Use of Simulation an Effective, Scalable and Affordable Way to Improve Timely Veteran Access to High-quality Mental Health Care?

1. Check IIR Readme to manage all people, platforms, and deadlines.
2. Submit ART VACO in January.
3. Submit VA Palo Alto RDIS in June.
4. Submit Data Safety & Monitoring Board (DSMB) via ART update in December.

5.4 Contribute to a Team PSD Manuscript

1. Review the open Team PSD manuscripts.
2. Request access to OSF & Zotero (via PI).
3. Complete the authorship app for prior_work and writing.
4. Sign up with R&D for a consult at #manuscript_monday.
5. Review the Team PSD Manual for additional guidance.

5.5 Request New Research Data

1. R&D adds team member to IRB with IRB modification on eProtocol.
2. Principle Investigator (PI) adds user to ORD_workgroup in BaseCamp.
3. DataOps submits a new DART request, which adds to VINCI project.
4. Team member checks data access with SQL Server.

5.6 Submit a Requisition

• Value Streams: Research, Development, Operations
• Workstreams: All
• Workflows: All
• Video
• Reference: Easy Instructions to Place a ReQlogic Order

Teams Channel Link

1. Get set up with ReQlogic.
2. Navigate to ReQlogic and login.
3. Click on the green requisitions bar on the top and you will see a menu pop up on the left-hand side.
4. Select Requisition Entry.
5. Push the plus button to start a new requisition entry.
6. Fill out everything that is listed in blue.
7. Push the Save button. You will see that nothing is blue anymore.

Tip: You can always edit by pressing the pencil next to the save button.

8. Enter justification notes.
9. Fill out item summary.
10. Sign your invoice.
11. Click Submit.

5.7 Submit VACO and VAPAHCS Progress Report

1. Use ReadMe to track deadlines for all grants & reports.
2. Develop user story maps to ensure progress on tests of specific aims in the months prior to reporting.
3. Enrollment tables: coordinate w/PeopleOps Manager.
4. Analyses for Tests of Specific Aims - coordinate with Statistician.
5. Put together first draft of report using last year’s drafts.
6. Coordinate with PI to get approval and submit.

NIH R01 VA Palo Alto RDIS - February NIH Annual Progress Report - 11/15 PAVIR Progress Report coordinate eRA submission NIH 11/15

VA IIR ART VACO - January VA Palo Alto RDIS - June DSMB update - December

5.8 Edit a Guide via Pull Request and Plan DEV/TEST/PROD Quality Assurance Sync

• Value Stream: Operations
• Workstream: PeopleOps
• Workflow: facilitate_workflow
• Video: this video reviews how to update mtl.how via a GitHub pull request. Dr. Zimmerman and Mushiana review and post the updated MTL 3.0 Facilitator Fidelity guides for the partner phase to the MTL Blue s01-s04 facilitator folders.

Teams Channel Link - A cross-reference to MTL 2.4, Improve the MTL repo via a pull request and QA.

*Cross-reference: MTL 2.4

1. Review QA dependencies via User Stories on Lucidchart.
2. Scope out QA assignees/reviewers, labels, and story points on Zenhub/GitHub.
3. Review Team PSD Manual for use of QA branch on GitHub.
4. Create a feature branch via a pull request from the QA branch.
5. Open feature branch from QA.
6. Make edits in markdown on GitHub.
7. Conduct QA on qa_branch using GitHub Actions.
8. Merge into QA.
9. Create a pull request from QA to Master and assign a PROD QA reviewer.

5.9 Improve the Team PSD Manual

This section explains how to use GitHub to update a section in the Team PSD manual. It will also detail how to request a review of your changes and incorporate into the document-of-record.

This section explains how to:

• Create a “feature branch.”
• Make and save edits to a Markdown file.
• Request a merge of the feature branch with the gh-pages branch (document-of-record).
• How to update the bookdown.yml file to compile the Team PSD Manual in the proper chapter order.

5.9.1 Create a Feature Branch from the gh-pages Branch

• Start by creating a feature branch with the beginning of the branch named “feature-gh-pages”. The “feature-gh-pages” must be written precisely - GitHub is triggering several automated functions using that naming.

---

---

• Branch naming conventions:
  • New chapter - If new chapter title is “My New Chapter” then name the branch “feature-gh-pages_my_new_chapter.”
  • Edit an existing chapter - If existing chapter title is “Using Markdown” then name the branch “feature-gh-pages_using_markdown_edit.”
  • If the chapter is being worked on by multiple contributors, or if the chapter is long, break down into multiple files that can be reconciled when compiling the publication.

---

---

5.9.2 Create a New Markdown File in the Branch

• If contributing to an existing markdown file, skip to step 3 below.
• Create and name a new markdown file.

---

---

5.9.3 Find and Edit a Markdown File

• Find the markdown file and open for editing.

---

---

• Chapter Heading Structure. The software that compiles the markdown files into a published manual, takes information from the heading markers (#, ##, ###) to determine if something is a chapter or a subsection. For example:

  • “# Standard Operation” compiles as “Chapter 3 - Standard Operations”
  • “## Team PSD” compiles as “Chapter 3.1 - Team PSD”
  • “###”Open-source, Transparent, Reproducible” compiles as “Chapter 3.3.1 - Open-source, Transparent, Reproducible”

---

---

• Add content. There are many features in markdown that support various formats and text emphasis. See markdown guide cheatsheet for more information.

---

---

• Add a link. There are two components to a link, the description and the uniform resource locator (URL). It goes like this, description in in brackets [uniform resource locator] followed immediately by the URL in parenthesis (https://en.wikipedia.org/wiki/URL). So all together uniform resource locator.
  • The description in brackets is a Section 508 Accessibility requirement, so visually impaired people can use a browser reader to interpret what is contained in the link.
  • The link can be placed anywhere in the document. The term in the brackets will be the only visible element in the rendered document.
• Add a graphic. Adding graphics are very similar to links because they both rely on a call to a URL.
  • Create and upload a graphic the the gh-pages_images folder. Team PSD uses the .png file format for still graphics, and .gif for screen-casts. When naming the image, describe what is contained in all lower case, separated by an underscore (ex., upload_image.png).
  • To render a graphic in bookdown, an html tag (img src = ) is needed before the link. See the graphic and steps below to learn how to format a graphic link.

---

---

• Add an html tag using the following image syntax:

Note: This is code, so all punctuation and special characters must be typed as shown.

<img alt="Image of IMAGE_DESCRIPTION." src="https://raw.githubusercontent.com/lzim/teampsd/gh-pages/images/IMAGE_FILE_NAME.png">

• Replace “IMAGE_DESCRIPTION” with a succinct description of what the image shows or depicts. This is a Section 508 Accessibility requirement.
  • For example: Image depicting how to navigate to the gh-pages branch.
• Replace “IMAGE_FILE_NAME.png” with the name and extension of the graphic file you want rendered.

---

5.9.4 Update the “_bookdown.yml” File to Reflect Proper Chapter Order

• .yml. The “_bookdown.yml” prints out the manual in the order of the the markdown files listed in line 6. As explained earlier, the headers of the markdown files listed tells the _bookdown.yml file whether the markdown is a chapter or a subsection. The order of the files in the _bookdown.yml file will be automatically numbered sequentially by the yaml program.

---

---

• Add a markdown file - with chapter heading. List the markdown filename in the desired chapter order of which, the file should appear in the manual.
  • Make sure to include quotations around the file name and a comma.
    
  • Note the last chapter does not need a comma.

---

---

• Add a markdown file - with subsection heading.
  • Sometimes a team must break the work out into sections and it is easier if everyone has their own file. the _bookdown.yml file supports compiling subsections from files separate from the main chapter heading file.
  • This is a great way to check the formatting and output of your markdown file in the actual Manual before you hand off the review for QA Test.

---

---

5.9.5 Make a Pull Request to the gh-pages Branch

• Check and resolve for errors returned by the markdown linter, spell checker and link checker.
• Assign QA Test reviewers.
• Once the reviewer has approved, then go to step 6 below.

---

---

---

5.9.6 Publish your Chapter to Master gh-pages Branch

• Merge the Feature branch into gh-pages branch.
• Check the actions and ensure the bookdown rendering did not encounter any problems.
• Resolve any bookdown problems.
• See the new work! Go to Team PSD Manual

5.10 Improve the Modeling to Learn Repo via a Pull Request and Quality Assurance

• Value Streams: Research, Development, Operations
• Workstreams: All
• Workflows: All
• Video 1
• Video 2 - an addendum to previous recording
• Video 3 - validating changes

Teams Channel Link

*Cross-reference: MTL 2.4

Note: Team PSD 3.0 Manual Chapter 4.2 is covered for facilitators in the MTL 3.0 Manual Chapter 2.4.

1. Review Team PSD Manual for editing gh-pages branch.
2. Navigate to lzim/mtl/gh-pages and make a “feature-gh_pages_*” branch.
3. Navigate to the new branch.
4. Make desired edits.
5. Open a pull request and fill out Pipeline, Reviewer, Assignee, Story Points, and any other appropriate labels. Make a note to the reviewer.
6. Review any findings from the spell checker, markdown linter, or link checker and resolve.
7. After review, merge request into the gh-pages main branch.
8. Review bookdown action and check rendered MTL 3.0 manual.

5.11 Create or Edit GitHub Issue Template

• Value Streams: Research, Development, Operations
• Workstreams: All
• Workflows: All

Teams Channel Link

GitHub Documentation is located here.

1. Workstream Lead logs in to lzim account for relevant GitHub repository (or repo).

2. Scroll down to Features.

3. Click Set Up Template.

4. Scroll down to edit and existing template for click “Create new Template.”

5. Templates needed:

   • Progress Reports
   • IRB Renewal
   • Training