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 <risker.wp(a)gmail.com> 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 <eranroz89(a)gmail.com> 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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l