Re: [Wikitech-l] A potential new way to deal with spambots

[Pine W]

On Wed, Feb 13, 2019 at 12:13 PM bawolff  wrote:

> I actually meant a different type of maintenance.
>
> Maintaining the encyclopedia (and other wiki projects) is of course an
> activity that needs software support.
>
> But software is also something that needs maintenance. Technology,
> standards, circumstances change over time. Software left alone will
> "bitrot" over time. A long term technical strategy to do anything needs to
> account for that, plan for that. One off feature development does not.
> Democratically directed one-off feature development accounts for that even
> less.
>

I understand. I was intending to comment on maintenance activities in
general, whether that be maintenance of a city's water system, maintenance
of the text of encyclopedia articles, or maintenance of software. My train
of thought proceeded into a somewhat detailed commentary detail regarding
maintenance of non-software Wikimedia elements. I think that the tendency
to under-resource maintenance in favor of novelties is similar in many
domains of human activity, but I also think that humans collectively are
not so unwise that we will prefer novelties over maintenance every time
that there is a referendum on whether to maintain an existing service or to
create something new. {{Citation needed}}

I think that multiple good points have been raised in this thread regarding
the subjects of technical and human systems for detecting and intervening
against possible unflagged bots. I am wondering what a good way would be to
get a WMF product manager or someone similar to dedicate time to this
topic. My preference remains that one or more WMF people, or teams, add
this to their list of topics to address in a future quarter such as Q1 of
the WMF 2019-2020 fiscal year. I don't know how the WMF Community Tech team
plans for maintenance of features after the features are initially built,
debugged, and deployed, and based on the current state of this discussion I
don't currently have a strong opinion regarding whether Community Tech or a
different team would be best suited to work on the topic of unflagged bots.
I also don't know how WMF makes decisions about what goals are for teams
other than Community Tech for future quarters, but that information could
be helpful to have for this conversation.

Thanks,

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] GSoC' 19 project idea ( proposal)

[Andrew Lih]

Hi, actually that Research:Data page seems stale. It says:

"Wikimedia broadcasts every change to every Wikimedia wiki using the
Socket.IO protocol," whereas the current preferred way is to use SSE. You
should take a look at: https://wikitech.wikimedia.org/wiki/EventStreams

I recently created a web app to visualize live Wikidata edits to artworks
by watching EventStreams, so feel free to ping me if you have any questions
or want to build off that.

-Andrew




On Sun, Feb 10, 2019 at 12:27 AM K. Kaushik Reddy 
wrote:

> Hi team,
>
> This is Kaushik Reddy.
> After a long work, I would like to introduce you to my idea proposal for
> the (Wikimedia) GSoC '19.
> Here is it:
> 1) Building an animation to dynamically create popups overlapped on a
> geographical map using a real-time API from Wikimedia.
>
> I had found the root of this in here( I have gone through it a bit):
>
> https://meta.m.wikimedia.org/wiki/Research:Data
>
>
> I would like to work on this idea, this summer. Hope any mentor would join
> to guide me . Also, feel free to comment on this.
>
> With regards,
> Kaushik.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
-Andrew Lih
Author of The Wikipedia Revolution
US National Archives Citizen Archivist of the Year (2016)
Knight Foundation grant recipient - Wikipedia Space (2015)
Wikimedia DC - Outreach and GLAM
Previously: professor of journalism and communications, American
University, Columbia University, USC
---
Email: and...@andrewlih.com
WEB: https://muckrack.com/fuzheado
PROJECT: Wikipedia Space: http://en.wikipedia.org/wiki/WP:WPSPACE
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Chris Koerner]

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

As always, feedback and questions welcome.

== Discussions ==

=== Search ===
* Based on feedback received during a conversation at All Hands, Erik
wrote up a page documenting  how to utilize dependencies inside
pyspark with a custom setup at the start of a notebook. [0]
* Julia (NLP contractor) is working on various things and will use
glent in part of that research. :) [1]
* Nuria is reading / watching all sorts of documentation regarding
search, here's a video that is interesting. [2]
* Erik finished up more documenting debt with adding the search sort
options that are available in the API [3]
* David worked on using subphrase matching for autocomplete by default
on specific sites [4]
* Erik worked on starting a new browser bot instance running elastic 6
to help get ready for the upcoming es6 upgrade [5]
* Erik noticed that once the elasticsearch cluster split is complete
we will need to be ready to start deploying the archive index split,
and went ahead and dropped the "archive" from generic index on
testwiki [6]
* Trey reviewed David's port of all of our internal and external
language analyzers to Elasticsearch 6. There are some unexpected
upgrades, and there were a few problems, which David immediately fixed
(and added new tests to cover). [7]

[0] https://wikitech.wikimedia.org/wiki/User:EBernhardson/pyspark_on_SWAP
[1] https://en.wiktionary.org/wiki/glent
[2] https://commons.wikimedia.org/wiki/File:BareBonesSearch.webm
[3] https://phabricator.wikimedia.org/T215198
[4] https://phabricator.wikimedia.org/T212788
[5] https://phabricator.wikimedia.org/T214422
[6] https://phabricator.wikimedia.org/T213851
[7] https://phabricator.wikimedia.org/T194849



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

[Wikitech-l] 2019-02-13 Scrum of Scrums meeting notes

[Grace Gellerman]

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

= 2019-02-13 =
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* Release Engineering: Beta Cluster and CI issues
https://lists.wikimedia.org/pipermail/cloud/2019-February/000538.html
* SRE: Sunsetting Wikipedia Zero stuff (
https://phabricator.wikimedia.org/T187716) is blocked by
https://phabricator.wikimedia.org/T213769 (and possibly others); not
urgent, but we want this done this quarter if possible.
* From Analytics: The old staging database in dbstore1002 will be set to
read-only on Feb 18th. Please, use the new one in dbstore1005, thanks!
* TechCom: RFC: Re-establish the development policies
https://phabricator.wikimedia.org/T190379

== 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:
* Blocking:
* Updates:
**

=== Readers ===
 iOS native app 
* Blocked by:
* Blocking:
* Updates:
**In a code freeze phase for 6.2 - testing
https://phabricator.wikimedia.org/tag/ios-app-v6.2-beluga-on-a-pogo-stick/
**Preapring for 6.2.1 - bug fixes, editing tools enhancements and mobile
html prototype
https://phabricator.wikimedia.org/tag/ios-app-v6.2.1-beluga-on-stilts/

 Android native app 
* Blocked by:
* Blocking:
* Updates:
**

 Readers Web 
* Blocked by:
* Blocking:
* Updates:
** Summary: we've transitioned the Proton PDF renderer to Readers
Infrastructure for final deployment, we're continuing the Advanced Mobile
Contributions project and have enabled ES6 support in MobileFrontend as
part of the Architecture investment effort.

** Responsive website (MinervaNeue / MobileFrontend):

*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
 Talk tabs disabled on main page T214724
 Page/talk toggle v1 T212216
 Design updates to Settings page & opt-in toggle T214195
 Create AMC edit tag T212959

*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture
 Enable Babel transpiling in MobileFrontend T202746
 Separate lazy loading from Skin T214658
 Migrate deprecated calls T208915
 Group web client error reports T212970

*** Page issues
https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues
 Miscellaneous bug fixes and maintenance T212376 T212371 T214550

*** ExternalGuidance extension review and support

*** Miscellaneous bug fixes and maintenance T215648 T215849 T213336 T202374

** Desktop website (Vector, 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

** PDF rendering (Proton)
https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality
*** Transitioned to Readers Infrastructure


 Readers Infrastructure 
* Blocked by:
** SRE: Sunsetting Wikipedia Zero stuff (
https://phabricator.wikimedia.org/T187716) is blocked by
https://phabricator.wikimedia.org/T213769 (and possibly others); not
urgent, but we want this done this quarter if possible.
* Blocking:
* Updates:
** Maps: codfw cluster OS upgrade to stretch started this week with
maps2004 T215521
** App Editor Tasks infrastructure work ongoing


 Multimedia 
* Blocked by:
** RelEng: Adding WikibaseMediaInfo to the gate; patch is
https://gerrit.wikimedia.org/r/c/integration/config/+/480463 and needs
deployment
* Blocking:
**
* Updates
** working towards first release of structured data statements (depicts)
** onboarding for 2 new hires

 Parsing 
* Blocked by:
* Blocking:
* Updates:

 UI Standardization 
* Blocked by:
* Blocking:
* Updates:
**

== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
** The replacement for dbstore1002 is in place now. Contains a queryable
replica of the wiki databases distributed in 3 nodes (dbstore100[345]).
** Up-to-date docs at:
https://wikitech.wikimedia.org/wiki/Analytics/Data_access#MariaDB_replicas
** The staging database is in dbstore1005. The old one in dbstore1002 will
be set to read-only on Feb 18th. And we plan to decomission dbstore1002 in
the upcoming weeks.
** Superset can connect to the new MySQL hosts, including the staging
database.

=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
**

=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Still testing PHP7 / MediaWiki 1.31 payments-wiki upgrade, has morphed
into testing our backup cluster as well
https://phabricator.wikimedia.org/T184460
** Fixing bugs in latest CiviCRM point upgrade
https://phabricator.wikimedia.org/T215802,

Re: [Wikitech-l] A potential new way to deal with spambots

[Jonathan Morgan]

Brian,

I think we may be talking past each other. I'm Mr. Socio-technical systems.
I thought what was being requested was a way to detect bots.

I maintain my own bots, work extensively with product teams, and have a
deep and abiding familiarity with the complexity of designing effective
tools for WIkipedia.

- J

On Wed, Feb 13, 2019 at 4:14 AM bawolff  wrote:

> I actually meant a different type of maintenance.
>
> Maintaining the encyclopedia (and other wiki projects) is of course an
> activity that needs software support.
>
> But software is also something that needs maintenance. Technology,
> standards, circumstances change over time. Software left alone will
> "bitrot" over time. A long term technical strategy to do anything needs to
> account for that, plan for that. One off feature development does not.
> Democratically directed one-off feature development accounts for that even
> less.
>
> In response to Johnathan:
> So lets say that ORES/magic AI detects something is a bot. Then what?
> That's a small part of the picture. In fact you don't even need AI to do
> this, plenty of the vandal bots have generic programming language
> user-agents (AI could of course be useful for long-tail here, but there's
> much simpler stuff to start off with). Do we expose this to abusefilter
> somehow? Do we add a tag to mark it in RC/watchlist? Do we block it? Do we
> rate limit it? What amount of false positives are acceptable? What is the
> UI for all this? To what extent is this hard coded, and to what extent do
> communities control the feature? etc
>
> We don't need products to detect bots. Making products to detect bots is
> easy. We need product managers to come up with socio-technical systems that
> make sense in our special context.
>
> --
> Brian
>
> On Tue, Feb 12, 2019 at 8:36 PM Pine W  wrote:
>
> > Since we're discussing how the Tech Wishlist works then I will comment
> on a
> > few points specifically regarding that wishlist.
> >
> > 1. A gentle correction: the recommendations are ranked by vote, not by
> > consensus. This has pros and cons.
> >
> > 2a. If memory serves me correctly, the wishlist process was designed by
> WMF
> > rather than designed by community consensus. I may be wrong about this,
> but
> > in my search of historical records I have not found evidence to the
> > contrary. I think that redesigning the process would be worth
> considering,
> > and I hope that a redesign would help to account for the types of needs
> > that bawolff described in his second paragraph.
> >
> > 2b.. I think that it's an overstatement to say that "nobody ever votes
> for
> > maintenance until its way too late and everything is about to explode". I
> > think that many non-WMF people are aware of our backlogs, the endless
> > requests for help and conflict resolution, and the many challenges of
> > maintaining what we have with the current population of skilled and good
> > faith non-WMF people. However, I have the impression that there is a
> common
> > *tendency* among humans in general to chase shiny new features instead of
> > doing mostly thankless work, and I agree that the tech wishlist is
> unlikely
> > even in a redesigned form to be well suited for long term planning. I
> think
> > that WMF's strategy process may be a better way to plan for the long
> term,
> > including for maintenance activities that are mostly thankless and do not
> > necessarily correlate with increasing someone's personal power, making
> > their resume look better, or having fun. Fortunately the volunteer
> > mentality of many non-WMF people means that we do have people who are
> > willing to do mostly thankless, mundane, and/or stressful work, and I
> think
> > that some of us feel that our work is important for maintaining the
> > encyclopedia even when we do not enjoy it, but we have a finite supply of
> > time from such people.
> >
> > 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
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jonathan T. Morgan
Senior Design Researcher
Wikimedia Foundation
User:Jmorgan (WMF) 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Beta Cluster and CI issues (was Fwd: [Cloud] [Cloud-announce] VPS hardware failure -- downtime ongoing)

[Greg Grossmeier]

This WMCS outage is affecting Beta Cluster (aka: deployment-pre VPS
project) and our CI build/test servers (aka: the integration project).

Apologies for any downtime and/or slow CI responses while this is being
sorted.

Greg

- Forwarded message from Andrew Bogott  -

> Date: Wed, 13 Feb 2019 07:25:39 -0600
> From: Andrew Bogott 
> To: cloud-annou...@lists.wikimedia.org
> Subject: [Cloud] [Cloud-announce] VPS hardware failure -- downtime ongoing
> Reply-To: cl...@lists.wikimedia.org
> 
> We're currently experiencing a mysterious hareware failure in our datacenter
> -- three different SSDs failed overnight, two of them in cloudvirt1018 and
> one of them in cloudvirt1024.  The VMs on 1018 are down entirely.  We may
> move those on 1024 to another host shortly in order to guard against
> additional drive failure.
> 
> There's some possibility that we will experience permanent data loss on
> cloudvirt1018, but everyone is working hard to avoid this.
> 
> The following VMs are on cloudvirt1018:
> 
> 
> a11y | reading-web-staging
> abogott-scapserver   | testlabs
> af-puppetdb01    | automation-framework
> api  | openocr
> asdf | quotatest
> bastion-eqiad1-02    | bastion
> clm-test-01  | community-labs-monitoring
> compiler1002 | puppet-diffs
> cyberbot-exec-iabot-01   | cyberbot
> deployment-db03  | deployment-prep
> deployment-db04  | deployment-prep
> deployment-memc05    | deployment-prep
> deployment-pdfrender02   | deployment-prep
> deployment-sca01 | deployment-prep
> design-lsg3  | design
> eventmetrics-dev01   | eventmetrics
> fridolin | catgraph
> gtirloni-puppetmaster-01 | testlabs
> hadoop-master-3  | analytics
> ign  | ign2commons
> integration-castor03 | integration
> integration-slave-docker-1017    | integration
> integration-slave-docker-1033    | integration
> integration-slave-docker-1038    | integration
> integration-slave-jessie-1003    | integration
> integration-slave-jessie-android | integration
> k8s-master-01    | general-k8s
> k8s-node-03  | general-k8s
> k8s-node-05  | general-k8s
> k8s-node-06  | general-k8s
> kdc  | analytics
> labstash-jessie1 | logging
> language-mleb-legacy | language
> login-test   | catgraph
> lsg-01   | design
> mathosphere  | math
> mc-clusterA-1    | test-twemproxy
> mwoffliner5  | mwoffliner
> novaadminmadethis-4  | quotatest
> ntp-01   | cloudinfra
> ntp-02   | cloudinfra
> ogvjs-testing    | ogvjs-integration
> phragile-pro | phragile
> planet-hotdog    | planet
> pub2 | wikiapiary
> puppenmeister    | planet
> puppet-compiler-v4-other | testlabs
> puppet-compiler-v4-tools | testlabs
> quarry-beta-01   | quarry
> signwriting-swis | signwriting
> signwriting-swserver | signwriting
> social-tools3    | social-tools
> striker-deploy04 | striker
> striker-puppet01 | striker
> t166878  | otrs
> togetherjs   | visualeditor
> tools-sgebastion-06  | tools
> tools-sgeexec-0902   | tools
> tools-sgeexec-0903   | tools
> tools-sgewebgrid-generic-0901    | tools
> tools-sgewebgrid-lighttpd-0901   | tools
> ve-font  | design
> wikibase1    | sciencesource
> wikicitevis-prod | wikicitevis
> wikifarm | pluggableauth
> women-in-red | globaleducation
> 
> 
> 
> ___
> Wikimedia Cloud Services announce mailing list
> cloud-annou...@lists.wikimedia.org (formerly 
> labs-annou...@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/cloud-announce
> ___
> Wikimedia Cloud Services mailing list
> cl...@lists.wikimedia.org (formerly lab...@lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/cloud

- End forwarded message -

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team ManagerA18D 1138 8E47 FAC8 1C7D |

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

[Wikitech-l] MediaWiki PHP coding conventions for declaring return types

[Brad Jorsch (Anomie)]

I've started a discussion at
https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP#Declaring_of_return_types.
Please comment there if interested.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia production excellence (January 2019)

[Brad Jorsch (Anomie)]

On Tue, Feb 12, 2019 at 10:54 PM Krinkle  wrote:

> Brad fixed the code a few hours later, and it was deployed by Roan later
> that same day.
> Thanks! —  https://phabricator.wikimedia.org/T213168
>

Correction: It was Gergő Tisza who submitted the patch to fix the code for
this one, not me.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] A potential new way to deal with spambots

[John Erling Blad]

It is extremely easy to detect a bot unless the bot operator chose to make
it hard. Just make a model for how the user interacts with the input
devices, and do anomaly detection. That imply use of Javascript though, but
users not using JS are either very dubious or quite well-known. There are
nearly no new users that does not use JS.

Reused a previous tex-file, and did not clean it up? "Magnetic Normal Modes
of Bi-Component Permalloy Structures" ;)


On Mon, Feb 11, 2019 at 6:47 PM Aaron Halfaker 
wrote:
>
> We've been working on unflagged bot detection on my team.  It's far from a
> real product integration, but we have shown that it works in practice.  We
> tested this in Wikidata, but I don't see a good reason why a similar
> strategy wouldn't work for English Wikipedia.
>
> Hall, A., Terveen, L., & Halfaker, A. (2018). Bot Detection in Wikidata
> Using Behavioral and Other Informal Cues.
> *Proceedings of the ACM on Human-Computer Interaction*, *2*(CSCW), 64.
pdf
> 
>
> In theory, we could get this into ORES if there was strong demand.  As
Pine
> points out, we'd need to delay some other projects.  For reference, the
> next thing on the backlog that I'm looking at is setting article quality
> prediction for Swedish Wikipedia.
>
> -Aaron
>
> On Mon, Feb 11, 2019 at 11:19 AM Jonathan Morgan 
> wrote:
>
> > This may be naive, but... isn't the wishlist filling this need? And if
not
> > through a consensus-driven method like the wishlist, how should a WMF
team
> > prioritize which power user tools it needs to focus on?
> >
> > Or is just a matter of "Yes, wishlist, but more of it"?
> >
> > - Jonathan
> >
> > On Mon, Feb 11, 2019 at 2:34 AM bawolff  wrote:
> >
> > > Sure its certainly a front we can do better on.
> > >
> > > I don't think Kasada is a product that's appropriate at this time.
> > Ignoring
> > > the ideological aspect of it being non-free software, there's a lot of
> > easy
> > > things we could and should try first.
> > >
> > > However, I'd caution against viewing this as purely a technical
problem.
> > > Wikimedia is not like other websites - we have allowable bots. For
many
> > > commercial websites, the only good bot is a dead bot. Wikimedia has
many
> > > good bots. On enwiki usually they have to be approved, I don't think
> > that's
> > > true on all wikis. We also consider it perfectly ok to do limited
testing
> > > of bots before it is approved. We also encourage the creation of
> > > alternative "clients", which from a server perspective looks like a
bot.
> > > Unlike other websites where anything non-human is evil, here we need
to
> > > ensure our blocking corresponds to social norms of the community. This
> > may
> > > sound not that hard, but I think it complicates botblocking more than
is
> > > obvious at first glance.
> > >
> > > Second, this sort of thing is something that tends to far through the
> > > cracks at WMF. AFAIK the last time there was a team responsible for
admin
> > > tools & anti-abuse was 2013 (
> > > https://www.mediawiki.org/wiki/Admin_tools_development). I believe
> > > (correct
> > > me if I'm wrong) that anti-harrasment team is all about human
harassment
> > > and not anti-abuse in this sense. Security is adjacent to this
problem,
> > but
> > > traditionally has not considered this problem in scope. Even core
tools
> > > like checkuser have been largely ignored by the foundation for many
many
> > > years.
> > >
> > > I guess this is a long winded way of saying - I think there should be
a
> > > team responsible for this sort of stuff at WMF, but there isn't one. I
> > > think there's a lot of rather easy things we can try (Off the top of
my
> > > head: Better captchas. More adaptive rate limits that adjust based on
how
> > > evilish you look, etc), but they definitely require close involvement
> > with
> > > the community to ensure that we do the actual right thing.
> > >
> > > --
> > > Brian
> > > (p.s. Consider this a volunteer hat email)
> > >
> > > On Sun, Feb 10, 2019 at 6:06 AM Pine W  wrote:
> > >
> > > > To clarify the types of unwelcome bots that we have, here are the
ones
> > > that
> > > > I think are most common:
> > > >
> > > > 1) Spambots
> > > >
> > > > 2) Vandalbots
> > > >
> > > > 3) Unauthorized bots which may be intended to act in good faith but
> > which
> > > > may cause problems that could probably have been identified during
> > > standard
> > > > testing in Wikimedia communities which have a relatively well
developed
> > > bot
> > > > approval process. (See
> > > > https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval.)
> > > >
> > > > Maybe unwelcome bots are not a priority for WMF at the moment, in
which
> > > > case I could add this subject into a backlog. I am sorry if I sound
> > > grumpy
> > > > at WMF regarding this subject; this is a problem but I know that
there
> > > are
> > > > millions of problems and I don't expect a different project to be
> > dropped
> > > > 

Re: [Wikitech-l] A potential new way to deal with spambots

[bawolff]

I actually meant a different type of maintenance.

Maintaining the encyclopedia (and other wiki projects) is of course an
activity that needs software support.

But software is also something that needs maintenance. Technology,
standards, circumstances change over time. Software left alone will
"bitrot" over time. A long term technical strategy to do anything needs to
account for that, plan for that. One off feature development does not.
Democratically directed one-off feature development accounts for that even
less.

In response to Johnathan:
So lets say that ORES/magic AI detects something is a bot. Then what?
That's a small part of the picture. In fact you don't even need AI to do
this, plenty of the vandal bots have generic programming language
user-agents (AI could of course be useful for long-tail here, but there's
much simpler stuff to start off with). Do we expose this to abusefilter
somehow? Do we add a tag to mark it in RC/watchlist? Do we block it? Do we
rate limit it? What amount of false positives are acceptable? What is the
UI for all this? To what extent is this hard coded, and to what extent do
communities control the feature? etc

We don't need products to detect bots. Making products to detect bots is
easy. We need product managers to come up with socio-technical systems that
make sense in our special context.

--
Brian

On Tue, Feb 12, 2019 at 8:36 PM Pine W  wrote:

> Since we're discussing how the Tech Wishlist works then I will comment on a
> few points specifically regarding that wishlist.
>
> 1. A gentle correction: the recommendations are ranked by vote, not by
> consensus. This has pros and cons.
>
> 2a. If memory serves me correctly, the wishlist process was designed by WMF
> rather than designed by community consensus. I may be wrong about this, but
> in my search of historical records I have not found evidence to the
> contrary. I think that redesigning the process would be worth considering,
> and I hope that a redesign would help to account for the types of needs
> that bawolff described in his second paragraph.
>
> 2b.. I think that it's an overstatement to say that "nobody ever votes for
> maintenance until its way too late and everything is about to explode". I
> think that many non-WMF people are aware of our backlogs, the endless
> requests for help and conflict resolution, and the many challenges of
> maintaining what we have with the current population of skilled and good
> faith non-WMF people. However, I have the impression that there is a common
> *tendency* among humans in general to chase shiny new features instead of
> doing mostly thankless work, and I agree that the tech wishlist is unlikely
> even in a redesigned form to be well suited for long term planning. I think
> that WMF's strategy process may be a better way to plan for the long term,
> including for maintenance activities that are mostly thankless and do not
> necessarily correlate with increasing someone's personal power, making
> their resume look better, or having fun. Fortunately the volunteer
> mentality of many non-WMF people means that we do have people who are
> willing to do mostly thankless, mundane, and/or stressful work, and I think
> that some of us feel that our work is important for maintaining the
> encyclopedia even when we do not enjoy it, but we have a finite supply of
> time from such people.
>
> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l