Page MenuHomePhabricator

Pywikibot Support for Thanks (GSoC Proposal)
Closed, DeclinedPublic

Description

Project


Pywikibot support for Thanks
  • darthbhyrava (Sriharsh Bhyravajjula)
  • Corresponding Phab Task: T129049
  • Also look at T89067

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.

  1. Adding thanks to normal revisions.
    • wiki_pagehistoryrevisionsthank_linknotification
    • 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.
  2. Adding thanks to comments on StructuredDiscussions boards.
    • wiki_pageflow_boardsthank_linknotification
    • 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:

PhaseDatesSchedule
Community BondingApril 22 - May 22Getting to know the community. Making a plan.
Week 1May 23 - May 29Subtask 1 : Talking to mentors, designing code, testing, first patch.
Week 2May 30 - June 5Subtask 1 : Revising and improving code, community review, getting code merged.
Week 3June 6 - June 12Subtask 2 : Talking to mentors, designing code, testing, first patch.
Week 4June 13 - June 19Subtask 2: Revising and improving code, community review, getting code merged.
Week 5 - Midterm EvaluationJune 20 - June 26Wrapping up Subtasks 1 and 2, Bug Fixes, Documentation
Week 6June 27 - July 3Subtask 3 : Talking to mentors, designing code, testing, first patch.
Week 7July 4 - July 10Subtask 3 : Revising and improving code, community review, getting code merged.
Week 8July 11 - July 17Subtask 4 : Discussing design, implementing code, testing, community review, getting code merged.
Week 9July 18 - July 24Subtask 5 : Designing the script, coding it, testing, getting review, getting code merged.
Week 10July 25 - July 31Subtask 6 : Designing the feature, implementing it in Thanks, testing, community review, getting code merged.
Week 11Aug 1 - Aug 7Subtask 6 : Implementing the feature in pywikibot, testing, review, getting code merged.
Week 12Aug 8 - Aug 14Wrapping up subtasks 3-6. Bug fixes, documentation.
Week 13Aug 15 - Aug 23Wrapping 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.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
IMPORTANT: The deadline for submitting your proposal to Google Summer of Code 2016 application system at GSoC application system falls in roughly 24 hours at Mar 25 2016, 19:00 UTC. Please make sure that you have a pdf copy of your proposal in the application system beforehand, to avoid last minute confusions. Remember to relate your Phabricator task and associate 2 mentors in the proposal description, so that it gets easy for review. Past the deadline, you should only make changes limited to fixing typos, or incorporating feedback's. Good Luck, and check out the micro-tasks!

@Niharika @Sumit @01tonythomas - could you please let me know if I am flouting or missing any procedures or conventions?

Also, any feedback at this stage would be greatly appreciated. :D
Thank you!

Hi @darthbhyrava, I looked over your proposal and it looks good. Please note that it's a hard requirement for the MVP to be complete by the mid-term, so make sure to account for that in your timeline. Also, discuss with your prospective mentors on where this MVP will live (Labs instance is the most obvious choice) and mention that in your proposal.
Further reading: https://wikitech.wikimedia.org/wiki/Help:FAQ
Good luck!

Hi @darthbhyrava, I looked over your proposal and it looks good. Please note that it's a hard requirement for the MVP to be complete by the mid-term, so make sure to account for that in your timeline. Also, discuss with your prospective mentors on where this MVP will live (Labs instance is the most obvious choice) and mention that in your proposal.
Further reading: https://wikitech.wikimedia.org/wiki/Help:FAQ
Good luck!

Thanks for the feedback (and the mention in the other task), @Niharika! :D

Well, I assumed the MVP to be for the entire program, not just till mid-term. But if that is the case - I'll have to modify my current MVP to include just subtasks 1 and 2, since that is what I have planned till mid-term.

@jayvdb @Legoktm - please note that I have changed my MVP (to be assessed at mid-term) in the task description to include only subtasks 1 and 2 in the wake of Niharika's post.

Thank you!

As mentioned in @Mattflaschen's comment here in T129049: Pywikibot support for Thanks , I'd like to add in the courtesy opt-out feature as a deliverable for subtask 5 ( #5 in the Project Details ). Refer to Faebot/thanks for more.

<Adding the deliverable in the comments, since the deadline for the proposal is long gone, and I am not allowed to make a major change to the proposal now.>

Congratulations @darthbhyrava for getting selected for this project in GSoC 2016! Wish you a good luck with it. You can start discussing ideas and get to speed with the project as the Community Bonding period has started.

Thanks @Sumit!

I am looking forward to being a part of the Wikimedia Community! :D

Welcome to Google-Summer-of-Code (2016) and to the Community Bonding period! Happy to have you here, and this should be crucial time to create important decisions regarding how your project should take shape during this two month internship period. You can find information about Community bonding period, from our Life of successful doc here. To make sure everything go as per planned, please follow the instructions in T133647 and create the 'Community Bonding Evaluation for $project' task as a subtask of your proposal task. Please note that all further tasks you create for evaluation and GSoC organization purpose should be subtasks of your proposal, and not the parent task - lets reduce the notification count. In case you are stuck, feel free to comment below T133647 or open up a conpherence task with the mentors and org admins. You can find example tasks in the task description of T133647

Each time a user is thanked, a record of the action is added as a log entry at Special:Log/thanks. Furthermore, classes like Revision contain the metadata details of a revision.

Note that it is not public which edit you are thanked for.

The only thing that is public is "A thanked B on YYYY-MM-DD HH:MM". Thanks logging can also be turned off. It is on in WMF production.

For when you have some spare time (i.e. after 16th)...

If you want to use the Thanks functionality in production, to get a feel for how it works, here are some lovely media that deserves lots of thanks.

https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2015

The thanks will be logged here: https://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=thanks&user=darthbhyrava

Unfortunately you are not eligible to vote (https://tools.wmflabs.org/meta/accounteligibility/39/darthbhyrava), but you can still log thanks to show your appreciate for the best few ;-)

For when you have some spare time (i.e. after 16th)...

If you want to use the Thanks functionality in production, to get a feel for how it works, here are some lovely media that deserves lots of thanks.

https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2015

The thanks will be logged here: https://commons.wikimedia.org/w/index.php?title=Special%3ALog&type=thanks&user=darthbhyrava

Unfortunately you are not eligible to vote (https://tools.wmflabs.org/meta/accounteligibility/39/darthbhyrava), but you can still log thanks to show your appreciate for the best few ;-)

Thanks for the info!
The contenders are indeed beautiful. (I actually have a copy of Vincent Van Gogh's Starry Night on my wall :D )

It's unfortunate that I don't have 75 Wikipedia edits before Jan 1st. But I'll use the thank feature for quite a lot of them nonetheless. :)

In T130585#2268954, @Mattflaschen wrote:

Each time a user is thanked, a record of the action is added as a log entry at Special:Log/thanks. Furthermore, classes like Revision contain the metadata details of a revision.

Note that it is not public which edit you are thanked for.

The only thing that is public is "A thanked B on YYYY-MM-DD HH:MM". Thanks logging can also be turned off. It is on in WMF production.

Thanks @Mattflaschen.

As the thanks is not linked to a revision, the task "Getting lists of thanks." needs to be slightly redesigned and re-written.

Also, the code needs to accurately determine whether thanks logging is enabled or disabled.

Finally, I vaguely recall that the Thanks log did link to a Revision. Is that correct? (@darthbhyrava, you can answer this by looking through the git log of the Thanks code base) If so, when was it removed? And a link to the task removing it would be helpful.

For the Mid-term evaluation...

Have the MVP of the project ready on a Labs instance, as well as on my GitHub.

Pywikibot projects do not need a MVP of the project ready on a Labs instance, as it is not web-deployed. Please revise the plan.

However, the code must *all* be merged to pass the mid-term evaluation.

If you have failed to get your code merged, we will still do a mid-term evaluation if you have submitted *all* of your code in Gerrit with +2 from jenkins-bot, and you need to have a branch in your Github fork which has *all* pending patches integrated, and all of your tests passing. Failure to do that would be immediate failure of the mid-term evaluation.

@jayvdb, @darthbhyrava: Thanks are linked to revisions. The revision associated with a thank action is stored both in the logging table (if Thanks logging is enabled) and as part of the Echo notification. The revision (and page) associated with a thanks action is not public, however. It is basically treated as private information, but that's the only data associated with a thank action that is considered private. The timestamp, sender, and receiver are treated as public information.

@kaldari , right, Subtask 1 & 2 (thanking) are Revision based - but Subtask 3 (thanks log) can't be Revision (or Page) based.

To answer my own question, based on T51087 which provides lots of rationale/background, it appears that the thank log never included the revision/page.

The test plan for the User.thanks_enabled property, sending thanks needs specific verification that it does the right thing for anon users: T63022: Add ability to thank anonymous/IP users.
Given that anons cant currently receive thanks, I think a simple version of User.thanks_enabled property is needed for Subtask 1.

In T130585#2268954, @Mattflaschen wrote:

Each time a user is thanked, a record of the action is added as a log entry at Special:Log/thanks. Furthermore, classes like Revision contain the metadata details of a revision.

Note that it is not public which edit you are thanked for.

The only thing that is public is "A thanked B on YYYY-MM-DD HH:MM". Thanks logging can also be turned off. It is on in WMF production.

@jayvdb, @darthbhyrava: Thanks are linked to revisions. The revision associated with a thank action is stored both in the logging table (if Thanks logging is enabled) and as part of the Echo notification. The revision (and page) associated with a thanks action is not public, however. It is basically treated as private information, but that's the only data associated with a thank action that is considered private. The timestamp, sender, and receiver are treated as public information.

Thanks for the info - @Mattflaschen @kaldari!
I have included the details in my tasks and proposal.

Also, the code needs to accurately determine whether thanks logging is enabled or disabled.

I've included this in the subtask description now.

@kaldari , right, Subtask 1 & 2 (thanking) are Revision based - but Subtask 3 (thanks log) can't be Revision (or Page) based.

Noted, I've mentioned this in Subtask 3, too.

To answer my own question, based on T51087 which provides lots of rationale/background, it appears that the thank log never included the revision/page.

Thanks for mentioned that here, helps me understand the reasoning behind the decision. I should have found it myself earlier, though. :/

The test plan for the User.thanks_enabled property, sending thanks needs specific verification that it does the right thing for anon users: T63022: Add ability to thank anonymous/IP users.
Given that anons cant currently receive thanks, I think a simple version of User.thanks_enabled property is needed for Subtask 1.

Thanks for this @jayvdb - I have made the necessary changes in Subtasks 1 and 4.
I have also made changes to the MVP as stated.

@darthbhyrava, I see that the subtasks (e.g. T135409) havent been updated so they are consistent with the changes that you have made to this task. Could you fix that please.

@darthbhyrava, I see that the subtasks (e.g. T135409) havent been updated so they are consistent with the changes that you have made to this task. Could you fix that please.

Ah, didn't notice. Fixed. :)

End of project timeline. Closing it down. Thank you for all the efforts.

Outcome of this 2016 round projects at https://www.mediawiki.org/wiki/Google_Summer_of_Code_past_projects#2016