Milestone Planning: Discussions Improvements + Integrations (Phase 1 + 2)
Closed / Resolved Milestones
In Development Milestones (Phase 1)
To Be Closed / Resolved in Phase 2
Roadmap Preview
To Be Considered for Phase 2 Milestones
Some budget to be allocated for future milestones not yet in Jira that need additional definition work + partner input.
* Moderator email notifications / digest for flagged content or content in need of moderation
* Learner email notifications / digest for updates “My Posts” content
Platform Cleanup and Health (redistributed to other milestones)
Improved Role & Permission Configuration for Discussions Apps
Support External Development for Medium + Full Support Integrations
Support Import / Export Persists Discussions Configuration
Import / Export Support to enable Github Authoring Workflow still persisting Discussions configuration
TBD --> v1.N Refactor from Ruby to Python (Cs-Comments-Service)
https://openedx.atlassian.net/secure/PortfolioPlanView.jspa?id=18&sid=18#plan/releases
Archived Details
Name | Release Details | Delivery Est. |
|---|
Name | Release Details | Delivery Est. |
|---|---|---|
v1.0: Previewing Basic Support for Discussion Integrations | Goal: Manually convert X new course runs to new framework Runbook: details on what that manual configuration/rollback looks like - Steven or David (https://openedx.atlassian.net/browse/TNL-7666 ) | December |
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:
Next Step: TNL task for tickets / stories to be ready for grooming - @David Joy (Deactivated) Runbook: TBD Details
|
|
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:
|
|
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.
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: | ~Late Nov |
v1.7+: Educator Preview of New In-Context edX Discussion Experience | Goal: Runbook: | ~ |
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: | ~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 |
|
|
| Authoring / Operating | Engaging | Developing |
|---|
| Authoring / Operating | Engaging | Developing |
|---|---|---|---|
v1.0 |
|
|
|
v1.1 |
|
|
|
v1.2 |
|
|
|
v1.3 |
|
|
|
v1.4 |
|
|
|
v1.5 |
|
|
|
v1.6 |
|
|
|
v1.7 |
|
|
|
v1.0: Previewing Basic Support for Discussion Integrations
https://github.com/edx/xblock-lti-consumer/pull/77
Enables embedding LTI content outside an XBlock
v1.1: Educator Configuration of Basic Support Discussion Integrations (Yellowdig, Piazza)
v1.2: Educator Preview of New edX Discussion Experience
v1.3: Educator Preview of New In-Context edX Discussion Experience
https://github.com/edx/edx-platform/pull/24601
We think this PR is related to in-context-level discussions, and thus should be moved down to about here.
https://github.com/edx/edx-platform/pull/24737
Specific to in-context discussions
https://github.com/edx/edx-platform/pull/24380
For this milestone, we don’t need the in-context discussion code and would prefer to pull it out of this PR
https://github.com/edx/edx-platform/pull/24759
Same as above, if there is in-context-specific code in here, it’s not necessary for this milestone.
“It caches the field added in 24380 in the courseoverview model.”
v1.4: Pilot Migration to New edX Discussions Experience in Select Courses
v1.5 Enable Catalog Option to use New edX Discussions Experience
v1.6: Discussions Social Presence: Profile Pictures
v1.7: 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.