Page MenuHomePhabricator

[GSOC 2024] Improve the training module creation and update process [Programs & Events Dashboard]
Open, Needs TriagePublic

Assigned To
Authored By
Mar 31 2024, 3:21 PM
Referenced Files
F55067112: Displaying Custom error messages.png
Sat, Jun 8, 3:50 PM
F55067092: Validations at frontend.png
Sat, Jun 8, 3:50 PM
F55067018: Successfully created first library.png
Sat, Jun 8, 3:50 PM
F55066985: Create Library Modal.png
Sat, Jun 8, 3:50 PM
F55066966: Main-Training-Page(After).png
Sat, Jun 8, 3:50 PM
F55066895: Main-Training-Page(Before).png
Sat, Jun 8, 3:50 PM
F43952798: Library Page.png
Mar 31 2024, 6:36 PM
F43952498: Screenshot from 2024-03-31 19-37-34.png
Mar 31 2024, 6:33 PM
"Like" token, awarded by Maryann-Onyinye.


Profile Information

Name : Om Chauhan
Nickname : om-chauhan1
Phone Number: +91-9759498037
Github: om-chauhan1
Linkedin: om-chauhan1
Location: India (UTC+5.30)
Typical working hours: Between UTC 11:00 PM to UTC 4:00 PM


[Programs & Events Dashboard] Improve the training module creation and update process

The Wikimedia movement has played a pivotal role in making knowledge accessible to people worldwide, empowering individuals to both consume and contribute to a wealth of information. Embedded within this vibrant ecosystem, the Wiki Education Dashboard / Programs & Events Dashboard is a dynamic web tool that helps people organize groups of newcomers to contribute to Wikipedia effectively, facilitating collaboration and learning within the Wikimedia community.

However, within this dashboard, the current process of creating and updating training content poses significant challenges to users. Creating new modules requires the manual creation of .json pages to define libraries or modules, coupled with adherence to specific formatting conventions for individual training slides. This cumbersome workflow not only discourages potential contributors due to its technical complexity but also limits the efficiency of training content creation and management.
Detailed description about the current implementation:

To address these challenges, there is a pressing need for a more intuitive and user-friendly approach. That is where this project comes in, to simplify the process of creating and editing training content on the Programs & Events Dashboard for Wikimedia. This involves removing the need for .json pages and allowing the configuration of Libraries and Modules directly from the Dashboard UI. This enhancement will streamline content creation and make it more accessible to users. Ultimately, it will benefit Wikimedia by improving the efficiency of training material management and fostering greater engagement and participation within the community.

Possible mentor(s)


Have you contacted your mentors already?



This is the layout of training content, referenced from the official documentation :

  • Library
    • Module 1
      • Slide 1
      • Slide 2
      • Slide 3...
    • Module 2
      • Slide 1
      • Slide 2
      • Slide 3...

Now our main aim is to have a user interface that is capable of creating, deleting and updating this training content in all possible terms.
Our approach is to continue using wiki_data for TrainingSlide records, but not for the TrainingLibrary and TrainingModule records.
Based on the information gathered, I designed the whole workflow from start to end(all possible scenarios have been taken care of). This workflow is explained with the help of UI designs, to better convey about the same.

Client Side Rendering is done for all the newly created front-end components (using react).

Basic Flow: Based on user selection the required details are asked from the user, and validations are performed on the provided data at the front end. After validating this data, a request for the selected operation is sent to the back-end. The back-end controller will perform the requested operation on the database and after receiving the successful response from the back-end a success banner will be displayed to the user.
During this whole process if any error occurs then a custom error message will be shown with an alert banner to the user.

While designing the flow of every functionality it is taken care that our database remains free from any of these anomalies :

  • Insertion Anomalies
  • Updation Anomalies.
  • Deletion Anomalies
Now, based on the current style of the dashboard I have designed 2 approaches :

Approach 1

Let’s talk about each functionality one by one:

1. Creation of New Training Content:

Main Training Page:

Main Training Page.png (2×2 px, 259 KB)
Users can begin the creation of new training content, by creating a new library. This can be done with the help of the ‘Create New Library’ button provided on the main training page.
After clicking on this button a new create modal pops up asking about the basic details like name and introduction of the library.

Creating Library Modal:

Screenshot from 2024-03-31 19-37-34.png (646×933 px, 36 KB)
Based on the library name entered by the user, the library slug is dynamically generated and visible to the user in the modal itself at the same time. In the same way, as happens while creating a new campaign. Aiming to maintain consistency in styling throughout the dashboard. Validation is provided for the uniqueness of this slug.
After clicking on the ‘Create’ button of this modal. This new library is created instantly and saved as a draft. To uniquely identify it is visible on the main training pages in a greyed-out colour as shown in the image above. In this draft mode, this library is only visible to the user who has created it such that he/she can complete the contents of the training library like creating new categories, adding new modules, adding new slides etc. Once the user feels that the training library is completed he/she can publish it to make it visible to everyone.

As the user clicks on this greyed-out library on the main training page, he/she will be able to open it as a normal library and this page will be visible to him/her :

Library Page:

Library Page.png (2×2 px, 193 KB)
(Content used here is only for demo purposes)
This page the necessary buttons required to cover all the actions, the user can do within this newly created library. After clicking on each button the dedicated modal is provided, to enter the required details for that action and after validating those details this action can be done successfully.
After creating the desired categories and adding modules to them, user can click on any module to configure it according to their requirements. Clicking on any module leads him to the below show module page :

Module Page:

Croped Module Page.png (1×2 px, 191 KB)
Here details of the module can be edited. Slides can be added or removed with the help of the ‘Configure Slides’ button.

Provide Translations:

After creating the whole training content user can provide translations with the help of a button provided on the library page. That button will lead the user to the below shown modal, helping him to add 1 or more translations for the whole training content at one place.

Translations Modal Page:

Provide Translations Modal.png (902×832 px, 61 KB)

Once the user is done creating the whole training content, he/she can publish this newly created library to make it visible to everyone.

Editing and Deletion of existing training content :

Users with the available permissions can edit the contents of the available libraries(existing/published) in the database.
After clicking on any library that the authorized user wants to edit, the same library page(shown above) is visible to him/her with all those buttons available except the publish button because the library is already in its published state.

Approach 2

In this approach, we will handle all training content from our main training page itself. Here we will have 3 main buttons: Create Update Delete

CRUD_buttons.png (204×1 px, 21 KB)

1. Create functionality:

This functionality will help users create a new Training Library including its new Training Modules segregated by users under their preferred category.

Create Modal 1.1 :

Create Modal 1.png (884×987 px, 53 KB)
After clicking on the next button :

Create Modal 1.2 :

Create Modal 2.png (907×817 px, 53 KB)
After clicking on the next button :

Create Modal 1.3:

Create Modal 3.png (911×798 px, 51 KB)
For each of module user can add/remove slides based on their preference.

After creating the whole training content by providing basic library details, defining its categories, segregating modules in those categories and adding slides in those modules, all those details are saved in the database and the user is provided an option whether he/she wants to input translations for this whole training content or not.
If the user selects yes then he/she will be given:

Provide Translations Modal :
The fields of this modal will be dynamically generated based on the no. of categories and no. of modules in each category, that the user has created above.

Translations Modal Page:

Provide Translations Modal.png (902×832 px, 61 KB)

2. Update Functionality

This functionality will help the user to update anything he/she wants, either in any of the existing or newly created training content.
I have categorized this update functionality into four types according to what exactly the user wants to update

  • Edit Details
  • Provide Translations
  • Add Module
  • Add Slide

To uniquely identify exactly which library or module the user wants to update, I will use the slug of that library, module or slide.

And i am also thinking of adding the functionality to update the slug of any library or module. But i think it is better to have a discussion with the mentor and finalize whether it is required or not.

Update Modal 1.png (652×864 px, 41 KB)
Based on the user's choice the next page will be displayed to him to update the desired thing.

Explanation of each :

  • Edit Details Section :

Under this section, there will be 2 choices given to the user whether he/she wants to edit details related to any library or any module.
For the selected library, the user can edit the:

    • Library name
    • Library introduction
    • For each category under this library
      • Category title
      • Category description For the selected module, the user can edit :
    • Module name
    • Module description
  • Provided Translations Section:

    Under this section, the first user will be asked the slug of the library for which he/she is providing translations. Using this library slug, the no. of categories(their original title) and no. of modules(their original name) in each of those categories are fetched from the database.

    Using this information this modal will be created and provided to the user (same as given in the last step of the creating process):

    Translations Modal Page:
    Provide Translations Modal.png (902×832 px, 61 KB)
  • Add Modules Section: Under this section, the 2 choices will be given to the user whether he/she wants to add modules in the already exiting category or wants to create a new category in the selected library. After finalizing about category user can add one or more modules in this category:
    Add Module Modal.png (752×1 px, 45 KB)
    After clicking on the Next button : Adding Slides Modal:
    Adding Slides Modal.png (843×1 px, 52 KB)
    Users can add slides under each of these newly created modules.
  • Add Slides Section: This option will allow users to add slides in the already existing modules. The user will be given a prompt asking about the library and module slug to which he/she wants to add slides. After that, the user will be given this modal to add one or more slides in that selected module: Adding Slide Modal:
    Adding Slides Modal.png (843×1 px, 52 KB)
    The same modal used in the 2nd step of adding new module functionality

3. Delete Functionality

Under this section, users can delete any existing or newly created library, module or slide based on his/her preference.
The user will be given three options to clarify what exactly he/she wants to delete :

DeleteModal_1.png (453×882 px, 20 KB)

  • For Library deletion: Users have to provide the target library slug, based on the slug that library will be identified from the database and a delete operation is performed on that target library. Note: Before deleting any library first we have to delete all of its child modules and slides inside these modules. Tables Affected in the database: Training Library, Training Module and Training Slide all three.
  • For Module deletion: Users have to provide the target module and related library slug, based on the slug that module and related library will be identified from the database and a delete operation is performed on that target module. Note: Before deleting any module first we have to delete all of its child slides. And after deleting the target module we have to safely remove it from its parent library. Tables Affected in the database: Training Library, Training Module and Training Slide all three.
  • For Slide : Users have to provide a slug of the target slide and the related module, based on the slug that slide and related module will be identified from the database and a delete operation is performed on that target slide. Note: After the slide deletion operation, we have to ensure that this slide must be safely removed from its parent module.Tables Affected in database: Training Module and Training Slide only two.

All the points in the note section above ensure that no deletion anomaly occur in our database.

Timeline :

PeriodTaskAllocated Time
4th May to 27th MayCommunity bonding period — User Interface Design Proposal3 Weeks
27th May to 10th JuneFront-end Implementation (Phase 1)2 Weeks
10th June to 24th JuneBack-end Implementation (Phase 1)2 Weeks
24th June to 1st JulyUnit Testing and Integration (Phase 1)1 Week
1st July to 8th JulyFeedback Gathering and Incorporation (Phase 1)1 Week
8th July to 15th JulyMid-term evaluation1 Week
15th July to 29th JulyFront-end Implementation (Phase 2)2 Weeks
29th July to 12th AugustBack-end Implementation (Phase 2)2 Weeks
12th August to 19th AugustUnit Testing and Integration (Phase 2)1 Week
19th August to 26th AugustDebugging, Bug Resolution and Buffer time1 Week
26th August to 2nd SeptemberFeedback Gathering and Incorporation (Phase 2)1 Week
2nd September to 4th SeptemberFinal End-Term Evaluation

Detailed elaboration of each phase(specified in the timeline) is given below :

Before Mid Term Evaluation

  1. User Interface Design Proposal (During Community Bonding Period)
    • Discuss, develop and finalize detailed Figma design proposals for creating new training content, modifying existing training content and deleting both from the Dashboard UI.
    • Discuss and finalize the whole proposed approach with the mentor and incorporate the changes suggested by them.
    • Discuss about the potential future challenges and ways to overcome them.
  2. Front-end Implementation (Phase 1)
    • Begin with developing front-end components that are finalized in the community bonding period.
    • Target to complete the front-end part for the whole creating functionality as well as more than half of the updating functionality.
    • Incorporate user-friendly interfaces for language selection and input for translations.
    • Set up validations at the front end to ensure consistency in data.
  3. Back-end Implementation (Phase 1)
    • Implement necessary routes and controllers to facilitate the creation and modification of training content.
    • Implement necessary API endpoints for incorporating the provided translations into the database.
  4. Unit Testing and Integration (Phase 1)
    • Write Jest tests for created front-end components to validate functionality and ensure consistent behaviour.
    • Write unit tests using RSpec for back-end functionality developed in phase 1.
    • Utilize Capybara for end-to-end integration testing to ensure seamless functionality across the stack.
  5. Feedback Gathering and Incorporation (Phase 1)
    • Gather feedback from the mentor on the developed components and functionalities in phase 1 of development.
    • Incorporate feedback into the design and do development to ensure alignment with user needs and expectations.

Before End Term Evaluation

  1. Front-end Implementation (Phase 2)
    • Extend front-end UI components using React.js for remaining update functionality and for delete functionality.
    • Utilize Stylus along with its Rupture utility for style-sheet management, ensuring a consistent and responsive design.
  2. Back-end Implementation (Phase 2)
    • Extend back-end functionality to support the newly created front-end in phase 2.
    • Ensure that the whole code aligns with Rubocop linting rules and optimize code to improve performance wherever possible.
  3. Unit Testing and Integration (Phase 2)
    • Develop tests to verify the functionality of the newly added features in both the front-end and back-end.
    • Conduct comprehensive testing of the entire system developed in both phases to ensure its reliability and correctness.
  4. Debugging, Bug resolution and Buffer time
    • Solve all reported issues and bugs found during testing.
    • Tackle all the scenarios in which anomalies can occur in the database and ensure database consistency.
    • Allocate the remaining buffer time to any pending work.
  5. Feedback Gathering and Incorporation (Phase 2)
    • Gather final feedback on the implemented features and improvements done so far.
    • Incorporate any final feedback into the project, ensuring that the system meets the expectations and requirements of the users.
  6. Documentation
    • Document any challenges faced and solutions implemented during this whole journey.
    • Document the implemented front-end UI components and their functionality.
    • Document the back-end API endpoints and data processing mechanisms.


Throughout the Google Summer of Code (GSoC) program, I intend to maintain an open line of communication with my mentor and the community to ensure steady progress. My primary modes of communication will be through Slack, Zulip, Email, and scheduled video call sessions as necessary. I will also actively participate in GitHub discussions, where I will publish my source code, submit pull requests, and engage in code reviews.
Progress updates will be documented through regular biweekly reports, detailing completed tasks, challenges encountered, and plans for the upcoming weeks. Additionally, I will be available for ad-hoc discussions and issue resolution during my working hours.

About Me

My Education

I am currently pursuing my Bachelor of Technology in Computer Science at Bennett University(The Times Group). I am in the second year of my program.

  • Computer Science Engineering | Bennett University | Current *CGPA*:  *9.76 / 10*
  • *XII (CBSE) | School 92% | 2021*
  • X (CBSE) | School 93% | 2019

Q. How did you hear about this program?

I first learned about the Google Summer of Code program through a senior who participated in a previous year's edition. Intrigued by the opportunity to contribute to open-source projects, I decided to explore it further and eventually became enthusiastic about applying for this year's edition.

Q. Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program?

During the duration of the Google Summer of Code program, I will not have any significant time commitments that would impact my participation. My current semester ends in the third week of May, precisely when the official coding period commences. During this long break, I plan to dedicate all my time to advancing this project, aiming to accomplish a significant portion of the coding tasks.

Following this break, my college will resume in August. Despite returning to academic responsibilities, I will ensure consistent progress on the project by allocating 5-6 hours per day on weekdays and 6-8 hours per day on weekends. I am confident in my ability to manage these commitments effectively and meet the project deadlines without compromising on quality or timeliness.

Q. We advise all candidates eligible for Google Summer of Code and Outreachy to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?

I am only applying for Google Summer of Code exclusively with the Wikimedia Foundation.

Q. What does making this project happen mean to you?

Making this project a reality means a lot to me on both a professional and personal level. I am fully committed to dedicating my time, effort, and skills towards its successful completion. As an aspiring software developer, the opportunity to contribute to an impactful open-source initiative aligns perfectly with my career goals. It's not just about writing lines of code anymore, it's about creating something that will touch the lives of millions of people worldwide. Knowing that what I'm building will be used by individuals across the globe fills me with a sense of pride and excitement. Plus, being able to stay connected with this amazing group of people who share my passion for open-source development is something I truly cherish. It's not just about the project itself, but the journey and connections that come with it.

Past Experience

Past Contributions to Wiki Education Dashboard - Link

Pull RequestTitleInvolved
#5709 (merged)Made site notice configurable from the dashboard through the settings page, before it was handled from application.yml• Creation of front-end components and methods in settings controller • Modification in existing redux state of settings • Caching Implementation
#5628 (merged)Made sandbox url for an Assignment updateable• Creation of front-end components, actions to modify redux state • Defining new routes and controller • Creating unit tests for this functionality • Displaying custom error messages
#5649 (merged)Fixed replica_spec.rb and replica.rb• Finding and fixing unreliable test case • Segregating into individual test cases
#5667 (merged)Made 'impact_stats' editable from the dashboard through the settings page• Creation of new front-end components and routes • Caching Implementation • Modification in Controller
#5599 (merged)Solved bug of next estimated update• Implementation of logic to verify the date
#5614 (merged)Fixed the error of adding and removing articles through the Article Finder tool• Utilization of useRef() hook
#5592 (merged)Resolved CORS error occurring while fetching revisions from• Logical Implementation
#5621 (draft)Restored removed self-assign articles to the pool of Available Articles• Creation of action method in controller and actions to handle redux state
#5591 (merged)Added "Start Date" column in the Programs tab of Campaign and its sorting feature based on date and timing• Modification in its view and utility script
#5671 (merged)Fixed bug of supplementary.jsx and refactored it to functional component• Debugging and bug resolution • Conversion from class to functional
#5674 (open)Extended error logging for 'update_categories' of update_course_stats.rb• Logging implementation in category.rb model
#5666 (merged)Refactored course_stats_download_modal.jsx to functional component• Conversion from class to functional
#5644 (merged)Refactored salesforce_link.jsx to functional component• Conversion from class to functional
#5610 (merged)Refactored course_quality_progress_graph.jsx to the functional component.• Conversion from class to functional
#5606 (merged)Refactored course_ores_plot.jsx to functional component• Conversion from class to functional
#5600 (merged)Refactored available_articles.jsx to functional component• Conversion from class to functional
#5585 (merged)Refactored articles_handler to functional component• Conversion from class to functional
#5582 (merged)Refactored list.jsx from class to functional component• Conversion from class to functional
#5643 (open)Refactored overview_handler.jsx to functional component• Conversion from class to functional
#5574 (merged)Refactored add_available_articles.jsx from class to functional component• Conversion from class to functional
#5573 (merged)Refactored article_finder.jsx to Functional Component• Conversion from class to functional
#5563 (merged)Refactored article_finder_row from class component to functional component• Conversion from class to functional

Future Goals (Post GSOC)

Looking ahead from Google Summer of Code, I see myself as a long-term collaborator with the WikiEduDashboard project. Beyond the summer, I'm committed to supporting and helping our project grow. Here's what I aim to do:

  1. Facilitate a smooth transition to React 18: I will work on enabling Strict Mode and addressing any challenges arising from component upgrades. This includes ensuring compatibility with React 18 features and optimizing our codebase accordingly.
  2. Enhance testing infrastructure: I will research and implement alternative testing frameworks that better support React 17 and beyond. This may involve transitioning from Enzyme to more compatible solutions like React Testing Library (RTL) to improve the reliability and efficiency of our testing processes.
  3. Streamline codebase: I will systematically migrate class-based components to functional components, adhering to modern React best practices. This will involve replacing deprecated APIs, adopting hooks, and refactoring code where necessary to improve maintainability and readability.
  4. Optimize bundle size and performance: I will analyze bundle size dependencies and identify opportunities to reduce overhead. This may involve removing unnecessary libraries, optimizing imports, and exploring alternative solutions to minimize the application footprint and enhance performance.
  5. Remain actively engaged in community support: I will continue to contribute to issue resolution, conduct thorough code reviews, and actively participate in community discussions. I aim to facilitate a collaborative environment by providing ongoing support and sharing knowledge with fellow contributors.

Coding Skills

  1. Proficient Languages and Frameworks:
    • HTML, CSS, JavaScript
    • React (including state management with Redux)
    • Ruby (with Ruby on Rails)
    • C/C++
  2. Front-end Development Expertise:
    • Experienced in building user interfaces using React.
    • Proficient in managing state with Redux for complex applications.
  3. Back-end Development Proficiency:
    • Skilled in server-side development with Ruby on Rails.
    • Familiarity with Node.js for building scalable web applications.
  4. Conceptual Understanding:
    • Strong grasp of Object-Oriented Programming (OOP) principles.
    • Knowledgeable about Model-View-Controller (MVC) architecture for designing web applications.
  5. Specialization in Full Stack Development:
    • Actively pursuing Full Stack Development as a specialization within the Computer Science field.

Backend Flow Chart

Backend Flow Chart(Training-Content).png (898×1 px, 66 KB)

Use Case Diagram for Training Content

Use_Case_Diagram(Training-Content).png (793×1 px, 172 KB)

Figma link for the proposed designs:

Approach 1 | Approach 2


All the designs provided in both approaches above are not yet finalized, they are just a way to express what the implementation will look like. I am ready to provide more design ideas and ways of implementation and am also open to incorporating any design/idea suggested by the mentor. Till now what I am thinking is utilizing the user-friendly way of 1st approach and forms of 2nd approach for gathering information from the user based on the actions he/she wants to perform.
The approach and designs will be finalized after discussing with the mentor during the community bonding phase.

Event Timeline

FYI 3 of the files still need to be attached to this task otherwise nobody can see them.

OmChauhan updated the task description. (Show Details)
Maryann-Onyinye renamed this task from Improve the training module creation and update process [Programs & Events Dashboard] - GSOC 2024 to [Proposal] Improve the training module creation and update process [Programs & Events Dashboard] - GSOC 2024.Apr 2 2024, 11:09 AM
debt renamed this task from [Proposal] Improve the training module creation and update process [Programs & Events Dashboard] - GSOC 2024 to [GSOC 2024] Improve the training module creation and update process [Programs & Events Dashboard].Tue, Jun 4, 5:26 PM
debt updated the task description. (Show Details)
debt added a subscriber: dumbPotato.
debt subscribed.

Weekly Internship Report (27 May - 2 June)

1. Overview of Tasks Completed:

Task 1: Added functionality for creating new training libraries through the dashboard.

  • Sub-task 1: Implemented validations at the frontend.
  • Sub-task 2: Applied access rights, restricting functionality to admin users only.
  • Sub-task 3: Displayed success and custom error notifications to users.

Task 2: Wrote all possible test cases for this newly created functionality to ensure robustness.

2. Key Accomplishments:

Admins are now able to create new training libraries through the dashboard as shown step by step in the images below.

Pull Request:



Main Training Page

Main-Training-Page(Before).png (255×1 px, 25 KB)

  1. Added button Main Training Page

Main-Training-Page(After).png (257×1 px, 29 KB)

  1. Form to create new Training Libraries through dashboard

Create Library Modal.png (699×1 px, 76 KB)

  1. Successfully created library:

Successfully created first library.png (257×1 px, 32 KB)

  1. Setup Validations at the front-end:

Validations at frontend.png (669×1 px, 72 KB)

  1. Showing Custom Error Message to user:

Displaying Custom error messages.png (257×1 px, 35 KB)

3. Challenges Faced:

Challenge 1: Implementing access rights correctly took some trial and error, but I managed to resolve it with detailed testing and feedback.

4. Learnings and Skills Gained:

Learning 1: Gained insights into the project’s codebase and understood how a complete page renders with some static content from the server side(using haml templates) and interactive things on client side(using React).

Skill 1: Improved my skills in frontend development, particularly in implementing validations and user notifications.

Skill 2: Enhanced my understanding of access control mechanisms within web applications.

5. Goals for Next Week:

Goal 1: Change the validation pattern, as discussed with mentors.

Goal 2: Develop functionality for adding categories to the newly created as well as existing training libraries.

Goal 3: Fix the test cases that were failing on the CI build.

Goal 4: Write new test cases for the functionality developed in next week.