Hi all,
James Forrester, Florian, and I met Wednesday, 22-July-2015 to discuss the
Editing roadmap, with the backdrop of editing modes available in mobile web
and apps but both the mobile web and apps teams now being in the Reading
department. Notes:
* FY 2015-2016: active Editing development for apps not planned
* General plan is to replace the current mobile web editing experiences
with new (replacement) VE and wikitext editor maintained by the VE team for
mobile web
* Q1: VE mobile prototyping (doesn't require Reading involvement)
* Q2: Editing for mobile web replacement *coding* starting, but rollout on
mobile web would begin in some future quarter _after_ Q2
* Feature submission practices for volunteers submitting editing related
stuff for the mobile web for the time being (feature submissions
discouraged for now as it will end up being replaced; mainline VisualEditor
/ next gen wikitext editing in collaboration with VE team would probably
make more sense) -
** Create task in reading-web Phabricator board and indicate the details of
what you were thinking to work on and roughly when. Add James Forrester and
Joaquin Hernandez to card.
** Reach out to James_F (Senior Product Manager, VisualEditor) and joakino
(Reading Web engineering product owner and tech lead) on #wikimedia-mobile
on Freenode to discuss the idea and to determine who would need to code
review and test
* Code review for bugfixes for the existing mobile editing code should be
done by Reading Web, and code review plus testing should be done by Editing
as well. Ping joakino and James_F on IRC to figure out who to add to
bugfixes.
* As the Editing team gets into the practice of submitting patches for
MobileFrontend to swap out the editor, as usual, tasks should be filed well
ahead of time in the reading-web Phabricator board so there's a heads up
about potential code review. Also, Editing and Reading should be tracking
Q2 and subsequent quarter planning together to ensure dependencies are
clearly defined and agreed upon.
I also spoke to Roan from Collaboration after the Scrum of Scrums the same
day. Roan indicated that there isn't an emphasis on rolling out Flow to
mobile Wikipedias en masse for FY 2015-2016. And generally, when Flow does
become slated for rollout on the mobile Wikipedias and sister projects in a
broader sense it shouldn't require work - or anything substantial, anyway -
from the Reading team.
-Adam
Hi guys !
I'm working on a website, which find your position using geolocation,
and then show the wikipedia's pages around you on an OSM map. For the
moment it works.
The goal here is to create a full solution dedicated to tourism. For
example a tourist is dropped in a city he doesn't know, and he can have
informations on what's around thanks to Wikipedia and wikidata. But I'd
like to add WikiVoyage informations too.
I know it's possible with Wikidata API to enter a position (longitude
and latitude), a range, and have all Wikipedia pages around. Is it
possible to do the same with WikiVoyage pages ?
Thanks a lot ! :)
Sylvain.
There's a ticket for removing mobile.wikipedia.org and wap.wikipedia.org
domains/subdomains, which are legacy domain names superceded by
m.wikipedia.org and its subdomains.
https://phabricator.wikimedia.org/T104942
The rationale for the removal of these legacy domain names is to help
support HSTS preloading in browsers with the existing TLS SAN cert.
After review of the ticket, can anyone think of a compelling reason to keep
those old domain names?
I'm going to open a separate thread on mobile-l about this given this is
more mobile-targeted, yet some people only operate on one of wikitech-l or
mobile-l.
-Adam
Hello,
I have upgraded Zuul this morning which has a slight regression. To be
considered for merging, Zuul require the change to have a Verified +2.
In most case that is not a problem since the tests ran and voted V+2
already. But there is a few other cases where Verified is 0 or -1.
The workaround is thus to manually vote Verified +2 in addition to
Code-Review +2. You might have to remove the prior CR+2 to have the
change properly recognized.
The task is:
https://phabricator.wikimedia.org/T106531
Will give it a shot tomorrow.
--
Antoine "hashar" Musso
I'm pleased to announce that Brad Jorsch has been promoted to Senior
Software Engineer.
Brad joined the WMF in October of 2012 as a member of the MediaWiki
Core team under RobLa [0]. Prior to joining the WMF, Brad was a strong
contributor in a volunteer capacity both on-wiki and via code
contributions. He has community earned admin rights on enwiki and his
bots (AnomieBOT, AnomieBOT II, MediationBot, MedcabBot, ...) have made
over 1.8 million edits on project wikis [1]. His community
contributions led directly to his recruitment and hiring following the
2012 Berlin Hackathon.
During his tenure at the WMF, Brad has become the de-facto owner of
the Scribunto extension and the primary maintainer of the MediaWiki
web API (api.php). During the 2014-2015 fiscal year, Brad has focused
primarily on the MediaWiki web API (api.php). This largely solo
project has included writing an RfC [2] and working on implementation
not only in MediaWiki core but also across many affected extensions.
Recent improvements have included JSON format updates [3] and the
simplification of continuation mode processing for clients [4].
I look forward to working with Brad on the Wikimedia Reading
Infrastructure team to continue stewardship of the MediaWiki web API
[5] and expect to see continued excellence from his MediaWiki and
Wikimedia contributions.
[0]: https://lists.wikimedia.org/pipermail/wikitech-l/2012-October/064120.html
[1]: https://tools.wmflabs.org/guc/?user=AnomieBOT
[2]: https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap
[3]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-May/00008…
[4]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-June/0000…
[5]: https://lists.wikimedia.org/pipermail/wikitech-l/2015-May/081648.html
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Hi,
I'd like to add my extension
https://github.com/DanweDE/mediawiki-ext-UserBitcoinAddresses
as "mediawiki/user-bitcoin-addresses" in packagist.
When trying to do so, packagist states I should ask someone with the proper
rights to maintain the "mediawiki" vendor.
I have read up on
https://www.mediawiki.org/wiki/Manual:Developing_libraries#Packagist_guidel…
And I wrote two of the guys listed to have access to the "mediawiki" vendor
account but I am not sure I am getting a reply so I thought I'd also try it
through this channel.
Any advice how I'd get my GitHub repo on packagist under the "mediawiki"
vendor would be highly appreciated.
Cheers,
Daniel
According to our docs/internal checks, our min php version is 5.3.3.
However as of 6e283d394f31, MediaWiki doesn't work with php 5.3.3 (You
aren't allowed to implement an interface using an abstract method, on
that version of PHP so you get "Fatal error: Can't inherit abstract
function IDatabase::getType() (previously declared abstract in
DatabaseBase) in git/includes/db/Database.php on line 32").
Is it time we up'd our version requirements (And does anyone know if
that would affect lots of third parties?) Or should that change be
reverted?
--bawolff