...
Discussions Service: A generic micro-service that can be used to model different types of discussions. This service should expose APIs that will be used by the discussions plugin. And this service should not have an understanding of the groups or how the plugin is implemented.
Discussions Plugin: This plugin should expose a configuration that can be configured while adding to a group, have a user interface that is embeddable within groups UI and use the configuration to render the discussions for a group.
Discussion Service
As mentioned above, this service should be built in a generic way and expose APIs that enables different types of discussions. A few thoughts (random and not in any specific order) that need to be considered for designing the discussions service:
There are various dimensions to discussions: its Character, Category, Content, Community, Purpose, Usage, Lifecycle, Administration, Supportability
Discussions can be a question, feedback, comment, dialogue (lengthy, threaded interaction between 2 or more parties), forum
Discussions can be marked public, or between groups, or by invitation only
Depending on whether it is a question, feedback, comment etc., its association with content, community, usage, experience, lifetime and administration can be different.
Discussions can be at a Platform Level (general questions about usage, enrolment, feedback, complaints, issues etc..) or at a course level or across courses
Discussions Initiated by - Student, Faculty, Tutors, automatically initiated…
There could be discussion forums which are time bound like forums for courses which are started at the beginning and are over (archived) at the end of the course or open forever like platform level general forums
Discussions that are specific kinds - discussions that happen on an event - for example, end of the module (review) discussions or a quiz.
There could be forums specific to certain topics - assignments, submissions, clarifications, supplementary content, general help etc.
Specific Forums that are scheduled discussions - scheduled say every Saturday and ends on Monday where all questions are guaranteed to be answered. Or between Tutor and Student groups where all questions have to be answered and monitored. Or Faculty appearance Forums/Discussions where the Faculty come be online for 2 hours every week - what kind of discussions are these?
Forums created for a set of students - student groups, for a very specific discussion/purpose - i.e. targeted discussions between a group of students.
Moderated and Unmoderated Forums
Actions on Discussion Items
Repost them, close them, delete them, link to it from somewhere else, promote it, best discussions, best question, best answer, Auto generate FAQs (can we associate a FAQ to content elements)
HashTags, Search on Tags, Search by Keywords etc.
Send a discussion item to somewhere else. For example, link a discussion to some other course, if it is relevant
Administration: Monitor the Discussions, Participation, Turn Around Times (if the tutor has to respond to something with in certain time, how does this get monitored and ensured?)
Administration: Detection of spurious, frivolous, obscene, unacceptable content.
Administration: Dealing with emotions, language used, arguments et
There can be lot of problems - content relevancy - how to purge trivial stuff, how to archive/promote good stuff, convert a discussion into a learning content?
how does this service identify users that are part of sunbird platform? do we need SSO or integrate with user service/keycloak for verifying the user?
how to backup, archive your own discussions, email to self, share with others, etc..
Life time, time duration of a discussions and forums
Given so many dimensions - how do we distinguish them, characterise them (categorisation, content length, time, etc). for example what is the behaviour of Moderated and Unmoderated forums other than assign some moderators?
Another design recommendation is that Sunbird discussions service should have its own API interface definition, even if an existing tool like discourse or nodeBB is used for the implementation. This is mainly for two reasons:
The underlying implementation can be changed from one tool to another or to a custom implementation without impacting the plugins and apps using this service.
Any customisation required to be done on top of the underlying tool (like discourse) can be implemented in the API layer.