Page Comparison

OpenedX releases

• Going from 4 months → 6 months

Waffle switches/flags/samples

• Why we don't like them

  • It’s dumb that the configuration is in our database.

    • Hard to debug

    • Hard to manage/duplicate

  • There is now no validation or review before making a change.

  • Often they don’t have good docs on how to manage them.

  • Often don’t have many people who know how they’re supposed to work.

  • Even if we had manual review, review of django-admin UI is not as good as reviewing code or config.

• Some reasons why waffle is nice.

  • Sometimes we want to roll-out low risk things and changing settings via remote config is WAY slower and has more overhead.

  • Really useful for quickly flipping and testing a configuration before ripping the flags out.

• Things we’re doing that should help?

  • Toggle Documentation Improvements

    • Should this be required?

  • We could be reducing complexity of the waffle things by building/simplify better waffle base classes.

• Other Notes

  • Making more abstraction layers on top of waffle/django might not be a great idea.

  • However if we are constantly fighting our flag framework.

Let pyupgrade switch %-formatting and {}-formatting to f-strings?

• f-strings are usually easier to read, any objections to moving to this?

• How does this work with translations?

• is the "optimization" faster than both %-formatted and str.format or just one?

  • Jeremy thinks yes.Dave

  • DaveO points out that string interpolation doesn’t ever seem to be in the critical path for perf, so don’t make that the primary concern.

• Major re-format will cause downstream issues with people maintaining forks.

• Feanil: What if we also run Black?

  • If we’re ruining the git blame anyway, may as well do it now.

  • Reasons not to do this:

    • Black diffs are much harder to read and might produce more merge conflicts in the future.

Open edX contributions:

• What’s eduNEXT?

  • Open edX company based in Colombia, doing some blended development work for us

    • They’ve been to 7 of the 6 open edx conferences.

• Do we merge any PRs from any open edx contributors? Or is there some flag that identifies the GitHub user that we can take contributions from?

  • No, we don’t just merge everything.

  • Bot will greet open source users and make sure they have signed a contibutors agreement. This can be used to spot open source PRs

  • You should review any PR before accepting it.

• What is blended development and what is the typical workflow for blended development tickets? What are teamsedXteams'/developers' responsibilities towards OpenEdx/blended development tickets?

  • Sometimes Blended PRs get auto closed, and devs don’t know why?

    • The PR is linked to a Jira ticket, if the PR is auto-closed it might have been because the Jira ticket closed.

  • Some engineers are getting tagged directly on blended tickets.

    • You should make sure your team is aware of it and that it’s tracked on your side. Blended projects might tag you because your team owns a repo being updated via blended.

• Have more questions ask in the #openedx channel

Ownership

• Different teams are treating ownership differently.

• Some teams are treating ownership more loosely when it comes to upgrades than others.

  • Is this okay?

• (Product management is not fully onboarded or clear on the implications of ownership either. Awareness and confidence in plans are unevenly distributed here - Marco)

Rebranding edX.org and its i18n implications - defered till next time.