Page MenuHomePhabricator

Pointless fixing of lint filters in discussion pages, especially discussion archives
Open, Needs TriagePublic

Description

The linter filter system, as is currently delivered, puts discussion pages and discussion page archives into its compiled lists of problems. Then people come along , and cycle through lists and edit these pages from any point in time because the linter report tells them to do so. In these identified places this is noise-making for little benefit and becoming very annoying.

Can we please design the system so it is focusing on fixing major issues, and focusing on issues in the CONTENT namespaces as determine for each wiki?

An example: an archived page from 5+ years ago, that people are running bot-like scripts through to fix something that is deprecated is close to insane, Archives are archives, and in any good archival system usually are preserved as are. We don't even have a means to have pages opted out. So we just have people coming in and doing their thing with a tacit encouragement of developers.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 6 2020, 8:52 AM

With few exceptions, the important part of talk page archives is the actual discussion. Many lint errors arise from deprecated markup constructs that impact the readability of pages they appear on (a good example is closing tag semantics, which have changed in the past few years; many talk pages/archives from the distant past have malformed tags which, under the current parsing semantics, cause various styles like strikeout, superscript, or small to be applied to the entire rest of the page); therefore, I would argue, updating this markup is important for preserving the readability of these archives, and broadly speaking does not change the actual text, only the underlying markup and the styling applied to the text. In this light, these updates are desirable and positive. As for the purely preservationist perspective, well, the original markup is still present in page histories.

ssastry added a subscriber: ssastry.Apr 6 2020, 9:18 PM

We provide tools for surfacing problems, and provide specific guidance where we need pages fixed ( https://www.mediawiki.org/wiki/Help:Extension:Linter#Why_and_what_to_fix ). But, I think it is up to individual wikis to figure out their policies around what to fix and how to fix. I imagine different wikis will have different policies. But, that said, to add to what @Dinoguy1000 said, some of these errors will affect readability of archived pages in the long run as the software evolves.

TheSandDoctor added a subscriber: TheSandDoctor.EditedApr 7 2020, 10:10 PM

There is currently an ongoing discussion very closely relating to this on Meta that appears to be garnering consensus in the other direction/against this ticket/proposal.

Thanks @TheSandDoctor. I'm inclined to agree with the emerging consensus on that page as well.

I can totally empathise with not wanting to be distracted by edits that appear to add no value. When two ways of writing the syntax both technically work, then personally I would agree that archived content should remain as-is no matter how unusual, confusing or otherwise unpopular the old syntax may've been. Even if it was written that way by mistake, if it works, leave it! Anyway, that's my opinion. Local communities should make their own policies.

But I hope you can trust the developers that if there was a reasonable way for old syntax to continue to work, we would do so. If you find a linter rule has been deployed without the expectation that the affected syntax will break the rendering of those archived pages, then please contest the general deployment of that specific linter rule, and not the linter system itself or the ways users are helping fix the problems it found.

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

Izno added a subscriber: Izno.EditedApr 8 2020, 3:00 AM

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

There is no guarantee that browsers will continue to support deprecated/obsolete tags/attributes and I think it's a reasonable statement to say that there is also no guarantee MediaWiki will continue to support deprecated/obsolete tags/attributes. (I make no statement or suggestion as to the timeline in which it will come to pass that browsers and MediaWiki will stop supporting deprecated/obsolete tags/attributes.)

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

There is no guarantee that browsers will continue to support deprecated/obsolete tags/attributes and I think it's a reasonable statement to say that there is also no guarantee MediaWiki will continue to support deprecated/obsolete tags/attributes. (I make no statement or suggestion as to the timeline in which it will come to pass that browsers and MediaWiki will stop supporting deprecated/obsolete tags/attributes.)

It's also worth pointing out that any resemblance between a particular bit of MediaWiki markup and a particular HTML element is incidental; all markup is tokenized during parsing, so in theory any unique string could serve as the identifier for any given bit of parsed HTML. Ultimately this means it's perfectly reasonable for some bit of markup to be deprecated by the devs even if an exactly identical HTML element exists and is not deprecated by the W3C (of course, whether it would make sense to deprecate any particular bit of markup is its own question, e.g. I don't think anyone would sanely suggest to deprecate the <br> or <div> tags).