DEPR Board Review

Context

Whether or not a DEPR had a replacement ready or not was always a simple fact, but the latest DEPR OEP now makes this more explicit with important timeline discussions that never happened before.

When https://github.com/openedx/frontend-component-footer/issues/459 started pushing forward again just before cutting Teak, it was argued that this was an old ticket, and should be grandfathered into a time when timelines weren’t discussed.

I (Robert) believe that the new process was created to avoid this situation, and a review of all the tickets can get us into a more stable place where we can avoid surprises for operators, especially those that are early deployers.

Ticket Timeline Updates

Timeline updates in DEPR Template

The DEPR template should better reflect all states and names of the new timeline noted in the OEP.

See https://github.com/openedx/.github/pull/167 for proposed changes.

Review After Date board field

[proposal] Add a “Review After Date” custom field that is displayed on the board.

• My [Robert’s] team puts this field to good use on our board. It has flexibility.

• The field generally means that the ticket has been discussed and is waiting on something to happen or simply time to pass, which would be noted in a comment on the ticket.

• The date doesn’t prohibit discussion, but when reviewing the board, it makes it clear what tickets can be skipped until a later date.

• An example usage would be if a ticket moves to “Transition Unblocked”, and we decide on a 1 month waiting period before moving to “Breaking Changes Unblocked”, we could update this field with that date so we don’t need to discuss the ticket again until then, and anyone looking at the board knows that the ticket wouldn’t be moving until that date at the earliest. For “RFC” tickets, you could use this field for the date we plan to move to “Plan Accepted”, etc.

• The board README could detail how this field is used.

DEPR Board Ticket Review

• “Draft” DEPR ticket review

  • Which tickets had been announced in the distant past, before made additional RFC requirements (e.g. having a coordinator or owner)?

    • A possible example: https://github.com/openedx/public-engineering/issues/316, which is actively trying to be pushed forward.

    • These tickets certainly require a coordinator or owner to make it to Plan Accepted.

    • [proposal] Any Draft ticket should have an updated timeline (see template improvement ideas below) before making it to Plan Accepted.

    • [proposal] A potentially short (3-7 day minimum) review period should be required to revive old announced tickets to allow for feedback on any updated timeline.

      • Set the new “Review After Date” board field as appropriate if we add this field.

    • [proposal] We add a comment to these Draft DEPR github issues noting what is required to move it to the RFC stage.

    • An example DEPR in this state is: https://github.com/openedx/edx-platform/issues/33627

  • Are there any old tickets that should move to “Abandoned/Rejected”, or do we not care if the Draft column grows forever?

    • Again, we could use the “Review After Date” (if added) to note that the ticket was once reviewed, and that we don’t see a need to look at it again until this future date (a month out, a year out, etc.).

    • This “Review After Date” would also help indicate to us all the tickets we have reviewed in this board review, assuming we won’t get through all tickets in one session.

• “Plan Accepted” ticket review

  • Does the ticket have a coordinator/owner? If not, move it to draft and follow the Draft ticket review.

  • Does the ticket have all timeline details? If not, determine whether it should move to Draft, or should just get updated and potentially re-announced as an inform, etc.

  • Is the replacement ready? If so, should move to “Transition Unblocked”.

    • We could start the 1 month countdown and inform others.

    • This would provide a 1 month warning, and avoid surprises, but how many tickets fall into this category after completing this board review? Too many? 1 or 2?

  • Set the new “Review After Date” board field as appropriate if we add this field.

• “Blocked” ticket review

  • Is this status needed, and how will it be used?

  • If we keep this status, we should note it in the OEP so the board and OEP reflect each other.

• “Breaking Changes Unblocked” ticket review

  • Since this was recently renamed, we can double-check that removal is imminent and that everyone is aware of these tickets.

  • Set the new “Review After Date” board field as appropriate if we add this field. In this case, it could simply mean we don’t need to check on ticket progress until after this date.

DEPR OEP improvement ideas

• The OEP could do a better job highlighting "coordinator" responsibilities. Namely, it should clarify that this role is about seeing a ticket through from RFC to Plan Completed.

  • In the diagram, could "Someone is ready to own the ticket and does RFC work" => "A coordinator is ready to own the ticket and does RFC work"? I'm looking to make a link between whatever term we choose and the diagram.

  • Is "coordinator" the right term? What about something like "ticket owner"?

  • We should note that the “coordinator” becomes the assignee on the DEPR ticket, and that only Draft DEPR tickets might not have an assignee.

  • Who’s job is it to ensure that each ticket is in the proper column on the DEPR board? The DEPR WG? The coordinator?

• The OEP could point to https://openedx.atlassian.net/wiki/spaces/AC/pages/23003228#EverythingAboutDatabaseMigrations-Howtodropatable as special considerations during removal.

DEPR Ticket Tracking for Operators

It was noted that https://github.com/nedbat/dinghy exists as a possible tool for deployers to track changes on the DEPR board.