Name: Gourishankar panda
Major: Computer Science
Timezone: IST (GMT+5:30)
Background work and Programming Skills
I am a second-year student. I'm pursuing a degree in Computer science. I use mostly Android studio for development. I am proficient in java and comfortable in Python.
Java easily lets me convert my ideas into code. I like it mainly because it is a very well structured language which gives you the freedom to do so many things dynamically. I like Java a lot. I have a very great experience reading tutorials on Java and also blogs.
I started programming as an Android developer, I used Django all the time which made me familiar with Python in the beginning. I know how to use Git and Github. If I am stuck, I go to Google and always come back with a solution. I have participated in many Hackathons and won prizes at Hackathons.
Past Experience And The Project
I know about Open source since the fall of the previous year. Since then I love open source.
I learned a lot from open source projects. I have developed many android apps and published some to Google Play Store.
*Weather app This app helps you see the weather forecast of any cities.
*Messaging app In this app you can chat your contact list and group chat and much more.
*Women safety app This app is designed to ensure safety for women. And many more.
I also participated in (kwoc) Kharagpur Winter of Code. In there I contributed many projects some of them are Fitofy-India, Melonicious , Open-Source-Android-Weather-App,instigo-android.
The Problem and Motivation
A new section called Leaderboard next to Achievements can be created. This leaderboard will show User’s Avatar, Name, and Score. The score could reuse some numbers from achievements, but should only count edits done with the mobile app because otherwise, Vicuna/etc users will dominate the top of the leaderboard even if they don't use the mobile app.
Listing in the leaderboard only the users who have ever opened the achievements activity. We will keep track of that information server-side. So the leaderboard would only list app users who have an interest in this kind of game.
We can add auto-scroll to the user's current rank and highlight it so that users don't have to look at all results to see the rank, also a button can be added which will automatically jump to the user's rank on clicking.
Tapping the name of a user in the leaderboard should open the gallery of that user's pictures, probably as a browser URL for now. Knowing they are being watched by their peers will probably reduce the temptation to "cheat" (for instance by uploading 1000 pictures of the same spoon).
The user's name should be highlighted.
The length of the leaderboard could be dynamic, for instance, if I am 3rd it could be 10 people, but if I am 13rd it could be 20 people. Or just make more people appear when scrolling down.
There could be weekly (last 30 days) rankings, yearly (last 365 days) rankings, all-time rankings.
To make it more visually attractive. Users like to personalize their avatar, so we could also offer the option to select one of the user's uploads as an avatar picture, but that may lead to more selfies, so this option could be a privilege to unlock (only users who are above level 5 for instance).
The leaderboard lists should probably be calculated on the server where we currently perform achievement calculations, and cached (re-serve the same results if less old than 1 hour). The user will probably upload a few more pictures in 5 minutes and come see the leaderboard again. So we could recalculate only that user's new scores (and let the other people's scores stay the same until the next hour comes). In other words, only the users who keep looking at the leaderboard would have their score grow at smaller intervals than 1 hour. That 1-user-only recalculation itself should be cached something like 1 minute because a picture can not be neatly uploaded in less time, and to avoid useless server load.
We can automatically add the user in the leaderboard, once he performs any of these actions:
or nearby upload
In our backend, we will have:
A list of users(with option 1 or 2) for whom we need to calculate statistics
Periodically fetch the statistics (every 1 or 4 hours). Update the statistics in our tools forge DB
When the Commons app does an API call to get leaderboard info, serve the statistics using tools forge DB instead of calculating real-time.
Since I don’t know much about design. Whatever the community will decide I will go for it. I believe that the project has some design guidelines. Here are some basic screenshots from GitHub discussion #2074.
Do you plan to submit any other proposal apart from this one?
No, I am only submitting this proposal.
Do you have any other plans this summer?
No, I don’t have any other plans this summer
How many hours per week can you dedicate to this?
I would be able to devote 40 - 50 hours a week during the project since I have no other big project devoted to the summer. My summer vacations start on 29 April and I'll not be engaged in vacations. My academic year would begin by July 17, but for the first month, I would still be able to devote around 40 hours since I love this project.
|Community Bonding Period||The principal focus in this period would be studying in detail the functionalities Wikimedia API and also Community.I'll ask guidance from my mentor upon the functioning of the Wikidata API Client library that is the most crucial part of my project.If possible, I would also start coding in this phase only, so that I get a head-start.|
|Week 1||In this period, I'll update the UI current achievements activity to the first tab and leader board to the second activity. Discuss.|
|(SubTask)||Create a UI for the Leader board.|
|Week 2||Design and implementation of API. How should they Calculate and displaying ranks about users(all-time, monthly, weekly).|
|(SubTask)||implement the code API.|
|Week 3||In this period, I’ll design and implementation of API based on 2nd option(i.e uploads, nearby)and use the APIs|
|(SubTask)||Fetch the results from the API using Retrofit|
|Week 4||Designing and implementing the APIs for displaying leaderboard (user list) based on 2 parameters - duration (all-time, monthly, weekly), type (uploads, nearby, images used).|
|(SubTask)||Discuss and Design the API and Code the API in Python and Test it.|
|Week 5||Start write Unit Test for API.|
|(SubTask)||Fix bugs if any|
|Week 6||Complete Unit Tests for APIs fetch|
|(SubTask)||Complete Unit Tests for APIs for displaying leaderboard.|
|Week 7||Add pagination in the leaderboard screen to load more data.|
|(SubTask)||Fetch the results from the API using Retrofit and adjust the UI to display the results|
|Week 8||Complete Tests for Pagination and Auto-Scroll|
|(SubTask)||Write Tests for Pagination|
|(SubTask)||Write Tests for Auto-Scroll Feature|
|Week 9||Add duration filters in the leaderboard screen and show results based on the selected filter (weekly, monthly, yearly, all-time). Change the UI to show and select filters.|
|(SubTask)||Implement Filter Classes|
|(SubTask)||Update the UI to use filters and improve UX|
|Week 10||Change the UI to show 3 different results (based on uploads, nearby, used). - add 2 more tabs|
|(SubTask)||Update the UI to enclose three different kinds of leaderboards|
|(SubTask)||Improve the UX|
|(SubTask)||Write Unit Tests for duration filters and this Feature|
|Week 11 && Weak 12||Unit testing and finding the bugs and solving the issue.|
|(SubTask)||Write Unit tests and finishing/fixing bugs for existing so far.|
|Week 13- Final||Over all Evaluation|
|(SubTask)||Any Remaining Bug Fixes or Tests and Suggestions|
Previous Contribution And Issues
I am still exploring the commons-app now. So far I have made #3522 and #3418 Pull Requests to the project and they both already merged. Also, I opened two issues i.e #3531 and #3520 out of which one is closed and one is open.I’m currently working on the one assigned issue #3547.
How do you envision your involvement with Commons after the GSoC?
I will continue my journey in Wikimedia as contributing and also I'll keep on seeing the work done by me and fixing issues if they emerge in the future.
What is your ideal approach to keeping everybody informed of your progress, problems, and questions throughout the project?
In order to keep the Wikimedia community update with my progress, I would maintain a blog. I would update the blog at the start of every week on Monday with my accomplishments for the previous week and targets for the next week. I found this approach quite useful for my GSoC2020 project.
I have my own ideas that I plan to implement as extensions to this registry, thus contributing long term.
I have specifically listed down each week’s deliverables by being as specific as possible. I would aim at sticking to each week’s goals.
Is there any special reason why we should pick you?
I have a special connection with the project. This would probably ensure a higher level of commitment. Besides that I have my own ideas that I plan to implement as extensions to this registry, thus contributing long term.
I’ve already been participating in the Wikimedia community for a while, mainly with small Commons features. Compared to the other online communities I’ve participated in, Wiki is the most welcoming, and I enjoy being a part of it. Till now I haven’t had a chance to do anything major here, and I feel that GSoC is a great way for me to do a major project. I feel that I can have a better impact by implementing core features in a budding better media application over enhancing an existing application.
- I have no commitment during summer which means I'm free to work completely on my project.
- I am very enthusiastic about my work being beneficial to other people in the open-source community. I'll be more productive these days. I'll keep on seeing the work done by me and fixing issues if they emerge in the future.