Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla
I'd like to thank John Daniel for all their work creating static-bz! +1 From: aklap...@wikimedia.org To: wikitech-l@lists.wikimedia.org Date: Mon, 8 Jun 2015 17:13:08 +0200 Subject: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla Hi everybody! More than six months ago, Wikimedia migrated its bug report management from Bugzilla to Phabricator. At the same time, Bugzilla was turned read-only (but still allowed users to log in to access and manually migrate votes or saved searches) and moved to the address old-bugzilla.wikimedia.org. Before that migration, users were asked to join Phabricator and were made aware of required steps and limitations [1]. This was done via a banner on top of Bugzilla, emails on wikitech-l@, announcements on en.wp Village Pump, and two emails to all Bugzilla users who had logged in since October 2013 [2]. Now after everybody had more than six months to switch to Phabricator, old-bugzilla.wikimedia.org is planned to get switched off on June 22nd [3] (as keeping Bugzilla running requires maintenance like applying security updates). Thanks to John and Daniel, a static HTML version of old-bugzilla exists at https://static-bugzilla.wikimedia.org [4]. It allows to still access those historical Bugzilla reports and the related history/activity. Please note that you can still claim the activity of your Bugzilla account imported into Phabricator [5] after switching off old-bugzilla, as this functionality does not rely on old-bugzilla being available. I'd like to thank John Daniel for all their work creating static-bz! Cheers, andre [1] https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Missing_data [2] https://phabricator.wikimedia.org/T618 [3] https://phabricator.wikimedia.org/T95184#1327072 [4] https://phabricator.wikimedia.org/T85140 [5] https://www.mediawiki.org/wiki/Phabricator/Help#Claiming_your_previous_Bugzilla_and_RT_accounts -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ 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] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
It would be nice if MediaWiki API _AND_ pywikipedia bot do not deprecate
at once.
Now it looks as
API: we are deprecating what we promised to deprecated long ago - ok
pywikipedia compat: did not handle the deprecation of API before, and are
not going to fix copy-pasted in tens of places (not one place, it's never
that simple) query builders to support rawcontinue, we announce compat as
discontinued together with the old style API.
API deprecation was not coordinated with client library deprecation - not ok
If there is one year gap between two deprecations - ok, bot writers can
choose either compat or core, and their bots can still work.
Most users don't use APi directly so it should be the problem of
coordination between API and clients developers.
--
Message: 1
Date: Wed, 3 Jun 2015 19:08:24 +0300
From: Yuri Astrakhan yastrak...@wikimedia.org
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation
mode for action=query will change at the end of this month
Message-ID:
CALOOOkhzCUf14Tf=
p0uqw7zxamwb9qaxs4kgvbjavssmqy8...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
MZ: I feel that former MediaWiki Web API maintainers should actively pay
attention to which mailing lists they're posting to. ;-) I doubt you
intended to send this message to mediawiki-api-announce.
Mz, I don't think I ever spent much time maintaining it :)) But yes, good
point, reply all is evil at times :)
MZ: re why minimalistic lib - for most apis out there, people tend to write
reference implementation - code that explains to would-be lib authors how
to use API. It sets up prefered usage patterns and guidelines. We never had
that for the api. This resulted in a large number of API libs that vary in
how they use api. Pywikibot is a powerful platform, but is too big for many
usecases (as discussed in Lyon). Hence the need.
SW: Most operator are volunteers and don't have time to change the code
every month because there is a change in the api.
* I might agree about every month, but we are talking about a feature that
has been out for 2 years...
The old one was imho perfectly.
* Most API users imho would laugh at this statement. See the roadmap
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap which
came as a result of analysing numerous bugs wishes filed against the api,
such as returning {} instead of [] for empty values, inconsistencies, the
silly '*' value for text, and many other problems that have accumulated
during the years. API might work for you, but it does not support
multilingual error messaging, it overcomplicates the process of writing
javascript clients, it does not easily cache. In short, lots of problems.
Was the new api coded by WMF or by volunteers?
* I wrote the original API as a volunteer (took about a year in 2005/6). I
recently coded the continuation as a volunteer, and Brad has improved it as
a WMF employee. I later became a full time WMF employee as well, but my
project was Zero, not API. As a volunteer, over 2 years ago I wrote a huge
API
improvement roadmap
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmapthat Brad
picked up and greatly extended, and is driving it forward with the amazing
improvements. From what I know, Brad has now been officially moved into
position of working on the API. In other words, that employee vs volunteer
line is very fuzzy. No point of splitting it that way.
TLDR;
In short, we need to make improvements if we want to move forward in
turning API into a platform, with flexible JavaScript-driven interfaces
such as Visual Editor. To allow creative uses that go beyond AWB, that
support complex interactions, and not just the way for bots to make edits.
Unfortunately, that means that despite our best efforts, very infrequently,
some bots must be updated.
If the bot author cannot add a simple one line change rawcontinue=1 once
in two years because of their busy personal live, I don't think that person
should be making automatic edits to Wikipedia - because sometimes bots make
mistakes that require substantially more time involvement. I would not
trust wikipedia edits to a bot runner under such circumstances. If the bot
runner is not a programmer, they should get the latest version of their
bot. If there is no up-to-date code because noone is maintaining it, it
again should not be accessing wikipedia - we sometimes discover security
bugs that require fixing, or because bot calls wiki too often, or other
changes in content structure - e.g. introduction of WikiData for interwiki
links required all interwiki bots to be updated.
Wikipedia is a living, developing ecosystem, and it does require updates to
all parties accessing it. People accessing wikipedia from the older
browsers discover that they no longer can do
Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla
On Mon, 2015-06-08 at 09:48 -0700, Legoktm wrote: Do we have usage statistics on how many people are still using old-bugzilla? I still use it frequently for searching for example. Only data that I am aware of is https://phabricator.wikimedia.org/T86859#1182758 (And yes, Phabricator's Search can be improved as stated in https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Considerations ) andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla
On 8 Jun 2015, at 16:13, Andre Klapper aklap...@wikimedia.org wrote: Thanks to John and Daniel, a static HTML version of old-bugzilla exists at https://static-bugzilla.wikimedia.org [4]. It allows to still access those historical Bugzilla reports and the related history/activity. I noticed that it serves content in two places now: https://static-bugzilla.wikimedia.org/show_bug.cgi?id=1 https://static-bugzilla.wikimedia.org/show_bug.cgi?id=1 https://static-bugzilla.wikimedia.org/show_activity.cgi?id=1 https://static-bugzilla.wikimedia.org/show_activity.cgi?id=1 and: https://static-bugzilla.wikimedia.org/bug1.html https://static-bugzilla.wikimedia.org/bug1.html https://static-bugzilla.wikimedia.org/activity1.html https://static-bugzilla.wikimedia.org/activity1.html Can these be de-duplicated for search indexing? Either by 301 redirecting, or by using a rel=canonical HTTP Link-headers https://support.google.com/webmasters/answer/139066 https://support.google.com/webmasters/answer/139066 I suggest we consider the show_bug/show_activity urls as canonical to the public. The html files are secondary/internal, no need to expose those directly. https://static-bugzilla.wikimedia.org/show_activity.cgi?id=1 https://static-bugzilla.wikimedia.org/show_activity.cgi?id=1 should not become a redirect. On 8 Jun 2015, at 17:48, Legoktm legoktm.wikipe...@gmail.com wrote: Will old-bugzilla redirect to static-bugzilla? +1 Will bugzilla also redirect to static-bugzilla? E.g. https://bugzilla.wikimedia.org/show_activity.cgi?id=1 https://old-bugzilla.wikimedia.org/show_activity.cgi?id=1 should both 301 redirect to https://static-bugzilla.wikimedia.org/show_activity.cgi?id=1 All other bugzilla endpoints not covered by show_bug/show_activity I assume will become 404. (Seems acceptable). Currently they are 301 redirect to old-bugzilla. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Mediawiki-i18n] [Wikimedia-l] ContentTranslation gets to 2000
On Sat, Jun 6, 2015 at 3:12 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Again, the same problem with the infobox and lead image, but there was a gallery that popped over and I was quite pleased with that. I'm glad to hear, thank you :) I published the article with no categories, because the categories didn't line up this time as they did in the Spanish-Dutch case. Yes - categories adaptation works only if directly corresponding category pages can be found in both languages. We may make it smarter in the not-so-far future. Thinking over my experience, I would prefer you incorporate the Wikidata item info to build the infobox, rather than the source article. Using Wikidata for infoboxes would be ideal, of course. This requires better adaptation of infoboxes to Wikidata, and this must be done by the communities, but some work is being done in that direction. FWIW note that mobile has this (for the time being but we are removing it soon due to lack of traction) ! click on more information on https://en.m.wikipedia.org/wiki/Albert%20Einstein?mobileaction=alpha I was talking on the bug to remove it about creating a web service for this [1]. [1] https://phabricator.wikimedia.org/T100722#1319958 I was working on a painting, but a generic biography infobox has already been done with the PrepBio tool (from Magnus) so you could use that: https://tools.wmflabs.org/magnustools/prepbio.php Thanks, I'll consider it. (We are already using another tool by Magnus in the dashboard, if you haven't noticed ;) ) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2015-06-06 20:28 GMT+03:00 Jane Darnell jane...@gmail.com: Thanks for your thoughtful answerrs, which are certainly enlightening. I tried it again today, this time to translate an article from English to Dutch. Again, the same problem with the infobox and lead image, but there was a gallery that popped over and I was quite pleased with that. I published the article with no categories, because the categories didn't line up this time as they did in the Spanish-Dutch case. Thinking over my experience, I would prefer you incorporate the Wikidata item info to build the infobox, rather than the source article. This would be a good trigger for people to update the Wikidata item should they notice any differences. I was working on a painting, but a generic biography infobox has already been done with the PrepBio tool (from Magnus) so you could use that: https://tools.wmflabs.org/magnustools/prepbio.php On Sat, Jun 6, 2015 at 6:55 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Hi Jane, Thanks for trying ContentTranslation and providing feedback. Replies inline. I decided to translate a short article from Spanish to English Currently the extension is configured for translation *from* English, but not *to* English. This will probably be changed soon to allow translation to English, but there will be a proper separate announcement about this. Then I tried to enable it for my 'Dutch userpage and got the extension up and running for Spanish-Dutch but couldn't find which link was the from link and the to link (a couple of tries and I got the dashboard up and running). The easiest ways to open the dashboard are: 1. Hovering over the Contributions link at the top personal bar and clicking Translations. 2. Opening the article that you want to translate and finding the language into which you want to translate in the interlanguage links list. (It's guessed automatically; for example, it's suposed to appear there if you selected it in ULS.) Then I found myself in the Visual editor It's not *the* VisualEditor, but *a* visual editor - a very simple WYSIWYG editor. (It's possible that in the future it will be *the* VisualEditor, but there's no solid plan for it yet.) There are several reasons for doing it this way, see https://www.mediawiki.org/wiki/Content_translation/Documentation/FAQ . and tried to wikify some text with no luck. It doesn't support wiki syntax, as explained above. It supports simple formatting and adding links (the links support is being rewritten right now to be more stable and intuitive). Because it is not supposed to be a full-fledged article editing environment, it only provides the most basic formatting tools. For full-fledged wikification you can use the wikitext editor or the VisualEditor, whichever you wish. I then clicked on one of the reference links and lost my work. This is definitely a bug! Usually references work pretty well. Sorry about that. Which article was it? I restarted the page and saved some basics, but was disappointed that there was no translation of the infobox or the image, which was what I was hoping for. We don't support infoboxes yet. It's
[Wikitech-l] possible wikitech breakages tomorrow, 20:00 UTC
Tomorrow I'm going to make another attempt at switching us over to a new labs controller host. That won't break anything for running labs instances, but it will probably have some or all of the following effects on wikitech users: 1) Wikitech will go into maintenance mode 2) Wikitech sessions will end and you'll have to re-log in 3) New logins may fail (briefly, if the keystone switch goes poorly) 4) Instance creation/deletion and status queries may fail I'll send an 'all clear' after this switch is finished or abandoned. -Andrew ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [editing-department] Read the VisualEditor process review
Hi Greg, The process improvement effort is not explicitly tied in with quarterly goals. If we come up with specific recommendations that require enough effort to register on a quarterly scale, or that influence the output of the team that much, they could be inputs to goal-setting. Team Practices Group also does the quarterly Team Health Check survey, which is also not part of quarterly goals. I think that process improvement in general is probably better handled separately from goals, to avoid creating any incentives to bias measurement stats, consciously or unconsciously. Joel *Joel Aufrecht* Team Practices Group Wikimedia Foundation On Sat, Jun 6, 2015 at 3:34 PM, Greg Grossmeier g...@wikimedia.org wrote: quote name=Neil P. Quinn date=2015-06-05 time=16:56:07 -0700 Hello everybody! For the past couple months, Joel Aufrecht and I have been working on a project to document and improve the VisualEditor team's processes; we just published a draft of our report https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on mediawiki.org. If you're interested, please read it over and, of course, shout at us on the talk page if we wrote anything stupid. Neil et al, this is great! Thanks for the very informative read, even as someone who works closely with the VE team on a semi-daily basis (at least!). I think it is great that the time and energy was devoted to developing this report. The plan at [0] suggests that this is a one-time process with a conclusion (which is good), thus it isn't tied in, explicitly, with the quarterly goal planning process, correct? Best, Greg [0] https://www.mediawiki.org/wiki/VisualEditor/2015_Team_Process_Review#Plans -- | 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] Feedback requested on our search APIs
Do you use our search API? If so, I'd like to hear from you! The Discovery Department https://wikimediafoundation.org/wiki/Staff_and_contractors#Discovery at the Wikimedia Foundation is tasked with building a path of discovery to relevant and trusted knowledge. In line with that, one of our primary responsibilities is to ensure that our search APIs are stable, fast, and easy to use. We'd love to hear from the people that are using our APIs, so we can learn what you love about them, what frustrates you, and what we can do to improve them for you. I'd prefer that you keep the comments about the API itself rather than the relevance of the results it returns; I plan to start a separate thread about the result relevance, since they're separate topics. If you have some feedback, please reply in this thread or reach out to me privately. Thanks! Dan -- Dan Garry Product Manager, Discovery Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please help a patch not to become two years old
On 6/8/15, Andre Klapper aklap...@wikimedia.org wrote: On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l You won't believe this one weird trick to get your patch reviewed in under 2 years. -- bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please help a patch not to become two years old
There's a weird loophole in devs' brain which will make any dev want to merge your patches NOW! Vito 2015-06-08 23:44 GMT+02:00 Brian Wolff bawo...@gmail.com: On 6/8/15, Andre Klapper aklap...@wikimedia.org wrote: On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l You won't believe this one weird trick to get your patch reviewed in under 2 years. -- 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
Re: [Wikitech-l] Please help a patch not to become two years old
Discover why you should never merge this 10 patches... Il 09/06/2015 00:18, Stephen Niedzielski ha scritto: Devs hate him! and Congratulations! You have been selected to win a free iPatch. On Mon, Jun 8, 2015 at 4:11 PM, Vi to vituzzu.w...@gmail.com wrote: There's a weird loophole in devs' brain which will make any dev want to merge your patches NOW! Vito 2015-06-08 23:44 GMT+02:00 Brian Wolff bawo...@gmail.com: On 6/8/15, Andre Klapper aklap...@wikimedia.org wrote: On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l You won't believe this one weird trick to get your patch reviewed in under 2 years. -- 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 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] Please help a patch not to become two years old
Devs hate him! and Congratulations! You have been selected to win a free iPatch. On Mon, Jun 8, 2015 at 4:11 PM, Vi to vituzzu.w...@gmail.com wrote: There's a weird loophole in devs' brain which will make any dev want to merge your patches NOW! Vito 2015-06-08 23:44 GMT+02:00 Brian Wolff bawo...@gmail.com: On 6/8/15, Andre Klapper aklap...@wikimedia.org wrote: On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l You won't believe this one weird trick to get your patch reviewed in under 2 years. -- 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla
Hi, On 06/08/2015 08:13 AM, Andre Klapper wrote: Now after everybody had more than six months to switch to Phabricator, old-bugzilla.wikimedia.org is planned to get switched off on June 22nd [3] (as keeping Bugzilla running requires maintenance like applying security updates). Do we have usage statistics on how many people are still using old-bugzilla? I still use it frequently for searching for example. Will old-bugzilla redirect to static-bugzilla? -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Read the VisualEditor process review
x-posting to teampractices list On Fri, Jun 5, 2015 at 4:56 PM, Neil P. Quinn nqu...@wikimedia.org wrote: Hello everybody! For the past couple months, Joel Aufrecht and I have been working on a project to document and improve the VisualEditor team's processes; we just published a draft of our report https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on mediawiki.org. If you're interested, please read it over and, of course, shout at us on the talk page if we wrote anything stupid. In addition to the team's significant strengths, we identified three major challenges we'd like to work on: - Consulting stakeholders like Analytics and Design Research often have trouble engaging with VE’s development. - The process for early-stage requirements and design decision-making is informal and incomplete. - The team has a high reporting load which may no longer be justified. Next week, we'll start to expand the report with some proposed solutions (suggestions welcome!) Have a good weekend! — Neil P. Quinn https://meta.wikimedia.org/wiki/User:Neil_P._Quinn-WMF, product analyst Wikimedia Foundation +1 (202) 656 3457 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feedback requested on our search APIs
On Mon, Jun 8, 2015 at 4:16 PM, Brian Wolff bawo...@gmail.com wrote: The search api (by which I mean query=search in api.php) is somewhat poorly documented. You have to dig to find https://www.mediawiki.org/wiki/Help:CirrusSearch . I recently added https://www.mediawiki.org/wiki/API:Search_and_discovery which clarifies the connection with Help:CirrusSearch, and mentions other kinds of searching like geosearch. I would much prefer that the relavent documentation was including in the normal api.php auto-generated help. https://gerrit.wikimedia.org/r/216899 changes the 'apihelp-query+search-param-search message' in https://www.mediawiki.org/wiki/Special:ApiHelp/query+search to *srsearch* Search for page titles and page content that match this value. You can use the search string to invoke special wiki search features, depending on what its search backend implements. But API query search can only use CirrusSearch features if it's installed. I think Extension:CirrusSearch could handle the 'APIGetAllowedParams' hook to modified this help text. If I understand correctly, it might be easier to interpose WMF-specific help text that links to mw:Help:CirrusSearch in a 'wikimedia-apihelp-query+search-param-search' key in extensions/WikimediaMessages/i18n/wikimediaoverrides/en.json ; I tried it locally and it didn't work. Even better would be if that api allowed users to specify the options using normal url parameters, (as a separate options from using operators in the search string). Its also not entirely the most clear from the api that the search options differ depending on which extensions you have installed. What do you mean? Beyone special terms in srsearch I'm not aware of any changes to query+search's sr parameters depending on extensions. Additionally, from the help page, its not entirely clear about some of the limitations. e.g. You can't do incategory:Foo OR intitle:bar. regexes on intitle don't seem to work over the whole title, only word level tokens (I think, maybe? I'm a bit unclear on how the regex operator works). Yes it's not a full reference. -- =S Page WMF Tech writer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feedback requested on our search APIs
On 6/8/15, Dan Garry dga...@wikimedia.org wrote: Do you use our search API? If so, I'd like to hear from you! The Discovery Department https://wikimediafoundation.org/wiki/Staff_and_contractors#Discovery at the Wikimedia Foundation is tasked with building a path of discovery to relevant and trusted knowledge. In line with that, one of our primary responsibilities is to ensure that our search APIs are stable, fast, and easy to use. We'd love to hear from the people that are using our APIs, so we can learn what you love about them, what frustrates you, and what we can do to improve them for you. I'd prefer that you keep the comments about the API itself rather than the relevance of the results it returns; I plan to start a separate thread about the result relevance, since they're separate topics. If you have some feedback, please reply in this thread or reach out to me privately. Thanks! Dan -- Dan Garry Product Manager, Discovery Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l The search api (by which I mean query=search in api.php) is somewhat poorly documented. You have to dig to find https://www.mediawiki.org/wiki/Help:CirrusSearch . I would much prefer that the relavent documentation was including in the normal api.php auto-generated help. Even better would be if that api allowed users to specify the options using normal url parameters, (as a separate options from using operators in the search string). Its also not entirely the most clear from the api that the search options differ depending on which extensions you have installed. Additionally, from the help page, its not entirely clear about some of the limitations. e.g. You can't do incategory:Foo OR intitle:bar. regexes on intitle don't seem to work over the whole title, only word level tokens (I think, maybe? I'm a bit unclear on how the regex operator works). Cheers, Brian ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month
On Tue, Jun 9, 2015 at 6:04 AM, Ilya Korniyko intra...@gmail.com wrote: It would be nice if MediaWiki API _AND_ pywikipedia bot do not deprecate at once. Now it looks as API: we are deprecating what we promised to deprecated long ago - ok pywikipedia compat: did not handle the deprecation of API before, and are not going to fix copy-pasted in tens of places (not one place, it's never that simple) query builders to support rawcontinue, we announce compat as discontinued together with the old style API. API deprecation was not coordinated with client library deprecation - not ok If there is one year gap between two deprecations - ok, bot writers can choose either compat or core, and their bots can still work. Most users don't use APi directly so it should be the problem of coordination between API and clients developers. On the pywikipedia side, it has been unofficially deprecated for a while, and the intention was to decommission compat as gracefully as possible, with Wikimania as the final killing ground. The pywikibot developers roughly hashed out a decommissioning plan at the Lyon hackathon, and worked with WMF staff to start doing impact analysis. https://phabricator.wikimedia.org/T101214 Then the MW API continuation breakage was announced post Lyon. Hmm. The continuation problem in pywikipedia / compat is not so much those 50 or so occurrences where continuation bugs appear to exist, but 1. testing those 50 or so occurrences 2. finding the other less obvious occurrences 3. scripts people have written using compat's query.GetData may also be broken, as it doesnt do continuation. With a lot of wasted effort, 1 2 might be resolved so that 'compat' code works, and someone could create a hack on query.GetData which adds continuation for scripts not yet adapted to do continuation. However the active pywikibot developers (approx. 5 people?) are focused on making core better , including about 10 complex patches under review that improve its query continuation algorithms, and making core more compatible with 'compat' to ease the pain of switching to core. If anyone submits patches for compat continuation bugs affecting them, they will be reviewed (usually by people familiar with compat) with the presumption that the patch author has tested it, and merged if there are no major problems. -- John Vandenberg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feedback requested on our search APIs
On 6/8/15, S Page sp...@wikimedia.org wrote: On Mon, Jun 8, 2015 at 4:16 PM, Brian Wolff bawo...@gmail.com wrote: The search api (by which I mean query=search in api.php) is somewhat poorly documented. You have to dig to find https://www.mediawiki.org/wiki/Help:CirrusSearch . I recently added https://www.mediawiki.org/wiki/API:Search_and_discovery which clarifies the connection with Help:CirrusSearch, and mentions other kinds of searching like geosearch. Last I looked at the docs was about 6 months ago. Glad to hear they're improving. I would much prefer that the relavent documentation was including in the normal api.php auto-generated help. https://gerrit.wikimedia.org/r/216899 changes the 'apihelp-query+search-param-search message' in https://www.mediawiki.org/wiki/Special:ApiHelp/query+search to *srsearch* Search for page titles and page content that match this value. You can use the search string to invoke special wiki search features, depending on what its search backend implements. But API query search can only use CirrusSearch features if it's installed. I think Extension:CirrusSearch could handle the 'APIGetAllowedParams' hook to modified this help text. If I understand correctly, it might be easier to interpose WMF-specific help text that links to mw:Help:CirrusSearch in a 'wikimedia-apihelp-query+search-param-search' key in extensions/WikimediaMessages/i18n/wikimediaoverrides/en.json ; I tried it locally and it didn't work. It shouldn't be WMF specific (since its not WMF specific like TOS links), it should be specific to CirrusSearch. One possible implementation would be to do an override message (I would note, that the wikimediaoverride messages aren't direct overrides, they are replacement messages used by other code that does the overriding). In my original email I was thinking more from a user perspective of what I'd like to see, without thought to how it would be implemented. Without looking at the code, I would probably favour an extra hook just for the search module, instead of using the generic hook. Even better would be if that api allowed users to specify the options using normal url parameters, (as a separate options from using operators in the search string). Its also not entirely the most clear from the api that the search options differ depending on which extensions you have installed. What do you mean? Beyone special terms in srsearch I'm not aware of any changes to query+search's sr parameters depending on extensions. Yeah, that doesn't happen currently. I think it should be the case, it would mesh much better with the mediawiki api if instead of doing https://commons.wikimedia.org/w/api.php?action=querylist=searchsrsearch=Black+incategory:Felis_silvestris_catussrnamespace=6 you could do something like https://commons.wikimedia.org/w/api.php?action=querylist=searchsrincategory=Felis_silvestris_catussrsearch=Blacksrnamespace=6 . Especially if all the parameters were documented in the normal api way, I think it would represent a big boon to discovering the hidden features of search. (I appreciate it might be a lot of work to express all the search options possible, but the original email sounded like it wanted a wishlist). -- bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please help a patch not to become two years old
On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please help a patch not to become two years old
Just for kicks, I revived an almost 2,5 year old patch to add WebP upload support :D https://gerrit.wikimedia.org/r/#/c/95872/ Anyone interested ? DJ On Mon, Jun 8, 2015 at 1:29 PM, Ricordisamoa ricordisa...@openmailbox.org wrote: Il 08/06/2015 12:56, Andre Klapper ha scritto: On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) Thanks for the suggestion! And the two years are over... see you in 2016 :-( ___ 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] Stalled task: page status indicator sorting
I would like some more eyes on https://phabricator.wikimedia.org/T94307. Since its inception, page status indicators have one major drawback; automatic sorting cannot be disabled. It purports to give placements control as it sorts by indicator name, but this proves difficult, as none of the templates invoking idicators allow passing the name. And even then, order is not guaranteed due to the used sorting algorithm. So while in theory, it would make more sense to leave sorting be govenrned by local consensus, we are now stuck with a solution that essentially does not allow any order control at all. I submitted a patch that disables sorting, but the task and patch are stalled. So please, more voices and solutions on how we can solve this. Regards, -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please help a patch not to become two years old
Il 08/06/2015 12:56, Andre Klapper ha scritto: On Sat, 2015-06-06 at 21:40 +0200, Ricordisamoa wrote: https://gerrit.wikimedia.org/r/67588 needs love. Less than 2 days left! Thanks in advance. For future reference, adding basic context (e.g.: Scribunto here) is very welcome if you would also like to reach people who normally do not click links named 50 things that will make you say Oh! or You cannot imagine what will happen at the end of this video. :) Thanks, andre (obviously surprise-averse) Thanks for the suggestion! And the two years are over... see you in 2016 :-( ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Stalled task: page status indicator sorting
Il 08/06/2015 14:08, Erwin Dokter ha scritto: I would like some more eyes on https://phabricator.wikimedia.org/T94307. Since its inception, page status indicators have one major drawback; automatic sorting cannot be disabled. It purports to give placements control as it sorts by indicator name, but this proves difficult, as none of the templates invoking idicators allow passing the name. That depends on local wikis, not indicators. And even then, order is not guaranteed due to the used sorting algorithm. So while in theory, it would make more sense to leave sorting be govenrned by local consensus, we are now stuck with a solution that essentially does not allow any order control at all. I submitted a patch that disables sorting, but the task and patch are stalled. So please, more voices and solutions on how we can solve this. Regards, ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla
Hi everybody! More than six months ago, Wikimedia migrated its bug report management from Bugzilla to Phabricator. At the same time, Bugzilla was turned read-only (but still allowed users to log in to access and manually migrate votes or saved searches) and moved to the address old-bugzilla.wikimedia.org. Before that migration, users were asked to join Phabricator and were made aware of required steps and limitations [1]. This was done via a banner on top of Bugzilla, emails on wikitech-l@, announcements on en.wp Village Pump, and two emails to all Bugzilla users who had logged in since October 2013 [2]. Now after everybody had more than six months to switch to Phabricator, old-bugzilla.wikimedia.org is planned to get switched off on June 22nd [3] (as keeping Bugzilla running requires maintenance like applying security updates). Thanks to John and Daniel, a static HTML version of old-bugzilla exists at https://static-bugzilla.wikimedia.org [4]. It allows to still access those historical Bugzilla reports and the related history/activity. Please note that you can still claim the activity of your Bugzilla account imported into Phabricator [5] after switching off old-bugzilla, as this functionality does not rely on old-bugzilla being available. I'd like to thank John Daniel for all their work creating static-bz! Cheers, andre [1] https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Missing_data [2] https://phabricator.wikimedia.org/T618 [3] https://phabricator.wikimedia.org/T95184#1327072 [4] https://phabricator.wikimedia.org/T85140 [5] https://www.mediawiki.org/wiki/Phabricator/Help#Claiming_your_previous_Bugzilla_and_RT_accounts -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [editing-department] Read the VisualEditor process review
And, as a person that is not involved in the development of VisualEditor in any way but knows many of the VisualEditor Team quite well, I also found this very interesting. Thanks for putting it together! Dan On 6 June 2015 at 21:18, Risker risker...@gmail.com wrote: As a non-technical volunteer, I've drifted in and out of the VE discussion, and have participated at wildly variable levels over the past few years. I found this to be a very interesting and informative read - especially as it came from people new to the entire history. It's good to have fresh eyes on a situation. Thank you for your work on this, it was quite enlightening. Risker/Anne On 7 June 2015 at 00:09, Neil P. Quinn nqu...@wikimedia.org wrote: Hey Greg! Yes, this is meant to be a one-time process. We've been spending a significant proportion of our time on it ever since we joined in mid-April (I'd say about 30% for me, and probably more for Joel)—too much to make it a regular thing. And hopefully, if we manage to address these problems, we won't find them replaced by new ones the very next quarter :) Thanks for the question—it feels great to know that someone is out there reading our child of the mind! — Neil P. Quinn https://meta.wikimedia.org/wiki/User:Neil_P._Quinn-WMF, product analyst Wikimedia Foundation +1 (202) 656 3457 On Sat, Jun 6, 2015 at 3:34 PM, Greg Grossmeier g...@wikimedia.org wrote: quote name=Neil P. Quinn date=2015-06-05 time=16:56:07 -0700 Hello everybody! For the past couple months, Joel Aufrecht and I have been working on a project to document and improve the VisualEditor team's processes; we just published a draft of our report https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on mediawiki.org. If you're interested, please read it over and, of course, shout at us on the talk page if we wrote anything stupid. Neil et al, this is great! Thanks for the very informative read, even as someone who works closely with the VE team on a semi-daily basis (at least!). I think it is great that the time and energy was devoted to developing this report. The plan at [0] suggests that this is a one-time process with a conclusion (which is good), thus it isn't tied in, explicitly, with the quarterly goal planning process, correct? Best, Greg [0] https://www.mediawiki.org/wiki/VisualEditor/2015_Team_Process_Review#Plans -- | 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 -- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla
On Mon, Jun 8, 2015 at 11:13 AM, Andre Klapper aklap...@wikimedia.org wrote: Thanks to John and Daniel, a static HTML version of old-bugzilla exists at https://static-bugzilla.wikimedia.org [4]. It allows to still access those historical Bugzilla reports and the related history/activity. The few times I've really needed to use old-bugzilla were because old attachments weren't always imported to Phab, which I see is https://phabricator.wikimedia.org/T78747. In particular, this might be a problem for restricted-access bugs. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
