• We switch to the two-week sprint model.
• Segovia will always be the main person responsible for support, supported by a two LDs and a review LD.
• Support can take up an estimated 10% of time every other sprint, although in reality that percentage will be much smaller.
• Backup testers: only when needed - estimated 10 hours a year

Note: Everyone will be expected to attend the Support Triage meeting the Tuesday before the new sprint, for handoff of ongoing tickets. ****That way current LDs and Kevin can update next weeks LDs on what happened that week, and any things to look out for.

Support Calendar

Important Links

Common Issues and Responses To TAs

Support Forms

HubSpot (Inspark)

SESE Google Form (HW, SES 107)

• Spreadsheet of responses

Infiniscope Form

Gates - These come from OLI to Kevin and Mia.

Bugs and Platform Issues

ETX 2024 Support JIRA Board

• For support issues

‣ board

• For bugs, assign tickets to Mia

General Support Process Flow

1. When an issue is received from a student, TA, or instructor:
   • Create a ticket on the ETX Support JIRA Board if it's an Infiniscope issue or an InSpark issue requiring LD attention. The ticket should include the following:
2. Once created, Kevin or an LD should move the ticket to the Triage column, under Discovery. This stage involves an initial investigation to determine if we have enough information, if it's a student error, or if there might be a problem with the lesson or platform.
   1. If you lack sufficient information, reach out to the ticket's submitter (a student, TA, or instructor), and place the ticket under Triage → Waiting for Information. Communication is best through Slack and by tagging people in the ticket.
   2. If it's a student error, provide the necessary information to the submitter, then move the ticket to the Done column.
   3. If there's a problem with the lesson or platform, move the ticket to In Progress and assign the appropriate LD (which could be yourself).
3. The In Progress column is where you investigate the issue, identifying the problem and the necessary fix.
   • If you're a Point LD and have determined a potential fix, you should:
   • If you're unsure about the issue or the fix, follow similar steps as above, moving the ticket to In Progress → On Hold and consulting a Review LD for the next steps.
   • If it's not an authoring issue but an adaptive page (advanced or simple author) or platform issue, you should:
   • If you would like, you can always create a copy of the lesson and try fixing the issue in the copy, just make sure you apply the changes to the actual lesson as well!
4. Once the fix is done, move the ticket to the Testing (QA) column. At this point, you will need to test your fix. The testing method depends on the course:
   1. If the lesson is only used in one or two course sections, publish the changes without pushing to all sections, and test in either an open and free or canvas version. Once the fixes are confirmed, you'll need to accept the updates in each course section.
   2. If the lesson is in many course sections, test multiple times in the author preview. Then publish the changes and push them to all sections. After that, quickly test your changes in open and free or canvas to ensure the fix worked as expected and didn't cause other issues.
   3. Minor fixes may not need additional testing, but for significant changes, it's good to ask Kevin, a student, or another LD to review it.
5. Once the lesson has been tested, move the ticket to Done. Then inform the person who reported the issue that the problem has been fixed, but (in most cases) for the student to see the fix, they will have to restart the LX. Communication is best through Slack and by tagging people in the ticket.

InSpark Support Process