Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Story: Check whether schedule changes provide at least one week of lead time #1650

Open
Tracked by #33
owades opened this issue Jul 21, 2022 · 0 comments
Open
Tracked by #33

Comments

@owades
Copy link
Member

owades commented Jul 21, 2022

Summary

As a Cal-ITP team member, I want to know whether a given agency has provided at least 7 days' notice for recent schedule changes, so I can understand their compliance with the GTFS Guidelines (draft v3).

As the draft guidelines state, Changes to the base schedule should be published at least one week in advance of every service change.

We are making an effort to automatically measure as much of the GTFS Guidelines as possible, so we can understand very easily where a given agency stands, and what support they need.

Acceptance Criteria

  1. I can see an overview of all GTFS schedule changes made in the last month* by the agency, showing:
  • The minimum "lead time" in days (if a schedule update was made on a Monday, to go into effect the following Wednesday, that would be a 2-day lead time.
  • The average lead time for all updates
  1. In implementing User Story: Data structure and/or dashboard to support GTFS Guideline check-level reporting #1688 an analyst/engineer should be able to use the output of this ticket to create the "check" defined as: "All schedule changes in the last month have provided at least 7 days of lead time".

*I wrote "in the last month" above, but we may find a shorter or longer window to be more useful.

Notes

I imagine this is blocked by the schedule pipeline v2, so it would be helpful to confirm with Laurie whether this would be possible post-launch.

Tester [Stakeholder]

  1. Scott O

Sprint Ready Checklist

    • Acceptance criteria defined
    • Team understands acceptance criteria
    • Team has defined solution / steps to satisfy acceptance criteria
    • Acceptance criteria is verifiable / testable
    • External / 3rd Party dependencies identified
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant