Page MenuHomePhabricator

GSoC: Pywikibot-Thanks | Meeting 6 | 15th June
Closed, ResolvedPublic


| Wednesday, 15th June 2016 - 15:00 UTC
| jayvdb, darthbhyrava

Description: A brief meeting mid-week to review last week's work and talk about plan for T135411.


  • Review code and get it patch ready.
    • Code for - P3242
    • Code in - P3243
    • Code for - P3248
    • User.thanks_enabled property - P3249
  • Flow-related thanks code?
    • Decide approach and where to place Flow-related thanks code.
    • Construct plan with objectives re:Flow for next meeting on Friday.

Minutes of the Meeting


  • The script must check for User.thanks_enabled == true before thanking the revision.
  • Use recentchanges() to get the user to be checked.
  • It's a design mess. It looks pretty, but is poor from a design perspective. Lots of changes required, but they are not a priority since it is a very effective mess for now.

The issue with the current version of, P3248, is that a user can't think himself/herself. In order to be reproducible, we need to ensure that the unit_tests need to be rerun regularly. But if we can't thank ourselves, then things get a bit difficult.

  • Approach One: Can the same revision be thanked twice? If yes, then we can hardcode the revision we will be thanking, and then check log. Tried using the script to thank twice, but it got logged only once. Approach discarded.
  • Approach Two: Is it possible to login with a different user in the middle of a script? It is possible, but it is not easy to do so in a test suite, and it is not something expected to work regularly. Discarded.
  • The Chosen Approach: Take a revision from Special:RecentChanges using the recentchanges() method in Make sure the parameters are correctly set while extracting this single revision, and then thank it, and check for an entry in Special:Log/thanks. So before the test, we should make an edit on test:test, and then run the test, which should pick up this new edit. This is not exactly reproducible, since if no one makes any edits between the reruns, then it will end up thanking the same edit again without the log entry. We are comfortable with this since
    • The tests are not run very regularly for test:test,
    • There are a lot of edits being made on test:test,
    • These tests are of an auxiliary nature.
  • Add in a note, however, emphasizing on the fact that this test relies on activity in recentchanges, and that we must make edits before running these changes.
Re: User.thanks_enabled property
  • Add in a docstring to indicate that this does not determine if thanks is enabled for the logged in user.
  • Also add in the bug number and task number on Phab related to the above issue.
  • In the highly unlikely case there is no request for the above, then make one.
  • Also add to the docstring how the functionality for the same doesn't exist yet.
  • This is just icing on the cake.
Mid Term Evaluation Discussion
  • @darthbhyrava officially has till 27th June to finish the MVP.
  • @jayvdb's guess is that Google have an earlier cutoff date for filing 'incomplete' evaluations. Exact date needs to be checked, but the MVP probably needs to be finished earlier than the 27th.
  • Let's take a safe deadline to be the 20th of June, though there probably will be some time after that to finish things off.
  • By the 20th, thanks for both normal revisions and flow comments, as well as unit tests for both, ought to be ready.
  • If the above works by then, then @jayvdb will be writing an approval on the expectation that the rest of the code gets working after that.
  • Put the thank code and its unittests in a patch on Gerrit. This is an MVP requirement.
  • By the meeting on Friday, the code for subtask 1 must not be -1 or +1, but a solid +2 by jenkins. Else the evaluation will be failed.
  • The patch might fail the first time, the second time. Don't panic and start fixing things one by one, try fixing them all at once, and try to get jenkins happy by the third patch.
  • If the patch is not submitted or getting a +2 from jenkins, @Legoktm won't be pleased, either, and will probably get a failed evaluation from him, too.
Thanking Flow Comments
  • "Where should the code go?" is @darthbhyrava's responsibility.
  • By Friday's meet, hack a working script for flow based thanking.
  • Start afresh, it will be easier, and not much of the earlier code will be useful anyway.
  • By the next meet, if the prototype for thanking comments is ready, there will be time to write tests for the same.
jayvdb's availability notice
  • Effectively offline after the Friday meeting.
  • Will provide as much assistance as possible till Saturday evening, however.
  • After that, @darthbhyrava is on his own till the new deadline of 20th, and till the 25th.
  • Use the community and other resources in that duration.

Before Next Meet

  • Fix adding the User.thanks_enabled property: P3258 ; P3243
  • Fix User.thanks_enabled by adding in the docstring: P3249
  • Fix thanks_tests with the new approach and get it to work. P3263
  • Submit patch for T135413 on Gerrit
    • Get a +2 on it from jenkins
  • Get a working prototype for Flow based thanks.
    • scripts/ P3256
    • thank_flowpost() method in P3257