Kyle McCormick

A little more detail on the migration path I'm imagining... we'd collapse all of `FEATURES` into the root of common.py. For backwards compatibility, we'd provide a magical `FEATURES` dict for...

@robrap You're right, linting is totally feasible here just by inspecting the length or keys of the FEATURES dict.

@robrap Regarding naming... I'm looking at common.py to see what other third-party apps do. It seems like the convention is to prefix with feature area, so I like that a...

@robrap Oh, I didn't realize that there was edx-toggles work in flight--nice! > Yours is a more elegant solution from a readability perspective, as long as people don't get caught...

> Leaving studio_duplicate alone - I don't think that sort of code belongs in the XBlock but rather the runtime, where it already was. Agreed, please revert the studio_duplicate changes...

@bradenmacdonald `editor_saved` is already used by SplitTestBlock and VideoBlock. `post_editor_saved` is used by the (legacy) LibraryContentBlock. This PR just formalizes the methods into the CMS XBlock inheritance hierarchy (well, kinda--...

This ticket will handle upgrading codejail itself to 3.11. As a follow-up, we will need to upgrade edx-platform's codejail execution environment (a.k.a. edx-sandbox) to Python 3.11/3.12: https://github.com/openedx/edx-platform/issues/34469

I'm fully in favor of removing a dependency on a 3rd party service that doesn't work (and manages to [break our builds ](https://about.codecov.io/blog/message-regarding-the-pypi-package/), too), but enforcing code coverage still strikes...

As I understand it: * This is an issue for people creating new repos. Existing repo are already working around it, either by using something else or by disabling coverage-checking...

@robrap Ah, I was confused too. I didn't realize that this was an active issue for existing repos. Those docs look great @dianakhuang ! Would you both agree that: *...