Implement Track Changes

[jrbl]

@stephensanchez please. I'll be on vacation next week, but @caesar2164 and @stvstnfrd will be around and can handle our end of the PR process.

• Creates "TrackChanges" django model, which ties a (submission_uuid,
  scorer_id) pair to a set of edits suggested by peers for a particular
  submission.
• Adds machinery for on-the-fly installation of the New York Times's ICE
  library for collaborative editing, allowing peer assessors to create
  marked-up versions of submissions, which can then be returned to the
  author as feedback.
• Adds machinery for displaying suggested edits to the creator of a
  submission with their scores and other feedback.
• Configurable within Studio on a per-Assessment basis by including a
  URL to the ICE library as part of the assessment definition.
• For additional details, see:
  https://docs.google.com/document/d/18PITJu133sFpDl_B2GCbo2eb0GODcwVmVsktwPQfVSg/edit?usp=sharing

Co-authored-by: Giulio Gratta giulio@giuliogratta.com
Co-authored-by: Steven Burch stv@stanford.edu
Co-authored-by: Joe Blaylock jrbl@jrbl.org

[sefk]

Peeking in on the AUTHORS file here, @jrbl is already in there but @stvstnfrd and @caesar2164 are not. Maybe one or both should be added in this PR?

[stvstnfrd]

AUTHORS updated at 52b0d8b

[sarina]

Also this needs a rebase - appears to have a merge conflict w/ master

[caesar2164]

@sarina & @stephensanchez - this is now rebased and squashed and all pretty ready for review!

(tag @jrbl, @stvstnfrd & @sefk)

[stephensanchez]

Thanks @caesar2164 ! I'm going to ping @explorerleslie and @Lyla-Fischer to get a product review of the feature before we go through the full code review.

It may be worthwhile to get some readthedocs dev documentation around this feature, to better understand what steps are required to get this working on the platform.

[sarina]

@caesar2164 while you're waiting for Product review I recommend that you investigate and solve your test failures, as well as make sure your test coverage is as close to 100% as possible.

[stephensanchez]

@andy-armstrong just FYI on a new ORA2 feature in the pipeline.

[wedaly]

If this is the case, I think you should add a unique_together constraint so this invariant is enforced at the database level.

[stephensanchez]

Done reviewing for a first pass, once some of these changes are completed I'll try standing up a VM with the branch and see if anything stands out.

One additional comment, via the email chain associated with this, is that we'll need a way to put this all behind a feature flag.

[stephensanchez]

I don't have a silver-bullet suggestion for this, but the track changes logic throughout the mixins and xblock is a bit inter-woven and it'd be nice if it were more cleanly separated. The solution may be another mixin, that declares the additional fields and logic that is found throughout, but I imagine whatever the refactoring will be beneficial to putting track changes behind a feature flag as well.

[sarina]

Review ticket: https://openedx.atlassian.net/browse/OSPR-31 Please add any supporting information to this ticket. JIRA is a place for product owners to prioritize feature reviews. Supporting information that is good to add there is anything that can help Product understand the context for the PR - supporting documentation, edx-code email threads, timeline information, partner information, etc.

[stephensanchez]

@stvstnfrd @caesar2164 I just want to check in and make sure I did not miss anything; we're still looking to update the CSS to SASS, and put the functionality behind a feature flag? I don't mean to rush anything, I just want to make sure I'm not being a neglectful reviewer.

[sarina]

Hi everyone: just going through old PRs. Is this PR still under active development? If not, would it be appropriate to close it? It can always be reopened (or a new PR submitted) at a later date.

[sarina]

Haven't received a response on this PR so I'm going to close it for now - it can always be reopened when it is ready to be reviewed.