Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

V3 Roadmap / Focus Areas (June - Dec)

Created

  1. Simplify SunbirdED - What is required from inQuiry?

    1. Installation

      1. Automate installation? Installation scripts

    2. Ease of Upgrade

    3. Maintain Ease of Maintenance

      1. Error traceability, proper error codes, doc for debugging etc

      2. Automation testing

  2. Sunbird Training & Certification

  3. Adaptability

    1. flexibility / configurability / remove hardcoding

    inquiry → ED should

    1. Flexibility

      1. inQuiry should be made easily pluggable

    2. configurability

      1. inQuiry should be made configurable

        1. Remove hardcoding present in the code

  4. Scalability

    1. inQuiry should enable ED to run on minimum scale and

    has
    1. to have the capability to autoscale as per the

    adopters’
    1. adopters usage.

V3 Roadmap (June - December)

  • Enable course assessment through ED (for any training use-case) to provide enhanced capabilities to existing and potential adopters.

    • Support for FTB/ MTF Question types

    • Question reusability: Create within a Question Set, use elsewhere.

      1. Question lifecycle changes as per tech review

    • Attach audio in a question

    • Support 25k TPS scale

      • Load testing and Performance Benchmarking

  • Simplify inQuiry Server Installation

  • Out-of-the-box analytics for question usage, performance, and other question/question set related metrics.

    • Define the metrics for measuring learning outcomes

    • Pilot/PoC using Sunbird cQube & Obsrv for data analysis

  • Integrating all the inQuiry user-cases to the demo portal

  • Inquiry Code clean-up

    • Remove hard coding of B/M/G/S

    • Remove hard coding of functionalities to a certain primary category or question type (Ex: MCQs, SA, responseVariables etc)

    • Hard coding of content organisation and target frameworks in the editor to point to a specific framework has to be removed. For ex., any hard coding in editors to point to K-12 framework as the target framework.

    • Streamline BB code/ remove deprecated code etc. to ensure a clean offering that is fully understood by the team that owns it

  • Ease of debugging and proper error traceability

    • Error standardisation, error codes have to be made available

V2 Roadmap

Created |

Status
colourYellow
titleWorking on

Outcome & Benefit

Action Items

Priority

Contributor (Who?)

AMJ '23

JAS '23

OND '23

JFM '24

1

Enable course assessment through ED (for any training use-case) to provide enhanced capabilities to existing and potential adopters.

Today Course is one of the leading use-cases for ED adopters (DIKSHA & otherwise), but the assessments in a course are powered through ECML which has its shortcomings.

  1. Ability to create and consume FTB (P1) & MTF (P2)

  2. Question reusability: Create within a Question Set, use elsewhere.

    1. Question lifecycle changes as per tech review,

    2. Out of scope: Visibility private (P3), Old ECML (P3)

  3. Attach audio in a question

  4. Support 25k TPS scale

P1

YES

2

Value Proposition

Become more specific about who will find it more valuable, what will be their reason to believe in the benefits offered and thus having clarity on the right to play. Identify value propositions for independent software vendors (or IT teams in organisations).

  1. Engage with ecosystem actors in two phases through conversations rooted in this hypothesis & research plan.

  2. Round 1: NIIT/StackRoute, Tarento (Pulse), Manipal (Edu Next), Infosys.

  3. Round 2: Quizizz, DoubtNut.

P1

3

Ease of use: Simplify and self-serve installation

Gives the ability for anyone (including ED) to leverage inQuiry with minimal support.

  1. Installation process is completely open-sourced

  2. Simplify installation: Local & Server installation Script with proper documentation

  3. Make it cost-effective for any one to use

P1

YES

4

Operational Monitoring: A self-serve tool to monitor the health of inQuiry micro-service.
•Saves the team's time is debugging issues.
•Helps in Faster Resolution

Today the team spends time assisting adopters debug issues. Mostly the issues are in the complimentary systems around inQuiry.

  1. Enable health-monitoring for adopters

  2. Tech FAQ and document steps to debug incase of commonly occurring issues

5

Experience and learn inQuiry. Help users imagine and visualise the possibilities using inQuiry.

  1. Prototypes in experience centre, Microsite upgrade, completeness, and simplification

  2. Reference solution packages for Test prep, Assessment, and Quizzing/Practice use-cases.

P2

6

Scale performance benchmarking

Today we do not know if inQuiry works at large scale (e.g. 25k TPS). It has neither been used or tested at such a high scale. We rely on it purely based on our design & development practices.

We need to explicitly establish the scale benchmarks for inQuiry.

  1. Performance Testing & Benchmarking: Today we don’t know this. We want to achieve <5% error rate at expected scale or 25k TPS.

  2. Load testing scripts and reports will be published as open-source assets.

YES

7

Testing Automation

Promise that it works with minimal time/effort spent every release by implementing test automation for all components

  1. Functional Testing Automation: Today the coverage is xy% (i.e x/total APIs). We want to achieve >90% coverage across all APIs.

  2. Current status of code coverage is

    1. Editor: 61%

    2. Player: 87%

    3. Micro-service: 84%

We want to achieve >90% unit test code coverage as well.

P1

YES

8

Easy to ensure QuML compliance (Validate & Generate).

Ensures that inQuiry follow the QuML spec and hence allow reusability, interoperability and longevity of its assets.

Today people need to deeply understand QuML specification to implement it. inQuiry makes it easy for people to implement and adopt QuML spec.

  1. Fix the QuML compliance gaps.

  2. Need to put a check so that it is always compliant in future as well and makes it easy to validate & generate QuML spec-based questions & question sets.

P1

YES

9

Light-weight/low-code inQuiry package

Today, by design, inQuiry is more suitable for high-scale usage. We need to offer a Starter Kit to small & mid-scale usage adoptions.

  1. Lower cloud infrastructure to make it cost efficient

  2. Simpler tech stack to make it easy to operate & maintain

  3. Easy to swap-out/swap-in dependencies (i.e. Knowlg)

P2

10

Out-of-the-box capabilities for visibility of learning outcomes.

One of the primary reason for people to use question/sets is to get insights from the data generated by user’s/player’s response.

•This will generate necesssary information for questions and question set's analytics and hence make maximum use of the generated data
•The users will be able to make informed decisions based the analytics data

Out-of-the-box analytics for question usage, performance, and other question/question set related metrics.

  1. Define the metrics that matter

  2. Pilot/PoC using Sunbird cQube & Obsrv for data analysis

  3. Publish event schema so that anyone can understand

  4. <this items needs to be fleshed out further>

P3

11

Activate Community engagement

Today there is much active interest around inQuiry from education & learning related projects, yet their active contribution in shaping the roadmap, contributing functionality, and accelerating adoption remains low.

  1. Co-created roadmap with the 4 active projects

  2. Regular community huddles to evolve the roadmap

  3. Design thinking or Brainstorming sessions on certain specific topics

P2

V1 Roadmap

Last updated |

Status
colourRed
titleArchived

...