@Urbanecm_WMF you were interested in bringing the #growthexperiments-communityconfiguration work into core, would this be a use-case where we could do that and support another extension (PageTriage)?

In T323632#8416229, @kostajh wrote:

@Urbanecm_WMF you were interested in bringing the #growthexperiments-communityconfiguration work into core, would this be a use-case where we could do that and support another extension (PageTriage)?

Hello! Yes, I think this would be a great use-case. I (finally :)) filled T323811: [EPIC] Community configuration 2.0: Factor Community configuration out of GrowthExperiments to record the idea of moving Community configuration elsewhere, and listed this task as a possible use-case.

Even though i created this ticket (3 years ago), looking at it with fresh eyes i am not sure this is the best approach. These values are normally set in operations/mediawiki-config and there is a standard way to do it there.

For preparing to deploy pagetriage to ruwiki, i imagine iniquity setting up a localhost wiki with pagetriage and exploring the features. Then noting their preferred settings. Then we can make one big settings patch for the mediawiki-config repo and be all done with configuring.

Where community configuration could hypothetically come in handy is if there are some settings that need to change frequently. I am not sure pagetriage wg variables need to change often though. I think they typically stay static.

I'm going to disagree with Novem Linguae here. I see it as a matter of jurisdiction - this is information that should be controlled by the local community, which if it should be changed (regardless of how rare that is) then there's no reason to force that change to go through the site-requests process, or for the PageTriage developers or sysadmins to have to care.

In T323632#10793676, @Novem_Linguae wrote:

Even though i created this ticket (3 years ago), looking at it with fresh eyes i am not sure this is the best approach. These values are normally set in operations/mediawiki-config and there is a standard way to do it there.

For preparing to deploy pagetriage to ruwiki, i imagine iniquity setting yp a localhost wiki with pagetriage and exploring the features. Then noting their preferred settings. Then we can make one big settings patch for the mediawiki-config repo and be all done with configuring.

Where community configuration could hypothetically come in handy is if there are some settings that need to change a lot. I am not sure pagetriage wg variables need to change often though. I think they typically stay static.

Agreed for the most part, I think the major thing that needs to be moved to community configurations is the two (previously js, now json) files. I'll go through these and mark anything that seems community configurable (a lot of these unfortunately might require a peek from DB folks if too-high values are set).

In T323632#10793679, @Pppery wrote:

I'm going to disagree with Novem Linguae here. I see it as a matter of jurisdiction - this is information that should be controlled by the local community, which if it should be changed (regardless of how rare that is) then there's no reason to force that change to go through the site-requests process, or for the PageTriage developers or sysadmins to have to care.

I completely agree. I will also add that the community configuration helps with several things:

1. It saves developers from constant +2 checks where it is not important for development.
2. Increases community awareness of possible extension settings, since the settings are always hidden somewhere and many simply do not know about them.
3. Helps overcome the Phabricator barrier for non-technical administrators, i.e. many settings do not change because people are afraid to write tickets.
4. Simplifies work with the extension in general for all involved users.

In T323632#10793698, @Soda wrote:

a lot of these unfortunately might require a peek from DB folks if too-high values are set

Yes, changes that can break production should not be in CC.

Agreed mostly with Soda's edit, except I would put the noindex stuff in community configuration, and let the wikis deal with how Google handles noindex at their peril.

Change #1221986 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/extensions/PageTriage@master] [WIP][DNM] Move deletion tagging into community configuration

https://gerrit.wikimedia.org/r/1221986

Change #1221986 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/extensions/PageTriage@master] [WIP][DNM] Move deletion tagging into community configuration

https://gerrit.wikimedia.org/r/1221986

Based on a talk with folks on Mod-Tools last week, not gonna go forward with the patch unless there is community interest (since properly implementing CommunityConfigurations will require some amount of rethinking of the deletion module as well)