DEPR Meeting Notes (2024)

DEPR Project board

 

14 November 2024

17 October 2024

  • devstack settings file deprecation has a few more weeks, due to AXIM priorities.

3 October 2024

22 August 2024

  • new DEPR tickets

    • a wave of new tickets have been filed

    • coming out of discussions about maintenance and what we (the community) would like to continue to maintain

    • ecommerce repos are really, really going to deprecated this time?

  • depr tickets getting announced to the depr channel

    • is this too noisy?

    • decided this isn’t for now. will re-evaluate as more depr work comes in

  • keep track of action items at the top of the page

    • want to make sure we ensure these things get done

  • how do we handle legacy frontends in edx-platform?

    • ticket for conversion of: Complete the MFE conversion process for edx-platform · Issue #31620 · openedx/edx-platform

    • try to enforce bugfix only in edx-platform for legacy frontends

      • can require codeowners approval for any changes to legacy frontend code

      • allow for an appeals process for exceptions

    • do we have a good catalog of the legacy frontends/views left?

      • can we make a list of where the old views should go in MFEs?

      • updates to MFE Rewrite Tracker

        • can add list of views to this page for further discussion

    • can we allow people to copy/paste old code from edx-platform?

      • ‘crappy’ MFEs

      • need to be able to make decent, reusable APIs in edx-platform, though

        • prevent APIs from becoming tightly wedded to the frontend as much as possible

      • are their performance implications?

    • do we have the capacity to handle these sorts of requests to update/change the legacy frontends?

    • current focus is to remove old frontends with replacements

      • this is easier than doing the full conversion

    • other replatforming work?

      • we got updates to learner dashboard and studio frontend.

      • big thing is instructor dashboard

        • APIs underlying it is being rewritten to be DRF APIs

        • can we be able to do the conversion tab by tab?

          • create a shell for new tabs to be added to?

        • we already have the gradebook mfe. can we turn this into the instructor dashboard mfe?

8 August 2024

  • Legacy Text Editors - What would it take to move off of them?

    • DEPR Ticket

    • Two Categories of Issues

      • Perf Issues, the new editor takes a long time to load large amounts of text.

      • UX Issues

        • How do we have the UX conversation about the editor?

          • 2U had a practice to add a “Feedback” button into interfaces to easily give feedback changes on UX changes.

            • The feedback buttons went out with openedx but where does that feedback go?

            • In Redwood.2 it will be removed instead of going to 2U

          • It’s unclear what the plan was with the studio MFE and the editor, what are our options for solutions?

          • This should go in as a new enhancement request to the Product WG so that we can plan and discuss this as a community.

        • FYI, Course Authoring MFE will have a full replacement for studio

          • The course outline is replaced in Redwood

          • In Sumac the Unit editor will also be replaced with an MFE Page

            • This new page will not work with the legacy editor so it implicitly drops the old editor support in the new UI.

            • In Sumac you can still drop back to the old UI/editor but in Teak, this might not work.

        • What’s the plan for the problem editor? The new MFE has a lot more issues than the old problem editor MFE.

          • Similar, to the text editor, the MFE is on by default in Redwood but the old one will still be available.

  • Review of MFE Rewrite Tracker to fill in DEPR ticket section.

    • Note: @Feanil Patel @Robert Raposa are also discussing this in Maintenance WG.

 

@Peter Pinch to put up some product tickets around improvements to the new Text Editor and new Problem Editor, Peter will get people closer to the problem to open the ticket.
@Kyle McCormick to check in with Jenna about re-prioritizing content-libraries work if having only the new editor might prevent people like MIT from using content-libraries all together.
@Kyle McCormick will make VideoBlock and ProblemBlock editor DEPRs so there is a place to collect feedback on those
Update this page with known views and add suggestions of which MFEs they should be added to: MFE Rewrite Tracker

25 July 2024

  • Open edX conference happened!

    • is there anything that came up that is particularly relevant to this group?

      • More conversations around https://github.com/openedx/open-edx-proposals/issues/595 occurred

        • There is a lot of desire to communicate more breaking changes via DEPR.

        • Many saw DEPR as one of the more mature and clear process in the open edx community.

      • Pinata was destroyed

        image-20240715-160032.png

         

        • Celebrating

          • paver cleanup and soon to be removal

          • platform assets cleanup

          • badges implementation

          • bok-choy

          • many other things

  • Automating cross-posting to Discourse/Slack

    • if a ticket moves into ‘Announced’ can we have that auto-announced to Discourse and Slack?

    • this requires development to get done

  • Maint WG proposal for DEPR process changes

11 June 2024

  • Profile and Account MFEs deployed to edge

  • Maintenance working group proposed using the DEPR process to communicate/manage all breaking changes in Open edX.

    • Seems like a good way of leveraging the existing knowledge and infrastructure to reduce duplication.

    • What do we need to do in order to make this change?

    • Could we make it more automated to reduce friction?

      • if a ticket moves into ‘Announced’ can we have that auto-announced to Discourse and Slack?

      • this could be similar to the discourse to slack automation to some degree

27 June 2024

  • replacement/extensibility of ID verification system: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4307386369

  • Node 18 deprecation

  • problem-builder deprecation: https://github.com/openedx/public-engineering/issues/268

    • this seems to be just for an already existing XBlock in the open-craft repository

    • good to see other parts of the Open edX ecosystem using the DEPR process to announce changes!

  • maintenance working group: expand and and contract for changes

    • use the DEPR process to announce breaking changes, not just deprecations

    • this would necessitate a change to the deprecation OEP to match this update to the process

    • overall, it seems good to leverage the existing process that people know about for this

    • adding metadata to track dates so we can filter/graph/etc them instead of relying on reading and parsing the ticket only

13 June 2024

  • testeng-ci deprecation

    • cleaning up the last few things still using it instead of repo-tools

    • mostly being used for Python upgrade

  • Studio frontend MFE DEPR ticket incoming

    • will trying to farm out work to CCs to help clean up the old views in edx-platform

  • Removed old calendar invite in favor of a new one set up by AXIM

30 May 2024

2 May 2024

18 April 2024

4 April 2024

  • Update the OEP to match the new process listed below

    • Hopefully the new process has been updated to accommodate everyone’s feedback

      @Deborah Kaplan to draft a proposal (create a PR) to update the OEP to match the proposed changes below
  • Go through the board, move tickets to the appropriate status according to the process

    • Moved tickets around and assigned new owners to some of them.

  • Send out announcements about the changes to the DEPR process.

    • This will happen once the PR to update the OEP has been created

  • [Diana] 2U is in the process of planning out how to handle the removal of the devstack infrastructure from openedx

21 March 2024

  • [Diana] [inform] Devstack has been deprecated/archived. 2u has created a fork.

  • [Feanil] https://github.com/openedx/public-engineering/issues/51 - Does Kyle’s latest suggestion here make sense? Should we proceed with this?

  • Discussion: how do we handle breaking changes in, for example, edx-platform in the future?

    • tutor maintainers will handle updating Tutor, but all the other operators will need to be informed and make the appropriate changes

    • ex: moving static asset compilation out of paver

    • 2U interested in maintaining a list of incoming work from DEPR/other community work that needs to be addressed by 2U

      • Can we make this information available to the public as well?

      • We are currently maintaining it within 2U boards, but maybe we can do this going forward

      • We aren’t doing a good job of marking tickets with the last open edx release

    • Should we have new metadata

    • Can we be better ownership of DEPR tickets and the work?

      • The person owning the DEPR ticket can update the ticket with information about the scheduling of the removal.

      • Encourages a conversation with the concerned parties about the timing and blockers internal to their organization regarding the DEPR.

    • We should update the OEP to reflect the new expectations around the people who do the removal

      • The person who is planning on doing the removal should post a comment to the ticket to let the people following the ticket know that the work is starting

      • Maybe we shouldn’t allow to the tickets to move forward out of ‘Proposed’ unless there’s an owner.

        • If the owner drops off the ticket, we going to move the ticket back to ‘Proposed’

        • We want to preserve ‘Communicated’ as the commitment to actually do the thing.

      • Proposal to update the process:

        • People can post things to Proposed whenever they want.

          • Optionally an announcement can be pushed to the community whenever to inform the community that we’re thinking of doing this deprecation.

        • Whenever someone comes around who wants to push the DEPR forward, they can pick it up and commit to being owner.

          • When they pick it up, they should be able to view the history of the DEPR via comments and state changes.

        • If they have to drop it, we move the DEPR back to Proposed.

        • Owner is responsible for informing followers on the DEPR ticket when the DEPR ticket moves through the various stages because GitHub doesn’t notify followers when this happens.

        •  

07 March 2024

  • [Diana] Don’t think we managed to talk about CourseGraph before

    • Who uses it besides 2U? I can file a DEPR, but I just wanted to get a sense before I did anything here

    • MIT pushes course data into a separate data store

    • This would allow us to drop a dependency on Neo4J from edx-platform

    • We can try filing a DEPR to see what happens

  • [Diana] Overlap with Maintenance Working Group

    • How do we want to split duties/areas of focus?

    • Should we be doing things that they’re doing right now? Are there things we’re doing that they should be doing?

  • [Diana/Feanil][inform] Tubular deprecation

    • The new plan is to remove the old retirement code from the tubular repo before deprecating/archiving it.

    • 2U is in the process of moving over, but it might be worth noting for other groups who use these retirement scripts

  • [Robert] What kind of process can we put into place in order to inform the community about things that are moved into ‘Done’ so that final org-specific cleanup can happen?

    • ex: bok-choy and 2U

      • Diana to pick up this action item to do the search on the edx org

22 Feb 2024

  • [Diana] Usage of CourseGraph? Can we rip out the integration in edx-platform?

  • [Feanil?] Tubular deprecation

  • [Diana] Timing of migration/deprecation of devstack and configuration

    • Have we gotten enough pushback from the community to justify leaving it in the openedx org? Is this just waiting on 2U?

    • [proposal] (Discussed in Maintenance WG)

      • Update https://github.com/openedx/devstack/issues/907 description to describe the new plan of 2U fork and of someone else maintaining (until Tutor is ready) or it being archived. (Make it clear in the DEPR that it has materially changed via warnings and/or closing and replacing.)

        • 2U will update the description and make a new announcement

      • Send an updated announcement that notes the new plan. 2U to continue to maintain devstack during the two week DEPR review period.

  • [Diana] Configuration

    • Update README to mention it’s deprecated

      • Update the openedx.yaml so it’s not tagged for release for Redwood

08 Feb 2024

  • [Dave] Announced django-splash deprecation.

  • [Dave] Kyle announced the Blockstore DEPR

  • [Diana][inform] Configuration updates

  • [Diana] Devstack DEPR - what does this mean on a practical level?

    • Should we talk to the community about who is still using it?

      • What announcements should we make?

      • Send a message to Slack about this deprecation.

    • Did add a notice to the top of the devstack repo.

    • Might still be better for MFE development, but there is a concerted effort to improve this.

  • [Robert] Insights DEPR, and potentially a meta-DEPR question.

  • [Peter] Has anyone been able to look at the edx.org xqueue database to find other groups using xqueue and/or xqueuewatcher?

    • Adam Blackwell did some digging on this that i will need to do some followup on, though he’s not at 2U anymore.

      • Adam told me that Daniel Streby would be the contact for graders. Should I reach out to him?

        • Not right now. The 2U folks will probably try to handle this side of things.

  • [Diana] Tag MFE DEPR tickets and create a blocked

25 Jan 2024

11 Jan 2024

  • [Adolfo] Axim’s picking up the frontend deprecation project (which we last discussed here in 18 May 2023) in earnest, for a December 2024 delivery. Would love a braindump from folks about this.

    • Jeremy Bowman is probably the best person to talk to about this, for high level strategy discussions about this work.

    • We need to get started on this soon

  • [Robert] [inform] Created [DEPR]: EDX_API_KEY #34039.

    • I don’t expect removal action on this, but just needed it documented to answer a question in Discuss.

    • Once accepted, a quick win might be updating a couple of docstrings, as details in this DEPR comment.

  • [Robert] [inform] The main effort behind [DEPR]: USE-JWT-COOKIE header #371 is nearly complete.

    • I may pass along the long tail work to someone itching for DEPR work.

  • [Peter] [question] Any news on deprecating xqueue and xqueue-watcher?

    • Is October still realistic for this?

      • We need to check in with the other course teams about this outside of MIT

      • What is the migration effort?

    • What is the actual cost of running this vs. running an alternative?

    • Finding courses still using it: look at the xqueue databases

  • [Diana] review board

    • Suggestion: Add a task list to our DEPR ticket template.[