Project
Pywikibot support for Thanks
Synopsis
The Python MediaWiki Robot Framework (Pywikibot) is a collection of tools made to help users write and run "bots", which help maintain and contribute to Wikipedia by automating common and tedious tasks. More than 20% of edits are recorded to have been made by bots. One important feature of pywikibot is to provide support for MediaWiki extensions. But pywikibot is not implemented for all extensions, Thanks being one such example. The Thanks extension allows users to thanks other users for their individual edits by providing a 'thank' link in history and diff views, and under Flow comments if Flow is installed. It makes use of the Echo extension and provides an API for sending thanks.
This project aims to implement pywikibot support for the Thanks extension. This can be done by dividing the task of implementing its API into a set of smaller deliverables, the details of which follow.
Possible Mentors
Primary Mentor: @jayvdb (John Vandenberg)
Co-Mentor: @Legoktm (Kunal Mehta)
Project Details
Following are the list of subtasks I propose to do in order to achieve my goal of implementing Pywikibot support for Thanks.
- Adding thanks to normal revisions.
- → history → revisions → thank_link →
- Under the History tab of every page, there is a list of revisions of the page containing details of the timestamp when the edit was made and the user who made the edits. Next to each revision (if the revision is not by the current logged in user), there is a 'thank' link. Clicking on this link will send an notification to the corresponding user using the Echo extension, unless the user has opted out of receiving thanks notifications. (Anons can't currently receive thanks, so a simple version of User.thanks_enabled property, as mentioned in Subtask 4, is needed here) .The Thanks API is called using action=thank, with parameters rev, source and token. This concept of thanking revisions, as seen in the class ApiRevThank (which extends ApiThank) in Thanks needs to be implemented in Pywikibot, and then tested using the test suite.
- Adding thanks to comments on StructuredDiscussions boards.
- → flow_boards → thank_link →
- Flow extension provides a discussion and collaboration system for talk pages. When the Flow extension is installed and Flow is enabled on a page, the page becomes a Flow board, i.e, the content model property changes to 'flow-board'. If Flow is installed along with its dependencies, the thank link for the corresponding user is available under comments on the Flow boards, clicking which will have the same effect of sending the user Echo Notifications. The corresponding class which needs to be implemented in pywikibot, along with proper testing, is ApiFlowThank (which extends ApiThank). This API is different from ApiRevThank, as it is called by action=flowthank, with parameters postid and token.
- Getting lists of thanks.
- Each time a user is thanked, a record of the action is added as a log entry at Special:Log/thanks (if Thanks logging is enabled) and also as a part of the Echo notification. Furthermore, classes like Revision contain the metadata details of a revision. However, the Revision and the Page associated with the thank action are considered private information. (Hence this task can't be Revision or Page based.) Only the timestamp, sender and receiver are treated as public information. Pywikibot must implement a class which supports this concept of getting lists of thanks, including access to all related metadata as objects, using such existing classes, the method logThanks and ThanksLogFormatter. Needless to say, the implementation then needs to be tested using the test suite. Also, refer to T51087.
- Adding a thanks_enabled User property.
- Users can disable thanks notifications if they want to. In this case, when the thanks link against their revision is clicked, a "thanked'' message appears instead of the link, but no notification is sent ( T57401 deals with privacy of thanks preferences.) A thanks_enabled property needs to be added for the same to the User class. This preference for the user can be stored in the Thank log, too. Also specific verification that it does the right thing for anon users: (see T63022) is required.
- Creating a table for 'thanked' statistics.
- This link has tables showing top thankers for two wikis with number of thanks. We must add a script to Pywikibot which can create similar tables (both for thankers and the thanked?) showing statistics for top x (where x can be taken as a parameter) users with corresponding number of thanks, for any wiki wiki and for any month month (also other time intervals like a week or a year?). This implementation would require a class of its own, where the script needs to interact with the Thank log and the wiki database, with each metadata element as separate columns for the table. Queries corresponding to the requirements of the table should retrieve data from the database and then return the output in a tabular format. A good place to start would be logThanks. During the implementation, the script needs to be tested regularly.
- Allowing thanks for log entry.
- This functionality is slightly removed from the project description, as it involves adding a feature to the Thanks extension first, and then implementing Pywikibot support for it. As mentioned in T60485, when a page gets created or deleted or protected, someone else may want to thank the User. This is currently not possible in Thanks, and I would like to work on it. This would require adding a new method getLogFromParams or, if necessary, a new class ApiLogThank, testing it, implementing the method or class in Pywikibot, and then testing the latter.
Deliverables
- At the end of this project, I aim to add pywikibot/thanks.py, tests/thanks_tests.py, make relevant modifications in site.py and other related scripts in pywikibot (like flow.py ) which will implement the features and API calls as mentioned in the detailed project description for subtasks 1, 2, 3.
- For subtask 4, I will add a property thanks_enabled to the User class, while for subtask 5, I will write a script implementing the functionalities of a thanks_stats bot.
- For subtask 6, I would have to add the feature to the MediaWiki Thanks extension first, and then implement it in pywikibot.
- Classes and methods corresponding to ApiThank, ApiRevThank, ApiFlowThank, along with subtasks 4 and 5 in entirety will be the minimum expected output over the entirety of the program.
- MVP for the mid-term evaluation:
- The MVP would be subtasks 1 and 2 implemented, reviewed and wrapped up.
- The code for subtasks 1 and 2 must all be merged to pass the mid-term evaluation.
- If the code is not completely merged, then the code may still be considered if all of it has been submitted in Gerrit with a +2 from jenkins-bot.
- There must be a branch on my GitHub fork which has all the aforementioned patches integrated and all the tests passing.
- Apart from the technical deliverables, I would also be having weekly reports for progress along with a weekly blog post, and regularly update the documentation as required.
Extra Deliverables
If the deliverables, as mentioned above are completed earlier than the stipulated time, then I would like to work on two extra deliverables, in a priority order which can be decided by the mentors at that time. The first one would be to pursue T71636: Thanks: Implement an undo feature. I'll take up from the patch abandoned by @EBernhardson (due to Echo refactor reasons), and try and implement the time-out key to delay events as suggested in the patch. The second would be to use my experience from this project and start work on T85656: Pywikibot to detect and correctly handle edits that trigger abusefilter rules. Or I could work on JS based bugfixes in MediaWiki as suggested by @jayvdb.
Testing
At each stage of the project, while the patches are being submitted, design and code will be continually be tested, with tests being added to thanks_tests.py . Suitable test objects and inputs (and unittests) will be used for each module and tested in layers - first on my local machine ( in accordance with the instructions in tests/README, with flake and nose tests being executed multiple time ) and second by the mentor and other concerned reviewers.
Post Google Summer of Code
I am a second year undergraduate in a dual degree course, and hence have at least three more years till I finish college. Given the lack of immediate pressure to join a full-time job, and the abundance of time over the next two years at least, I would like to follow up on my project work even after the Google Summer of Code program is over. I will be available for maintenance and bug fixes (if any) in my work even after GSoC, and would very much like to use this experience to work on other extensions which need Pywikibot support as mentioned in T89067, starting with AbuseFilter.
Timeline
An overview:
Phase | Dates | Schedule |
Community Bonding | April 22 - May 22 | Getting to know the community. Making a plan. |
Week 1 | May 23 - May 29 | Subtask 1 : Talking to mentors, designing code, testing, first patch. |
Week 2 | May 30 - June 5 | Subtask 1 : Revising and improving code, community review, getting code merged. |
Week 3 | June 6 - June 12 | Subtask 2 : Talking to mentors, designing code, testing, first patch. |
Week 4 | June 13 - June 19 | Subtask 2: Revising and improving code, community review, getting code merged. |
Week 5 - Midterm Evaluation | June 20 - June 26 | Wrapping up Subtasks 1 and 2, Bug Fixes, Documentation |
Week 6 | June 27 - July 3 | Subtask 3 : Talking to mentors, designing code, testing, first patch. |
Week 7 | July 4 - July 10 | Subtask 3 : Revising and improving code, community review, getting code merged. |
Week 8 | July 11 - July 17 | Subtask 4 : Discussing design, implementing code, testing, community review, getting code merged. |
Week 9 | July 18 - July 24 | Subtask 5 : Designing the script, coding it, testing, getting review, getting code merged. |
Week 10 | July 25 - July 31 | Subtask 6 : Designing the feature, implementing it in Thanks, testing, community review, getting code merged. |
Week 11 | Aug 1 - Aug 7 | Subtask 6 : Implementing the feature in pywikibot, testing, review, getting code merged. |
Week 12 | Aug 8 - Aug 14 | Wrapping up subtasks 3-6. Bug fixes, documentation. |
Week 13 | Aug 15 - Aug 23 | Wrapping up all subtasks. Complete documentation, final reports and bug fixes, and announcement on wikitech-I. |
In detail:
Week 0 (Community Bonding) | April 22 - May 22
- Find out the resolved tasks and patches under Thanks and understand the code.
- Look at resolved tasks like T67119: Implement Flow support in Pywikibot which can help me in current project
- Read the docs and manuals for Thanks
- Create a finer and more detailed plan for executing the current project, with subtasks for each deliverable.
- Decide structure for the project's source code
Weeks 1, 2 | May 23 - June 5
- Discuss with mentor and design implementation of the new scripts and their contents.
- Create the new scripts in pywikibot, and add basic classes and methods required.
- Revise according to community review, add more methods, review, test and get code merged.
- Fix bugs, document and update reports.
Weeks 3, 4 | June 6 - June 19
- Discuss and design the structure of code with mentor. Understand scripts to be modified.
- Implement code for API, test for test Flow objects, get beta review and revise.
- Merge code, announce feature, fix bugs, edit documentation.
Week 5 - Midterm Evaluation | June 20 - June 26
- Unit testing and integration testing of the code in thanks.py, thanks_tests.py and other scripts.
- Fix minor issues and bugs in the code, get community review on the same and revise.
- Finish reports, documentation and code-cleanup.
- Achieve the MVP of the project.
Weeks 6, 7 | June 27 - July 10
- Deciding on the parameters required in the list.
- Discussing and designing the structure of the methods to get these params.
- Implementing the code, reviewing it, revising it and then merging it.
- Documentation, reports. bug fixes.
Week 8 | July 11 - July 17
- Discussing the User class with mentors, designing the feature.
- Understanding applications and modifying and reviewing design.
- Adding the thanks_enabled property, testing and revising code.
- Merging the code, and getting community review.
- Delineating further tasks based on this feature
Week 9 | July 18 - July 24
- Discussing and designing parameters and permissions required by the script.
- Understanding design of a wiki database which stores values of metadata. Testing interactions with the database.
- Creating queries and methods which will gather data and return output in tabular form. Testing them.
- Submitting code, getting review, revising it, then merging it.
- Documenting the feature, and then making it accessible.
Weeks 10, 11 | July 25 - Aug 7
- Adding thankLogEntry feature to the Thanks extension.
- Testing, reviewing and getting the code merged in mediawiki-core.
- Adding corresponding script in pywikibot.
- Testing, reviewing, documenting and merging the pywikibot-core code.
Weeks 12, 13 | Aug 8 - Aug 14
- Unit testing and integration testing for the entire codebase.
- Pencil down stage. Finish documentation.
- Code cleanup, bug fixes and comments for later revisions.
- Create daily reports and blog post about the project.
- Submit Code to Google.
- Announce functionality on wikitech-l.
Profile
| Sriharsh Bhyravajjula
| CS Undergraduate (Second Year)
| IIIT Hyderabad, India
| Resume
| hbhyrava@gmail.com
| freenode nick: darthbhyrava
| darthbhyrava
| MediaWiki User Page
| Hyderabad, India (UTC+5:30)
| 7-10 hours per day (at least 45 hours a week) : 5am-10am & 9pm-1am (localtime)
Communication
I will be active during my working hours via IRC on #pywikibot and I'll be subscribed to relevant Phabricator tasks and participating in discussions on all these tasks round the clock. I'll also be active in relevant Conpherence rooms. I'll create weekly reports of progress on Phabricator, as well as write weekly blog entries on the same. I would also be comfortable with discussions on the pywikibot mailing list or respond to personal mail round the clock. My source code will pushed to Gerrit, and can be reviewed there.
Contributions
Microtasks: T129193 T89670 ( T111735 )
Authored: T130189 T129017
Other tasks: T129834 T115810 T93098 T117176 ( T51541 T115428 )
Note: The ongoing () tasks will be all wrapped up by the 31st of March.
Edit on 31st March: Ongoing tasks are still in progress, unfortunately, due to issues in the requirements. Please check back in a couple of days.
Edit on 11th April : Please check the individual ongoing tasks for progress- all of them have patches in review.
I have been contributing to MediaWiki since late February, and have been active ever since, adding over 180 lines of code. I have set up a local wiki on my server, and have a working environment for pywikibot-core. You can have a look at my merged patches here and here. I've also finished two microtasks, and am working on more. This is my first experience with Open Source, but I like it so far and would like to contribute to more FOSS orgs in the future. :)
About Me
- Education : I am currently in my second year of undergraduate study at IIIT Hyderabad, pursuing a dual degree course which will award me with a B.Tech in Computer Science, and an MS in Computational Linguistics, with the expected year of graduation being 2019. My projects and my skills - they have been elaborated upon here.
- Why WMF? I grew up using Wikipedia as my source for content for all my high school projects and essays. And later on, I did the same for secondary school and junior college, too. And today, in my sophomore year of undergraduate study, when the need for reliable, extensive knowledge on my topics of study is more pressing than ever, Wikipedia still remains as resourceful as it ever was. So naturally, when I decided to start contributing to FOSS, MediaWiki was my first choice. Also since I have three more years before I graduate, I hope to find some means of using my Computational Lingusitics domain knowledge to improve the multilingual functionalities of projects under the WMF umbrella later on. Why the Thanks extension? Well, working on improving a system which thanks contributors for their efforts seems like a very good way to give back. If I could, in some way, improve the contribution experience for the editors, people like me who view their content would have a better experience, too.
- Other Details :
- I have no other commitments during the duration of this program.
- I am eligible only for the Google Summer of Code program.