Name Release Details Delivery Est.
v1.1 Discussions Provider Selection UI & Piazza LTI Config within Studio (edx-admin) Goal: Shift away from Django Admin configuration for third party forums, the initial implementation of Support level and feature matrix Scenario: An edX Developer can go to frontend-app-course-authoring in production to see “Pages & Resources” view with Discussions card. Clicking the discussions configuration action pulls up modal with provider selection (hard coded list from code), and you can pick legacy edX or Piazza to start. (legacy edX option has no config options) From this provider selection, the next button then pulls up modal with LTI configuration details for Piazza. This release has basic hardcoded feature table needed for educator rollout of which features are supported. Next Step: TNL task for tickets / stories to be ready for grooming - @David Joy (Deactivated) Runbook: TBD Details “hard coded list” of discussions apps says name and also has a capabilities list. Piazza would have no capabilities by default, just LTI. edX Forums would have all capabilities. This informs the feature matrix and the configuration UI. v 1.2 Legacy edX Discussions Provider Selection UI (edx-admin) Goal: Enable configuration of legacy edX discussions from new discussions configuration / selection area. Scenario: An edX Developer can now configure the legacy edX discussion provider option and see the supported configuration settings are for legacy edX discussions. v1.3: Yellowdig Discussions Plugin and Conversion Goal: Enable Yellowdig Plugin to switch more courses over to new model v1.4: New Pages & Resources View Goal: New Pages & Resources View Live on Production, enabling easier configuration of course tools (Discussions only to start, to establish a pattern) Questions: What tiles will we include in this milestone? A: for this milestone, just focus on Discussions. We don’t need this view to be available for course teams, so it doesn’t have to fully make sense. Q: Existing API PRs? Use Cases: edX admins can use this new page to configure discussions, rather than using django admin. Runbook:
v1.5: Full Rollout of Pages & Resources View | Goal: Shift educators from old Pages view to new Page & Resources view in production Use Cases: whatever isn’t in v1.2 that would let us deprecate the existing Pages view | |
v1.6+: Educator Preview of New edX Discussion Experience | Goal: Pilot Educators enrolled in course with new discussions experience for ongoing feedback + comments Next Step: How feasible to land / test / break up into more milestones? Runbook: TNL Release Details, Blended Release Details | ~Late Nov |
v1.7+: Educator Preview of New In-Context edX Discussion Experience Goal: Runbook: TNL Release Details, Blended Release Details ~ v1.8+: Educator Configuration of Basic Support Discussion Integrations (Yellowdig, Piazza) Goal: Moving forward, defaulting to new config model & educators can do them themselves Runbook: TNL Release Details, Blended Release Details ~Early Dec v1.9+: Pilot Migration to New edX Discussions Experience in Select Courses v1.10 Enable Catalog Option to use New edX Discussions Experience v1.11: Discussions Social Presence: Profile Pictures v1.12: Learner / Moderation Notifications
Milestone 1 Questions (from earlier meeting:):
What is the UX of a course team selecting a discussion app configuration? Do they first select the type (Piazza) and then a specific integration?
Partial Conclusion: We don’t expect to have a dropdown for picking a particular Piazza integration.
Is it a requirement that administrators be able to set up an integration once and then it can be re-used across courses?
It’s not a requirement to be able to share secrets/basic LTI config across a site or org
We do not need to have customizable defaults for config at the site or org level.
Conclusion: We don’t need to have config_overrides - there’s nothing we care about overriding.
What is the right data model for discussion configuration?
Is configuration composable, and if so, who are the composers? (user roles, personas, instructor vs. admin, etc.)
Educators can configure a specific learning context’s LTI details per program / per course run along with settings for that course run ( ex: in-context is off)
Administrators (edx internal for now) can decide which providers to show / limit for a given organization, but all options are visible unless otherwise specified.
What is the right level of configuration reuse, from a security point of view?
It matters what kind of configuration it is, and who can see it.
There’s configuration at the course team and user level as well.
Technical discovery on providers:
For Piazza, Yellowdig, etc., should we see what their actual configuration looks like, so we understand what level of composability makes sense?
Piazza, same URL regardless of which LMS/course you use, the other credentials depend on which class you want to integrate with. If you want the same forums across two courses, you need to use the same credentials.
One set of credentials used across multiple courses, but with different “class” (Piazza’s term for a course) IDs per course. We expect we’ll use course IDs to differentiate between them. Today you have to send them an email to set up a new class ID and associate it with your credentials.
Concern from Kshitij - sprint ending on 16th, so to reach any sort of milestone, need clarity ASAP.
Easier to move from split to combine, moving in reverse is a lot harder.