Profile Information

Name: Ujjwal Pathak
Web Profile: https://ujjwalpathaak.github.io/portfolio
GitHub: https://github.com/ujjwalpathaak
Linkedin: https://www.linkedin.com/in/ujjwalpathaak
Location: Noida, India
Typical working hours: 6:00 PM to 8:00 PM and 10:00 PM to 2:00 AM IST (UTC+5:30)

---

Synopsis

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

Programs & Events Dashboard ( https://outreachdashboard.wmflabs.org ) is used to organize events like edit-a-thons and other newcomer-focused wiki programs while being focused on the global Wikimedia community. It has a feature of adding training modules. What are training modules? They are a set of informational slides divided into different modules and libraries. These slides are helpful as teaching materials, for making quizzes in workshops, or for sharing information with others.

The current process of creating new training content is tedious. We need to make different pages and JSON objects to list libraries, modules, and add slides on Wikimedia ( http://meta.wikimedia.org ) which are then fetched by the dashboard. This project aims to simplify the creation of training content by giving users the ability to create them directly from the dashboard, using a user-friendly interface. This approach will not only increase efficiency but will also encourage more engagement with the content creation process.

Possible Mentor(s) -

@Ragesoss

Have you contacted your mentors already? -

Yes

---

Deliverables

1) Creating Content

We need a new interface to let users create training content directly on the dashboard, this raises an issue of adding the same content as pages and JSON objects on Wikimedia. To solve this issue we can use the MediaWiki Edit API ( https://www.mediawiki.org/wiki/API:Edit ), using this API we can add new pages or update the existing ones on Wikimedia which would will help us to sync the changes/additions made in our dashboard to Wikimedia.

Each change made by a user would activate 2 workflows simultaneously:

1. Update the content on Wikimedia.
2. Save the data in the database.

i) Design

• Each component will be nested inside their parent component to help users navigate between creating content intuitively ( mockup ).
• The components for adding new content will be kept simple and easy to interact along with all the necessary functionality.
• New forms will use the modal.jsx component as a base, and existing common components and preset styles will be used to keep everything uniform across the dashboard.
• I have made a mockup on figma of how can these new components be designed and structured, the link is present in the last section of this proposal

ii) How will these new components work and look like?

Here are few slides from the mockup and their JSON objects

a) Library

• Users will fill out a form with basic details of the new library they want to create, these would include details such as name, slug, introduction, and the categories this library would have (along with their names and descriptions).
• ID will be auto-generated based on the current series, and slugs will be derived from the library name entered by the user.
• Modules array for each category will be empty till new modules are created or imported from Wikimedia.

b) Modules

• Modules are children of libraries.
• Creation of new modules will begin from the library where you want the module to reside.
• A dropdown will display all existing categories within that library previously defined by the user.
• After adding the necessary details and hitting submit
  • The new module will be added to both the database and Wikimedia.
  • A new object will be appended to the module array of the respective category under the parent library
  • This new object will contain attributes like slug, name, and description to create a link between the parent library and the new modules.
  • Slides array will be empty till new slides are added to this module.

c) Slides

• Slides are children of modules, and they will be following the New_method to create slides from this new workflow
• Creation of new slides will start from the module where you want the slides to belong.
• There will be an option to add a quiz while editing the slide, which would open another modal to add questions, answers and their explanations why they are wrong or why they are correct.
• There will be an API call to create a new page (wiki_page).
• The slug will be automatically added to the parent module's slides array in both the database and Wikimedia to create a link between the module and this new slide.

iii) Creating new slides

We can use the same methodology to create slides as mentioned in Formatting slides while trying to give a better interface for using templates to add assets.

a) Adding Images:

• There will be a popup when users select the option to add a new image.
• This would require users to provide relevant information about the image.
• Along with a drop-down menu for selecting the layout, giving users the flexibility to choose the desired arrangement for the image within the content.
• Users will have the option to upload images directly from their local device or use an image already uploaded to Wikimedia.
• Local images from the user's device would first be uploaded to Wikimedia using the MediaWiki API ( https://www.mediawiki.org/wiki/API:Upload ), then their URLs ( link to access the image on Wikimedia servers ) will be used.

b) Adding Videos:

• The same pop-up can be used for videos with different fields asking for information such as captions.
• Along with an input for a link to the video uploaded on youtube.

c) Adding Quizzes:

• After clicking on “add quiz”, there will be a model which would ask for the details required to make a quiz.
• These details would include the question, different options and their explanations about why they are the wrong or the right option.
• This would later be converted to the desired quiz template.

d) Adding Text

• We could take the help of TinyMCE Editor (already being used in lib/wikitext.rb )
• This editor generates the content in HTML which could later be used to generate WikiText, we are doing something similar to this ( lib/wikitext.rb ) using pandoc-ruby library or we can use the https://en.wikipedia.org/api/rest_v1/#/Transforms/post_transform_html_to_wikitext API endpoint.
• This WikiText would be used to make wiki_pages on Wikimedia.

e) Preview Slides:

• Using the same technique of parsing and showing the slides we could have a preview mode where we give users the option to preview how the content will appear upon submission.
• The interface is inspired by GitHub's PR comment component.

I think that the process should start from .haml pages ( _all_modules.html.haml ), and the New components will be rendered client-side for enhanced interaction with Redux for state management. training_module.html.haml already renders its resulting webpage both client-side and server-sided, I could use something similar.

2) Editing Content

• Upon clicking the edit button, populate the component used for creating that particular content with the current data intended for editing ( mockup ).
• We can draw inspiration from the edit block interface found in the course timeline view.
• Users can make necessary adjustments and then initiate the workflow to apply the changes using similar routes and controllers which were used initially while creating the content.
• This would also work for the content already present on Wikimedia ( old/existing content )

3) Add content using URLs

• There will be a functionality which takes the URL of a page as input and then adds it to our database or perform needed operations on Wikimedia.
• This will be useful for -
  1. Re-assigning the child content when their parent is removed ( mentioned in “Removing Content” section )
  2. While integrating the new system with the existing one. ( mentioned in “How will I roll out changes ensuring backwards compatibility?” section )
  3. When you would like to link new child to existing parent
     • Example - If a module named module_a is created on Wikimedia and it needs to be added under Library_a. access Library_a's modules page, utilize the URL functionality to link module_a to Library_a, updating both Wikimedia and the database entries accordingly.
• This feature would work like “copy course from another server” functionality.
• More controllers and logic would be added to the existing functionality of training/wiki_training_loader.rb to handle individual pages instead of adding multiple pages together.
• New API calls will be written to update the parent child relation between the content on Wikimedia.
• The MediaWiki API ( https://www.mediawiki.org/wiki/API:Get_the_contents_of_a_page ) will be used to retrieve the contents of the desired page and save it in the database if the content is being added for the first time or was removed earlier.

4) Removing Content

We can conceptualize the training content as a tree data structure, where each component has its designated parent node. This linkage ensures that a component can only have one parent node.

So to delete Library 1 and use its modules in Library 2, we first remove Lib1 it from the database, then the library itself and the modules associated with it would not show up on the dashboard, but both the library and the modules would be present on Wikimedia ( here we can give and option to also remove the pages from Wikimedia ) from there we could use the URL functionality which would help us to link those modules to Library 2 as the modules are present in the database they have not been deleted. Same can be done if module 1 is deleted and you would like to use the slides from module 1 into module 2.

5) Translations

• Currently, translations are managed by the Translate extension ( https://www.mediawiki.org/wiki/Extension:Translate ), but for it you need the data present on Wikimedia and wrapped in <translate></translate> tags.
• There would be a new parser written which would make our slide’s data ready for translations.
• This parser would read the contents of a slide and add necessary tags wherever required based on predefined regex patterns – would do more research on how to create something like this in the research phase.
• If you have a look at https://www.mediawiki.org/wiki/Help:Extension:Translate/Translation_units This shows an example of how the slides are to be formatted for translations.
  1. Text - The parser would automatically wrap strings written by the user in <translate><translate/> tags removing the need to manually add them.
  2. Images & Videos - We only need to wrap the main text within the templates in <translate><translate/> tags. This would also be taken care of by the parser.
     • Example - [[ File:Torsö.jpg | thumb | <translate>A typical view of Fréttinga</translate> ]]
• We can run this parser when our HTML is converted to Wikitext by any of the two methods mentioned above.
• If the user would like to make a few manual changes to these translated tags we could add an intermediate slide showing the transformed WikiText with the tags added then they can make changes and continue to publish the content on Wikimedia.

6) How will I roll out changes ensuring backwards compatibility?

To prevent disturbing the current system for the duration of the project, the implementation of these new features will be a multi-step process broken down to adding the basic functionalities first and then build more on top of them.

I will also write a few basic tests with the completion of each phase to ensure that the new additions don't break the previously added functionality and then more in-depth tests considering the edge cases would be written in the last phase of the project.

i) Phase 1

• Implement the add content by Wikimedia URL functionality for all types of training content.
• So that users can create content on Wikimedia and use this functionality to link them to the other content on the dashboard or add the new content directly without calling /reload_trainings.

ii) Phase 2

• Give users the ability to create new libraries & modules from the dashboard itself.
• For this phase the slides would have to be created on Wikimedia.
• Then the users can add those slides to the dashboard using the URL functionality.

iii) Phase 3

• Push the ability to create new slides on the dashboard itself.
• Write API calls to integrate uploading of local assets to Wikimedia.
• After this phase the user will have the ability to create all the content from the dashboard itself.

iv) Phase 4

• Start to work on integrating Translations.
• I think working on translations before “removing and editing features” is better as translations would require more time so we could have a buffer if plans change in the later stages.

v) Phase 5

• Start to work on the ability to let users edit the existing content present on the dashboard & Wikimedia.
• Give users the ability to remove content from the dashboard.
• Start writing tests to handle edge cases.

Timeline

May 1 - May 26 ( Week 0 )

• Community Bonding Period
• Learn more about how to implement the proposed changes
• Discuss how to implement certain features of the project ( mentioned before the timeline )
• Further refine the approach to ensure all project objectives are met

May 27 - June 2 ( Week 1 ) - Phase 1

• Finalize how to set up different parts of the UI to make creating new training material simple, easy, and intuitive
• Create new UI mockups or make changes to the existing prototype as per the requirement
• Start making the UI components to incorporate the URL functionality based on the mockups

June 3 - June 9 ( Week 2 )

• Complete the URL functionality backend for all types of training content.
• Write controllers to use API:Get_the_contents_of_a_page and store data in the Database
• Write API calls to API:Edit to update parent-child relationship on Wikimedia

June 10 - June 16 ( Week 3 ) - Phase 2

• Create forms for the Add Library feature.
• Write API call to add these new libraries to Wikimedia.

June 17 - June 23 ( Week 4 )

• Create forms for the Add Module feature.
• Write the controller to get all the Categories to help users categorize the new module.
• Make API calls to add this new module to Wikimedia & update this module’s slug in the parent library.

June 24 - June 30 ( Week 5 ) - Phase 3

• Create forms for the Add Slides - Quiz Slides feature.
• Write the backend to add Quiz Slides to modules.
• Create UI components for the Add Slides - Text Slides feature.

July 1 - July 7 ( Week 6 )

• Write controllers & UI logic to upload Images.
• Write logic to integrate the use of templates while creating new slides.
• Build on the HTML to Wikitext parsing functionality.

July 8 - July 14 ( Week 7 )

• Midterm evaluation.
• Buffer time for previous weeks
• Add the preview slide functionality.
• Conduct manual testing to pinpoint potential areas while creating new slides where the code could break

July 15 - July 21 ( Week 8 ) - Phase 4

• Make revisions based on the feedback I receive.
• Start working to integrate translations into the existing system.
• Write the script/parser to automatically add tags where necessary.

July 22 - July 28 ( Week 9 )

• Add the option to view and make manual changes to the translation tags.
• Conduct manual testing to pinpoint failures where the script doesn't perform as expected and make changes.

July 29 - Aug 4 ( Week 10 )

• Start writing the routes and logic for the edit functionality.
• Add the ability to remove content from the dashboard.

Aug 5 - Aug 11 ( Week 11 )

• Start writing tests to define the expected behavior and help in future modifications and maintainability.
• Make revisions based on the feedback I receive.

Aug 12 - Aug 18 ( Week 12 )

• Refactor and optimize the code to improve readability
• Document the code, functionality, and usage for reference and future maintenance
• Prepare for final evaluation by ensuring all project requirements are met

---

Participation

• I have been actively communicating my issues and doubts with @Ragesoss through Slack and GitHub, and I will continue to do so.
• I would be glad to help other contributors and users solve their issues.
• The entire process will be documented in biweekly progress reports.
• I will be available via Slack, Zulip, Email, or Video Call sessions as needed.

About Me

Your education (in progress)

• University: Jaypee University of Information Technology, Solan.
• Course: B.Tech in Computer Science Engineering
• Year of Study: Third Year

How did you hear about this program?

I learned about GSOC from one of my college friends who was in the "writing a proposal" stage himself for GSOC 23’. I thought the process was fascinating and thus made the decision to try it out for myself in 2024.

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 program, I won't have any significant commitments. I’ll have my exams in the first week of June and then I'll be on summer break from my college till the end of July. After July, I intend to allocate 5-6 hours on weekdays after my college classes and 7-8 hours on weekends for GSOC. Moreover, as my college schedule isn't too demanding, I'll have time available between my college hours as well.

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 to Google Summer of Code with the Wikimedia Foundation.

What does making this project happen mean to you?

This was the first time I tried contributing to any open-source project. The jump from making personal projects & participating in hackathons to contributing to a large-scale project which real users use was surely a learning curve for me, and I enjoyed every part of it. I have been contributing to the Dashboard since November last year and I am grateful for this opportunity. I promise to keep putting in effort and staying dedicated to this project.

---

Past Experience

Internships

Culinda Inc

• Role: Full-Stack Intern
• Responsibilities:
  • Transitioned web scraping bots from Selenium to Puppeteer.
  • Set up scheduled cron jobs for automation.
  • Integrated OpenAI for retrieving answers to recruitment questions.
  • Streamlined the job application process without requiring user interaction.

Exponance Twirltree LLP

• Role: Full-Stack Intern
• Responsibilities:
  • Contributed to both frontend and backend development tasks.
  • Developed Staff Attendance System by designing and building RESTful APIs reducing manual work.
  • Enhanced system security by integrating JWT authentication and an access control system minimizing unauthorized access.

Personal Projects.

Pintastic Video Link

• It is a pin-sharing social media site like Pinterest
• Developed using Next.js, Firebase, and TypeScript.
• Users can explore and like pins shared by other users and add their pins.
• I also added a Chrome Extension to make the process of adding pins from other websites easy and efficient.

Interviewlabs Video Link

• It is a platform designed for conducting C++ coding interviews online.
• Developed using React.js, Express.js, WebRTC, Docker, and Socket.io
• It provides communication between interviewers and candidates through video calls and real-time collaborative IDE.

JUIT Webkiosk API GitHub Link

• It is a web scraper designed to get academic data from the JUIT Webkiosk student portal.
• It fetches information such as attendance records, grades, and other informational data about students and their performance in academics
• The API initiates sessions using the student’s credentials, retrieves cookies for it, and uses them to replicate API requests using request-response to the backend. It then receives HTML responses containing valuable information, which is extracted using cheerio for further use.

Skills

• Languages: C++, JavaScript, TypeScript
• Frontend: HTML, CSS, Next.js, React.js, Redux, Tailwind CSS
• Backend: Node.js, FastAPI, Express.js, MongoDB, Socket.io
• Others: Git, GitHub, Linux, Docker, APIs, Web Scraping

Contributions to the Dashboard

Pull Request #5541

• Addressed a bug occurring when users tried to select a time before selecting the date while creating a new course.
• Gained familiarity with the codebase and how tests work on the dashboard.

Pull Request #5538

• Converted dashboard icons from Font Files to SVGs.
• Tested the method of extracting SVGs from Font files.

Pull Request #5542

• Continued conversion of icons to SVG format.
• Converted one component to a functional component.

Pull Request #5562

• Completed the conversion of all remaining icons to SVG format.
• Learned about server-side rendering and navigated through significant front-end code.

Pull Request #5544

• Added a UI feature providing advice on selecting a username before users are directed to Wikipedia to create their accounts.

Pull Request #5583

• Simplified program deletion by enabling deletion from the campaign itself.
• Started exploring the backend code and created child controllers for course deletion.
• Learned about routes and controllers.

Pull Request #5638

• Feature to prompt users to indicate if they plan to add more instructors and send reminder emails.
• Gaining comfort with Ruby and understanding database structure, alert mechanisms, email handling, and periodic checks.

Pull Request #5714

• Working on a feature to only show specific featured campaigns on the explore page on demand from the settings page.
• More hands-on experience with Ruby and wrote feature tests for the new functionality

Pull Request #4712 ( Open )

• Moving the training update process to Sidekiq to free up rails processes that serve web traffic to free up resources during the /reload_training workflow

---

Any Other Info

Prototype on Figma: Link to prototype

Data Flow Diagrams

There are two Dashboard’s each showing the data flow when the respective endpoints are called.

Current flow of data

Proposed flow of data