Per https://wikitech.wikimedia.org/wiki/Add_a_wiki once the wiki has been created
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
[L10N] Add support for smn site | pywikibot/core | master | +29 -28 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Xqt | T264962 Add support for smnwiki to Pywikibot | |||
Resolved | Urbanecm | T264859 Create Inari Sámi Wikipedia | |||
Resolved | bd808 | T264900 Prepare and check storage layer for smnwiki |
Event Timeline
@Xqt changing the subtask to parent task that you did is wrong. Look https://www.mediawiki.org/wiki/Phabricator/Help#Parent_tasks_and_subtasks
If Task A cannot be solved until Task B is solved, then Task A is the parent task and Task B is the subtask
Task A here is adding smnwiki to pywikibot and Task B is actually creating the wiki. I know it has been the way it used to be done but that was wrong.
In that sense you are right; I understood that parent/subtask differently as splitting a bigger issue into parts which seems more logically to me.
The most logical thing IMO is to have two tickets for creating a wiki. One umbrella (tracking) one that pywikibot would be subticket of that, and one for making that wiki go live which would be subticket of this. But I think that's a little bit of overkill.
The most logical thing IMO is to have two tickets for creating a wiki. One umbrella (tracking) one that pywikibot would be subticket of that, and one for making that wiki go live which would be subticket of this. But I think that's a little bit of overkill.
Don’t think so that this us an overkill as long as the T264859 has a checklist that Pywikibot task (and others) is done. That means each is waiting for the other which means both are parents and sub task for the other task.
Change 634986 had a related patch set uploaded (by Xqt; owner: Xqt):
[pywikibot/core@master] [L10N] Add support for smn site
Change 634986 merged by jenkins-bot:
[pywikibot/core@master] [L10N] Add support for smn site