For Czech WIkivoyage:
- RESTbase
- CX Config
- Analytics refinery
- Pywikibot
- Wikidata
- Namespaces
- Project name (wgSitename)
- Logos and wordmarks
- Timezone
- Import from Incubator
- Clean up old interwiki links
- Add the wiki to a CVNBot for SWMT monitoring
For Czech WIkivoyage:
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T370913 Post-creation work for cswikivoyage | |||
Resolved | Zabe | T370905 Create Wikivoyage Czech | |||
Resolved | BTullis | T370912 Prepare and check storage layer for cswikivoyage | |||
Resolved | Jgiannelos | T370914 Add cswikivoyage to RESTBase | |||
Resolved | Meno25 | T370915 Add support for cswikivoyage to Pywikibot | |||
Resolved | Ladsgroup | T370916 Add Wikidata support for cswikivoyage | |||
Resolved | Dzahn | T370917 Add cswikivoyage to wikistats | |||
Resolved | MF-Warburg | T370918 Import cswikivoyage from incubator | |||
Resolved | BUG REPORT | None | T371182 [cswikivoyage] Wrong count of Mainspace pages | ||
Open | None | T371648 Run rebuildall.php on cswikivoyage |
Change #1056553 had a related patch set uploaded (by Gerrit maintenance bot; author: Gerrit maintenance bot):
[analytics/refinery@master] Add cs.wikivoyage to pageview allowlist
Change #1056632 had a related patch set uploaded (by Zabe; author: Zabe):
[operations/mediawiki-config@master] Further configs for cswikivoyage
Change #1056632 merged by jenkins-bot:
[operations/mediawiki-config@master] Further configs for cswikivoyage
Mentioned in SAL (#wikimedia-operations) [2024-07-25T00:35:26Z] <zabe@deploy1002> Started scap sync-world: Backport for [[gerrit:1056632|Further configs for cswikivoyage (T370913)]]
Mentioned in SAL (#wikimedia-operations) [2024-07-25T00:37:53Z] <zabe@deploy1002> zabe: Backport for [[gerrit:1056632|Further configs for cswikivoyage (T370913)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2024-07-25T00:43:48Z] <zabe@deploy1002> Finished scap: Backport for [[gerrit:1056632|Further configs for cswikivoyage (T370913)]] (duration: 08m 22s)
Added the RESTBase one to our board, please let me know if I'm missing anything else.
I think there has been some confusion over how the RESTBase requirement should be handled when new wikis are created.
I see that you commented at T368067#9930630 saying "let us know when a RESTBase deployment is needed". Can this not be done immediately after a wiki is created? If not, then what has to happen first?
Is creating a separate task with the "MediaWiki-Engineering" (e.g., T365231 and T368068) or "Content-Transform-Team" (T370914) tag sufficient, or should something else be done in order to attract "the right eyes"?
(Finally, for my own benefit, can you briefly explain what things on-wiki actually depend on it being added to RESTBase? I've tried more than once to read the documentation, but it hasn't really enlightened me.)
Indeed, we are currently discussing what is the future of this process while we work on RESTBase Sunsetting. For now, I don't have much to add other than: we will do a best effort to fulfil these requests and try to make them obsolete once we deprecate RESTBase.
I see that you commented at T368067#9930630 saying "let us know when a RESTBase deployment is needed". Can this not be done immediately after a wiki is created? If not, then what has to happen first?
Unfortunately, it's not an automated process and the plan is to deprecate RESTBase in the current FY.
Is creating a separate task with the "MediaWiki-Engineering" (e.g., T365231 and T368068) or "Content-Transform-Team" (T370914) tag sufficient, or should something else be done in order to attract "the right eyes"?
The best thing to do is tag the MediaWiki-Engineering so it get "enough eyes". At the moment the Content Transform Team perform deployments in restbase but by necessity instead of ownership.
(Finally, for my own benefit, can you briefly explain what things on-wiki actually depend on it being added to RESTBase? I've tried more than once to read the documentation, but it hasn't really enlightened me.)
RESTBase proxy to a few services that might be important to a wiki, like the Page Preview (summary endpoint), Mobile Apps support (iOS/Android), Math formulas (although this is going to change to native rendering), etc.
OK, sure, but that doesn't really answer my question. (Thank you for the other answers, BTW.) You left that comment a week after the subtask T368068: Add btmwiki to RESTBase was created and T368038: Create Wikipedia Mandailing was closed, indicating that the wiki itself had been created. Is there any particular reason you didn't start making the changes at that time rather than asking for a separate (future) request? (IOW, did you not know that the wiki had already been created or that the request for RESTBase support had already been made? Or was there some other reason the request couldn't be fulfilled at that time?)
I'm not trying to be critical of you, personally; I'm just trying to figure out why certain post-creation tasks are taking a really long time to get done, as if the folks who would do them aren't getting the message that they need to be done. If the answer is simply the usual "we're all volunteers here", then so be it, but I suspect that there's more going on here than just that.
In T334740#8791966 @Dzahn was complaining that the true dependencies between tasks were not being captured by the system of parent/child tasks being used. Is that what's going on here, too? If so, which tasks should be parents or children of which, to improve the situation?
Certainly, there's a process gap here and by no means the delay was intended to caused disruptions. This process was hindered by volunteer work, and that was the first time I interacted with this responsibility as a Product Manager. RESTBase has no clear ownership, which is one reason it is being deprecated. The Content-Transform-Team and MW-Interfaces-Team are involved in its deprecation. Still, we started doing deployments by necessity and taking on requests on RESTBases is treated as Essential-Work, and we try to do our best to tackle as soon as possible. Right now, I can only think about two people who deployed to RESTBase, and they still are not entirely comfortable doing it.
To answer your questions directly, I was unaware of any SLA to finish this work, and I apologize for that. The workload and resourcing for Essential Work investigating a process we didn't get involved in the past prevented us from working on it immediately. Knowing or not that the wiki was created is irrelevant; we would still be delayed by the challenges we faced. As mentioned before, it was our best effort.
But to answer your question, I found out about T368068 randomly. Reading my comment now, I see it wasn't clear that I was expecting the people responsible for creating the configurations to send a patch and raise when it should be deployed. Meanwhile, I still brought this to an ownership discussion with the MediaWiki-Engineering group, which led to the discussion or context I already shared.
In an attempt to be constructive, I would suggest that an SLA be clearly stated and raised before the wiki's creation if this is immediate work.
I'm not trying to be critical of you, personally; I'm just trying to figure out why certain post-creation tasks are taking a really long time to get done, as if the folks who would do them aren't getting the message that they need to be done. If the answer is simply the usual "we're all volunteers here", then so be it, but I suspect that there's more going on here than just that.
I appreciate your feedback and civil discourse. I also don't want to be defensive, although I'm making excuses. I just want to make sure you get the full context so we can proceed with a solution and/or evolution of the current process.
In T334740#8791966 @Dzahn was complaining that the true dependencies between tasks were not being captured by the system of parent/child tasks being used. Is that what's going on here, too? If so, which tasks should be parents or children of which, to improve the situation?
I don't know how to answer that, but for RESTBase-specific work, we need an SLA and an upfront heads-up to plan accordingly until this step is no longer needed.
I'm blocked from running my usual script that checks what interwikis are left to clean up by T370912: Prepare and check storage layer for cswikivoyage not being done. This also still needs to be added to CVN, which tends to take months.
Interwiki checking script reports:
1 local interwikis [('Uživatel:Polda18', 'enwikivoyage')] 0 interwiki template use(s)
Only thing left to do here is countervandalism network.