Final Fantasy Wiki
No edit summary
(reply)
 
Line 23: Line 23:
 
:The point is big edits to these pages '''shouldn't''' merely be reviewed by one mod. They must be reviewed by the community and by the consensus process. The pages are delicate where they are because an addition of a paragraph may be grammatically correct and formatted properly with the right sources, but we would still have reason to reject it if we find it harms the flow of the page or makes it too lengthy. The hardest part of writing these pages was saying as much as possible in as few words as possible.
 
:The point is big edits to these pages '''shouldn't''' merely be reviewed by one mod. They must be reviewed by the community and by the consensus process. The pages are delicate where they are because an addition of a paragraph may be grammatically correct and formatted properly with the right sources, but we would still have reason to reject it if we find it harms the flow of the page or makes it too lengthy. The hardest part of writing these pages was saying as much as possible in as few words as possible.
 
:'''That said''', aside from the fact I don't think mboxes belong on finished pages (but am fine with it appearing as a sort of in-editor popup), I am happy with the proposal. I'll add when new media releases that an article should have an mbox then and be required to go through the consensus peocess before the mbox is removed.--{{User:Technobliterator/Talk}} 20:33, 17 August 2022 (UTC)
 
:'''That said''', aside from the fact I don't think mboxes belong on finished pages (but am fine with it appearing as a sort of in-editor popup), I am happy with the proposal. I'll add when new media releases that an article should have an mbox then and be required to go through the consensus peocess before the mbox is removed.--{{User:Technobliterator/Talk}} 20:33, 17 August 2022 (UTC)
  +
::Sure, an in-editor popup sounds preferable to an mbox on a good page (there's no such thing as a finished page, but I digress). This is strongly preferable to hasty rollbacks or sysop-level protection IMO. [[User:Catuse167|Cat]] ([[User talk:Catuse167|meow]] ∙ [[Special:Contributions/Catuse167|hunt]]) 21:03, 17 August 2022 (UTC)

Latest revision as of 21:03, 17 August 2022

FFWiki forum logo
Forums: Index > Rin's Travel Agency > Archive > Permanent locking Cloud Strife, Tifa Lockhart, and Aerith Gainsborough


Technobliterator

As stated, this proposal seems a bit overkill. Since Tifa Lockhart was locked at autoconfirmed level in February, it has received only one edit. If our mods is really incapable of reviewing the tiny amount of edits that make it past the usual safeguards of autoconfirmed + abusefilter, then a better solution sounds like aggressively recruiting more mods. And if that's what the problem here actually is, then that just means that I need to put on my bcrat hat and get to work.

That said, the current status quo is problematic, to say the least. It's a really bad look if we say that we're the "database that anyone can edit" and then if a newly autoconfirmed user makes a change to our front-facing pages it's immediately rollbacked: this sends a message that our slogan is a bit of a lie. So, counterproposal:

If FFWiki, through a public-facing process such as Rin's Travel Agency or a talk page, identifies a page as both high-traffic and high-quality, then that page will be locked indefinitely, and given an mbox saying "if you want to make a major edit, or are anon and want to make a minor edit, please discuss on the talk page first, other edits are liable to be reverted". This protection should be used sparingly, and should be dropped when new media comes out concerning the article's subject (eg, when the next FFVII Remake part drops).

There's a somewhat orthogonal issue that I think gets conflated with the above issues: the shipping wars. The evidence of the autoconfirmed protection on Tifa Lockhart is quite clear IMO: it almost entirely wipes out the influx of Twitter meatpuppet weirdos. So this counterproposal would also deal with shipping war nonsense. Cat (meowhunt) 15:18, 17 August 2022 (UTC)

The point is big edits to these pages shouldn't merely be reviewed by one mod. They must be reviewed by the community and by the consensus process. The pages are delicate where they are because an addition of a paragraph may be grammatically correct and formatted properly with the right sources, but we would still have reason to reject it if we find it harms the flow of the page or makes it too lengthy. The hardest part of writing these pages was saying as much as possible in as few words as possible.
That said, aside from the fact I don't think mboxes belong on finished pages (but am fine with it appearing as a sort of in-editor popup), I am happy with the proposal. I'll add when new media releases that an article should have an mbox then and be required to go through the consensus peocess before the mbox is removed.--Magicite-ffvi-ios Technobliterator TC 20:33, 17 August 2022 (UTC)
Sure, an in-editor popup sounds preferable to an mbox on a good page (there's no such thing as a finished page, but I digress). This is strongly preferable to hasty rollbacks or sysop-level protection IMO. Cat (meowhunt) 21:03, 17 August 2022 (UTC)