• In-video quizzes
• Easier authoring in studio

• Some clients are chill and can wait
• Often will have to deploy to a fork temporarily

• Excited for plugins
  • Would like to be able to build custom stuff as plugins, which isn't always possible today
• Deployment is super complex
• Blockstore
• APIs - documentation

• 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

• extra IDAs
• Client is a release behind

• 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

• community supported analytics packages for smaller instances, then that's good

• 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

• edX spends a lot of time on upgrade efforts

• 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

• history of OpenCraft involvement

• 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

• 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.

• 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

• 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

• 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.

• 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.