Approach to question-set editor code separation

[pallakartheekreddy]

Currently, both Collection & QuestionSet editors are using a single code base and based on configuration collection or question-set editor will be launched. This codebase is currently under Knowlg BB.
This design was implemented when both editors were built and maintained by a single team - sourcing circle. Now, the question set editor is part of inQuiry BB. In AMJ, one of the roadmap items for inQuiry BB is to separate question set editor code from Knowlg. We can think of 3 options to achieve this goal.

Option 1:
1. inQuiry will copy the collection code from Knowlg BB and make changes on top of it.
2. Question-set editor code will not have any collection & content-related changes.

Option 2:
1. A base editor needs to be designed & implemented.
2. Both question-set & collection editor will use this base editor.

Option 3:
1. Status quo - Question set editor component in inQuiry uses/depends on collection editor component of Knowlg
2. inQuiry team will contribute to Knowlg BB for any new feature requests related to the Question sets.

All of these options have advantages & disadvantages. for ex., option 2 is a generalized approach to solve this problem but is effort-intensive. Hence, initiating this thread to seek inputs from the community.

@vrayulu @maheshkumargangula @vinukumar-vs @Krishnaj20 @vaibhavbhuva @alok-os

[Krishnaj20]

thanks @pallakartheekreddy for initiating this thread.

@vrayulu @maheshkumargangula @vinukumar-vs @Krishnaj20 @vaibhavbhuva -
In my view, option 1 involves duplication of code base hence not in favour of this approach although it enables inQuiry to quickly set up the editor and enhance the editor for its use cases. The question set editor can still be enhanced via active contribution by inQuiry BB to Knowlg BB (as proposed in option 3). So, I prefer option 3 over 1.

For option 2 - need to have a separate base editor which will power both collection & question set editor. I believe even in the current implementation, collection editor powers question set editor. So, in a way, collection editor is the base hierarchy editor. How is the current implementation different from what is proposed in option 2?

[alok-os]

keeping adopter in mind - I would prefer option 1 where Collection Editor and Question Set Editor will have different code bases and will reside in their respective BBs making both BBs (Knowlg and InQuiry) independent. - Easier adoption and deployment

From the code perspective - it means that both editor code bases might end up writing similar code separately. We shld look at following questions:

1. How much code is really similar?
2. Moving fwd - keeping common code - how much does it help to enable multiple use cases across collection and question set reducing significant duplicate coding
3. Do we anticipate that keeping common code may make design too complicated or even hinder certain use cases ?
4. How does maintainability of code impacted?

@pramodkvarma

[Krishnaj20]

Looping in other contributors for their inputs:
@vijiurs @aks30 @kiranharidas187 @Prerna789 @aayushkedia95 @rahul101001000

[vrayulu]

@pallakartheekreddy - can we take a plugin approach to address this:

• collection editor can be a bunch of plugins combined together (at compile time) in different ways to have multiple flavours of the editor (e.g.: question set editor or a course editor).
• some of the plugins can be core plugins (like the hierarchy plugin for tree navigation) which are always mandatorily included in the editor. These core plugins should support multiple configurations to support different options (e.g.: depth of tree, allowed object types, API request paths, etc).
• rest of the plugins that are specific for different use cases (MCQ, MTF, FTB, etc) can be optional ones that can be included for creating a question set editor.
• in this approach, the core editor framework and core plugins can be owned by any one BB and BB specific plugins (like MCQ, MTF, etc) can be owned by the respective BB. And each BB will have their own build script to build their own flavour of the editor.

We can also plan to implement this in a phased manner. The first step can be keep the collection editor in the existing repo and refactor it to break the current components into pluggable components.

@vinukumar-vs & @pallakartheekreddy - please explore this option and let us know if this is feasible.

@SanthoshVasabhaktula - please share your ideas/thoughts on this.

[Krishnaj20]

@vrayulu - Can you elaborate on what does this option mean from an adopter point of view?
Currently the common components which the question set editor is using are the tree, hierarchy plugin & header. Rest of the functionalities - 'Add from library' & 'Create New' are custom modules written for question set editor.

[vaibhavbhuva]

@vinukumar-vs @pallakartheekreddy @Krishnaj20 @surendrasinghs -
We have created the design documentation and updated the conclusion in the below wiki:
https://project-sunbird.atlassian.net/wiki/spaces/SBDES/pages/3181051923/Design+Separation+of+question-set+collection+editor
And, we have communicated the same to the inquiry team.