===Profile Information
**Name** Shashwat Kathuria
IRC nickname on Freenode**GitHub** [shashwatkathuria](https://github.com/shashwatkathuria)
Web Profile**Personal Website** [shashwatkathuria.github.io](https://shashwatkathuria.github.io/)
Resume (optional**LinkedIn** [shashwat-kathuria-053796182](https://www.linkedin.com/in/shashwat-kathuria-053796182/)
Location (country or state**Resume** [Click to view](https://shashwatkathuria.github.io/layouts/resume.html)
**Location** New Delhi, India
**Typical working hours (include your timezone)** 12PM to 3 AM UTC+5.30
===Synopsis
- **Short summary describing your project and how it will benefit Wikimedia projects**
- Possible Mentor(s)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/
Over the last several years, evolution in the JavaScript trends have led to new features and some of them are to be implemented in the build tooling of the application. Currently, the project uses Gulp, a toolkit for running, automating time-consuming tasks and Webpack, a static module bundler for JavaScript (mostly) along with HTML, CSS and images which generates a dependency graph for helping developers in modular approach.
Webpack is basically an advanced build process, being similar to Gulp or Grunt, taking files, running them through some sort of conversion and spitting them out into something the browser can understand. It splits things in a modular way, such that things are no longer global, relieving us of certain collisions in namespaces, and making things very explicit which is very much required in an application made in React. It also handles conversion from ESNext to the current version of JavaScript that works in the browser using Babel. So using it with something like Babel or Sass or autoprefixer basically converts the code to something the browser can read, also making the code very organized. It can do dead code elimination, bundle up smaller modules of JavaScript so that all JavaScript of the application doesn’t end up reaching a user using only a small part of the application. The current usage of Gulp in our project can be completely replaced by Webpack, giving a significant performance boost and modularity.
- **Possible Mentor(s)**
- Have you contacted your mentors already?@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
The current implementation of the build tooling and bundle needs improvement. Removal of !!! (2 libraries relating to it in !!package.json!!) and replacing it with !!vanilla JavaScript!!(which can work well when used with Code Splitting), and removal of other unnecessary dependencies needs to be done.
Currently the tasks !!Gulp!! is used for can be performed by !!Webpack!! itself. So, keeping in mind the advantages and disadvantages, removal of !!Gulp!! needs to be done, and the tasks be performed by !!Webpack!! itself, after weighing multiple factors like layering in running the tasks, I/O Operations in the processes, number of available plugins, number of tasks, compatibility with other operating systems like Windows in which !!npm!! doesn’t work nicely, etc.
Now coming to the tasks, following tasks can be found in !!gulp/tasks!! :
- !!clean.js!!
- !!copy-static.js!!
- !!i18n.js!!
- !!icon-font.js!!
- !!jquery.uls.js!!
- !!lint.js!!
- !!minify.js!!
- !!set-development.js!!
- !!stylesheets.js!!
- !!watch.js!!
- and ultimately !!webpack.js!!
All of these tasks relate to asset compilation (which are present in !!app/assets!!, consisting of !!fonts!!, !!images!!, !!javascripts!!, !!stylesheets!! and !!svgs!!) which can be handled by !!Webpack!! pretty nicely in a modular and well organized fashion, which is why it has become an industry standard these days. Currently, in !!webpack.config.js!! we make use some of the libraries (configured as entry points) defined in !!app/assets/javascripts!! consisting of :
- !!main.js!!
- !!raven.js!!
- !!styleguide.js!!
- !!survey.js!!
- !!survey-admin.js!!
- !!survey-results.js!!
- !!campaigns.js!!
- !!charts.js!!
- !!tinymce.js!!
- !!embed_course_stats.js!!
Some of these are standard libraries, while others are user defined/project specific.
When the asset compilation will be shifted to !!Webpack!! along with Code Splitting, we will observe a significant performance boost as this extra layer of !!Gulp!!, which is not recommended when the number of tasks goes into two or more digits (which here is 11 tasks), will be removed. Also many of the extra dependencies involved with !!Gulp!! in !!package.json Line 38 - Line 61!! can be removed and the related (and required) !!Webpack plugins, loaders, etc!! can be added to !!webpack.config.js!!, which will definitely be less in size and number. One of such instances can be pointed by looking at the !!i18n.js!! task in !!Gulp!! itself, which can be integrated into !!Webpack!! by adding !!! or !!!.
A significant performance boost can be obtained by Code Splitting, i.e., chunking the bundle along several entry points which are to be identified and configured, prevention of duplication of libraries by separating shared modules like !!! and Prefetching & Preloading modules. A useful feature can be implemented to split code into various bundles which can be loaded as required - on demand / parallel. Also implementing dynamic importing wherever applicable. Prefetching & Preloading of modules can be done where usage hints are there for future use in application, for example, Prefetching & Preloading libraries required for !!Login Module!! when a user clicks !!Log In With Wikipedia Link!!.
A !!Webpack!! bundle analyzer tool !!! will also be added to visualize the size of the asset compiled files (output) of !!Webpack!!.
Along with this, Tree Shaking will be done, i.e., removal of code exported but not imported, which can be solved by importing by module name as much as possible. A useful feature of !!Webpack!!, Scope Hoisting will also be implemented which can help in reducing the !!Webpack!! bundle size and make !!JavaScript!! execute faster in the browser.
We can observe that a heavy library !!lodash!! is being used in many places in the code. It can be observed in !!package.json!! that 6 libraries relating to !!lodash!! are being used, so the removal of unused features of some libraries like !!lodash!! can be a boost. Addition of !!! can be done to remove !!lodash features!! that are not being used. This would significantly help in reducing bundle size.
Moreover, there are a few Ruby gems which can be eliminated, some which are deprecated and some which can be replaced with others. They include !!! which can be replaced by !!! !!!, removal of !!!, !!! which can be replaced by !!! !!! and ! !!([Related Link](https://frontdeveloper.pl/2020/03/how-we-migrated-from-timecop-to-built-in-rails-5-2-time-helpers/)) (linked to issue [#3864](https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3864)) with rails in built features if linked PR is not merged.
===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 bundle analyzer tools and possible ways in which bundle size can be reduced
- Gather more knowledge about how the usage of some heavy libraries like jQuery can be replaced with vanilla JavaScript (plain JavaScript)
- Continue solving more project related bugs on WikiEduDashboard
====== __May 4 - May 30__
- **Community bonding period**
- Finalize the bundle analyzer tool to be used
- Discuss the advantages, disadvantages and differences between Gulp and Webpack (and npm) with the mentors
- Finalize the libraries (and dependencies) and gems which are to be added or removed from the build pipeline and rails bundle respectively as per the current trends
- Mark the bugs to be solved during the internship
====== __Week 1 (1st June - 7th June)__
- Perform Tree Shaking
- Remove dead code from the bundle in places where code is exported but not imported anywhere
====== __Week 2 (8th June - 14th June)__
- Perform Scope Hoisting
- Add a bundle analyzer tool.
- Integrate the use of i18n internationalization files into Webpack
- Add fingerprints to the i18n files
====== __Week 3 (15th June - 21st June)__
- Replace the use of jQuery with vanilla Javascript
- Remove unnecessary dependencies wherever applicable
====== __Week 4 (22nd June - 28th June)__
- Testing
- Documentation
- Analysis using bundle analyzer, performance metrics
- 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)__
- Removal of Gulp
- Transition into Webpack
====== __Week 8 (17th July - 23rd July)__
- Perform Code Splitting
- Split code into various bundles
====== __Week 9 (24th July - 27th July)__
- Testing
- Documentation
- Analysis using bundle analyzer, testing and documentationperformance metrics
- 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 performing Code Splitting
- Split code into various bundles
- Prefetching & Preloading of modules
- Removal of unused features of lodash
====== __Week 13 (14th August - 20th August)__
- Replacement of deprecated gems and removal of unnecessary gems in the rails bundle
====== __Week 14 (21st August - 24th August)__
- Testing
- Documentation
- Analysis using bundle analyzer, performance metrics
- 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](https://shashwatkathuria.github.io/) and [meta wiki user page](https://meta.wikimedia.org/wiki/User:Shashwatkathuria).**
===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. etcI 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](https://meta.wikimedia.org/wiki/User:Shashwatkathuria)
- Weekly publish my experience on my [personal website](https://shashwatkathuria.github.io/)
===About Me
**Tell us about a few:**
- **Your education (completed or in progress)**
- 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)?**
- What does making thisI am applying only for Google Summer of Code and in 2 project happen mean to you?s 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**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, Amazon Web Services, Microsoft Azure, 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.
- Deployed at https://social-cloud-sk17.herokuapp.com/
- Code Repository at https://github.com/shashwatkathuria/SocialCloud
===== __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.
- Deployed at https://drawing-canvas-sk17.herokuapp.com/
- Code Repository at https://github.com/shashwatkathuria/Drawing-Canvas
===== __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.
- Deployed at https://iitj-healthcare-sk17.herokuapp.com/
- Code Repository at https://github.com/shashwatkathuria/IITJHealthCare-Project
===== __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.
- Code Repository at https://github.com/shashwatkathuria/Disaster-Safety-Web-App
==== __Pull Requests in WikiEduDashboard__ (Started contributing around the starting of March 2020)
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3881
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3680
- It modifies the hash of flags in the TrainingModulesUsers to accommodate course id as well if the training module is an exercise by using nested hash of flags indexed by course ids.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3875
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3873
- It deletes the open requested account requests related to a course if a course is deleted.
- **Under discussion** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3869
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3847
- Adds a filter to the activity tab to display course specific activity, i.e., tracked revisions of the course.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3867
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3647
- It tracks only those revisions which are tracked by the course wikis, and hence counts those only.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3837
- Continuation of **Closed** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3828
- Fixes https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3500
- Adds a new feature (enhancement) of displaying the time taken by a user to complete a training module. If the completion time is less than one hour, it is displayed.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3863
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3849
- It renders the navbar only when the course information is received.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3823
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3822
- It parses the data received from wiki requested accounts response, parses and displays the data in a user friendly format.
- **Under discussion** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3842
- Fixes https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3500
- Adds a new feature (enhancement) of introducing time limit in clicking the next page of the training modules if the user is logged in. This is done so that the user does not fast forward through the training slides for the sake of completion.
- **Ready for merging** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3907
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3905
- Corrects navigation as required and adds an additional preview link.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3815
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3792
- It adds a z-index to edit button so that it doesn’t overlay on the dropdown.
- **Merged** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3817
- Fixes the issue https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3816
- Minor statement bug.
- **Under discussion** https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/3814
- Fixes https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3807
- Minor bug to fix the alignment of the text ‘Log In With Wikipedia’
==== __Issues in WikiEduDashboard__
- https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3822
- https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3847
- https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3807
- https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3812
===Any Other Info- https://github.com/WikiEducationFoundation/WikiEduDashboard/issues/3816
Add any other relevant information such as UI mockups, references to related projects, a link to your proof of concept code, etc