Document Snapshots - Bring reliability to publishing and safety to editing

[iturgeon]

This is an excerpt from notes taken during a brainstorming session between @zachberry and @iturgeon

The discussion focused on issues around these topics:

• exposing modules to the public library
• faculty using their own modules in their own course
• faculty using another author's public library modules in their own course
• how editing and updating effects published modules

Document Snapshots Proposal

Goals

Safety for Editing

Allowing faculty to update modules w/o the fear of losing something or screwing up something in a live course. Zach's personal use case on this: he creates a copy all the time just to make sure he doesn't mess something else up. However, with something like Google Docs, he doesn't. The first half, version history is solid and safe. The remaining half is the fear or messing up a course while editing a module. Editing or updating a module that's in use shouldn't have the threat of causing 2000 students to email their instructors.

Prioritize Reliability For In-Course Use

For faculty, it's important that they can rely on their course content as much as possible. Having a sudden issue caused by something out of their control is going to be a pretty terrible experience. We need to make sure using an obojobo module isn't a nail-biting experience.

Inform Faculty About Module Updates

Ok, great, we'll create reliability by not auto-updating modules. The cost to this is faculty no longer get automatic updates. We need a way for faculty to stay informed about newer versions and elect to update.

Assumptions

• people are probably making a lot of copies to compensate for live updates
• working on a module used in a course is scary to everyone, if it's not they just don't realize why they should be scared.
• faculty prefer reliability over automatic updates of content

Features and Implementation

• a snapshot is a new construct/model. It has a name, version, draft, content_id, publish date, and description
• snapshots have versions, new versions can point at updated versions of the same module
• snapshots inherit ownership from the module they were created from
• placing something in the public library requires creating a 'snapshot'.
• Technically, the module isn't in the public library, the snapshot to a specific version is.
• a new parallel concept to 'public library' named 'personal library'.
• what appears now on the dashboard will be 'my workshop' (needs a name maybe)
• public library modules display last update date, name, version number. Allow access to previous releases (not same as edit history)
• authors can continuously save and update the module without fear of automatically updating it in anyone's course
• for instructors the launch interface in the course:
  • shows what version is in use
  • tells them there's a new version
  • lets them quickly update, or choose any published version
• When you embed from personal library, there's a checkbox to turn on live update mode.
  This will alleviate having to find them in the course to updating your own modules. The reason we don't have this for public modules is to make sure authors feel safe while editing modules in use in many courses.
• the changes to launch interface will require new query params. (Potentially snapshots get a new url? We'll need to support the old urls or update them)
  • snapshot=xxx
  • autoupdate=true|false
• publish to public library checks for that module already being present there.
  • If not present, add.
  • If present, tag version "v1.2" to the existing one.
• people who add from public library always get the current version: future feature allow them to choose from older versions

[maufcost]

When authors create/fork a snapshot module from a public library module and make changes to it, do you have any ideas how we are going to handle perhaps "merge" conflicts when authors try to update the snapshot with a newly available version of the original public library module? Or for now, the new retrieved updates from the original public library module will just override any updates to the snapshot?

If no overriding is going to happen, when updating a snapshot with new updates from the public library, perhaps we could let authors choose on Obo's UI which changes originally made to the snapshot they would like to carry on to the new updated snapshot (in order to solve merging conflicts).