Change Details

{icon calendar} | Friday, 20th May 2016 - 15:00 UTC {icon user} | jayvdb, darthbhyrava **Skype Call** **Description**: Second meeting. Discussed progress so far, chalked out a plan going ahead, cleared many doubts. *** === Minutes of the Meeting . ===== Detailed Plan 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 [[ https://www.mediawiki.org/wiki/Extension:Thanks#API_Documentation | here ]]. - Mediawiki [[ https://www.mediawiki.org/wiki/Extension:Thanks | page ]] for Extension:Thanks. - Discussion Page for the extension [[ https://www.mediawiki.org/wiki/Extension_talk:Thanks | here ]]. - Feature Requirement [[ https://www.mediawiki.org/wiki/Notifications/Feature_requirements#Thank_you_notification | here ]]. - More details on the [[ https://www.mediawiki.org/wiki/Extension:Thanks | overview ]] page. - Code is the best manual - see the code [[ https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FThanks | here. ]] - Feedback on the Wikipedia Talk [[ https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks | page ]]. ===== Regarding Subtask 1 - {T135409} - 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. ===== Other feedback - 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 [[ https://gerrit.wikimedia.org/r/#/c/288871/ | 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 [[ https://gerrit.wikimedia.org/r/#/c/283749/ | 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 [[ https://gerrit.wikimedia.org/r/#/c/282616/ | 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 - Biweekly Meetings on Skype - Biweekly Meetings on IRC - Need to decide upon next meeting's timeslot and agenda. *** === Follow Up - [ ] Submit new patchset for the python-based bug. - [x] Modify proposal and add the changes suggested. - [x] Modify the MVP as required. - [x] 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.

{icon calendar} | Friday, 20th May 2016 - 15:00 UTC {icon user} | jayvdb, darthbhyrava **Skype Call** **Description**: Second meeting. Discussed progress so far, chalked out a plan going ahead, cleared many doubts. *** === Minutes of the Meeting . ===== Detailed Plan 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 [[ https://www.mediawiki.org/wiki/Extension:Thanks#API_Documentation | here ]]. - Mediawiki [[ https://www.mediawiki.org/wiki/Extension:Thanks | page ]] for Extension:Thanks. - Discussion Page for the extension [[ https://www.mediawiki.org/wiki/Extension_talk:Thanks | here ]]. - Feature Requirement [[ https://www.mediawiki.org/wiki/Notifications/Feature_requirements#Thank_you_notification | here ]]. - More details on the [[ https://www.mediawiki.org/wiki/Extension:Thanks | overview ]] page. - Code is the best manual - see the code [[ https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FThanks | here. ]] - Feedback on the Wikipedia Talk [[ https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks | page ]]. ===== Regarding Subtask 1 - {T135409} - 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. ===== Other feedback - 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 [[ https://gerrit.wikimedia.org/r/#/c/288871/ | 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 [[ https://gerrit.wikimedia.org/r/#/c/283749/ | 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 [[ https://gerrit.wikimedia.org/r/#/c/282616/ | 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. *** === Follow Up - [ ] Submit new patchset for the python-based bug. - [x] Modify proposal and add the changes suggested. - [x] Modify the MVP as required. - [x] Continue reading documentation on Thanks. - [x] jayvdb will provide me a with an example script which will help me with the API workflow. Study it. - [x] Shortlist three timeslots for next meeting, and finalize upon one. - [ ] Look at Alex's patchsets, and ensuing discussions and decisions.

{icon calendar} | Friday, 20th May 2016 - 15:00 UTC {icon user} | jayvdb, darthbhyrava **Skype Call** **Description**: Second meeting. Discussed progress so far, chalked out a plan going ahead, cleared many doubts. *** === Minutes of the Meeting . ===== Detailed Plan 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 [[ https://www.mediawiki.org/wiki/Extension:Thanks#API_Documentation | here ]]. - Mediawiki [[ https://www.mediawiki.org/wiki/Extension:Thanks | page ]] for Extension:Thanks. - Discussion Page for the extension [[ https://www.mediawiki.org/wiki/Extension_talk:Thanks | here ]]. - Feature Requirement [[ https://www.mediawiki.org/wiki/Notifications/Feature_requirements#Thank_you_notification | here ]]. - More details on the [[ https://www.mediawiki.org/wiki/Extension:Thanks | overview ]] page. - Code is the best manual - see the code [[ https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FThanks | here. ]] - Feedback on the Wikipedia Talk [[ https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks | page ]]. ===== Regarding Subtask 1 - {T135409} - 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. ===== Other feedback - 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 [[ https://gerrit.wikimedia.org/r/#/c/288871/ | 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 [[ https://gerrit.wikimedia.org/r/#/c/283749/ | 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 [[ https://gerrit.wikimedia.org/r/#/c/282616/ | 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 - Biw- Weekly Mmeetings on, alternating Skype e and IRC, i.e. - Biweekly Meetings on IRCwith IRC next week. - Need to decide upon next meeting's timeslot and agenda. *** === Follow Up - [ ] Submit new patchset for the python-based bug. - [x] Modify proposal and add the changes suggested. - [x] Modify the MVP as required. - [x] Continue reading documentation on Thanks. - [ - [x] jayvdb will provide me a with an example script which will help me with the API workflow. Study it. - [ - [x] Shortlist three timeslots for next meeting, and finalize upon one. - [ ] Look at Alex's patchsets, and ensuing discussions and decisions.