Page MenuHomePhabricator
Create Task
Maniphest T248918

GSoC 2020 Proposal : Improve Wiki Education Dashboard's Error Monitoring
Closed, ResolvedPublic
Actions

Description

Profile Information

Name Shashwat Kathuria
GitHub shashwatkathuria
Personal Website shashwatkathuria.github.io
LinkedIn shashwat-kathuria-053796182
Resume Click to view
Location New Delhi, India
Typical working hours 12PM to 3 AM UTC+5.30

Synopsis

  • Short summary describing your project and how it will benefit Wikimedia projects

WikiEduDashboard is a web application which provides tools that help instructors and students share their knowledge on different wikis like Wikipedia, Wikidata, etc and also be able to track their contributions. Instructors are able to organize different types of courses like Edit-a-thons, Article Scoped and Basic, along with the flexibility to also let program leaders and instructors run campaigns having multiple courses. Keeping track of contributing on a vast platform like Wikipedia, or other wikis is itself a task and this application helps in managing that. With the backbone of such a strong implementation, there are many articles on Wikipedia which ultimately help people across the globe in having access to the knowledge shared. It is implemented with Ruby on Rails on the backend and mostly ReactJS on the frontend and runs on two websites: https://dashboard.wikiedu.org/ and https://outreachdashboard.wmflabs.org/

WikiEduDashboard pulls data related to a wide range of WikiMedia projects, across groups of editors. This scales upwards when we go on to different courses, then different campaigns. This is really huge data coming from the MediaWiki API which is updated course by course. Following the /manual_update path on a specific course itself eats up a few seconds time on the developer’s system, and this is when the revisions are small in number. And this data is what is ultimately kept track of by the WikiEduDashboard application. Currently, all the error logging is done with the help of gem sentry-raven which takes care of both errors on the server-side Ruby and the client-side JavaScript. The problem with sentry-raven is that it is noisy and not that helpful when it comes to errors that relate to specific jobs. A number of reasons due to which errors can occur can be that some unusual part of the data is not handled properly and it never updates, failing every time, or maybe WikiMedia servers might be unavailable for a short period due to a load full of requests coming at the server or some other bug, or maybe the course itself is so big that the server is only able to handle a partial amount before it gets out of memory, or maybe the server itself crashes while fetching the data. Currently, there is no way for a course leader or participant to know what is happening.
The course stats are pulled in a regular cycle of continuous updates, which is managed with the help of gems sidekiq and sidekiq-unique-jobs of which the former is a job scheduler and the latter prevents duplicate jobs in the Sidekiq queue.
Currently in the lib directory three types of errors are being handled, i.e., relating to authentication errors(which is overridden with modifications in messages), rescue development errors and rescue errors.

  • Possible Mentor(s)

@Ragesoss

  • Have you contacted your mentors already?

I have communicated with my mentor Sage Ross many times, via GitHub and Slack and have been able to figure out a common time for discussion.

Implementation Details

An error mechanism will be created that works along with UpdateCourseStats, and the errors will be saved in the database in association with a particular course. Along with this multiple Sidekiq jobs and Sidekiq queue are to be kept track of, and failing ones will be notified.

There will be a separate tab in a course for showing data related errors and statuses of failed Sidekiq jobs, with its visibility set only for admins, program leaders and instructors.

Abnormalities in the JSON response objects from the MediaWiki API will be reported as errors in the course error tab, alerting about some unexpected data or API changes.

Data is currently fetched in three compartments. The error monitoring of these three compartments is very crucial because course data is updated on the basis of the data received here :

  • CourseRevisionUpdater
  • RevisionScoreImporter
  • CourseUploadImporter

The separate jobs will be kept track of and if any job fails, the process will be rolled back if possible and notified of the job failing. There are a lot of Sidekiq::Workers being used in app/workers (CourseDataUpdateWorker being a crucial one) which are to be kept track of, along with use of Sidekiq::Queue in scheduling of course updates in lib/data_cycle/schedule_course_updates.rb. Their status can be tracked with the help of gem sidekiq/api or gem sidekiq-status, each with some pros and cons, like sidekiq-status allowing us to store data with a job, whereas sidekiq/api has more user base but is somewhat not recommended for scalable applications as some of the operations cannot be used in bulk or automated fashion.

The update_course_categories, update_article_status, update_average_pageviews and update_caches being called for the updation of course categories, article status, average pageviews and caches also have to be verified in some way that they are updated. Either the checking of the updated things has to be done by keeping track of the counts, or in depth checking of the data is to be done. A helpful tool can be ActiveModel::Dirty .

Following updation of caches are to be kept track of :

  • ArticlesCourses
  • CoursesUsers
  • HistogramPlotter

Errors will also be reported if a significant upward deviation from course.flags[‘average_update_delay’] occurs in the course update process. Some relation regarding the total number of revisions with the total time taken for a course to update can also be analyzed statistically to detect any odd behaviour. Errors regarding system hitting a rate limit or unavailability of MediaWiki API servers will also be kept track of, if no responses are being received to the requests sent. Also, if the system gets out of memory, because of the course data being very big, errors will be notified accordingly.

Deliverables

Describe the timeline of your work with deadlines and milestones, broken down week by week. Make sure to include time you are planning to allocate for investigation, coding, deploying, testing and documentation

1 April - 3 May
  • Study more about the ways in which errors can occur in the background Sidekiq jobs, how to handle them and track their status
  • Gather more knowledge about how to handle the errors in an efficient way in the scenarios discussed
  • Continue solving more project related bugs on WikiEduDashboard
May 4 - May 30
  • Community bonding period
  • Finalize the gem to be used to track the status of Sidekiq jobs
  • UI mockups and finalizing how to display errors and statuses of jobs.
  • Finalize the error mechanism to be used for checking if the data is fetched properly, API changes, MediaWiki API server down, verification of updated details etc
  • Mark the bugs to be solved during the internship
Week 1 (1st June - 7th June) & Week 2 (8th June - 14th June)
  • Add gem to track Sidekiq jobs status
  • Implement the functionalities of the same in the existing jobs and store the job statuses if they fail
  • Make API interface/controller for communication of the same
Week 3 (15th June - 21st June)
  • Start working on UI Tab for displaying job statuses
Week 4 (22nd June - 28th June)
  • Testing
  • Documentation
  • Solve bugs
Week 5(29th June - 3rd July)
  • Phase 1 Evaluations
  • Start doing Week 6 work alongside
Week 6 ( 3rd July - 9th July) & Week 7(10th July - 16th July)
  • Start working on the custom error mechanism
  • Design and migrate to database as required
  • Make API interface/controller for communication between client and course error information
Week 8 (17th July - 23rd July)
  • Work on UI Tab to display course specific errors
  • Start working on errors to be handled in different scenarios
Week 9 (24th July - 27th July)
  • Testing
  • Documentation
  • Solve bugs
Week 10 (27th July - 31st July)
  • Phase 2 Evaluations
  • Start doing Week 11 work alongside
Week 11 (1st August - 6th August) & Week 12 (7th August - 13th August)
  • Continue working on UI Tab to display course specific errors
  • Continue working on errors to be handled in different scenarios
  • Verify updation of course details
Week 13 (14th August - 20th August)
  • Add some statistical time related error handling, i.e., average delay in course update in relation to number of revisions, etc
Week 14 (21st August - 24th August)
  • Testing
  • Documentation
  • Solve bugs
24th August - 31st August
  • Final Project Submission
  • Final Evaluation Submission
31st August - 7th September
  • Final Evaluations by Mentors
8th September
  • Final Results Announced

Additionally, I will post about weekly updates and experiences on my personal website and meta wiki user page.

Participation

Describe how you plan to communicate progress and ask for help, where you plan to publish your source code, etc

  • Joined Slack group for WikiEduDashboard
  • Regularly communicating with mentors and asking for help as required
  • I am going to work on separate branches on git (GitHub) and upload code on a regular basis. Also, create pull requests as and when a feature is completed. I have followed this process since a while now in my PRs.
  • Online on Slack and active on GitHub during my working hours.
  • I will also communicate on Phabricator via comments on the related project subtasks.
  • I will submit my weekly reports on my meta wiki user page
  • Weekly publish my experience on my personal website

About Me

Tell us about a few:

  • Your education (completed or in progress)

I am currently pursuing Bachelor of Technology, Computer Science & Engineering from Indian Institute of Technology (IIT), Jodhpur and I am in my 3rd year (6th Semester) currently. The program spans four years (8 Semesters).

  • How did you hear about this program?

I heard about this program through students in my college. A few of them have already participated in the program. I have gained a lot of insight regarding the same from them, and was encouraged to take part in the same as I am really interested in open source development and participating in this program would give me a kick start for the same.

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

I will be able to dedicate 40 hours per week to this project, and more if required.

I don’t have any other time commitments during the duration of the program apart from a brief period of time other than vacations in my college. Also, my summer vacations span from 3rd of May to 19th of July and I will be able to work during that time fully. In the remaining small part of the college days, I will still be able to work in the working hours specified as mostly all of my classes are during early morning hours only. Also, I have mostly worked while attending college till now in the WikiEduDashboard GitHub repository and do not face any issues regarding time commitments.

  • 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 applying only for Google Summer of Code and in 2 projects of Wikimedia Organization regarding WikiEduDashboard project.

  • What does making this project happen mean to you?

My inspiration to work on this project is due to the reach and free knowledge that this project provides, being used in many universities worldwide and collectively enhancing our knowledge, so I want to be a part of this initiative by contributing and try to make it even better with more features. Apart from that, there are technical reasons also due to which I am extremely excited to work here, first and foremost, WikiEduDashboard being a Web Development project, which is my favourite field, along with the real life applications of how an application is implemented to serve people communicating in different languages, the design of the application, database, classes, testing, performance, etc put together to give one piece of a software which is used by so many people around the globe.

Past Experience

Describe any relevant projects that you've worked on previously and what knowledge you gained from working on them. Describe any open source projects you have contributed to as a user and contributor (include links). If you have already written a feature or bugfix for a Wikimedia technology such as MediaWiki, link to it here; we will give strong preference to candidates who have done so

I have been working with Ruby on Rails, Django, Flask and JavaScript frameworks like ReactJS, AngularJS since 3 years and have done several web development related projects, implementing all of them from scratch as a full-stack (both frontend and backend) developer. I have also worked with several databases like MongoDB, PostgreSQL, SQLite, MySQL and also used several hosting services like Heroku, Microsoft Azure, Amazon Web Services, MongoDB Atlas, GitHub Pages, etc. along with testing tools like Rspec, Jest, Capybara, Selenium, Django testing framework, etc.

I use Linux Ubuntu, have worked with virtual environments in my Django projects and also, I am very comfortable with git VCS (Version Control System) and have been using it in all of my projects since the past 2 years.

Relevant Projects
Social Cloud

An Instagram like website for users to post images and follow people. Implemented with Ruby on Rails, MongoDB/SQLite/PostgreSQL, Bootstrap and AngularJS. Uses Rspec and related testing tools. Hosted on Heroku and database on MongoDB Atlas.

Drawing Canvas

A drawing application for users to draw stuff and save them. Implemented with Django, SQLite/PostgreSQL, Bootstrap and a ReactJS & d3JS frontend. Uses Django testing framework. Hosted on Heroku.

IITJ HealthCare

An online medical prescription portal for patients to get prescriptions from doctors. Also includes a medical store for inventory information about medicines and an emergency portal. Implemented with Django, SQLite/PostgreSQL, Bootstrap and Javascript. Uses Django testing framework. Hosted on Heroku.

Disaster Safety App

An online portal which broadcasts alerts about natural calamities like earthquakes, hurricanes, etc. as and when they happen through user interaction. It also has an android application apart from the web application. Implemented with Flask framework in Python, Android Studio, SQLite, Bootstrap. Used Microsoft Azure VM for deploying.

Pull Requests in WikiEduDashboard (Started contributing around the starting of March 2020)
Issues in WikiEduDashboard

Related Objects
Search...

Event Timeline

Shashwatkathuria created this task.Mar 30 2020, 8:38 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 30 2020, 8:38 PM
Shashwatkathuria added a parent task: T244428: Improve Wiki Education Dashboard's error monitoring.Mar 30 2020, 8:40 PM
Pavithraes moved this task from Backlog to Accepted Proposals on the Google-Summer-of-Code (2020) board.Mar 30 2020, 9:08 PM
Shashwatkathuria updated the task description. (Show Details)Mar 31 2020, 5:58 PM
Pavithraes mentioned this in T248920: GSoC 2020 Proposal : Improve Wiki Education Dashboard JavaScript build pipeline and reduce bundle size.May 5 2020, 5:45 PM
srishakatux subscribed.Sep 23 2020, 3:39 AM

Google-Summer-of-Code (2020) is over! I believe you have already documented your project here https://www.mediawiki.org/wiki/Google_Summer_of_Code/Past_projects#2020. If not, I would encourage you to do so. Also, is there anything else remaining in this task to address? If not, please consider closing this task as resolved.

srishakatux awarded a token.Sep 23 2020, 3:59 AM
Shashwatkathuria closed this task as Resolved.Sep 23 2020, 10:23 AM

Yes, I have added the documentation. There is nothing else remaining in this task, I am closing it as resolved

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits