Re: [Wikitech-l] Read access to patrolled flag in wikimedia API

[Max Semenik]

I don't think it's possible to filter by flagged status, however you can
combine this information with recent changes:
https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:ApiSandbox#action=query=json=flagged=recentchanges=2

On Wed, Mar 13, 2019 at 8:52 AM Сибирев Кирилл 
wrote:

> Hi, i can't find information about filtering pending changes through api,
> can someone
> help with my previous questions?
>
> 06.03.2019, 13:32, "Сибирев Кирилл" :
> > 05.03.2019, 19:33, "bawolff" :
> >>  Are you sure that patrol status is shown as colour coding on history
> pages?
> >>  I'm pretty sure its not.
> >>
> >>  If you mean kind of the dim yellow colour (like in
> >>
> https://en.wikipedia.org/w/index.php?title=List_of_programs_broadcast_by_Adult_Swim=history
> >>  for the moment, but that will likely change soon), that means a pending
> >>  change, which is a different system from patrolling.
> >>
> >>  Note, on enwikipedia (but not other projects) RC patrolling is
> disabled,
> >>  and only new page patrol is enabled (so only the first revision can
> have a
> >>  patrol status).
> >
> > Thanks for the answer, i'm little bit confused by naming here, i guess.
> > Mostly we use ru.wikipedia.org, where a lot of pages have blue/yellow
> markup
> > and legend for blue can be translated as "patrolled version", and yellow
> is "unverified version"
> > (here screenshot of what i am talking about
> https://yadi.sk/i/A0FRG6yz86ECdg)
> >
> > So, if i did understand you correctly, blue/yellow markup is about
> pending changes
> > (https://en.wikipedia.org/wiki/Wikipedia:Pending_changes) and not
> patrolling
> > (https://www.mediawiki.org/wiki/Help:Patrolling), am i right?
> >
> > Basically we want to get from api same data which users see on wikipedia
> article page
> > and as far as i understand yellow changes are not visible until approved.
> > Can you send me some page about comparing pending and patrolling,
> because for now
> > i can't understand if the two system can be applied to one page and what
> happens
> > if revision is patrolled (does it become approved and not pending after
> that)?
> >
> > If pending system is responsible for revision visibility on article page
> then it is
> > not matter to us what patrolling does, i guess.
> > But in that case we need to get pending property of revision from API,
> is it accessible?
> >
> >>  --
> >>  Brian
> >>
> >>  On Tue, Mar 5, 2019 at 4:13 PM Сибирев Кирилл 
> >>  wrote:
> >>
> >>>   Hi, we are using wikimedia http api for getting pages recent changes
> [1].
> >>>   We'd like to be able to distinguish patrolled and unpatrolled
> revisions and
> >>>   this feature is supported according to docs, but we still can't use
> it
> >>>   because of access permissions. For example if i making requests like
> [2] or
> >>>   [3] i am getting {"code": "permissiondenied", "info": "You need the
> >>>   \"patrol\" or \"patrolmarks\" right to request the patrolled flag."}
> error.
> >>>
> >>>   This API behaviour looks inconsistent to me, because anyone can see
> >>>   patrolled/unpatrolled colored markup at wikipedia revision history
> web
> >>>   pages. I think patrol right should be checked only at write (ones
> that mark
> >>>   revisions patrolled or not) API requests and not for read requests.
> >>>
> >>>   Is this behaviour really inconsistent and implemented that way due to
> >>>   technical restrictions or am i missing something? Can it be changed,
> so we
> >>>   can get patrolling information for revisions or maybe there are some
> >>>   workarounds exist?
> >>>
> >>>   [1] https://www.mediawiki.org/wiki/API:RecentChanges
> >>>   [2]
> >>>
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title|patrolled=3
> >>>   [3]
> >>>
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title=patrolled=3
> >>>
> >>>   ___
> >>>   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



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community-Engineering gaps as defined in configuration

[Pine W]

I believe that I've seen discussions of RC patrolling on ENWP too, although
I can't recall specifics. I am not familiar with the original discussion,
although my first guess is that the experienced patrollers were surprised
and that the surprise factored into their opposition to the change.

Starting an RfC regarding this would require some effort, but if other
communities are finding that the tool is useful, then I'll +1 the hope that
ENWP reconsiders this. Similar to Amir's comment, I'm thinking that having
participation in the discussion from someone like a WMF Community Relations
person or someone who could offer training might be useful so that people
can familiarize themselves with the option before making a decision. I
haven't used the tool myself, but in general I prefer that people have
"informed consent".

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Tue, Mar 12, 2019 at 5:00 PM James Forrester 
wrote:

> On Sat, 9 Mar 2019 at 11:50, bawolff  wrote:
>
> > In regards to wgUseRCPatrol - I suspect (but don't know) that originally
> > that was disabled on enwiki as a performance thing. If it was a
> performance
> > concern, that's probably irrelevant at this point.
> >
>
> Sadly, no. It was enabled as a new feature to help communities do their
> patrolling work. A small handful on enwiki power users complained in the
> hours after it was deployed about the "disruption" (the appearance of a !
> on edits in Recent Changes), and rather than help the community adjust to
> the new software and find it useful, the feature was disabled, effectively
> permanently. In the subsequent years, many English Wikipedians have
> complained about the lack of support for their work on Recent Changes
> patrolling, but there's been no effort to struggle through the community
> arguments to (re-)enable this tool, I believe.
>
> It would be lovely if we could enable this feature on the English Wikipedia
> given how useful many other communities have found this, but I don't expect
> it to happen.
>
> J.
> --
> *James D. Forrester* (he/him  or they/themself
> )
> Wikimedia Foundation 
> ___
> 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] Question to WMF: Backlog on bugs

[Pine W]

Hopefully I can say this in a way that is mutually acceptable.

For me this discussion is difficult but enlightening. I think that this is
the most difficult Wikimedia discussion in which I have been a participant
so far this year. I don't know what agreements will emerge from this
thread, if any. But the enlightenment is useful, and I hope that other
people also feel that they are learning something new or are being heard on
issues that are important to them.

I am thinking that ideally we would all be in a room together to have this
discussion. Perhaps a second best choice would be an online meeting
regarding the subject of technical debt. We could schedule a meeting via
Doodle. It's okay if people don't want to participate, but I'd like to
suggest an online meeting as an option.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Gergo Tisza]

On Wed, Mar 13, 2019 at 5:33 PM Tim Starling 
wrote:

> File a task in Phabricator under the Gerrit-Privilege-Requests
> project, recommending that the person be given access, giving your
> reasons and mentioning that you are the maintainer of the project in
> question. Wait for at least a week for comments. Then a Gerrit
> administrator should add the person and close the task.
>

Does the policy apply to Toolforge tools at all? The current text says "For
extensions (and other projects) not deployed to the Wikimedia cluster, the
code review policy is up to the maintainer or author of the extension." I'd
assume that by extension managing +2 permissions is also up to them
(although this is not explicitly stated, might be worth clarifying).
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Tim Starling]

File a task in Phabricator under the Gerrit-Privilege-Requests
project, recommending that the person be given access, giving your
reasons and mentioning that you are the maintainer of the project in
question. Wait for at least a week for comments. Then a Gerrit
administrator should add the person and close the task.

-- Tim Starling

On 13/3/19 11:18 pm, Zppix wrote:
> Hello,
> So what is the process for adding people to +2 on gerrit repos im the primary 
> maintainer of (for example my ZppixBot toolforge gerrit repo)
> 
> --
> Devin “Zppix” CCENT
> Volunteer Wikimedia Developer
> Africa Wikimedia Developers Member and Mentor
> Volunteer Mozilla Support Team Member (SUMO)
> Quora.com Partner Program Member
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters. I 
> also do not work for Mozilla, or any of its projects. ** 
> 
>> On Mar 13, 2019, at 12:40 AM, Physikerwelt  wrote:
>>
>>> On Wed, Mar 13, 2019 at 5:25 AM Tim Starling  
>>> wrote:
>>>
>>> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
>>> moved the new Gerrit privilege policy page out of my userspace to
>>>
>>> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>>>
>>> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
>>> ownership]], with some additional changes. I've now redirected both of
>>> those pages to the new policy page.
>>>
>>> The main changes are:
>>>
>>> * The wmde LDAP group, representing WMDE staff members, will be given
>>> +2 access to mediawiki/* projects, similar to the rights given to WMF
>>> staff members.
>>
>> Great. This is the first step towards a global movement;-)
>>
>>>
>>> * The ability of ShoutWiki and Hallo Welt! to manage access to the
>>> extensions they maintain is described and formalised.
>>>
>>> * The ownership model for extensions is discouraged in favour of
>>> individual requests on Phabricator. An extension owner was able to
>>> promote developers to +2 access at their own discretion.
>>
>> I think this does not harm too much since many people use Microsofts
>> GitHub to maintain their non-WMF deployed extensions these days.
>>
>>
>> Physikerwelt
>>
>>>
>>> * The Phabricator projects for requesting access have changed. I'm in
>>> the process of moving the tickets over.
>>>
>>> * The revocation policy has been expanded, better describing the
>>> present situation and making several minor changes.
>>>
>>> -- Tim Starling
>>>
>>>
>>> ___
>>> 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] 2019-03-13 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-03-13

=*2019-03-13*=

== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* Maps incident with geoshapes service:
https://wikitech.wikimedia.org/wiki/Incident_documentation/20190308-maps
* (From RI) RelEng: Review needed for deploying
Extension:WikimediaEditorTasks to production (
https://phabricator.wikimedia.org/T218136 )

== Audiences ==

=== Contributors ===
 Community Tech 
* Blocked by:
* Blocking:
* Updates:
**

 Anti-Harassment Tools 
* Blocked by:
* Blocking:
* Updates:
**

 Editing 
* Blocked by:
* Blocking:
** Updates:
**

 Growth 
* Blocked by:
* Blocking:
* Updates:
**

 Language 
* Blocked by: Several CI failures but RelEng is taking care of them. Thanks!
* Blocking:
* Updates:
** Fixed various bugs in cxserver while ContentTranslation patches were
blocked due to CI issues.
** Manually purging old unpublished drafts from ContentTranslation. This
will likely to move to cronjob in 2 weeks.

=== Readers ===
 iOS native app 
* Blocked by:
* Blocking:
* Updates:
**Working on 6.2.1 (
https://phabricator.wikimedia.org/tag/ios-app-v6.2.1-beluga-on-stilts/)
***bug fixes
***editing enhancements

 Android native app 
* Blocked by:
* Blocking:
* Updates:
** Working on the design changes of enhancing reading lists search
functions.
*** Bug fixes
*** Visual changes of "Suggested edits"

 Readers Web 
* Blocked by:
* Blocking:
* Updates:
** Summary: adding some features to QuickSurveys, tagging and UI changes
for Advanced Mobile Contributions, and continuing the MobileFrontend
Architecture investment project.

** Responsive website (MinervaNeue / MobileFrontend):

*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
 Add history link to actions menu T213352
 Tag Thanks actions with AMC tag T215477
 Provide mechanism to allow dynamically tag log entries T215675
 Add X-Analytics tag for AMC webrequests T212961
 Cannot access user contributions when following red link to user page
on mobile T201339

*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture
Use the Overlay.make pattern for notification feature T217296
 Refactor ImageOverlay T216198
 Refactor TalkSectionAddOverlay T217102
 Limit mobile.startup's mw.config variables T216848

*** QuickSurveys
 Consultation with Research
 Support sampling by country T213847
 Support sampling by edits T139317
 Remove templates T208605
 Revise deprecated ResourceLoader API usage T216746

*** Miscellaneous bug fixes and maintenance T218098 T207618 T217820

** Desktop website (Popups)

*** Popups https://www.mediawiki.org/wiki/Page_Previews
 WMDE reference previews review and support T67114
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews
 Bugfix for double pokey on some page previews T204627

 Readers Infrastructure 
* Blocked by:
** SRE: Sunsetting Wikipedia Zero stuff (
https://phabricator.wikimedia.org/T187716) is still blocked by
https://phabricator.wikimedia.org/T213769 (and possibly others); not
urgent, but we want this done this quarter if possible. (Repeat from
previous weeks)
** RelEng: Review needed for deploying Extension:WikimediaEditorTasks to
production (https://phabricator.wikimedia.org/T218136 )
* Blocking:
* Updates:
** mobile-html:
*** Changing URLs from https to be protocol independent because the iOS app
can handle that better when saving for offline.
*** Removing navboxes from mobile-html DOM
** Maps: incident with the geoshapes service
https://wikitech.wikimedia.org/wiki/Incident_documentation/20190308-maps

 Multimedia 
* Blocked by:
* Blocking:
* Updates
**

 Parsing 
* Blocked by:
* Blocking:
* Updates:
** Working on fast and spec-compliant HTML5 parsing and filtering
(querySelector) in PHP. If you are aware of code that could benefit from
this (probably anything that uses DOMDocument and related classes), please
add it to https://phabricator.wikimedia.org/T218183

 UI Standardization 
* Blocked by:
* Blocking:
* Updates:
** OOUI release in prep, we decide if minor or patch release, depending on
ongoing work by Multimedia team and Ed:
*** Bring StackLayout, MenuLayout, Tab*Layout, IndexLayout to OOUI PHP
https://phabricator.wikimedia.org/T215645
*** Quicken PHP tests
*** Make mixin configs extendable
** Unify error and system messages https://phabricator.wikimedia.org/T127405

== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** db1002 is now decommissioned, so we consider the migration of the
analytics mysql replicas from the old to the new hosts complete
** the EventLogging database in Hive is now in compliance with the data
retention guidelines
** medium refactor in 

[Wikitech-l] Call for maintainers: Configure extension

[Max Semenik]

This extension has been out of date with MediaWiki for years. A ticket[1]
was opened a while ago to archive it, and someone archived the extension's
page[2] on mediawiki.org. Is there anyone interested in maintaining it, or
we can officially call it dead?


[1] https://phabricator.wikimedia.org/T185227
[2] https://www.mediawiki.org/wiki/Extension:Configure

-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Amir Sarabadani]

On Wed, Mar 13, 2019 at 11:02 PM Strainu  wrote:

> - ContentTranslation v1 (obsolete now, has been unmaintained for 2
> years while in production)
> - UploadWizard (2 with high priority, 40 with normal, a few dozens
> low, hundreds more untriaged): this is the project that got us out of
> the "overloading the lang parameter for customizing the uploader" era,
> the project that is used by millions of people every year, including
> during every photo contest
>
There's something called code stewardship [0] and there is a process called
code stewardship review for projects that are under-, un- or unclear
maintained [1] which basically a piece of code either gets undeployed from
WMF infra or we find maintainer(s) to fix the bugs. You can find the list
of current and past reviews in [2].

If you think a project doesn't have enough maintainer, you can start the
review process. If there's an active maintainer [3] but they are not fixing
bugs, most importantly critical bugs, you can raise the issue probably here
but with **concrete examples.**

[0]: https://www.mediawiki.org/wiki/Code_Stewardship
[1]: https://www.mediawiki.org/wiki/Code_stewardship_reviews
[2]: https://phabricator.wikimedia.org/project/board/3144/query/all/
[3]: https://www.mediawiki.org/wiki/Developers/Maintainers
-- 
Amir
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Andre Klapper]

On Wed, 2019-03-13 at 21:01 +0100, John Erling Blad wrote:
> This is like an enormous sinkhole, with people standing on the edge,
> warning about the sinkhole. All around people are saying "we must do
> something"! Still the sinkhole slowly grows larger and larger. People
> placing warning signs "Sinkhole ahead". Others notifying neighbors
> about the growing sinkhole. But nobody does anything about the
> sinkhole itself.

And repeating the same thing over and over again while repeatedly
ignoring requests to be more specific won't help either...

andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Strainu]

Wow, this thread has become quite huge (which is a good problem to
have!). Trying to repond to a few messages in a single email.

În dum., 10 mar. 2019 la 01:23, Dan Garry (Deskana)  a scris:
> I'm confused by this. I didn't mention volunteer teams taking over projects
> at all, and I don't think that'd work except in very rare and limited
> circumstances. I was talking about people helping with bug triage on
> Phabricator.

Got it. Glad we agree that project maintenance is the responsibility
of the WMF. :)
Bug triage (and even solving) is a great way of implicating volunteer
developers, the problem is what do you do with bugs on projects where
there are no volunteers. My take is that the paid teams that have
ownership of those products should offer a certain degree of
maintenance at least to widely deployed extensions (i.e. on all
versions of a project). The (negative) example I like to give is
Content Translation, were all bugfixes on v1 were stopped until v2 was
developed, process that was delayed by at least a year if not 2
compared to initial estimates. During this time tech ambassadors were
simply left with the task of explaining to users what they can do to
save their work (hint: nothing). That just shouldn't happen.

> > The projects belong to the community at large, not just the technical
> > subcommunity. They are the ones affected by the  bugs and also they are the
> > ones that need our support. So why should they be ignored in taking this
> > decision?
> >
>
> I'm confused by this too. I wasn't talking about ownership of the Wikimedia
> projects, I was again talking about the bug backlog, which anyone is
> welcome to get involved in simply by registering an account.

Me too. Prioritization should involve (as much as possible, and
certainly more than now) people reporting bugs, regardless of their
ability to provide a patch for the bug they file. If we can go further
into the communities, even better.

>
>
> > My proposal is to begin the discussion here: how can we better relay issues
> > that areSee above - "anyone is welcome" is not enough. more important to 
> > communities than new features? How can we have a
> > "community whishlist for bugs"?
> >
>
> The community wishlist explicitly accepts requests to fix bugs, as well
> requests for new features. So, is what you're asking for some process to
> supplement that?

A totally new process is not needed nor desirable. Improvements could
be easily done that would improve the overall results.

The main problem I see with the community wishlist is that it's a
process beside the normal process, not part of it. The dedicated team
takes 10 bugs and other developers another ~10. I think we would be
much better off if each team at the WMF would also take the top ranked
bug on their turf and solve it and bump the priority of all the other
bugs by one (e.g. low->medium). One bug per year per team means at
least 18 bugs (at least if [1] is up to date) or something similar.

As a side note, even this process has degraded over time: check out
how empty is the list for 2017 [2] compared to 2016. [3]

[1] https://meta.wikimedia.org/wiki/Template:Wikimedia_Foundation_departments
[2] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Results
[3] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2016/Results

În dum., 10 mar. 2019 la 07:42, Victoria Stavridou-Coleman
 a scris:
>
> Re reading this now on the ground in Austin, reminds me not to send emails in 
> a hurry from an airplane! So trying again - hopefully more grammatically 
> sound this time!
>
> The Tech Engagement team (which includes Wikimedia Cloud Services) in the 
> Tech department is investing in a developer advocacy team who I hope will 
> (amongst other things) speak on behalf of the communities that are affected 
> by tech debt.

That should help, as long as they speak within the normal development
process and not in parallel. Looking forward to seeing the official
announcement.

În dum., 10 mar. 2019 la 02:28, bawolff  a scris:
>
> Regarding:
> >My proposal is to begin the discussion here: how can we better relay issues
> >that are more important to communities than new features? How can we have a
> >"community whishlist for bugs"?
>
> Well fundamentally it starts with making a list.
>
> Change happens when stuff is measurable, and people can work towards a
> goal. Failing that, change happens when people can be held accountable.
> Objective measures are needed.

What a wonderful world that would be! Unfortunately, all too often I
feel that objective measures (such as "+1" on bugs, duplicates etc.)
have no effect on prioritization.

> if you for example knew how
> much time WMF currently spends on bug fixing, and you have an idea of how
> much time you think they should be spending. Even if management doesn't
> agree with your proposal, it would at least be specific enough to debate.

I have no way of finding that, do I? If there is one, I would be very
curious to learn 

[Wikitech-l] Discovery Weekly Update for the week starting 2019-03-04

[Chris Koerner]

Good to see you,

This is the weekly update from the Search Platform team for the week
starting 2019-03-04.

As always, feedback and questions are welcome.

== Discussions ==

=== Search ===
* We've updated Textcat with the new Russian wrong-keyboard and
wrong-encoding models and now need CirrusSearch to be up to date as well [0]
* In order to ease migration to ES6 we should migrate to 5.6.14 first (epic
task is now completed) [1]
** As part of the ES6 update, we needed to upgrade logstash and the
logstash elasticsearch cluster to 5.6.14 [2]
** We also upgraded logstash plugin to 5.6.14 as part of the prep for
elasticsearch upgrade [3]
* We've deployed & tested WikibaseCirrusSearch on beta cluster [4]
* We've also deployed & tested WikibaseCirrusSearch on testwikidata and
found things to be good! [5]
* We found that incigna monitoring for Elasticsearch doesn't seem to notice
when an out-of-memory error has happened on a node — this will be fully
fixed with the next cluster restart [6]
* There was some logspam due to deduplicating I18N messages between
Wikibase and WikibaseCirrusSearch that we resolved [7]
* A discovery was made with a WMFTimeoutException in Special:Search that
was resolved by decreasing timeouts and removing our timeout hack for
regexes [8]
* An umbrella task to track patches of merge commits to activate elastic6
support code [9]
* A ticket created way back in 2016 asked: 'the new substring search is
great on mw.o. Can we have it on office wiki too?' and yes, now it is [10]

=== Wikidata Query Service ===
* We've created CI testing environment for Blazegraph on our Jenkins CI [11]
* Working on hiring a contractor to help us with Blazegraph tasks [12]
* We noticed that metrics from wdqs updater JMX should be prefixed while we
were investigating something else, metrics exposed by jmx_exporter running
on wdqs-updater should be prefixed with wdqs_updater_ to make it more clear
what they are referring to (done!) [13]

== Other Noteworthy Stuff  ==
* Read Trey's new blog post about 'the anatomy of search: a place for my
stuff' [14]

[0] https://phabricator.wikimedia.org/T216083
[1] https://phabricator.wikimedia.org/T215931
[2] https://phabricator.wikimedia.org/T216052
[3] https://phabricator.wikimedia.org/T216993
[4] https://phabricator.wikimedia.org/T215684
[5] https://phabricator.wikimedia.org/T217276
[6] https://phabricator.wikimedia.org/T76090
[7] https://phabricator.wikimedia.org/T216839
[8] https://phabricator.wikimedia.org/T216860
[9] https://phabricator.wikimedia.org/T217043
[10] https://phabricator.wikimedia.org/T150153
[11] https://phabricator.wikimedia.org/T216855
[12] https://phabricator.wikimedia.org/T200558
[13] https://phabricator.wikimedia.org/T208215
[14]
https://wikimediafoundation.org/2019/03/12/the-anatomy-of-search-a-place-for-my-stuff/



Subscribe to receive on-wiki (or opt-in email) notifications of the
Discovery weekly update.

https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly

The archive of all past updates can be found on MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or
"Volunteer needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R

Yours,
Chris Koerner (he/him)
Community Relations Specialist
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Chico Venancio]

John,

Multiple people on this thread have pointed out that you are not giving
specifics bugs that are being ignored by WMF (and should not be). Can you
provide some examples?

Chico Venancio


Em qua, 13 de mar de 2019 às 17:01, John Erling Blad 
escreveu:

> This is like an enormous sinkhole, with people standing on the edge,
> warning about the sinkhole. All around people are saying "we must do
> something"! Still the sinkhole slowly grows larger and larger. People
> placing warning signs "Sinkhole ahead". Others notifying neighbors
> about the growing sinkhole. But nobody does anything about the
> sinkhole itself.
>
> I doubt this will be fixed.
>
> John
>
> ___
> 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] Question to WMF: Backlog on bugs

[John Erling Blad]

This is like an enormous sinkhole, with people standing on the edge,
warning about the sinkhole. All around people are saying "we must do
something"! Still the sinkhole slowly grows larger and larger. People
placing warning signs "Sinkhole ahead". Others notifying neighbors
about the growing sinkhole. But nobody does anything about the
sinkhole itself.

I doubt this will be fixed.

John

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Andre Klapper]

On Fri, 2019-03-08 at 13:31 +0100, John Erling Blad wrote:
> The backlog for bugs are pretty large (that is an understatement),
> even for bugs with know fixes and available patches

On tickets in general (not: patches) and their prioritization, I wrote
https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
to answer "Why has nobody fixed this yet?", "Why wasn't I consulted
about these changes?" and "How I can influence what is worked on?".

Cheers,
andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community-Engineering gaps as defined in configuration

[Amir Sarabadani]

This is one of things Scoring platform team wanted to tackle because having
RC patrolling enabled for a wiki + ORES predications can improve efficiency
of the patrollers significantly but we didn't have community relations
resources to start the discussion with communities and get it approved.
Maybe Growth team can take a look? I know they have a lot on their plate
already...

One ticket I found, I think there are more:
https://phabricator.wikimedia.org/T140475

Best

On Tue, 12 Mar 2019 at 18:00, James Forrester 
wrote:

> On Sat, 9 Mar 2019 at 11:50, bawolff  wrote:
>
> > In regards to wgUseRCPatrol - I suspect (but don't know) that originally
> > that was disabled on enwiki as a performance thing. If it was a
> performance
> > concern, that's probably irrelevant at this point.
> >
>
> Sadly, no. It was enabled as a new feature to help communities do their
> patrolling work. A small handful on enwiki power users complained in the
> hours after it was deployed about the "disruption" (the appearance of a !
> on edits in Recent Changes), and rather than help the community adjust to
> the new software and find it useful, the feature was disabled, effectively
> permanently. In the subsequent years, many English Wikipedians have
> complained about the lack of support for their work on Recent Changes
> patrolling, but there's been no effort to struggle through the community
> arguments to (re-)enable this tool, I believe.
>
> It would be lovely if we could enable this feature on the English Wikipedia
> given how useful many other communities have found this, but I don't expect
> it to happen.
>
> J.
> --
> *James D. Forrester* (he/him  or they/themself
> )
> Wikimedia Foundation 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Amir Sarabadani
Software engineer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de

Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de

Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Read access to patrolled flag in wikimedia API

[Сибирев Кирилл]

Hi, i can't find information about filtering pending changes through api, can 
someone 
help with my previous questions?

06.03.2019, 13:32, "Сибирев Кирилл" :
> 05.03.2019, 19:33, "bawolff" :
>>  Are you sure that patrol status is shown as colour coding on history pages?
>>  I'm pretty sure its not.
>>
>>  If you mean kind of the dim yellow colour (like in
>>  
>> https://en.wikipedia.org/w/index.php?title=List_of_programs_broadcast_by_Adult_Swim=history
>>  for the moment, but that will likely change soon), that means a pending
>>  change, which is a different system from patrolling.
>>
>>  Note, on enwikipedia (but not other projects) RC patrolling is disabled,
>>  and only new page patrol is enabled (so only the first revision can have a
>>  patrol status).
>
> Thanks for the answer, i'm little bit confused by naming here, i guess.
> Mostly we use ru.wikipedia.org, where a lot of pages have blue/yellow markup
> and legend for blue can be translated as "patrolled version", and yellow is 
> "unverified version"
> (here screenshot of what i am talking about https://yadi.sk/i/A0FRG6yz86ECdg)
>
> So, if i did understand you correctly, blue/yellow markup is about pending 
> changes
> (https://en.wikipedia.org/wiki/Wikipedia:Pending_changes) and not patrolling
> (https://www.mediawiki.org/wiki/Help:Patrolling), am i right?
>
> Basically we want to get from api same data which users see on wikipedia 
> article page
> and as far as i understand yellow changes are not visible until approved.
> Can you send me some page about comparing pending and patrolling, because for 
> now
> i can't understand if the two system can be applied to one page and what 
> happens
> if revision is patrolled (does it become approved and not pending after that)?
>
> If pending system is responsible for revision visibility on article page then 
> it is
> not matter to us what patrolling does, i guess.
> But in that case we need to get pending property of revision from API, is it 
> accessible?
>
>>  --
>>  Brian
>>
>>  On Tue, Mar 5, 2019 at 4:13 PM Сибирев Кирилл 
>>  wrote:
>>
>>>   Hi, we are using wikimedia http api for getting pages recent changes [1].
>>>   We'd like to be able to distinguish patrolled and unpatrolled revisions 
>>> and
>>>   this feature is supported according to docs, but we still can't use it
>>>   because of access permissions. For example if i making requests like [2] 
>>> or
>>>   [3] i am getting {"code": "permissiondenied", "info": "You need the
>>>   \"patrol\" or \"patrolmarks\" right to request the patrolled flag."} 
>>> error.
>>>
>>>   This API behaviour looks inconsistent to me, because anyone can see
>>>   patrolled/unpatrolled colored markup at wikipedia revision history web
>>>   pages. I think patrol right should be checked only at write (ones that 
>>> mark
>>>   revisions patrolled or not) API requests and not for read requests.
>>>
>>>   Is this behaviour really inconsistent and implemented that way due to
>>>   technical restrictions or am i missing something? Can it be changed, so we
>>>   can get patrolling information for revisions or maybe there are some
>>>   workarounds exist?
>>>
>>>   [1] https://www.mediawiki.org/wiki/API:RecentChanges
>>>   [2]
>>>   
>>> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title|patrolled=3
>>>   [3]
>>>   
>>> https://en.wikipedia.org/w/api.php?action=query=recentchanges=title=patrolled=3
>>>
>>>   ___
>>>   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] New Gerrit privilege policy

[Zppix]

Hello,
So what is the process for adding people to +2 on gerrit repos im the primary 
maintainer of (for example my ZppixBot toolforge gerrit repo)

--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also 
do not work for Mozilla, or any of its projects. ** 

> On Mar 13, 2019, at 12:40 AM, Physikerwelt  wrote:
> 
>> On Wed, Mar 13, 2019 at 5:25 AM Tim Starling  wrote:
>> 
>> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
>> moved the new Gerrit privilege policy page out of my userspace to
>> 
>> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>> 
>> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
>> ownership]], with some additional changes. I've now redirected both of
>> those pages to the new policy page.
>> 
>> The main changes are:
>> 
>> * The wmde LDAP group, representing WMDE staff members, will be given
>> +2 access to mediawiki/* projects, similar to the rights given to WMF
>> staff members.
> 
> Great. This is the first step towards a global movement;-)
> 
>> 
>> * The ability of ShoutWiki and Hallo Welt! to manage access to the
>> extensions they maintain is described and formalised.
>> 
>> * The ownership model for extensions is discouraged in favour of
>> individual requests on Phabricator. An extension owner was able to
>> promote developers to +2 access at their own discretion.
> 
> I think this does not harm too much since many people use Microsofts
> GitHub to maintain their non-WMF deployed extensions these days.
> 
> 
> Physikerwelt
> 
>> 
>> * The Phabricator projects for requesting access have changed. I'm in
>> the process of moving the tickets over.
>> 
>> * The revocation policy has been expanded, better describing the
>> present situation and making several minor changes.
>> 
>> -- Tim Starling
>> 
>> 
>> ___
>> 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