Re: [Wikitech-l] Please help a patch not to become two years old

[Andre Klapper]

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

[Ricordisamoa]

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] Stalled task: page status indicator sorting

[Erwin Dokter]

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] Stalled task: page status indicator sorting

[Ricordisamoa]

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

Re: [Wikitech-l] Please help a patch not to become two years old

[Derk-Jan Hartman]

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 
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

Re: [Wikitech-l] [editing-department] Read the VisualEditor process review

[Dan Garry]

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  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  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 ,
> > product analyst
> > Wikimedia Foundation
> > +1 (202) 656 3457
> >
> > On Sat, Jun 6, 2015 at 3:34 PM, Greg Grossmeier 
> > 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
> > > >  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

[Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

[Andre Klapper]

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] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

[Brad Jorsch (Anomie)]

On Mon, Jun 8, 2015 at 11:13 AM, Andre Klapper 
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

Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

[Legoktm]

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

[Arthur Richards]

x-posting to teampractices list

On Fri, Jun 5, 2015 at 4:56 PM, Neil P. Quinn  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
>  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 ,
> 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] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

[Steinsplitter Wiki]

> 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] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

[Andre Klapper]

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] [Mediawiki-i18n] [Wikimedia-l] ContentTranslation gets to 2000

[Jon Robson]

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 :
>
>> 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
>> > th

Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

[Krinkle]

> On 8 Jun 2015, at 16:13, Andre Klapper  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_activity.cgi?id=1 

and:
https://static-bugzilla.wikimedia.org/bug1.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 


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 
 should not 
become a redirect.


> On 8 Jun 2015, at 17:48, Legoktm  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] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

[Ilya Korniyko]

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 
> To: Wikimedia developers 
> Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation
> mode for action=query will change at the end of this month
> Message-ID:
>  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
>  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
> that 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 l

[Wikitech-l] possible wikitech breakages tomorrow, 20:00 UTC

[Andrew Bogott]

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

[Joel Aufrecht]

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  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
> >  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

Re: [Wikitech-l] Please help a patch not to become two years old

[Brian Wolff]

On 6/8/15, Andre Klapper  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

[Vi to]

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 :

> On 6/8/15, Andre Klapper  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

[Stephen Niedzielski]

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  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 :
>
> > On 6/8/15, Andre Klapper  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] Please help a patch not to become two years old

[Ricordisamoa]

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  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 :


On 6/8/15, Andre Klapper  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

[Wikitech-l] Feedback requested on our search APIs

[Dan Garry]

Do you use our search API? If so, I'd like to hear from you!

The Discovery Department
 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] Feedback requested on our search APIs

[Brian Wolff]

On 6/8/15, Dan Garry  wrote:
> Do you use our search API? If so, I'd like to hear from you!
>
> The Discovery Department
>  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] Feedback requested on our search APIs

[S Page]

On Mon, Jun 8, 2015 at 4:16 PM, Brian Wolff  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] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

[John Mark Vandenberg]

On Tue, Jun 9, 2015 at 6:04 AM, Ilya Korniyko  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

[Brian Wolff]

On 6/8/15, S Page  wrote:
> On Mon, Jun 8, 2015 at 4:16 PM, Brian Wolff  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=query&list=search&srsearch=Black+incategory:Felis_silvestris_catus&srnamespace=6
you could do something like
https://commons.wikimedia.org/w/api.php?action=query&list=search&srincategory=Felis_silvestris_catus&srsearch=Black&srnamespace=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] Feedback requested on our search APIs

[Gergo Tisza]

On Mon, Jun 8, 2015 at 4:16 PM, Brian Wolff  wrote:

> 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).
>

Being able to see a parse tree of the search expression would be nice, like
with the parse/expandtemplates APIs. That would make it easier to find out
whether the search fails because the query is parsed differently from what
you imagined, or because there really is nothing to return.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l