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.
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 edXteams'/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.
Manage space
Manage content
Integrations