On Tuesday, September 16, 2014, Jon Robson <jdlrobson(a)gmail.com> wrote:
>
> In the past when I've needed changes merged in this codebase I've had
> to actively search out people who feel comfortable reviewing it and
> +2ing it.
(snip)
> I personally think the idea of a code maintainer is outdated,
Then let's call them 'people who feel comfortable reviewing and +2ing'
patches in a repository. :) Or first points of contact that can help you
adding reviewers. Knowing who might be good reviewers for a patch is not
simple even for those developers working full time at the Foundation.
Imagine the situation of the rest of contributors.
> we should all be maintaining the code in the MediaWiki world.
Nice thought, but still not helpful for someone like Florian wondering who
should review his patch.
Looking at https://www.mediawiki.org/wiki/Developers/Maintainers and
looking at http://phabricator.wikimedia.org/T340 (
Start the process of expanding the arch committee), one idea could be to
organize all those components in areas, nominating "meta-maintainers" for
each area. This way, if a specific component doesn't have any maintainers
assigned, at least someone like Florian could check with the related
meta-maintainer.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
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
I can't access those links!
On Tue, Sep 16, 2014 at 11:14 AM, Daniel Kinzler <
daniel.kinzler(a)wikimedia.de> wrote:
> Hi all!
>
> The Wikibase team would like to allow data from any item to be used on any
> client page. To do this, we need to track which item is being used where,
> so we
> can purge the appropriate pages when the item changes. We would like to
> have
> people with database experience to look at our proposal and let us know
> about
> any concerns, especially wrt performance.
>
> Here you find a proposal for two database tables for tracking the usage of
> entities across wikis:
>
>
> https://gerrit.wikimedia.org/r/#/c/158078/9/usagetracking/includes/Usage/Sq…
>
>
> https://gerrit.wikimedia.org/r/#/c/158078/9/subscription/includes/Subscript…
>
>
> The "entity_usage" table would be on every client, recording wich entity
> is used
> on which page (kind of like the iwlinks table). The "entity_per_client"
> table
> would be on the repo, and track which wiki ("client") is interested in
> changes
> to which entity.
>
> Please have a look and let me know if you have any questions or
> suggestions,
> especially with regards to the following use cases:
>
> The following would happpen when editing/re-parsing a page on a client wiki
> (e.g. wikipedia):
> * get all entities used on a given page from entity_usage
> * delete rows based on a page id and a list of entity ids from entity_usage
> * insert rows for a page / entity pair into entity_usage
> * queriy rows for a set of entities from entity_usage (with no page id
> specified).
> * add rows for a set of (newly used) entites to the entity_per_client table
> * remove rows for a set of (no longer used) entites from the
> entity_per_client table
>
> The following would happen when dispatching a change from wikibase:
> * looking up interested wikis for a list of entities from the
> entity_per_client
> table.
> * (notification via the job queue)
> * looking up pages to be purged/updated based on a list of entity ids (and
> possibly an aspect id) in the entity_usage table.
>
> -- daniel
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
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
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ő
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/Quarter…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> 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_r…
>
> 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
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Hello together!
I have a short question: There is a changeset in gerrit[1] for ConfirmEdit,
which enables to show a Captcha directly after the Edit click, instead of
a first Save click (see Commit Msg and the Bug report[2] for more
details). This change was uploaded on May 30, 2014, unhappily without any
review until now. The list of maintainers for Wikimedia extensions [3] lists
only Emufarmers as a maintainer. Unhappily he/she only maintains the
FancyCaptcha module of ConfirmEdit (iirc the irc talk). So, my question: Ist
here anyone who maintains the core part of ConfirmEdit? Is there anyone who
can/want give the change a review?
Thanks in advance!
[1] https://gerrit.wikimedia.org/r/136323
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=19648
[3] https://www.mediawiki.org/wiki/Developers/Maintainers
Freundliche Grüße / Kind regards
Florian
Dear Wikitech-l Readers,
spreading open knowledge is not just about content, but also about tools. That's the reason we provide MediaWiki as an open source product. Fortunately, MediaWiki is used widely outside the Wikimedia world, so the mission is fulfilled, right? Well, not quite... Third party users of MediaWiki do have very specific needs that are naturally not in the primary focus when running Wikimedia sites.
Over the past few weeks, a group of people has been working on a proposal for a User Group that tackles exactly these issues: "We will advocate the needs of all users of MediaWiki. Our primary focus will be those who use MediaWiki outside the Wikimedia Foundation (WMF). We are a group of MediaWiki enthusiasts who care about the development and evolution of the MediaWiki as a tool for everyone." [1]
We have gathered quite a number of supporters and members. There were some meetings where we discussed the mission of this group and its purpose. Now we are ready to take the next step and apply for official recognition. Before we actually start, we are seeking your feedback. Any comments are welcome, here on the list and on the discussion page of the group [2].
Cheers,
Markus (mglaser) and Mark (hexmode)
[1] https://www.mediawiki.org/wiki/Groups/Proposals/MediaWiki_Cooperation
[2] https://www.mediawiki.org/wiki/Talk:Groups/Proposals/MediaWiki_Cooperation
Greetings All,
I'm very happy to welcome Jeff Hobson to the Wikimedia Foundation and
the Wikipedia Zero Engineering team. He'll be joining Yuri, Adam, and
Dan Foy to continue the great work that the Zero team has been working
on and focusing on building our carrier portal first. Today will be
his first day.
Jeff will be working remotely from Blacksburg, VA, but hopes to
eventually venture out to the west coast to join us locally. Jeff has
been building websites for over 12 of his 22 years and practically
weeped tears of joy when HTML5 was first released. Aside from web
development, he's dabbled in Parallel Computing, AI, and even some
robotics. But the ever-changing nature of web development has kept him
coming back and he's excited to join WMF to work with all the
challenges mobile brings. In his free time Jeff enjoys skiing, riding
roller coasters, speed running, and playing the drums.
Please join me in welcoming Jeff
--tomasz