Creating tracking bug for ease of further future changes
Description
Details
- Reference
- bz29744
Event Timeline
After talking this through with colleagues, our answer is that we are not accepting new wikis to enable Flagged Revisions, given the very significant problems that Flagged Revisions poses in terms of engaging new users, adding complexity and confusion to the existing too-hard-to-understand interface, and badly impacting the quantity, quality and depth of the wikis on which it has been used.
Sorry for the slowness of the response.
I am going to rise this question again in the community, as I don't think WMF should impose such limits on the individual communities. Either we should have a lot better explanation or Jdforrester-WMFs blocking of this must be overruled by WMF itself.
Hmmm... there is the main issue of who is willing to configure Flagged Revisions.
On philosophical grounds, as a volunteer, I'm not really inclined to handle such requests. @Reedy in your bug explicitly says the configuration process is painful.
So, to process Flagged Revisions requests, we need a volunteer who:
- doesn't have any conscientious objection
- knows how Flagged Revisions work
- has two to six hours of time to contribute to the initial configuration, then also blocks of one to two hours to see how things evolve, and if tweaking is needed, as a weeks/months commitment.
Or we can assign these tasks to a WMF employee, with the same heavy time and commitment constraint.
To get feedback from the global community on the FlaggedRevs deployment opportunity, I've launched a RfC on meta.
We have translated the system messages.
(this is a consensus) Please install FlaggedRevs extension on azwiki.
@Neriman2003: This task T31744 is a general task. Please discuss azwiki-only stuff in its existing dedicated task T194389. It is off-topic here. Thanks.