Change Details

Several tasks based on the experience from GAR, DecArch and SMVK-Mexiko uploads. The idea is to have defined a set of *reasonable defaults* for a newcomer to help out with scripting of batch uploads to avoid a) cognitive overload due to all options/tasks (["As a rule of thumb, limit High priority task assignments for a single person to three, five in exceptional times."](https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities) b) quality issues due to lack of "safety net" built in human and technical sanity checks c) waste of time/energy due to lack of real milestones e.g. get GLAM engagement or external feedback Most of the learning possibilities I've encountered relates to [onboarding](https://en.wikipedia.org/wiki/Onboarding). There is a project on Phabricator that acknowledges this need called [Engineering Onboarding Template](https://phabricator.wikimedia.org/project/view/1629/) An *organisational* approach is to re-work how we use Phabricator for [agile](https://en.wikipedia.org/wiki/Iterative_and_incremental_development#/media/File:Agile_Project_Management_by_Planbox.png) [iterative development](https://en.wikipedia.org/wiki/Iterative_and_incremental_development): [ ] Use subprojects/milestones with tag release for an iteration (e.g. get mapping tables, example images etc to users) to de-clutter? [ ] Decide on form for code review (Github/Diffusion?) to avoid solo-work and ad hoc, stressful feedback e.g. tag patch-for-review? [ ] Have regular sprint/iteration meetings to decide on closing of possible never-ending tasks such as maintanence for old batchuploads [ ] Daily standup meetings? Who should participate? Another simple way of doing this is to add documentation in friendly and familiar looking webpage (readthedocs? notebook on PAWS?) "introduction to batch uploads for beginners" or here with e.g: [ ] Tell what to do if something goes wrong e.g. how to [undo bad uploads on commons](https://commons.wikimedia.org/wiki/Commons:Deletion_requests) [ ] high-level introduction to Phabricator.e.g [Phabricator for project management](https://www.mediawiki.org/wiki/Phabricator/Project_management#Why_use_Phabricator_for_managing_your_project.3F) [ ] Suggested developer setup: [Pywikibot](https://www.wikidata.org/wiki/Wikidata:Pywikibot_-_Python_3_Tutorial/Setting_up_Shop), Github account and , [Phabricator account](https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account_and_notifications), [Botaccount on Commons](https://commons.wikimedia.org/wiki/Commons:Bots/Requests) [ ] Suggested layout of a batch upload repo (license, folders, metadata as wik-formatted infotexts.json-file etc) [ ] Useful example snippets e.g. [add speedy deletion template to files on Commons](https://gist.github.com/mattiasostmar/00d99a935923b32ed6b6bca1b5029165) [ ] Suggested use of BatchUploadTools (pip install, the three most useful methods with code examples) [ ] Suggested [use of Phabricator] (see [mediawiki phabricator help](https://www.mediawiki.org/wiki/Phabricator/Help) and [phabricator project management](https://www.mediawiki.org/wiki/Phabricator/Project_management)) [ ] Suggested team collaboration sign-off to ensure the developer doesn't work alone and waste time/prioritize wrongly [ ] Example workflow with handling maintanence tasks from mail, over Phabricator to review in Pull request, to reporting back to GLAM.

Several tasks based on the experience from GAR, DecArch and SMVK-Mexiko uploads. The idea is to have defined a set of *reasonable defaults* for a newcomer to help out with scripting of batch uploads to avoid a) cognitive overload due to all options/tasks (["As a rule of thumb, limit High priority task assignments for a single person to three, five in exceptional times."](https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities) b) quality issues due to lack of "safety net" built in human and technical sanity checks c) waste of time/energy due to lack of real milestones e.g. get GLAM engagement or external feedback Most of the learning possibilities I've encountered relates to [onboarding](https://en.wikipedia.org/wiki/Onboarding). There is a project on Phabricator that acknowledges this need called [Engineering Onboarding Template](https://phabricator.wikimedia.org/project/view/1629/) An *organisational* approach is to re-work how we use Phabricator for [agile](https://en.wikipedia.org/wiki/Iterative_and_incremental_development#/media/File:Agile_Project_Management_by_Planbox.png) [iterative development](https://en.wikipedia.org/wiki/Iterative_and_incremental_development): [ ] Use subprojects/milestones with tag release for an iteration (e.g. get mapping tables, example images etc to users) to de-clutter? [ ] Decide on form for code review (Github/Diffusion?) to avoid solo-work and ad hoc, stressful feedback e.g. tag patch-for-review? [ ] Have regular sprint/iteration meetings to decide on closing of possible never-ending tasks such as maintanence for old batchuploads [ ] Daily standup meetings? Who should participate? Another simple way of doing this is to add documentation in friendly and familiar looking webpage (readthedocs? notebook on PAWS?) "introduction to batch uploads for beginners" or here with e.g: [ ] Tell what to do if something goes wrong e.g. how to [undo bad uploads on commons](https://commons.wikimedia.org/wiki/Commons:Deletion_requests) [ ] high-level introduction to Phabricator.e.g [Phabricator for project management] and middle-level (https://www.mediawiki.org/wiki/Phabricator/Project_management#Why_use_Phabricator_for_managing_your_project.3F) [ ] Suggested developer setup: [Pywikibot](https://www.wikidata.org/wiki/Wikidata:Pywikibot_-_Python_3_Tutorial/Setting_up_Shop), Github account and , [Phabricator account](https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account_and_notifications), [Botaccount on Commons](https://commons.wikimedia.org/wiki/Commons:Bots/Requests) [ ] Suggested layout of a batch upload repo (license, folders, metadata as wik-formatted infotexts.json-file etc) [ ] Useful example snippets e.g. [add speedy deletion template to files on Commons](https://gist.github.com/mattiasostmar/00d99a935923b32ed6b6bca1b5029165) [ ] Suggested use of BatchUploadTools (pip install, the three most useful methods with code examples) [ ] A short text on why it's OK to 'bother collegues with questions/guidance' and what YOU're expected to do to do first. [ ] Example workflow with handling maintanence tasks from mail, over Phabricator to review in Pull request, to reporting back to GLAM.

Several tasks based on the experience from GAR, DecArch and SMVK-Mexiko uploads. The idea is to have defined a set of *reasonable defaults* for a newcomer to help out with scripting of batch uploads to avoid a) cognitive overload due to all options/tasks (["As a rule of thumb, limit High priority task assignments for a single person to three, five in exceptional times."](https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities) b) quality issues due to lack of "safety net" built in human and technical sanity checks c) waste of time/energy due to lack of real milestones e.g. get GLAM engagement or external feedback Most of the learning possibilities I've encountered relates to [onboarding](https://en.wikipedia.org/wiki/Onboarding). There is a project on Phabricator that acknowledges this need called [Engineering Onboarding Template](https://phabricator.wikimedia.org/project/view/1629/) An *organisational* approach is to re-work how we use Phabricator for [agile](https://en.wikipedia.org/wiki/Iterative_and_incremental_development#/media/File:Agile_Project_Management_by_Planbox.png) [iterative development](https://en.wikipedia.org/wiki/Iterative_and_incremental_development): [ ] Use subprojects/milestones with tag release for an iteration (e.g. get mapping tables, example images etc to users) to de-clutter? [ ] Decide on form for code review (Github/Diffusion?) to avoid solo-work and ad hoc, stressful feedback e.g. tag patch-for-review? [ ] Have regular sprint/iteration meetings to decide on closing of possible never-ending tasks such as maintanence for old batchuploads [ ] Daily standup meetings? Who should participate? Another simple way of doing this is to add documentation in friendly and familiar looking webpage (readthedocs? notebook on PAWS?) "introduction to batch uploads for beginners" or here with e.g: [ ] Tell what to do if something goes wrong e.g. how to [undo bad uploads on commons](https://commons.wikimedia.org/wiki/Commons:Deletion_requests) [ ] high-level introduction to Phabricator.e.g [Phabricator for project management] and middle-level (https://www.mediawiki.org/wiki/Phabricator/Project_management#Why_use_Phabricator_for_managing_your_project.3F) [ ] Suggested developer setup: [Pywikibot](https://www.wikidata.org/wiki/Wikidata:Pywikibot_-_Python_3_Tutorial/Setting_up_Shop), Github account and , [Phabricator account](https://www.mediawiki.org/wiki/Phabricator/Help#Creating_your_account_and_notifications), [Botaccount on Commons](https://commons.wikimedia.org/wiki/Commons:Bots/Requests) [ ] Suggested layout of a batch upload repo (license, folders, metadata as wik-formatted infotexts.json-file etc) [ ] Useful example snippets e.g. [add speedy deletion template to files on Commons](https://gist.github.com/mattiasostmar/00d99a935923b32ed6b6bca1b5029165) [ ] Suggested use of BatchUploadTools (pip install, the three most useful methods with code examples) [ ] Suggested [use of Phabricator] (see [mediawiki phabricator help](https://www.mediawiki.org/wiki/Phabricator/Help) and [phabricator project management](https://www.mediawiki.org/wiki/Phabricator/Project_management)) [ ] Suggested team collaboration sign-off to ensure the developer doesn't work alone and waste time/prioritize wronglyA short text on why it's OK to 'bother collegues with questions/guidance' and what YOU're expected to do to do first. [ ] Example workflow with handling maintanence tasks from mail, over Phabricator to review in Pull request, to reporting back to GLAM.