MVTA.com Service Change Procedure

Purpose

This procedure explains how to update the MVTA.com website when there is a service change. It covers which parts of the website need manual updates for the new schedule and who is responsible for making these updates. This ensures that changes are made quickly and smoothly, and it includes what to do if problems arise during the updates.

Scope

This procedure is limited to scheduled service changes, and some aspects (particularly anything mentioning timing) may not apply to an emergency service change.

Responsibilities

Party Summary of Responsibilities Current Lead Current Backup IT Lead Coordinates execution of this procedure, inspects the GTFS schedule for changed service IDs, provides the first line of technical support for any issues that arise, engages with the Website Developer (Creed) as needed, and leads efforts to improve this procedure. Shad Uhl John Miller Customer Service Lead Runs the GTFS import to the staging website, updates route PDF files and route titles/descriptions, verifies that the Routes page is accurate and complete, reports issues found during verification of staging, determines if staging is ready to push to production, and performs the push from staging to production. Richard Crawford Jason DeMoe Planning Lead Initiates the service change process by notifying the working group of upcoming service changes and provides clarification (upon request) about the details of the new schedule. Grace Almeida Ethan Buss Website Developer Provides the second line of technical support for issues arising during this procedure and adjusts preconfigured service IDs to match the new GTFS schedule as needed. Creed
All Departmental Leads (Includes IT Lead, Customer Service Lead, and Planning Lead) Communicates openly, proactively, and in a timely manner throughout the process and adhere to the responsibilities defined in this procedure.

MVTA.com Working Group Assists in resolving technical issues that arise during this process (as applicable) and participates in process improvement activities.

Key Considerations

All updates should be performed in the staging environment. Staging should not be pushed to production unless (1) all updates have been completed, (2) all updates have been verified, and (3) any issues arising from the updates have been resolved. This ensures that the public-facing (production) site does not have incomplete, inconsistent, or erroneous information at any point in the process. The Website Developer is not available after hours or on the weekends (even in emergencies), so it's important that we only make changes in staging and carefully consider if we are ready to push to production.

Because new schedules erase old schedules, the new schedule should be pushed to production as close as feasible to when the new schedule begins. The Routes table will only show schedules for the old schedule or the new schedule, but not both. We want to reduce the likelihood that a rider would look up the timetables for today and see that there are no trips scheduled for the day. To achieve that, the new schedule should be pushed to the production site as close as feasible to when the new schedule begins (for example, 9 pm the night before the schedule begins).

When this guide uses "share with the group", that means notifying the entire MVTA.com Working Group by posting in the working group team in Teams or by sending an email to all group members. Using one of these communication methods will ensure that all group members are aware of important developments in the service change process, and will help facilitate open communication and transparency. When in doubt about whether the group should be notified about something, err on the side of notifying the group.

Procedure

Initiation: Preparing for an upcoming service change.
Due by: One week prior to service change date.
1. The Planning Lead notifies the MVTA.com Working Group that a service change is taking place soon. This notice should be shared with the group at least a week prior to the date of the service change in order to allow time for coordination among group members.
  
  The notice should include the approximate date/time that the new GTFS schedule will be published in Avail.
2. Each of the departmental leads on MVTA.com (the IT Lead, Planning Lead, and Customer Service Lead) replies to the notification, confirming their availability to perform duties outlined in this procedure, or designating a substitute to fill in for them (for example: I'm on vacation on the day we'll be verifying the changes in the staging site, and so-and-so will be filling in for me).
Staging updates: Updates are performed to the staging site.
Due by: Morning of the day before the new schedule starts.
1. The Planning Lead notifies the MVTA.com Working Group that the new GTFS schedule has been published in Avail. Typically, this will be in the morning of the day before the new schedule begins.
2. The Customer Service Lead runs the GTFS import into the staging site. This is documented in this procedure: How to manually synch website. The GTFS import to staging should be performed as soon as feasible after notification that the GTFS schedule has been published Avail, in order to allow time for the remaining steps in this procedure to be able to be performed.
3. The Customer Service Lead replaces the route PDF files with updated versions for the new schedule. This is documented in this procedure: How to update route details on the website.
4. The Customer Service Lead reviews route titles and descriptions for accuracy with the new schedule and makes adjustments to them where necessary. This is also documented in this procedure: How to update route details on the website.
Staging verification: Updates to staging are verified to be accurate and complete.
Due by: Afternoon of the day before the new schedule starts.
1. The Customer Service Lead verifies that the Routes page is accurate and complete. The GTFS import step should have updated the Routes page's (found at https://mvtamnstg.wpenginepowered.com/routes/) list of routes, their timetables, their stops, and/or their shapes on the map, and this step is to verify that those updates match the new schedule. This is documented in this procedure: [[NEEDS TO BE DEFINED: HOW TO VERIFY THE ROUTES PAGE ON MVTA.COM]].
  
  As needed, the Customer Service Lead works with the Planning Lead to interpret details of the new schedule (for example, is it correct/intended that route X doesn't run on Mondays in the new schedule).
2. The Customer Service Lead verifies that the route PDF files, route titles, and route descriptions are accurate and complete. These were updated by hand in the previous (staging updates) phase and this step is verifying that effort.
Staging troubleshooting: Any issues identified during verification are resolved.
Due by: Evening of the day before the new schedule starts.
1. The Customer Service Lead reports any issues identified during verification. If any discrepancies are observed between the Routes page and the new schedule, or if any other issues are observed with the Routes page, they should be reported as soon as possible so they can be resolved before the start of the new schedule. The Customer Service Lead is the one responsible for reporting issues, though anyone else who finds an issue is also welcome to report it. Issues are reported in this manner:
  1. First, the person reporting the issue creates a ticket in Freshservice. Creating a ticket in Freshservice is described in this article under "Report an issue": How to Access and Use Service Desk. Describe the website behavior observed, what it was expected to do, and include screenshots whenever possible.
  2. Second, the person reporting the issue notifies the MVTA.com Working Group. This can include the same content as provided in the ticket. Notifying the working group in this way ensures that we're all on the same page about issues that were found.
2. The IT Lead troubleshoots the reported issues, keeping the MVTA.com Working Group apprised of progress. Using standard troubleshooting methodology, the IT Lead troubleshoots the issues, working with other members of the MVTA.com Working Group and/or the Website Developer (Creed) as needed. In the event that a full resolution to an issue is not achievable in time to push staging to production, mitigating steps should be identified and performed. The IT Lead should notify the working group with regular progress updates and when an issue is believed to be resolved.
  
  Because the Website Developer (Creed) is not available after hours or on weekends, there may be issues that arise that we cannot fully resolve before the new schedule begins. How to proceed in this situation is addressed later in this procedure.
3. As reported issues are resolved, the Customer Service Lead verifies that they have been resolved satisfactorily. Verification steps relevant to the issues should be repeated. The Customer Service Lead should notify the working group on whether the issue resolution was satisfactory or if it still needs to be fixed. If it still needs to be fixed, return to the previous step in this procedure.
Staging push to production: The changes made in staging are pushed to production.
Due by: 12:00 AM on the day the new schedule starts.
1. The Customer Service Lead, in consultation with the MVTA.com Working Group, makes a determination on whether the changes to staging should be pushed to production. Ideally, the staging site will be accurate and complete at this point, and it can be recommended to push to production.
  
  However, if updates to staging are not yet complete or issues have not yet been resolved, it may be prudent to delay pushing to production until the staging site meets expectations. The production site should only include accurate and complete information, and if it cannot be fully accurate and complete (whether because staging is pushed as-is or because the new schedule begins before staging is pushed), the Customer Service Lead is responsible for determining which course of action causes the least harm (and should therefore be taken). This determination should be made in consultation with the working group.
2. If it was determined that staging IS ready to push to production, the Customer Service Lead pushes staging to production. This is documented in this procedure: How to Promote from Staging to Production for mvta.com.
  
  The push from staging to production should be done as close as feasible to when the new schedule begins (for example, 9 pm on the day before the new schedule begins). See the discussion under the Key Considerations section for why this is important.
  1. The Customer Service Lead verifies that the staging to production push was successful. The full verification steps that were completed for staging do not need to be completed for production. Verification that the production site is up and a cursory examination of whether the Routes page was updated are sufficient.
  2. The Customer Service Lead notifies the MVTA.com Working Group that the staging to production push was successful. At this point in the procedure, the service change updates to the website have been completed.
3. If it was determined that staging is NOT ready to push to production, the Customer Service Lead will engage the working group to define (1) what adjustments must be made in order for a push to production to be appropriate, (2) who will perform these adjustments, and (3) a timeline for when these adjustments (and the push to production) will be completed.
  
  One consideration in this is that a permanent, complete fix to every issue may not be feasible before the new schedule begins, and therefore mitigating steps (such as a message on a web page explaining that information on that page may be inaccurate and we're fixing it as soon as possible) should be considered.
  
  When the defined adjustments have been completed, the relevant steps of the Staging Verification section and the Staging Push to Production section of this procedure should be repeated.
Closure: The procedure execution is reviewed and adjusted as necessary.
Due by: The next regularly-scheduled meeting of the MVTA.com Working Group.
1. The IT Lead shares any lessons learned or procedure improvement suggestions. Reflecting on how a process could work better is a key element in creating effective processes, and this step ensures that there is an intentional effort to improve the process. Lessons learned and procedure improvements may be minor or major and may reflect things that went well or things that went poorly. Care should be taken to avoid placing blame on any party (it's not about that), but rather imagining how the process could work better.
  
  Lessons learned or procedure improvements should be shared with the working group. This should be completed prior to the next regularly scheduled meeting of the working group.
2. Members of the MVTA.com Working Group share any additions or modifications to lessons learned or procedure improvement suggestions. While it's good to have one person kickstart the conversation, the feedback of group members is crucial, and this step gives group members the chance to share their perspectives. Group members need not wait until the IT Lead has posted lessons learned or procedure improvements before sharing their suggestions.
3. The IT Lead updates procedure documentation to incorporate lessons learned and procedure improvement suggestions. As applicable to the specific lessons learned or process improvement suggestions, this process or the processes it references should be updated and any changes should be shared with the group.

This procedure was approved by the MVTA.com Working Group on June 6, 2024.