| Friday, 20th May 2016 - 15:00 UTC
| jayvdb, darthbhyrava
Description: Second meeting. Discussed progress so far, chalked out a plan going ahead, cleared many doubts.
Minutes of the Meeting
Decided that once the proposal is modified in accordance with the changes suggested in the comments of the proposal task itself, it can be considered as the detailed plan. The changes required are:
- Account for the fact that the revisions and pages associated with a thank action are not public
- Account for the fact that thanks logging may be turned off. Add a requirement that the code needs to determine this first.
- Update MVP details as mentioned in T130585#2299692
- Edit Subtask 3 stating that it cannot be revision based.
- Edit Subtasks 1 and 4 with respect to User.thanks_enabled property.
Structure of the Code
- There will be a thanks.py and thanks_tests.py in pywikibot for most of the code. This will be the external API. For both, functionality is the primary concern. There is flexibility in terms of design of code. Style based aspects will not be assessed critically.
- Code will also be added to site.py. This is the lower level interface which interacts with the API. Code review will be more particular here. It has to be carefully designed and optimised in accordance with established norms, and this will be tricky and hard. More details once we get there.
- Project is similar to happy5214's code last year for the Pywikibot-Flow project. With respect to that:
- Alex had made changes to flow.py, flow_edit_tests.py, flow_tests.py and also site.py and page.py last year. flow.py was the external API of pywikibot, and along with page.py, exposed functionality .
- Look at the things Alex has put into site.py and other places - old changesets merged in Gerrit. This'll help with understanding the development process. Discussions between alex, jayvdb, xsize on these patchsets will be very illuminating and instructive. Spend one day per week for the first 4-5 weeks studying the Gerrit Code-changes in order to understand how development happens and to look at previous decisions. Learn from Alex's mistakes.
- Another interesting issue to tackle is placement of the code related to both thanks and flow - as it crosses the module divide. To be discussed in Week 2 of the coding process. First let's get thanks.py working, then we'll see.
Documentation for Extension:Thanks
Discussed places where I can find out more about the Thanks extension.
- The Thanks API documentation here.
- Mediawiki page for Extension:Thanks.
- Discussion Page for the extension here.
- Feature Requirement here.
- More details on the overview page.
- Code is the best manual - see the code here.
- Feedback on the Wikipedia Talk page.
Regarding Subtask 1 - T135409: Implement pywikibot support for adding thanks to normal revisions
- Determining which revision the thanks action is applicable for - a revision object will be passed to my method, and then I have to extract necessary details from it, checking if I've received an integer (revId) or an object.
- The workflow: Most activities happen via a page object. Method on page object which will call thanks module with all my thanks code which calls the site object which calls api object.I won't be calling api.php? directly. All calls must go through the site layer, and site calls must go through api layer which then is lower level again.
- First few days - I must design the methods, and account for the large scope of bugs.
- Being inactive due to ill- health and missing a week without informing mentors like earlier is undesirable. Any further absences from work must be notified in prior. There is flexibility afforded in terms of work distribution across weeks, but communication is of essence.
- None of the other three patches are merged. You should have had the python patch fixed.
- Patch 288871 is throwing up an assertion error. I need to correct it asap, have a successful travis build and submit on gerrit. Top priority.
- Patch 283749 is having an unexpected JS error (identified) due to my previous patch. Would appreciate feedback at T111735 for the same. In the event I get none, I have to figure it out myself.
- Patch 282616 needs time to address as it involves a lot of follow-up. Not top priority,
- Some practical advice from jayvdb: Unless one has a precise question, and unless there's a definite area of the code for the bug, feedback might not be easily forthcoming. Instant replies solving doubts asked should not be expected - the programmers competent enough to do that are paid to solve thousands of more important bugs, and to write code. Although they do spend time assisting new contributors by showing them the ropes, it is expected that someone who wants to fix the bug will keep at it until it gets solved. One must capitalize on the time such experts do spend giving feedback.
Mentor Meet Schedule
- Weekly meetings, alternating Skype and IRC, i.e. with IRC next week.
- Need to decide upon next meeting's timeslot and agenda.
- Submit new patchset for the python-based bug.
- Modify proposal and add the changes suggested.
- Modify the MVP as required.
- Continue reading documentation on Thanks.
- jayvdb will provide me a with an example script which will help me with the API workflow. Study it.
- Shortlist three timeslots for next meeting, and finalize upon one.
- Look at Alex's patchsets, and ensuing discussions and decisions.