He/you is Braden. They is OpenCraft. We are edX. (unless otherwise clarified)
Things he's surprised the platform doesn't support:
- In-video quizzes
- Easier authoring in studio
Building in time to their workflow to account for friction around merging upstream changes.
Do they wait for things to get merged before using them?
- Some clients are chill and can wait
- Often will have to deploy to a fork temporarily
What directions would you like to see the platform go?
- Excited for plugins
- Would like to be able to build custom stuff as plugins, which isn't always possible today
- Deployment is super complex
- APIs - documentation
Repositories they've contributed to?
- platform and blockstore? Or others?
- used to do work on analytics
- haven't touched many of the others
- payment providers
- analytics devstack - there was no way to run it locally
- First version of content libraries
OpenCraft uses Docker devstack
Sometimes have different devstacks if:
- extra IDAs
- Client is a release behind
How often clients on older versions?
- Clients who have been with them for a while, always on named release
- Never more than one release behind, generally
- If came from another open edx provider, maybe more behind, but they work with them to get their forks up to speed
- Has not tried himself
- worried about fragmentation and having too many ways to deploy platform
- Argument for doing things at two different scales - not everything edx.org needs is going to apply to smaller scale deployments
Excited about Appsembler's Figures package
- community supported analytics packages for smaller instances, then that's good
Changes to platform he has viewed as big steps forward or backwards?
- Quite a few! But not many that strike him as steps backwards.
- Simplifying configuration was exciting
- Documenting APIs
- Doesn't like: code in thousands of repositories - dependency management is hard. Doesn't view as a step forward.
- Likes the move to APIs with frontends that consume them - another big step forward
What can we do to expedite API improvements?
- edX spends a lot of time on upgrade efforts
How can the community help expedite these arch improvements (i.e., the APIs)?
- Hard for community to document an API if they don't have institutional knowledge of how it's supposed to work
- As part of existing projects, wherever working already, do housekeeping.
- how do you have that conversation with your business clients?
- Depends on how involved clients are, frankly
- Communicate clearly
- If more hands off, just do what they need to do
AJ mentions talk that OpenCraft gave this year at conference:
- history of OpenCraft involvement
Questions for edX:
- What are we (edX) excited for?
- API documentation, hope is part of larger effort tot have a well documebnted set of more generalized APIs that are useful for the community and us
- DevOps config and deployment work
- Bunch of cleanups in Juniper
- Python 3
- Adding APIs to XBlocks
- Has that effort grown? Is this an approach we can take to other XBlocks?
- Has not gone anywhere really
- Has ideas for replacement/evolution of XBlocks which support offline mobile from the get-go.
- OC built support for sandboxed XBlocks
- in an iframe on a different origin
- can execute JS but can't access session data
What are good ways we can ask the community for help? (ref: python 3)
- Usually not looking for something to do on its own, looking for something tied to their projects
- Have the INCR project really well defined - that's very helpful
- When you ask us to try new things out before their finished, that's helpful (especially ops-related things) Happy to try out early versions.
We have engineers who are not as open source-centric, and we also hire junior engineers. What would you tell them is the value of being open source first? Making that an essential part of their engineering lives?
- On individual level: Benefit is that your work is public and people can see what you've done, and you can point to it. Pragmatic reason.
- Philosophical reason: we're all benefiting from open source constantly, seems good to give something back and not just take, take, take.
- Benefits from open source - a lot more code review. More likely to be higher quality.
- Engaging with community, has its ups and downs, but is rewarding.
- Often a business challenge to get people to do open source - developers like it
- Hard to prioritize against other things demanding their attention
Evolution of XBlocks
- edX has been talking about frontend plugins - could this evolve into what Xblocks could be?
- Interested in frontend plugins - technically challenging
- Should connect on how this is related to XBlocks going forward
Thoughts about replacing/evolving XBlocks?
- Idea: Doing more in JS. It runs everywhere. V8 in python, JS runtime in iOS, very easy to get it wherever ou want.
- Can't do offline in python. But in JS, its trivial.
- putting allt the logic for a courseware component in JS, including the server side part of it.
- Gives you a ton of flexibility
- How to do assessment XBlocks so you can't cheat - i.e., when you need a backend.
Awkward question from Ned:
- What would you tell edX management to convince them it's important to accept/invest in contributions?
- The general argument is that you get features built for free / bug fixes for free
- hopes data shows that this is a worthwhile investment (i.e., more value from contributions than time spent reviewing it)
What happens if a OSPR isn't accepted by edX?
- they'll find some other way to implement - usually there's a good reason.
- Will try to do as a plugin if a client insists to do it
What's the average/ideal lead time to get something merged upstream?
- Ideally a couple weeks so it coincides with sprint goals
Harder to get product buy-in or engineering buy-in?
- Usually product is harder.
- Engineering buy-in early isn't has hard.