Hi all -
I've been reviewing a list of extensions with Reading Engineering and Reading Infrastructure leads - props to James Forrester for promoting this discussion. Here's a list of extensions we believe currently falls under Reading for triage (n.b., not all extensions will get active development support).
https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
Presuming no major issues with this, I think we should move the page to mw:Reading/Extension_Responsibility.
One important outstanding question:
Is MultimediaViewer appropriate for Reading given its consumption-oriented nature? Or is this actually better suited to Editing (where there exists a team named Multimedia)?
Some other notes:
* For skins with low utilization, we in time probably should coordinate handover to interested community members (or discuss with community members practical approaches for EOL).
* Regarding the Nostalgia skin, we believe it's only used on https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would be updating for breaking skin changes or security issues only.
* JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this more closely. Yuri (who has deepest PHP knowledge on extensions) is now over in Discovery, Jeff (JS & Lua) is in Reading, and now I'm managing instead of writing lots of code.
* Collection probably belongs in Services
Adam Baso, 20/07/2015 22:58:
I think we should move the page to mw:Reading/Extension_Responsibility.
Or better, merge with https://www.mediawiki.org/wiki/Developers/Maintainers
Nemo
Ah, yes, that.
On Mon, Jul 20, 2015 at 4:41 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Adam Baso, 20/07/2015 22:58:
I think we should move the page to mw:Reading/Extension_Responsibility.
Or better, merge with https://www.mediawiki.org/wiki/Developers/Maintainers
Nemo
A SLA and point person for each of these extensions would be a good next step. I worry that saying the reading vertical maintains the "Cologne blue" skin sets an expectation that we will be code reviewing all patches for Modern which is simply untrue.
This may also be a good time to revisit this thread... https://www.marc.info/?l=wikitech-l&m=139448582829276&w=3
On Mon, Jul 20, 2015 at 4:41 PM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Adam Baso, 20/07/2015 22:58:
I think we should move the page to mw:Reading/Extension_Responsibility.
Or better, merge with https://www.mediawiki.org/wiki/Developers/Maintainers
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Agreed. Borrowing a snippet from the earlier discussion on this, and I should have copied this in earlier:
"This is entirely about ... fixing urgent issues that affect production, ideally before they hit it (security issues, deprecated code, etc.). It is not necessarily about doing planning, development, or code review, except in as much as you want to do that and be 'good citizens' in open source and making people happy/*etc.*."
Marking SLAs and point people will be a good idea.
Regarding the skin sunset concept, glad you pointed out that thread. Will need to review the material. I understand it's complex.
On Monday, July 20, 2015, Jon Robson jdlrobson@gmail.com wrote:
A SLA and point person for each of these extensions would be a good next step. I worry that saying the reading vertical maintains the "Cologne blue" skin sets an expectation that we will be code reviewing all patches for Modern which is simply untrue.
This may also be a good time to revisit this thread... https://www.marc.info/?l=wikitech-l&m=139448582829276&w=3
On Mon, Jul 20, 2015 at 4:41 PM, Federico Leva (Nemo) <nemowiki@gmail.com javascript:;> wrote:
Adam Baso, 20/07/2015 22:58:
I think we should move the page to mw:Reading/Extension_Responsibility.
Or better, merge with
https://www.mediawiki.org/wiki/Developers/Maintainers
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
On Mon, Jul 20, 2015 at 3:58 PM, Adam Baso abaso@wikimedia.org wrote:
Hi all -
I've been reviewing a list of extensions with Reading Engineering and Reading Infrastructure leads - props to James Forrester for promoting this discussion. Here's a list of extensions we believe currently falls under Reading for triage (n.b., not all extensions will get active development support).
https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
Presuming no major issues with this, I think we should move the page to mw:Reading/Extension_Responsibility.
Definitely not a *major* issue, but VipsScaler https://www.mediawiki.org/wiki/Extension:VipsScaler would logically belong together with the media handler extensions (which are all on the list) IMO.
Shall I make it so?
On Tue, Jul 21, 2015 at 3:59 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Mon, Jul 20, 2015 at 3:58 PM, Adam Baso abaso@wikimedia.org wrote:
Hi all -
I've been reviewing a list of extensions with Reading Engineering and Reading Infrastructure leads - props to James Forrester for promoting this discussion. Here's a list of extensions we believe currently falls under Reading for triage (n.b., not all extensions will get active development support).
https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
Presuming no major issues with this, I think we should move the page to mw:Reading/Extension_Responsibility.
Definitely not a *major* issue, but VipsScaler https://www.mediawiki.org/wiki/Extension:VipsScaler would logically belong together with the media handler extensions (which are all on the list) IMO.
On Tue, Jul 21, 2015 at 6:11 PM, Adam Baso abaso@wikimedia.org wrote:
Shall I make it so?
I don't see a reason not to. While one could argue both for media handlers belonging to Reading and to Editing, they should in any case be all at the same place as they require the same knowledge (familiarity with core MediaHandler classes, File etc). VipsScaler is not itself a media handler, but it is about modifying media handler behavior via hooks so it is close enough.
Okay, to be clear, VipsTest, too, right?
On Tue, Jul 21, 2015 at 4:22 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Jul 21, 2015 at 6:11 PM, Adam Baso abaso@wikimedia.org wrote:
Shall I make it so?
I don't see a reason not to. While one could argue both for media handlers belonging to Reading and to Editing, they should in any case be all at the same place as they require the same knowledge (familiarity with core MediaHandler classes, File etc). VipsScaler is not itself a media handler, but it is about modifying media handler behavior via hooks so it is close enough.
On Tue, Jul 21, 2015 at 6:27 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, to be clear, VipsTest, too, right?
Yes, that's essentially the same extension (a different PHP endpoint in the same repo).
Done.
On Tue, Jul 21, 2015 at 4:30 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Jul 21, 2015 at 6:27 PM, Adam Baso abaso@wikimedia.org wrote:
Okay, to be clear, VipsTest, too, right?
Yes, that's essentially the same extension (a different PHP endpoint in the same repo).
If the MultimediaViewer extension is transferred to Editing (i.e. Multimedia), TimedMediaHandler should probably go with it, as they are both mainly for presenting media within pages.
On Mon, Jul 20, 2015 at 3:58 PM, Adam Baso abaso@wikimedia.org wrote:
Hi all -
I've been reviewing a list of extensions with Reading Engineering and Reading Infrastructure leads - props to James Forrester for promoting this discussion. Here's a list of extensions we believe currently falls under Reading for triage (n.b., not all extensions will get active development support).
https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
Presuming no major issues with this, I think we should move the page to mw:Reading/Extension_Responsibility.
One important outstanding question:
Is MultimediaViewer appropriate for Reading given its consumption-oriented nature? Or is this actually better suited to Editing (where there exists a team named Multimedia)?
Some other notes:
- For skins with low utilization, we in time probably should coordinate
handover to interested community members (or discuss with community members practical approaches for EOL).
- Regarding the Nostalgia skin, we believe it's only used on
https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would be updating for breaking skin changes or security issues only.
- JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this more
closely. Yuri (who has deepest PHP knowledge on extensions) is now over in Discovery, Jeff (JS & Lua) is in Reading, and now I'm managing instead of writing lots of code.
- Collection probably belongs in Services
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
+1 to thus On 21 Jul 2015 4:52 pm, "Ryan Kaldari" rkaldari@wikimedia.org wrote:
If the MultimediaViewer extension is transferred to Editing (i.e.
Multimedia), TimedMediaHandler should probably go with it, as they are both mainly for presenting media within pages.
On Mon, Jul 20, 2015 at 3:58 PM, Adam Baso abaso@wikimedia.org wrote:
Hi all -
I've been reviewing a list of extensions with Reading Engineering and
Reading Infrastructure leads - props to James Forrester for promoting this discussion. Here's a list of extensions we believe currently falls under Reading for triage (n.b., not all extensions will get active development support).
https://www.mediawiki.org/wiki/User:ABaso_(WMF)/Extension_Responsibility
Presuming no major issues with this, I think we should move the page to
mw:Reading/Extension_Responsibility.
One important outstanding question:
Is MultimediaViewer appropriate for Reading given its
consumption-oriented nature? Or is this actually better suited to Editing (where there exists a team named Multimedia)?
I agree. They should come as a package (fwiw im a little confused why viewing images and thus multimedia viewer doesn't come under reading).
Some other notes:
- For skins with low utilization, we in time probably should coordinate
handover to interested community members (or discuss with community members practical approaches for EOL).
- Regarding the Nostalgia skin, we believe it's only used on
https://nostalgia.wikipedia.org/wiki/HomePage, so maintenance would be updating for breaking skin changes or security issues only.
- JsonConfig, ZeroBanner, ZeroPortal - we'll need to examine this more
closely. Yuri (who has deepest PHP knowledge on extensions) is now over in Discovery, Jeff (JS & Lua) is in Reading, and now I'm managing instead of writing lots of code.
- Collection probably belongs in Services
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Tue, Jul 21, 2015 at 6:52 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
If the MultimediaViewer extension is transferred to Editing (i.e. Multimedia), TimedMediaHandler should probably go with it, as they are both mainly for presenting media within pages.
I agree with Jon that MMV should belong to Reading Web (especially since they already own the mobile media viewer and the plan is to merge the two), but the comparison does not really stand up. TMH is about a whole lot of things: it adds and manages a new page content type (TimedText), it integrates the file upload with machinery to run and control video transcoding jobs, it is deeply entangled with WMF infrastructure (it has its own server cluster), it provides its own file metadata API (although it probably shouldn't https://phabricator.wikimedia.org/T89971). And it also presents media within pages.
It could go to any number of teams - Reading Infrastructure is IMO a practical decision for now because all the recent TMH breakage I can remember was MW core or devops related (mostly because those have more interdependencies and a higher rate of change than frontend code), and the other potential teams focus on frontend. And while frontend is the part of TMH in the biggest need of a rewrite (TheDJ actually started that and anyone from the frontend teams helping out by reviewing his code would be great), extension responsibility is explicitly not about improvements but about reacting to breakage.