Page Comparison

Frontend-app-authoring issues and libraries

• Follow up from https://axim-collaborative.slack.com/archives/C04BM6YC7A6/p1731658458397369

• We’re using the repo’s issues both for task tracking for content libraries and for bugs and features coming into the rest of Studio.

  • That has made it harder for the maintaining team to pay attention to both the issues and bugs coming in as well as just managing the content?

  • Is that how we want workstreams for repos to work?

    • Would labels or tags help?

      • Labels per project might be useful so that we could filter out issues tied to an active workstream.

        • ie. if bug/issues related to an active project are tagged

• It makes sense to have the high-level epics stay on the platform-roadmap repo, but it would be useful to link to that from all the READMEs

• We can filter based on projects eg. ignore all tickets that are on the libraries overhaul project:

  • is:open is:issue -project:openedx/66

  • No other projects: is:open is:issue -project

    • Is this what the maintainer should be looking it.

    • If you have a lot of activity you may need something like this to filter out work that already have active folks looking at it.

      • is:open is:pr -project project:openedx/19 -label:FC

• What about bugs? Do the repo bugs go in public-engineering or stay in the code repo?

  • Keep the bugs in the FC issue list but if the FC closes move the bugs into the relevant code repo.

  • Testers will file bugs where they file them and we’ll triage and move as necessary.

Django

Setup.py related maintenance

maintainer-at-large status

(Time permitting) Devstack settings deprecation

Kyle McCormick

https://github.com/openedx/public-engineering/issues/247

Tutor's dev settings are a thin layer on top of its common settings overrides, which are always used with the yaml-based production.py. That means that "rebasing" Tutor's dev settings on to yaml-free common.py actually adds a ton of complex differences between Tutor's prod and dev, not to mention that it would break any tutor plugins that used yaml overrides.a

It seems that if we're going to rebase tutor's dev settings onto common.py, then we should do the same tutor's prod settings, and couple it together with a broader yaml deprecation. That does majorly increase the scope of this effort, probably turns it into a next-year project. Curious if you agree or if there's any small-bite work that you think I'm missing.

Discussion about a potential new ADR

https://github.com/openedx/edx-platform/issues/35898