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] 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] Community-Engineering gaps as defined in configuration

[James Forrester]

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

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

[Bartosz Dziewoński]

On 2019-03-09 16:12, Eran Rosenthal wrote:

- wmgUseSandboxLink
   - Enabled in 80 wikis. Why not enabling it everywhere?


It was enabled on all wikis that were already adding a link to a user's 
personal sandbox using site JS or a gadget enabled by default.


I wrote that extension as part of my volunteer work, and the goal was to 
improve page load performance on wikis that already had that link. In my 
experience discussing any interface changes to Wikimedia wikis is very 
unfun and I had no particular interest in doing that for this.


--
Bartosz Dziewoński

___
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

[bawolff]

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.

I generally agree that its good to try an unify config complexity where it
makes sense. But I don't think we should force it where it does not. People
are different and have different needs. Keeping communities happy in the
case of technical disputes is well worth the extra complexity in my mind
(within reason).

Re Risker with loading time: That can depend on the extensions. Some do
slightly increase loading times, but there are many extensions which should
not cause any change in loading time (or at least negligable - i.e. less
than a millisecond) no matter how bad the internet connection is.

--
Brian

On Sat, Mar 9, 2019 at 6:44 PM Risker  wrote:

> I suspect that a major factor in whether or not to deploy many of these
> extensions to every wiki is that, frankly...not every wiki has enough
> active editors for these extensions to make sense or to be helpful.  In
> some ways, the extension may well be unhelpful or could act to distract the
> few active editors from their main focus (content creation, in most cases)
> to activities that do not help them to build their projects.  Anything that
> requires language localization - often involving the use of interface
> administrator permission - is not helpful for projects that have no
> interface admins (or, in some cases, any administrators at all).
>
> It's not a good idea to assume that one configuration fits all.  There's a
> huge difference between the larger projects, with thousands of active users
> and dozens if not hundreds of administrators, and the majority of Wikimedia
> wikis that have fewer than 100 active contributors. Looking only at
> Wikipedia, 165 of 303 Wikipedias have fewer than 100 active (i.e., at least
> one edit a month) editors and fewer than 10 administrators.[1]
>
> It's easy to forget that many of the extensions were designed to assist in
> the work of medium to large Wikipedias; a lot of them aren't all that
> useful for smaller projects, and some of them can significantly add to the
> burden of projects with a small user and admin base.  Remember that every
> extension that's enabled extends the loading time - it may appear to be
> statistically unimportant in much of the Western world, but there are
> cumulative effects that are much more noticeable when contributors are
> participating on slow internet connections with older technology and are
> located a long way away from the servers.  These are real effects that most
> people participating on this list simply never have a reason to notice,
> until we're trying to edit logged-in from remote areas.
>
> Risker/Anne
>
>
>
>
>
> [1] https://meta.wikimedia.org/wiki/List_of_Wikipedias
>
>
>
> On Sat, 9 Mar 2019 at 10:12, Eran Rosenthal  wrote:
>
> > Hi,
> > Wiki communities can ask to override their default configurations
> > (following consensus). The reasons to override may vary:
> >
> >1. *customization* for community to align to community specific policy
> >(example: special namespaces / upload policy/user groups rights
> defined
> > per
> >project and language version)
> >2. *technical dispute* where community and engineering don't agree
> >(example:  VE as single tab for enwiki[1], disabling description
> > tagline in
> >enwiki[2] etc).
> >
> > Technical dispute are problematic - if the product is not good enough
> > engineering and community should ideally come with a solution how to
> > address the issues. We can define a plan to fix the product (disable till
> > task X is fixed), enable/disable feature in the USER level if it is a
> > matter of choice (not the site level) etc.
> > Anyway we should try to avoid letting specific communities override
> > defaults for long term if there is no community specific reason to
> override
> > the configuration. This create a jungle of configurations, inconsistent
> UI
> > across languages and more complex maintenance etc.
> >
> > This is a call for action for the wiki communities and engineering:
> >
> >- Engineering - consider to align all wikis to similar configuration
> if
> >it isn't community customization but "technical dispute"
> >- Communities - consider whether these configurations are old and can
> be
> >removed
> >
> > Examples of issues found in wmf-config:
> >
> >- VisualEditor tabs (wmgVisualEditorUseSingleEditTab 60 wikis
> "Deploying
> >slowly with community advanced notice"?
> >wmgVisualEditorSingleEditTabSecondaryEditor - enwiki overrides the
> > default
> >editor)
> >   - and more generally enabling VE deployments:
> >   https://www.mediawiki.org/wiki/VisualEditor/Rollouts
> >   - Patroling
> >   - wgUseRCPatrol - disabled by default but ~80 wikis enable it.
> Should
> >   be enabled for all wikis? (if not - what is missing from getting 

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

[Risker]

I suspect that a major factor in whether or not to deploy many of these
extensions to every wiki is that, frankly...not every wiki has enough
active editors for these extensions to make sense or to be helpful.  In
some ways, the extension may well be unhelpful or could act to distract the
few active editors from their main focus (content creation, in most cases)
to activities that do not help them to build their projects.  Anything that
requires language localization - often involving the use of interface
administrator permission - is not helpful for projects that have no
interface admins (or, in some cases, any administrators at all).

It's not a good idea to assume that one configuration fits all.  There's a
huge difference between the larger projects, with thousands of active users
and dozens if not hundreds of administrators, and the majority of Wikimedia
wikis that have fewer than 100 active contributors. Looking only at
Wikipedia, 165 of 303 Wikipedias have fewer than 100 active (i.e., at least
one edit a month) editors and fewer than 10 administrators.[1]

It's easy to forget that many of the extensions were designed to assist in
the work of medium to large Wikipedias; a lot of them aren't all that
useful for smaller projects, and some of them can significantly add to the
burden of projects with a small user and admin base.  Remember that every
extension that's enabled extends the loading time - it may appear to be
statistically unimportant in much of the Western world, but there are
cumulative effects that are much more noticeable when contributors are
participating on slow internet connections with older technology and are
located a long way away from the servers.  These are real effects that most
people participating on this list simply never have a reason to notice,
until we're trying to edit logged-in from remote areas.

Risker/Anne





[1] https://meta.wikimedia.org/wiki/List_of_Wikipedias



On Sat, 9 Mar 2019 at 10:12, Eran Rosenthal  wrote:

> Hi,
> Wiki communities can ask to override their default configurations
> (following consensus). The reasons to override may vary:
>
>1. *customization* for community to align to community specific policy
>(example: special namespaces / upload policy/user groups rights defined
> per
>project and language version)
>2. *technical dispute* where community and engineering don't agree
>(example:  VE as single tab for enwiki[1], disabling description
> tagline in
>enwiki[2] etc).
>
> Technical dispute are problematic - if the product is not good enough
> engineering and community should ideally come with a solution how to
> address the issues. We can define a plan to fix the product (disable till
> task X is fixed), enable/disable feature in the USER level if it is a
> matter of choice (not the site level) etc.
> Anyway we should try to avoid letting specific communities override
> defaults for long term if there is no community specific reason to override
> the configuration. This create a jungle of configurations, inconsistent UI
> across languages and more complex maintenance etc.
>
> This is a call for action for the wiki communities and engineering:
>
>- Engineering - consider to align all wikis to similar configuration if
>it isn't community customization but "technical dispute"
>- Communities - consider whether these configurations are old and can be
>removed
>
> Examples of issues found in wmf-config:
>
>- VisualEditor tabs (wmgVisualEditorUseSingleEditTab 60 wikis "Deploying
>slowly with community advanced notice"?
>wmgVisualEditorSingleEditTabSecondaryEditor - enwiki overrides the
> default
>editor)
>   - and more generally enabling VE deployments:
>   https://www.mediawiki.org/wiki/VisualEditor/Rollouts
>   - Patroling
>   - wgUseRCPatrol - disabled by default but ~80 wikis enable it. Should
>   be enabled for all wikis? (if not - what is missing from getting it
>   deployed in more wikis? are there alternative feature for it
> used in other
>   wikis?)
>   - wgUseNPPatrol/wgUseFilePatrol - few wikis override it. Do we really
>   need to override it?
>- wgImportSources
>- Each wiki define arbitrary list of wikis it import from. We should get
>   rid of it and allow import between any Wikimedia site. See
>   https://phabricator.wikimedia.org/T17583
>- wmgUseSandboxLink
>   - Enabled in 80 wikis. Why not enabling it everywhere?
>- wmgUseWikiLove -enabled in ~50 wikis including enwiki. is there a
>reason to not enable in all wikis?
>
> Thanks,
> Eran
>
> [1] https://phabricator.wikimedia.org/T128478
> [2] https://phabricator.wikimedia.org/T161805
> [3] https://phabricator.wikimedia.org/T214678
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing 

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

[Eran Rosenthal]

Hi,
Wiki communities can ask to override their default configurations
(following consensus). The reasons to override may vary:

   1. *customization* for community to align to community specific policy
   (example: special namespaces / upload policy/user groups rights defined per
   project and language version)
   2. *technical dispute* where community and engineering don't agree
   (example:  VE as single tab for enwiki[1], disabling description tagline in
   enwiki[2] etc).

Technical dispute are problematic - if the product is not good enough
engineering and community should ideally come with a solution how to
address the issues. We can define a plan to fix the product (disable till
task X is fixed), enable/disable feature in the USER level if it is a
matter of choice (not the site level) etc.
Anyway we should try to avoid letting specific communities override
defaults for long term if there is no community specific reason to override
the configuration. This create a jungle of configurations, inconsistent UI
across languages and more complex maintenance etc.

This is a call for action for the wiki communities and engineering:

   - Engineering - consider to align all wikis to similar configuration if
   it isn't community customization but "technical dispute"
   - Communities - consider whether these configurations are old and can be
   removed

Examples of issues found in wmf-config:

   - VisualEditor tabs (wmgVisualEditorUseSingleEditTab 60 wikis "Deploying
   slowly with community advanced notice"?
   wmgVisualEditorSingleEditTabSecondaryEditor - enwiki overrides the default
   editor)
  - and more generally enabling VE deployments:
  https://www.mediawiki.org/wiki/VisualEditor/Rollouts
  - Patroling
  - wgUseRCPatrol - disabled by default but ~80 wikis enable it. Should
  be enabled for all wikis? (if not - what is missing from getting it
  deployed in more wikis? are there alternative feature for it
used in other
  wikis?)
  - wgUseNPPatrol/wgUseFilePatrol - few wikis override it. Do we really
  need to override it?
   - wgImportSources
   - Each wiki define arbitrary list of wikis it import from. We should get
  rid of it and allow import between any Wikimedia site. See
  https://phabricator.wikimedia.org/T17583
   - wmgUseSandboxLink
  - Enabled in 80 wikis. Why not enabling it everywhere?
   - wmgUseWikiLove -enabled in ~50 wikis including enwiki. is there a
   reason to not enable in all wikis?

Thanks,
Eran

[1] https://phabricator.wikimedia.org/T128478
[2] https://phabricator.wikimedia.org/T161805
[3] https://phabricator.wikimedia.org/T214678
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l