[BD-03] 2020 Nov Sync: Agenda & Notes

11/12/20

• Status

  • David

    • able to get everything up and running - still needs to try Piazza

  • Steven

    • Technical concerns - need to change the way the tables interact, and maybe simplify

  • Kshitij

    • Piazza plugin is being cleaned up, up and running

    • Once we have the YellowDig plugin we’ll have two LTI plugins and we can extract the common parts, which will let us create an LTI-based plugin system. Going to work with @Giovanni Cimolin da Silva on this.

    • Discussions MFE UI

      • Figuring out the next steps for next phases

      • Which are the latest mockups?

    • On leave until Monday

    • Wants to plan out next phase which is v1.1

      • YellowDig Plugin

      • Not much config UI needed for either, since they’re just LTI-based

      • Do we want course authors to ever enter LTI credentials?

        • We do expect that authors would be specifying LTI keys/secrets for each course run

          • We want “new” forums for each course run

      • LearningContext flexibility is helpful for site/program level integrations, not necessarily to share an integration across multiple courses.

  • Marco

    • MFE TinyMCE UI Update - Minor note on TinyMCE, some UX review of controls + tools for discussions to show here: https://miro.com/app/board/o9J_ksXJkmY=/?moveToWidget=3074457351245072963&cot=12

      • still don't have answer for how to include symbol previews (tinyMCE plugin options exist) but the goal here is to remove the markdown + preview box areas to have 1 text entry area.

    • All Discussion Links from now on will be to this 1 Miro board: https://miro.com/app/board/o9J_ksXJkmY=/

  • Config code tech discussion

    • Relationship between two tables - using a foreign key. Because they’re historical tables, the course-level config would be locked to a historical version of the discussion provider. If someone makes a change to the discussion provider, how does that then get propagated to the courses that depend on it?

      • Response from Kshitij:

        • had almost the exact opposite goals in mind when designing it.

        • Think it may be better to think of this from scratch and come up with a simpler approach.

        • Historical tables should be for auditing - understanding who made what changes when, and be able to revert.

      •  

11/4/20

• Reviewed Discussions Milestones, in particular what is in scope for v1.0, v1.1

  • Reviewed PRs, set goal, broad details on runbook requirements for v1.0.

•