Skip to content

06_Procedures

Jump to bottom
Stacey Park edited this page Feb 11, 2020 · 3 revisions

Procedures

Sim UI PLDR Administration Page Use and Maintenance

The Sim UI PLDR Administrative Page provides a means for the Moderator to review issues submitted by members of the CP, to customize outgoing email messages and to create News Flash messages.

  1. Issue Submission Data. Since email and other PII are not passed forward, the Dashboard cross-references the issue with the email of the issue submitter. The Moderator is able to review the issue from this listing or export the entire listing to a spreadsheet.
  2. Customizable PLDR Outgoing Message Management. For each selection of the PLDR menu, there is a customizable outgoing message that will be sent when the user completes their interaction with the PLDR process. The Administration Page also provides a way for the Moderator to put out announcements for all participants in the MTL project to see via the News Flash, when they login. Below is a listing of available outgoing message types.
Type Sample Messages
News flash (flashing pop up) “There is an issue that needs your input, click on the link to see the discussion thread”
Idea response (email) “ Thanks for your idea
Issue response (email) “Thank you for your feedback! We have assigned your feedback information, issue number XXX. We will refer to this number with any correspondence to you. ”
Like response (email) “ Thank you for your feedback, we are striving to provide the best solution possible and your feedback is vital to that goal!”
Question response (email) “Thank you for your question. We are maintaining a database of these questions to help us provide better help support and information. Did you find what you are looking for in the Community of Practice Forum? If not . . . ”
Join (email) “Thank you for participating with us! We look forward to collaborating with you. In order to participate in the Community of Practice Forum, you will need to register with GitHub at www.github.com. The account is absolutely FREE, and it takes literally 2 minutes to register. Once you have a username, please send it to [email protected] so we can give you full access to the forum.

News Flashes

  1. News Flashes are used to notify the CP that there is an action in the online CP that requires their attention. News Flashes will go out to everyone, regardless of their association with the GitHub online CP.
  2. News Flashes can also be used by Team PSD to notify users and members of the CP about changes that have occurred in the Sim UI, or related dependent materials.
  3. News Flashes can also be used to alert users of service outages or related technical issues.

PLDR Issue Processing

  1. A user clicks on the PLDR button in the Sim UI. A form is presented that collects the desired information.
  2. The Sim UI creates a GitHub issue card and deposits the card via a REST- API in the triage silo of the issue_tracker.
  3. The Moderator or the Sim UI Workgroup Lead reviews the issue, within 1 working day and enters the details of the message with a card link on the Tuesday or Thursday Workgroup Leads meeting agenda.
  4. If the issue is unclear, the Moderator or the alternate will consult the PLDR Administration Page to find contact information and consult with issue submitter.
  5. The Workgroup Leads will review the issue and provide a disposition. Any issues deemed critical but outside the authority of the Workgroup Leads, will be pushed to the Principal Investigator for further disposition and guidance.
  6. If the issue requires discussion in the CP, the Moderator or the alternate will move the card to the PLDR tracker and write a message using the New Flash Procedure . PLDR Tracker Structure and Discussion Management The structure for tracking discussions will consist of 4 silos. The purpose of the silo is to indicate to the discussant, where the issue is with relation to the time that is left. The table below describes the silo structure. Most issues start out with 30 days for discussion. However, pressing issues can be put into shorter time silos as necessary to meet operational requirements.

Tracker Structure Table

Sprint
 – 30 days Sprint
 – 15 days Sprint
 – 5 days Issues Accepted for Action Tabled Issues
Most issues start here. After 16 days, they are moved to the 15 Day Review. Issues here have 14 days, but more than 5 days left for CP members to review. Issues with 5 days left are moved to the right. Issues here have 5 days, but more than 24 hours left for CP members to review. From here an issue is either accepted for action, tabled or closed. Issues here are accepted for action by the Workgroups in Team PSD and are moved back to the MTL Project tracker for action. Issues that require a hold to await additional information or better timing are parked here until further disposition.

The tracker system will be responsive to the production sprint process and is reflected below.

PLDR Community of Practice User Registration

At the end of each week, the Moderator or alternate will:

  1. Review requests to join the CP.
  2. Ensure requestors were successful at joining GitHub and have been pulled into the project.
  3. If a requestor has not completed registration in GitHub, sends out a follow up email offering assistance.

Adding Issue to Workgroup Leads meeting agenda.

Before each Workgroup Leads meeting the Moderator or alternate will:

  1. Review issues pending in the triage silo of the issues_tracker.
  2. The designate will place the issue on the agenda for triage and action by the Workgroup Leads.
  3. Once assigned to a Lead, the Lead is responsible for moving the issue through the Tracker.

Moving issue to Community of Practice for Discussion.

The Moderator, alternate or Workgroup Lead will confer with the PI, as necessary, and:

  1. Identify issues that require wider discussion or review in the CP Forum.
  2. Place issue in appropriate discussion time silo.
  3. Promote issue from silo-to-silo as time ticks down.
  4. Monitor the discussion and provide feedback to CP Forum members as required. Responses to CP Forum members should occur within 24 hours when possible.
  5. Bring action back to issue_tracker for final disposition.

Community of Practice Discussion Monitoring

  1. Purpose. The CP Forum is a place for members of the community of practice to meet and discuss issues related to the Sim UI, their experiments or other issues germane to the MTL program.
  2. Monitoring. Moderator, alternate and members of Team PSD will monitor the CP Forum and interact with members as necessary. All participants in the CP Forum will follow the Guidelines of the Community of Practice Forum, described above.
  3. Veteran Crisis Help Information. The following information will be prominently displayed in the GitHub Online CP, “If you’re a Veteran in crisis or concerned about one, there are caring, qualified VA responders standing by to help 24 hours a day, 7 days a week. Dial 1-800-273-8255 and Press 1 to talk to someone. Send a text message to 838255 to connect with a VA responder.”
  4. Trolling response procedure. Any occurrence of trolling behavior in the CP Forum will be immediately reported to the Principal Investigator or designee. The PI or designee will:
  5. Personal Identifiable Information (PII) discovery, reporting and resolution procedure. It is the responsibility of all members of Team PSD to immediately report any PII found in the CP Forum. An example of PII would be a person’s name and email address, or phone number. This can occur if someone answers a forum issue notification via email. If PII is found our reported, the Moderator or alternate will:

Modeling to Learn is a partnership.

Join our online Community of Practice and participate as a learner, designer or researcher.

Clone this wiki locally