Related from T154470:

An *organisational* approach is to re-work how we use Phabricator for agile iterative 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

• 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, Github account and , Phabricator account, Botaccount on Commons

• 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

• 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.

Notes from internal workshop on this (final decisions will be communicated on se.wikimedia.se):

Github-phabricator-gerrit:
Default: Fristående verktyg och “batchspecifik kod” i Github
I github commit message: Lägg till T<id>, I motsvarande task lägg till Patch-For-Review och länk till github PR.
Länk från README.md till relevant Phabricator
Testning:
Unittester för ny kod (inte gammal som en kan anta fungerar)
Motsvarigheten till integrationstester kan delvis lösas med documentation i Phabricator - t.ex. Beskriv förväntad utdata för X riktiga exempel indata.

Code-review:
Code-review sker på PR, storleken på en PR motsvarar ofta en task (ny funktionalitet, ändrad funktionalitet, bugg). Bra om PR är parallella inte interdependent.
För batchupload: bryt ut en informationsmängd (typ ett fält)
Mattias och Alicia kör review och pingar André inför skarp implementation som start
Lintning:
Kan någon ta på sig att hitta en linter som även kollar efter en specifik parameterdokumentationsstil?
Kan någon identifiera en naturlig plats på föreningswikin för spikade beslut
Kodande generellt:
Vi kör Python 3 i nya repon
Datalagring i Repositories:
Inte loggfiler i repo (bara konstigt, bättre som attachments till Phabricator)
Indata (ex: metadata) varierar om det ska/kan/bör vara i repot beroende på scope
Processerad data(ex: wikisyntax-formaterad utdata) bör inte ligga i repo
Att göra:
Starta “kodsnack” på Phabricator (Mattias)
Lägger in länk till tox+travis på github (André)
En naturlig plats på föreningswikin för spikade beslut (André)
Hitta en linter som även kollar efter en specifik parameterdokumentationsstil (Sebastian)

Greetings from Conduit!

In T154471#3016785, @Sebastian_Berlin-WMSE wrote:

Greetings from Conduit!

Cryptic, but nice! Hello! :-)

A note that the notes have moved to here