At Avanti Fellows, I along with Surya BV recently introduced Shuffle Question Ordering in quizzes to ensure fairness in online assessments. Here’s why this matters and how it works —

Why Shuffle Questions?

In an online setup, students taking the same test at the same time could easily share answers if questions appeared in the same order. Randomizing the sequence makes it harder to copy, ensuring a fairer assessment.

But there’s a catch within the system - it’s not pretty staright foward:

• We load questions in small batches, not all at once, to keep the system fast. So we will shuffle within this small buckets( batches of size 10 default)

[0,1,2,3,4…..9] => we will be randomizing in this block of questions only ensuring that question is fetched.

• Some quizzes have different sets of questions that get shuffled randomly, which can mix up the topics.
• The order of questions must stay the same, even if a student returns to the test later.
• This ensures students can navigate the questions easily and have a smooth experience.

Note: All the OMR assessments will have no effect as there is no need in shuffling of questions except OMR assesments we can find shuffling in all the other assessment types.

How Does It Work?

Instead of scrambling questions in a way that could break the test, we assign a hidden randomized order when a student starts the quiz.

Note: We will be following a 0-based indexing while accessing we use this and while displaying question-1 we go the index 0.

Example:

Imagine a quiz with 5 questions:

• Normally: Q0, Q1, Q2, Q3, Q4
• Shuffled: Q4, Q1, Q0, Q2, Q3

Now, when the student sees:

• “Question 1”, they’re actually seeing Q4(last question in the normal order).
• “Question 2”, they’re seeing Q1(second question in the normal order), and so on.

But behind the scenes:

• Answers are saved in their original positions to avoid confusion.
• If a student leaves and comes back, their shuffled order stays the same.

Edge Case: When the size of the question set exceeds the bucket size (10)

In this scenario, the question set will be divided into smaller chunks (buckets) of size 10. If the total number of questions isn’t a multiple of 10, the last bucket will contain the remaining questions.

For example, if there are 25 questions in the question set:

• The questions will be grouped as [0–9], [10–19], and [20–24].
• Each bucket is shuffled individually.

Handling Previous Sessions Without question_order

To address previous sessions where the question_order field was missing in the database, we added a backend script that assigns a linear ordering to the questions (from 0 to total_questions - 1). This ensures consistency across all sessions—both old and new.

Testing to Ensure Stability

We implemented comprehensive unit and end-to-end (E2E) tests to verify that the new functionality works as intended. These tests confirm that:

• The new feature correctly assigns a question order.
• Existing features remain stable and unaffected.

Final Thoughts

This has been a meaningful journey for me. There were moments when I felt it might not come together, but seeing the feature go from planning to development to thorough testing has been incredibly rewarding. Knowing that this project directly benefits students makes the experience even more fulfilling.

I’d like to express my sincere gratitude to Surya BV for his unwavering support and motivation. Without him, I might have completed the development but wouldn’t have gained such a deep understanding of the entire process.

Introduction

The AMRIT platform is a revolutionary open-source project with over 10+ frontend and 14 backend microservices, serving 2.2 crore beneficiaries across India. As an open-source initiative, it relies on contributors to grow and improve. However, the development setup process was time-consuming, taking 4–6 hours, which discouraged many developers from contributing. My role as a Community contributor was to simplify this setup, making it easier for developers to get started.

About AMRIT

AMRIT (Accessible Medical Records via Integrated Technology) is an open-source platform designed to streamline healthcare services. It provides a unified system for managing medical records, ensuring transparency and accessibility for millions of beneficiaries. The platform’s open-source nature encourages collaboration, but the initial setup process has been a significant barrier for developers.

The Problem: Why Does Setting This Up Feel Like a Full-Time Job?

The AMRIT platform consists of 25+ services (14 backend and 11 frontend), each requiring specific configurations, dependencies, and data loading. Developers had to spend 4–6 hours setting up the environment, which included:

1. Installing software dependencies (MySQL, Redis, MongoDB etc)
2. Loading dummy data into the databases.
3. Configuring environment variables for each service.
4. Managing ports to avoid conflicts.

This time-consuming process reduced the number of contributors, slowing down the platform’s growth.

My Journey: From Confusion to Clarity

The First Meeting: A Reality Check!

My journey began with a meeting with Mithun, the head of AMRIT, and the senior developers. They explained the challenges with the current setup, and we brainstormed ideas to simplify it. At first, I thought it would be a straightforward task, but Mithun warned me, “It’s not straightforward; there may be speed breakers.” He was right.

Setting Up Dependencies: The Easy Part… or So I Thought

The first step was setting up the required software dependencies. I used Docker to containerize services like MySQL, Redis, and MongoDB. This helped avoid conflicts with local setups, and everything ran smoothly at first.

Loading Dummy Data: The Unexpected Nightmare

Next, I had to load dummy data into the services. This turned out to be harder than I expected. There were version compatibility issues, and I spent a whole week debugging. With help from Anil, a senior developer at AMRIT, we fixed the issue by downgrading the software version.

Debugging a Massive SQL Script: A Horror Story in 800MB

After fixing the version issue, I faced another problem — debugging an 800 MB SQL script. It was huge, and debugging it was a nightmare. Again, Anil helped me out, and after several meetings, we finally loaded the dummy data. But this process took another week.

Setting Up Backend Services: Me vs. Java

With the data loaded, the next step was setting up the 14 backend services built on Spring Boot. I didn’t know Java, so this was tough. I spent some time learning the basics of Spring Boot and got help from Ravi, another senior developer at AMRIT. I managed to set up the main service, but it threw errors, and fixing them took another week.

Configuring Frontend Services: The Final Stretch

Once the backend services were running, I moved on to the 11 frontend services. Each frontend service needed to be configured with the updated backend ports. This way, developers could clone the repository, run the services, and start contributing without wasting time on setup. I tested each service thoroughly, logging in and checking for errors.

Technical Implementations: Quick Wins That Took Weeks!

Here’s a quick look at the technical work I did:

• Containerized MySQL, Redis, and MongoDB using Docker: This isolated the services, preventing conflicts with local setups and ensuring smooth operation.
• Automated dummy data loading: Optimized SQL scripts and resolved version compatibility issues to load data efficiently.
• Configured environment variables: Edited .env files for 14 backend and 11 frontend services to ensure seamless communication.
• Assigned unique ports: Managed port assignments for all services to avoid conflicts during local development.

Future Improvements: Making It Even Easier

While the current setup is much better, there’s still room for improvement. The next step is to dockerize the entire cloning and dependency installation process. This would allow developers to run all services within minutes, so they can focus on contributing to the platform and making a difference in the healthcare sector.

Special Thanks

This journey wouldn’t have been possible without the help of some amazing people:

• Mithun: My mentor and the maintainer of AMRIT, who guided me through every step, taking both my silly and complex doubts with the same wavelength — something I found truly impressive.
• Ravi, Anil, and Devika: The senior developers at AMRIT who were always there to help me when I got stuck.
• Pratham and C4GT: For giving me this incredible opportunity to contribute to such an impactful project.

Conclusion

With this, I’m signing off from my Docker container (just kidding!). But my journey in open-source doesn’t end here. The AMRIT platform is a great example of how collaboration can make a difference, and I’m proud to have been a part of it. If you’re thinking of contributing to open-source, don’t let self-doubt stop you. Dive in, learn, and make an impact!

Thank you for reading! If you’re interested in contributing to AMRIT, check out the repository and get started today.