Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Minutes and slides from the recent quarterly review of the Foundation's Language Engineering team are available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarterly_reviews/Language_Engineering/September_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller wrote: > > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > ___ > Wikimedia-l mailing list > wikimedi...@lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Phabricator update
Hi, if you were wondering what is going on in Phabricator land... Summary: You can see https://phabricator.wikimedia.org , you can touch https://phab-01.wmflabs.org/ , you will have a chance to provide feedback about the Bugzilla migration before the migration, based on a test instance with a sample of bugs imported. In detail: * https://phabricator.wikimedia.org exists as a read-only instance and it contains the tasks that were migrated from the now decommissioned fab.wmflabs.org. Registration is disabled while we fix some tasks -- details at https://www.mediawiki.org/wiki/Phabricator/Plan#Migration_plan . We will post here when the issues have been fixed. * We have a test instance at https://phab-01.wmflabs.org/ where you can play as much as you want. This instance is for testing and experimenting only. Anything in there can disappear in a whim. * When we open phabricator.wikimedia.org, the creation of new projects will be still disabled. Existing projects will be able to continue their work, but we are asking new projects to wait a few weeks, until we complete the Bugzilla migration. It's going to be still a bumpy road before Day 1, and we want to control the impact of these disruptions as much as possible. * RT migration will follow. Details will be shared in advance. * Bugzilla migration will follow. Details will be shared in advance as well, but we have a rough idea of the sequence of steps. Details available in the migration plan linked above, pasted here for convenience: 1. Earliest possible/expected date: October 06 but favoring Friday October 10 to interrupt engineering less (starting over the weekend). Bugzilla downtime expected of 1-3 days. Checklist: 2. Instructions to use Phabricator for bug reporting and project management. 3. Documentation of data and features that will not be available in Phabricator after the migration. Phabricator test instance available with a sample of Bugzilla reports imported automatically (say 1 of each 10, about 700 reports). 4. At least one week of margin to receive community feedback and implement improvements. 5. Documentation of the migration process detailing sequence of steps and timeline expected. 6. Go-NoGo meeting with the Phabricator team (Andre, Chase, Mukunda, Quim), Erik, Rob, MarkB, and Greg. Stay tuned. :) -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Best method to flag wiki pages based on rendered HTML
Thanks for the info! I have been unable to figure out the right place to interact with the parser, though. As far as I can see, there are no hooks between calling the parser and calling linksupdate, and the hooks which are internal to the parser have no knowledge of what they are parsing: the main wikitext or some random interface message. That's fine for extensions which use tracking categories to trace when something is broken, but I am trying to find out when something is missing; the logic would be triggered on every interface message or section preview or whatever. Short of adding a new hook (to the end of Content::getParserOutput maybe), I don't see how this could be done. On Mon, Sep 15, 2014 at 3:03 AM, Brian Wolff wrote: > On 9/14/14, Gergo Tisza wrote: > > Hi, > > > > I would like to flag a large number of wiki pages based on whether their > > HTML passes a certain test, so that failing pages can be easily listed > and > > counted. The flags should adapt when pages are created or modified. (The > > specific use case is collecting file pages which do not have > > machine-readable author and license information embedded.) > > > > I have been thinking of adding such pages to a maintenance category from > a > > parser hook (the test logic is already part of the imageinfo/extmetadata > > API and would be easy to reuse), is that a good way to do this? If so, > > what's the best way to achieve it? Is it OK to just add categories as > > needed via $parser->getOutput()->addCategory() or can that mess up > internal > > state such as the categorylinks table? > > > > Alternatively, the Cite extension just parses and appends a message to > the > > end of the text on ParserBeforeTidy when it encounters an error, and the > > message contains wikitext to include a category. That seems like a clever > > way of maintaining flexibility so it is easy to change the category name > or > > add extra text for a call to action without any need for a code change. > Is > > that approach safe/cheap? > > > > thanks > > Gergő > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > There's two ways that this is usually done, either page_props table, > or tracking categories. Provided the hook you use runs before > linksupdate (which is any hook in the parser), you should be fine in > adding such things. > > To add a page property, you would do something like > $parser->getOutput()->setProperty( 'prop name', 'optionally some extra > arbitrary data' ); > > > Pages can be found via Special:PagesWithProp or direct db query. > > To add a tracking category: > $parser->addTrackingCategory( 'tracking cat name' ); > > > You also have to define a message for the tracking category name and a > description message, add it to $wgTrackingCategories. See the code > docs for Parser::addTrackingCategory and $wgTrackingCategories. > > Generally page props are used for obscure things that a user is > unlikely to care about or cases where you need special cache > invalidation behaviour on change (there's special support for that > with $wgPagePropLinkInvalidations), where tracking categories are more > properties the user is interested in. Its possible to also make the > tracking category by off by default until users turn it "on" by > editing a mediawiki namespace page by making the category name defualt > to '-'. > > In the use case you describe I think tracking category is more suited. > > --bawolff > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Jenkins smarter with extension PHPUnit tests
Hello,
An hour or so ago, I have changed the way we run PHPUnit tests for
extensions.
* we now bring in mediawiki/vendor repository
* mediawiki/core is now using the branch of the proposed patchset. So if
you propose a patch for your extension against REL1_23, it will be
tested with core@REL1_23. Previously we always used master.
The job names have been changed:
- 'mwext-{extension}-testextensions-master'
+ 'mwext-{extension}-testextension'
Some jobs are still updating as I write this. Should be completed soon.
If I see any failure in between I will retrigger the jobs.
Something I have yet to figure out is to have the patch voted +2 to be
tested sequentially to ensure the queue of proposed changes works well
together. Should be dealt with this evening or at worse tomorrow.
If anything is suspicious / failing. Please fill in bugs against
Wikimedia > "Continuous integration".
More details / doc will follow as time allow (see bug 1).
--
Antoine "hashar" Musso
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator update
> * We have a test instance at https://phab-01.wmflabs.org/ where you can > play as much as you want. This instance is for testing and experimenting > only. Anything in there can disappear in a whim. Just to be extremely clear: Any data in the new phab-01.wmflabs instance can *and will* disappear when it is no longer needed for testing purposes. We make no commitment to transferring any data out of that instance into the production one. -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Phabricator update
We should've kept the fab subdomain ;-) On Sep 16, 2014 8:45 AM, "Greg Grossmeier" wrote: > > > * We have a test instance at https://phab-01.wmflabs.org/ where you can > > play as much as you want. This instance is for testing and experimenting > > only. Anything in there can disappear in a whim. > > Just to be extremely clear: > Any data in the new phab-01.wmflabs instance can *and will* disappear > when it is no longer needed for testing purposes. > > We make no commitment to transferring any data out of that instance into > the production one. > > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fixing PollNY -- ResourceLoader woes
How exactly did you try it: mw.loader.using( 'resource.name', function() {
... } ) ?
On Tue, Sep 16, 2014 at 3:00 PM, Jack Phoenix
wrote:
> Hi all,
>
> A few days ago I was fiddling around with my Labs instance [1], which
> serves as a development/testing/showcase area for social tools [2]. Somehow
> I ended up on Special:ViewPoll [3] and got curious as to why a JavaScript
> hover effect (mouseover/mouseout) didn't work on that page -- I was sure it
> used to work just fine not that long time ago. Without thinking that much
> about it, I clicked on the one and only poll listed on the page [4], and
> turns out the whole Poll: page is about as broken as it can be due to a
> JavaScript error.
>
> After a while of debugging, consultation and more debugging, turned out
> that my local development setup had $wgResourceLoaderDebug = true; in its
> LocalSettings.php, which apparently hides some race conditions or something
> like that. The Labs instance tries to be a more faithful representation of
> a production wiki, and as such, it doesn't have this setting enabled and
> hence why the problem manifests there.
>
> PollNY itself is a rather old extension, as most original social tools are
> (see the MW.org page [2] for details), and as such, it likely has some
> non-optimal code and it's also gone through plenty of iterations in the
> past. As a matter of fact, when porting PollNY to use ResourceLoader, it
> seems I myself made some suboptimal choices, such as bundling both CSS and
> JS into the same module and loading this module with 'position' => 'top'.
>
> Anyway, after decoupling the main CSS into its own module (locally, haven't
> submitted this to git yet), tweaking the callers and whatnot, I was able to
> get the hover effects on Special:ViewPoll to work as intended. While this
> is definitely a step forward, the actual problem with pages in the Poll:
> namespace still persists.
>
> PollNY has two JS files, LightBox.js and Poll.js. LightBox.js contains a
> lightbox implementation and technically it's not needed for stuff like the
> tag etc. and it should only be loaded on Poll: pages. Poll.js,
> on the other hand, is basically needed everywhere where there is PollNY;
> special pages, pages that embed a poll via the tag, Poll:
> pages...
>
> Now, the actual issue is that no matter what I do, I get a "TypeError:
> 'LightBox' is not defined" on Poll: pages (such as [4]). In the git master
> version, this is due to the aforementioned race condition: line 466 of
> Poll.js tries to use mw.loader.load() to load the LightBox RL module if
> it's not already loaded, but in RL's production mode this fails, because,
> as I've been told by those with more intimate knowledge of ResourceLoader
> and its inner workings, mw.loader.load is asynchronous. I've tried
> mw.loader.using, but it doesn't seem to do anything as far as fixing the
> issue goes.
>
> Please let me know if you're able to help me out with this; I've ran out of
> ideas.
>
> [1] http://social-tools.wmflabs.org/
> [2] https://www.mediawiki.org/wiki/Social_tools
> [3] http://social-tools.wmflabs.org/wiki/Special:ViewPoll
> [4] http://social-tools.wmflabs.org/wiki/Poll:How_is_the_weather_today%3F
>
>
> Thanks and regards,
> --
> Jack Phoenix
> MediaWiki developer
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fixing PollNY -- ResourceLoader woes
On 2014-09-16 3:00 PM, Jack Phoenix wrote:
> Hi all,
>
> Now, the actual issue is that no matter what I do, I get a "TypeError:
> 'LightBox' is not defined" on Poll: pages (such as [4]). In the git master
> version, this is due to the aforementioned race condition: line 466 of
> Poll.js tries to use mw.loader.load() to load the LightBox RL module if
> it's not already loaded, but in RL's production mode this fails, because,
> as I've been told by those with more intimate knowledge of ResourceLoader
> and its inner workings, mw.loader.load is asynchronous. I've tried
> mw.loader.using, but it doesn't seem to do anything as far as fixing the
> issue goes.
Loading a script that's not in the page is inherently going to be an
async thing. You're going to have to write your code to work async.
When you use mw.loader.using to load something in a script always use
the callback to wait till the script is actually loaded. It can safely
be called when something is already in the page, so just drop the
`typeof LightBox == undefined` (this is the wrong way to write a typeof
anyways) and do anything with the lightbox in the callback.
mw.loader.using( 'ext.pollNY.lightBox', function() {
LightBox.init();
} );
((Any other code using LightBox.* should probably do the same thing,
athough mw.loader.using is using jQuery's "promises" (I really want to
call this something else, since jQuery doesn't implement proper
promises) incorrectly so I'm not sure how well that will work))
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Status of collation config updates?
I cornered Sean Pringle in a dark alley and had him explain it. To summarize, there have been slave issues when UCA collation was being deployed on fr.wp and thus more deployments were held off just in case. However, wikis that are not in large.dblist should be good to go at any time. Wikis that are in large.dblist should have somebody monitoring the job with a kill stick and DBA tools ready, but are probably also good to go thanks to Aaron's patch https://gerrit.wikimedia.org/r/#/c/151027/. I'm going to try cornering some more people in near future to get this unstuck. :D -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Update: Standardizing icons across projects
Several front end engineers, designers, and others got together again to update on their progress to standardize icons across projects today. This was a follow to the previous conversation on 8/27 [1]. Big take aways: * Monte iterating and almost completing his SVG->Font python scripts * Trevor & Bartosz finalizing an npm module for customizing SVG generation * Jon needing additional support from Sam to move forward on mw ui icon markup Notes from the discussion can be found on etherpad [2] Follow up items: * Finish up SVG2FONT2SVG script (hopefully done in a week) (Monte) ** Create manifest for padding and other small options (Trevor) * Review Trevor's SVG/PNG generation (Everyone present once its out) * Followup with Sam for standard icon html mark-up (Matt) * Schedule team discussion follow up (Tomasz) Please update as necessary if you attended and I've forgotten or misrepresented anything. thanks all --tomasz [1] - https://lists.wikimedia.org/pipermail/mobile-l/2014-August/007922.html [2] - http://etherpad.wikimedia.org/p/IconStandardization ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Dynamically generating files from Scribunto
I'm interested in adding the ability to generate files via Scribunto. The
first major decision that we need to make is how we'd use these files from
a wiki page. I talked with TimStarling and Carmela on IRC about this, and
here's some of the ideas we came up with:
1. [[File:Module:Foo|bar=baz|width=200px]] - Module:Foo gets called to
generate the file
2. [[DynamicFile:Foo|bar=baz|width=200px]] - Module:DynamicFile/Foo gets
called to generate the file
3. [[File:Any file that doesn't exist.svg|bar=baz|width=200px]] -
Module:FileHandlers/Any file that doesn't exist.svg gets called to generate
the file
4. {{#invokefile:Foo|main|bar=baz}} Module:Foo's main function gets called
to generate the file
5. No use directly from wikitext. A Lua function mw.makeFile() would take
file content as a parameter and emit (stripped) HTML to display it.
Advantages:
1. Works everywhere that normal files work without any modifications.
2. As #1, but not quite everywhere. No clashes with existing files.
3. Works everywhere, and no clashes.
4. Consistency with {{#invoke:}} and doesn't cause confusion with "real"
files.
5. Simple.
Disadvantages:
1. Clashes with existing files already named File:Module:Foo.
2. Adding a second namespace that works like File is pretty much impossible.
3. Can't think of any right now.
4. Incompatible with things that expect filenames, which is a lot of
on-wiki templates, and things like Extension:ImageMap
5. Wikis would probably build a wrapper module around it, making it
equivalent to #4
At the moment, I'm leaning towards option 3.
Are there any other thoughts on these, or any additional ideas?
Jackmcbarn
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
