I'm Rishabh Rawat, a 3rd year (Junior year) engineering student specializing in Electronics and Communication from GGSIPU, India.
I'm working with PublicLab since October 2018. I was part of the Google Code-In mentors team.
Location: New Delhi, India
As we know, community-toolbox plays a big role when it comes to welcoming newcomers and having an in-depth look at our growing community, the idea revolves around enhancing the project with some new features and making it more reliable (by the error reporting to the user and the likes).
In short, it includes adding tests, documentation, and features while ensuring the maintainability of code backed with high reliability.
Abstract/summary (<20 words):
The implementation of this project can be classified majorly into 3 categories,
- Adding features,
- Dropdown for navigation,
- Implements PWA with offline & data fallback support, make it run as a standalone mobile app,
- FTO author list,
- Notifications for user knowledge,
- Night mode,
- Leaderboard of contributors,
- Filter for recent contributors,
- Stale issues,
- Make the project portable,
- Add bot for generating a list of all contributors,
- Add copy to clipboard button
- Writing tests, and
- Writing documentation.
Community-toolbox allows everybody to take a look at the activities going on in the PublicLab projects, helps in welcoming newcomers. It plays a major role in growing our community, the newcomers can look for fto and help-wanted issues in order to get-started & other people are able to notice their contributions and help them.
But, as our community is growing so fast, we need to be more active in community involvements in order to keep welcoming newcomers with the least possible latency, quick reviews, noticing stale issues and providing motivation to newcomers along with ease of use so that user can take a look at the page (cached), when he or she is offline.
Refactoring the code
The code in the current state is not refactored and contains files with lots of big chunk of functions. File names are not specified accordingly and the project structure needs to be updated. It is clearly not easy to read and get started with, so this idea includes segregating the code according to their use-case. This will make the code very easy to read and will make it highly maintainable.
Refactoring the code will make the project structure look like (based on the current state of code),
Here, in these screenshots, the model/database component is segregated according to the stages of their workflow, initialize.js will set-up the database, crud.js will be containing the code related to creation, deletion and reading the database and at last, util.js will provide the helper functions which will communicate with the outer code and to pass parameters to it.
Similarly, UI files, scripts, and utilities will get refactored.
Filter for sorting recent contributors
This idea includes adding a filter button for recent contributors' section which will allow users to sort the list according to the number of commits (highest first or lowest first).
This would include other filters like alphabetical and most-recent commit first.
We can store the data that we get for recent contributors from the Github API in the database so that we can manipulate it according to our needs.
Add dropdown for navigation
This includes adding a dropdown button for navigation, the user can view data for different repositories without having to change the URL by himself. This will make navigation much easier for people who don't know anything about URL & stuff.
Also, if a user will use the project as a standalone app, he won't have any address bar to enter the URL, so a navigation dropdown would make it sense.
Here's a quick look at the dropdown button working,
Add a list of FTO issue authors
This idea includes showing a list of
first-timer-only issue authors in order to appreciate the effort of people helping newcomers. This will encourage people & will lead us to a more welcoming community.
Currently, we get a list of
fto-candidateissues for any repository that is provided in the URL. We can filter out the issues having the label
first-timers-only in order to get their corresponding authors and show the formed list on the page. Here's a quick look at the list formed,
Add a list showing stale issues
One of the important sign of growing with everybody is no one should be stuck on a single issue for a long time, this is hence one of the most important steps we need to take in order to ensure "newcomer friendliness". It will surely improve a newcomer's experience.
As provided by Github API, we can fetch an organization's list of issues on which we can perform a check that if that issue's last updated date is within a period of 5-10 days (or so) or not. If it's not within 5-10 days (10 days is a good amount of time to measure against), we will put it on stale issues list so that people can take a look and help the author or contributor.
1. We first iterate over the issues and check if it's last updated date is 10 days back or not,
2. Then we push all the issues that are considered "stale" to the "staleIssues" array and call the UI function,
3. Finally, the UI code renders the data to the user
Adding the Notification system
This includes adding a notification system to the website. The main reason behind it is keeping the user in touch through notifications. This would let the user know what is going on or what's gone wrong. It will include notifications for some unexpected errors, exceeding the API limit and the likes.
A simple error notification will look like,
Adding Leaderboard of contributors
As the name suggests, this idea is about making a leaderboard of contributors last week/last month and show them on the page. This would provide inspiration to the new contributors and a sense of healthy competition will surely increase the productivity of people. As of now, we get the list of contributors last week and last month, that would help in extracting the list of super helpful contributors.
Step1: Calling utility function to store the RECENT contributors' data
Step2: Storing the data to the database
Step3: Using the data saved according to the filters we need to implement
Here's a quick look at plots2 leaderboard based on last month's commits,
Modify all contributors list's logic to include contributors of all different kinds
As we measure leaderboard according to the number of commits only, some of the contributors may get neglected in the process. Although creating the leaderboard by measuring all the variable factors (like comments, reactions, help in the chat, emojis, informal feedback, etc.) for each and every member is not possible (as Github API doesn't support that) but we can incorporate some library or logic to include all the of contributors while generating the list of all contributors so that no one gets neglected out.
As per discussion, we can use allcontributors.org for this purpose. It is basically a Github App (a bot) that helps us achieve that. The step associated are as follows:
Step 1: Install the Github App on community toolbox
The first step is to install the bot on the project so that it can take certain actions. (Below is an example screenshot of installation page)
Step 2: Configure the bot
We need to add a configuration file for the bot so that we can alter the behavior of the bot according to our needs. There's one option for setting the target file (the file which will get affected with every addition of contributor).
Here's an example config file,
Step 3: This is pretty much it on the coding part
After we've set up the bot and provided our version of custom JSON file as a config file, the bot is up and running on the project and now it is ready to work.
Its workflow goes something like,
1. Bot gets triggered when certain comments are present in issue or Pull request threads
2. After the PR gets merged, the corresponding contributor is added to the list affecting the targetted file. The contributors' card comes up something like this (with emojis expressing the type of contributions he or she did)!
Make community toolbox easily adaptable by other organizations or people in general
As we know, community toolbox is a portfolio of our community which does much more than that. It plays a major role in welcoming newcomers and maintaining momentum while iterating over our development milestones. It can surely turn out to be helpful for other people or organizations too, for sure!
This idea includes making the project portable so that any other organization can use it for their own purposes as well. This would be so much good for everybody, making this happen is way more fun.
As the only file we render is index.html, we need to make it portable first. It includes sourcing the data of index.html from a JSON file which will be the only file any new organization would have to change in order to get going with the setup.
All of the requests that get sent in the backend are already flexible to any organization, just needs some checks.
We can use jQuery's getJSON() to fetch the data from the JSON file and then we can insert that data to our index.html file accordingly.
Add a night mode theme
As community toolbox is a website that is very frequently visited by people especially by newcomers, there should be support for night mode theme which will help people use the website at night easily without straining their eyes.
It will also remember the user's choice when he visits after some time and will apply the theme accordingly. Like if the user had switched to night mode in his last visit, he'll be looking at the same mode he switched to, in his future visit.
Implement copy to clipboard for usernames
This idea includes adding a button for copy to clipboard functionality so that the job of copying & pasting the usernames of contributors become much easier for people. This can be helpful whenever we need to mention a bunch of people (like in check-ins).
Here's a quick look at the functionality,
1. Usernames get copied to clipboard after clicking that "Copy to clipboard" button,
2. Now we can paste them anywhere,
Offline support with data-fallback
As of now, the project does not support visiting the page when offline and does not support data-fallback in case of Github API not returning any data back to us.
So, this idea includes adding a service worker for converting the project into a Progressive Web App (PWA) which will help us achieve the following,
- Visit a (cached) page when offline provided he/she has visited that page at least once before,
- [Data Fallback] Take a look at the data that Github API provides when the user is offline, the copy of the data will always be the latest one and will be reliable. In case, the website couldn't make a successful request to the Github API, the data will be fetched from the stored clone of the most recent data that API sent to the site.
- Visit the project through his/her smartphone after adding the website to the home screen (as a standalone application).
Here's a script which will register the service worker,
Here's a quick look at how the website will behave when offline:
Adding the website to the home screen
The user would be able to add the website to the home screen so that he/she doesn't have to go to the browser to visit the site. Moreover, having a separate "app" for visiting
code.publiclab.org would enhance the UX and we will be able to add more OS specific features to the site in th future (like push notifications, using the camera, etc.).
Add Tests to the project
As the project is slowly getting big and so our community, we need a proper test suite to test the code written to ensure that we don't break anything as we move forward. This would promise high maintainability with less vulnerability to errors. Writing the tests can be broken down into 2 major categories,
1. Writing tests for the code written till first evaluation, and
2. writing the tests for the remaining part.
This way we can ensure that the code already present (by the end of first evaluation) is well covered with tests so that we can move forward without hesitation.
Here's the tentative directory structure for tests,
As the project is getting big, it needs proper documentation for a newcomer to get going with it and it should be easy to read and get started with. The good way of structuring this documentation would be to show a flowchart of the functions/files and indicate the flow of control through it. Adding code snippets will make it more easy to understand.
A sample flowchart for showing the control flow of the project in its current state looks like,
This can be explained along with code snippets. A good way of structuring the documentation.
Also, I'll try to create as many FTOs and PR reviews as I can, at the end of each week.
I'll be needing the guidance of my mentor(s), I'll be going through some documentations/libraries which is easily available on the internet :).
Contributions to PublicLab
Contributions to Community Toolbox
Contributions to other repositories
I've opened a check-in here.
I started programming around 1.5yrs back. So my first exposure to programming (web development) was learning HTML and CSS. I am contributing to PublicLab since October 2018.
I was the part of the Google Code-In Mentors team at PublicLab.
I've worked on other projects as well, I made incoming webhook notifiers and chatbots (more like slash commands) (on an already baselined codebase) for Zulip, I've worked with coding blocks as I was part of their annual summer of code event named Bountiful Open Source Summer (BOSS) and ranked in top 10, my personal projects include a python/Django website (https://github.com/rishabh570/refresher) and a simple chat-app made with Django-channels (https://github.com/rishabh570/chatroom) and a dynamic theme firefox add-on (https://github.com/Rishabh570/themed).
I've had my summer internship at Malik Ventures last year, I was working with a team of 6 people. We were working on two projects at that time, radixhealthcare.org (website for a hospital) and harvin.academy (a coaching institute) and I was responsible for the backend part (Node.js/Express). That was my first exposure to how teams work.
Moreover, I've been working with PublicLab since GCI'18, opened a couple of issues on multiple repositories and worked on multiple issues. Working with PublicLab has definitely solidified my understanding of how big teams work.
We at PublicLab have such a diverse group of people. Our community is very active which helps in maintaining the momentum, I get to learn so much while working on the project and the best thing is, we care about welcoming newcomers to our community (by ftos/fto-candidate/help-wanted) which is great. A good cause mixed with technology is a great combination!
My project would help in making the organization's portfolio more robust and will provide some features which will help in having a deeper look at the community involvements and welcoming newcomers.
Yes, I understand that. I would be fully committed to my work.