Change Details

{icon calendar} | Friday, 27th May 2016 - 16:30 UTC {icon user} | jayvdb, legoktm, darthbhyrava **Skype Call** **Description**: First weekly project meeting. Discussed plans for the first phase of the project - set goals. //Note: darthbhyrava messed up his UTC times, and turned up an hour late. ( Apologies, once more. :/ )// **Start**: **End**: *** === Minutes of the Meeting . ===== Conversation between jayvdb and legoktm A brief recap, then identifying the need for the latter's involvement going forward. - Not much has changed with respect to the flow and timeline of the project, hence no need for legoktm to go back and review progress all over again. - Going forward, not much required in the first two weeks or Phase-I of the project which involves basic code. legoktm can review the code to be submitted, but not much needed apart from that. - legoktm's participation and help required in Phase II (Weeks 3 and 4) when Flow gets involved. This would require someone to co-ordinate with the concerned people in WMF. - Also, legoktm to take a look at patches for pywikibot not on the ordinary gerrit list. ===== Patches from Community Bonding Period - JS and PHP based task can wait for later. Work on the Python task in spare time. - The time for these patches has passed. Focus must shift to the proposed project work entirely now. - In week 4, if project work is done, we can assess if week 5 can be used to work on these patches, again. May not be possible, since these 4 weeks will pass by very quickly. ===== Working on Subtask 1 - Weeks 1 and 2 will, broadly speaking, be about defining the way in which the thanks functionality will be exposed. - First objective: prototyping how classes and modules will work. - Proposed approach by darthbhyrava - taking a hardcoded revision object, and then thanking it using a new script. - Problem with the above - consistency. One script may work, but once I write another one on top of this, there's no guarantees as to the functionalities anymore. Hence, approach declined. - Since the use of API, and the elements that I'll be building will be tested by unit tests, I must get to unit tests quickly. - I must keep building a library of unit tests which make sure that everything I've done doesn't get undone later on. - A unit test based approach will lead to dependable incremental progress. - There will be methods on the `page.py` which allow for adding thanks, and methods on `site.py` which talk to the API. - Write down the said methods, their names, parameters and briefly mention components. The mentors and community can then review and suggest changes. - The specifications can be mentioned on the Phab task, and needn't be formal, something along the following lines will do: ``` class class_name( ... ): """ About class class_name """ def method1_name( param1, param2, ... ): """ About params and method""" def method2_name( param1, param2 ... ): ... ``` ===== Reviewing others' code A vital skill needed for a developer is the ability to interact with other coders. One needs to look at others' code and spot errors and changes. This helps one get more familiar with other areas of the community when they do their research while responding to the patch, it helps the reviewer to learn when others review or reply to his review, it exposes one to new style of coding, and it also teaches the reviewer about the process of code-merging. Needless to say, it provides the person submitting the patch with feedback, and helps the community. One will undoubtedly start with some silly comments and reviews. But that's fine. No code is off bounds, and reviewers have to be bold with their +1s and -1s. If the comment is not correct, it will be either ignored or corrected. Specific to @darthbhyrava: - As a flexible goal, do in-depth-reviews of two separate patches every week. - In gerrit, you can add a project to be watched. Once you're watching a project, you can be notified quickly and make first comments on new patches. Then others can respond to you. Look out for: - `site.py` and `page.py` - `pywikibot-core` - Do your homework before making comments. If you're unsure, then mention that you're unsure in the comments. - If //very// unsure, talk on the IRC channel. That'll help you get involved get you expert feedback. - Roughly one in every five patches can be reviewed, especially single or double line commits. --- Before next meet: - [ ] Update weekly reports. - [x] Study and ask **public** doubts about `basic.py` and `weblinkchecker.py`. - Doubts asked on `#pywikibot` - Read my notes on the scripts [[ http://bhyrava.me/code/gsoc/wikimedia/2016/05/30/GSoC4/ | here ]] - [ ] Study and ask doubts about unit_tests. - [ ] Submit rough design for methods as mentioned on the corresponding Phab task. - [ ] In-depth review of 2 patchsets. - [x] Update blog post: http://bhyrava/me/code

{icon calendar} | Friday, 27th May 2016 - 16:30 UTC {icon user} | jayvdb, legoktm, darthbhyrava **Skype Call** **Description**: First weekly project meeting. Discussed plans for the first phase of the project - set goals. //Note: darthbhyrava messed up his UTC times, and turned up an hour late. ( Apologies, once more. :/ )// **Start**: **End**: *** === Minutes of the Meeting . ===== Conversation between jayvdb and legoktm A brief recap, then identifying the need for the latter's involvement going forward. - Not much has changed with respect to the flow and timeline of the project, hence no need for legoktm to go back and review progress all over again. - Going forward, not much required in the first two weeks or Phase-I of the project which involves basic code. legoktm can review the code to be submitted, but not much needed apart from that. - legoktm's participation and help required in Phase II (Weeks 3 and 4) when Flow gets involved. This would require someone to co-ordinate with the concerned people in WMF. - Also, legoktm to take a look at patches for pywikibot not on the ordinary gerrit list. ===== Patches from Community Bonding Period - JS and PHP based task can wait for later. Work on the Python task in spare time. - The time for these patches has passed. Focus must shift to the proposed project work entirely now. - In week 4, if project work is done, we can assess if week 5 can be used to work on these patches, again. May not be possible, since these 4 weeks will pass by very quickly. ===== Working on Subtask 1 - Weeks 1 and 2 will, broadly speaking, be about defining the way in which the thanks functionality will be exposed. - First objective: prototyping how classes and modules will work. - Proposed approach by darthbhyrava - taking a hardcoded revision object, and then thanking it using a new script. - Problem with the above - consistency. One script may work, but once I write another one on top of this, there's no guarantees as to the functionalities anymore. Hence, approach declined. - Since the use of API, and the elements that I'll be building will be tested by unit tests, I must get to unit tests quickly. - I must keep building a library of unit tests which make sure that everything I've done doesn't get undone later on. - A unit test based approach will lead to dependable incremental progress. - There will be methods on the `page.py` which allow for adding thanks, and methods on `site.py` which talk to the API. - Write down the said methods, their names, parameters and briefly mention components. The mentors and community can then review and suggest changes. - The specifications can be mentioned on the Phab task, and needn't be formal, something along the following lines will do: ``` class class_name( ... ): """ About class class_name """ def method1_name( param1, param2, ... ): """ About params and method""" def method2_name( param1, param2 ... ): ... ``` ===== Reviewing others' code A vital skill needed for a developer is the ability to interact with other coders. One needs to look at others' code and spot errors and changes. This helps one get more familiar with other areas of the community when they do their research while responding to the patch, it helps the reviewer to learn when others review or reply to his review, it exposes one to new style of coding, and it also teaches the reviewer about the process of code-merging. Needless to say, it provides the person submitting the patch with feedback, and helps the community. One will undoubtedly start with some silly comments and reviews. But that's fine. No code is off bounds, and reviewers have to be bold with their +1s and -1s. If the comment is not correct, it will be either ignored or corrected. Specific to @darthbhyrava: - As a flexible goal, do in-depth-reviews of two separate patches every week. - In gerrit, you can add a project to be watched. Once you're watching a project, you can be notified quickly and make first comments on new patches. Then others can respond to you. Look out for: - `site.py` and `page.py` - `pywikibot-core` - Do your homework before making comments. If you're unsure, then mention that you're unsure in the comments. - If //very// unsure, talk on the IRC channel. That'll help you get involved get you expert feedback. - Roughly one in every five patches can be reviewed, especially single or double line commits. --- Before next meet: - [ ] Update weekly reports. - [x] Study and ask **public** doubts about `basic.py` and `weblinkchecker.py`. - Doubts asked on `#pywikibot` - Read my notes on the scripts [[ http://bhyrava.me/code/gsoc/wikimedia/2016/05/30/GSoC4/ | here ]] - [ ] Study and ask doubts about unit_tests. - [ ] Submit rough design for methods as mentioned on the corresponding Phab task. - [ ] In-depth review of 2 patchsets. - [x] Update blog post: http://bhyrava.me/code

{icon calendar} | Friday, 27th May 2016 - 16:30 UTC {icon user} | jayvdb, legoktm, darthbhyrava **Skype Call** **Description**: First weekly project meeting. Discussed plans for the first phase of the project - set goals. //Note: darthbhyrava messed up his UTC times, and turned up an hour late. ( Apologies, once more. :/ )// **Start**: **End**: *** === Minutes of the Meeting . ===== Conversation between jayvdb and legoktm A brief recap, then identifying the need for the latter's involvement going forward. - Not much has changed with respect to the flow and timeline of the project, hence no need for legoktm to go back and review progress all over again. - Going forward, not much required in the first two weeks or Phase-I of the project which involves basic code. legoktm can review the code to be submitted, but not much needed apart from that. - legoktm's participation and help required in Phase II (Weeks 3 and 4) when Flow gets involved. This would require someone to co-ordinate with the concerned people in WMF. - Also, legoktm to take a look at patches for pywikibot not on the ordinary gerrit list. ===== Patches from Community Bonding Period - JS and PHP based task can wait for later. Work on the Python task in spare time. - The time for these patches has passed. Focus must shift to the proposed project work entirely now. - In week 4, if project work is done, we can assess if week 5 can be used to work on these patches, again. May not be possible, since these 4 weeks will pass by very quickly. ===== Working on Subtask 1 - Weeks 1 and 2 will, broadly speaking, be about defining the way in which the thanks functionality will be exposed. - First objective: prototyping how classes and modules will work. - Proposed approach by darthbhyrava - taking a hardcoded revision object, and then thanking it using a new script. - Problem with the above - consistency. One script may work, but once I write another one on top of this, there's no guarantees as to the functionalities anymore. Hence, approach declined. - Since the use of API, and the elements that I'll be building will be tested by unit tests, I must get to unit tests quickly. - I must keep building a library of unit tests which make sure that everything I've done doesn't get undone later on. - A unit test based approach will lead to dependable incremental progress. - There will be methods on the `page.py` which allow for adding thanks, and methods on `site.py` which talk to the API. - Write down the said methods, their names, parameters and briefly mention components. The mentors and community can then review and suggest changes. - The specifications can be mentioned on the Phab task, and needn't be formal, something along the following lines will do: ``` class class_name( ... ): """ About class class_name """ def method1_name( param1, param2, ... ): """ About params and method""" def method2_name( param1, param2 ... ): ... ``` ===== Reviewing others' code A vital skill needed for a developer is the ability to interact with other coders. One needs to look at others' code and spot errors and changes. This helps one get more familiar with other areas of the community when they do their research while responding to the patch, it helps the reviewer to learn when others review or reply to his review, it exposes one to new style of coding, and it also teaches the reviewer about the process of code-merging. Needless to say, it provides the person submitting the patch with feedback, and helps the community. One will undoubtedly start with some silly comments and reviews. But that's fine. No code is off bounds, and reviewers have to be bold with their +1s and -1s. If the comment is not correct, it will be either ignored or corrected. Specific to @darthbhyrava: - As a flexible goal, do in-depth-reviews of two separate patches every week. - In gerrit, you can add a project to be watched. Once you're watching a project, you can be notified quickly and make first comments on new patches. Then others can respond to you. Look out for: - `site.py` and `page.py` - `pywikibot-core` - Do your homework before making comments. If you're unsure, then mention that you're unsure in the comments. - If //very// unsure, talk on the IRC channel. That'll help you get involved get you expert feedback. - Roughly one in every five patches can be reviewed, especially single or double line commits. --- Before next meet: - [ ] Update weekly reports. - [x] Study and ask **public** doubts about `basic.py` and `weblinkchecker.py`. - Doubts asked on `#pywikibot` - Read my notes on the scripts [[ http://bhyrava.me/code/gsoc/wikimedia/2016/05/30/GSoC4/ | here ]] - [ ] Study and ask doubts about unit_tests. - [ ] Submit rough design for methods as mentioned on the corresponding Phab task. - [ ] In-depth review of 2 patchsets. - [x] Update blog post: http://bhyrava/.me/code