Comment by jessriedel | Hacker News Reader

Comment by jessriedel | Hacker News Reader

Parent Full thread

> We're left with barebones facts that are of no help to anyone looking for reliable information about the band.

The fact that the band exists and has a newspaper article about it is helpful. Otherwise it's article will be very short. So what?

> All of this applies equally well to little-known authors, random Indian corporations, and your cat.

Yes to the first two. (My cat has zero verifiable information about it.) They will have very tiny stub articles. So what?

> If all we have to go on is a couple of primary sources and maybe a passing mention in the press, what is there to say without giving undeserved credence to the primary sources?

So don't say anything else.

I really, really don't understand what's motivating your position. I'm trying!

> But really, I'm just rewriting the ideas of the consensus based notability guideline, which is much better written and specific: https://en.wikipedia.org/wiki/Wikipedia:Notability

That page is almost exclusively about defining notability (which, because of the intrinsic vagueness, necessarily takes a long time and is mostly unsuccessful). The only part that's directly about the reasons for the requirement is this subsection:

https://en.wikipedia.org/wiki/Wikipedia:Notability#Why_we_ha...

And the only argument it brings up that I didn't address is this: "We require multiple sources so that we can write a reasonably balanced article that complies with Wikipedia:Neutral point of view, rather than representing only one author's point of view." This, again, is something that can easily be addressed by just requiring verifiability to include coverage by multiple sources. (Even in highly notable articles, there are a large number of facts that are only verified through a single source; this isn't a reason to delete the fact.)

The problem Wikipedia sees for these very short articles that state nothing other than the fact that they were mentioned in passing in a newspaper article is that there is no potential for them to ever be good articles. The band is defunct, no additional reliable sources will ever be created for it, all available sources have been exhausted to produce an article of almost no value.

You're right that the article has some marginal value. I think many deletionists would even agree.

The problem is risk/reward. Every WP article is a commitment to defend a topic against entropy and malice. Every article is part of the attack surface exposed to vandals and spammers.

So in the view of most of Wikipedia, articles that are fated to forever remain "stubs" have negative net value.

Reasonable people can obviously disagree about this, but I find the deletionist argument against zombie stub articles to be very compelling.

> Every WP article is a commitment to defend a topic against entropy and malice.

But at this point you've basically given up any attempt of civil community processes and you're doing things not because they are right, but because not doing them might give the enemy a speculative advantage.

I don't understand. My paraphrase of Wikipedia's position on (what I'm calling) zombie stub articles is that the risk/reward for them doesn't pan out. They have marginal positive value but pose significant risk of overhead and error.

But that's very much not the case with other stub articles, or even other zombie articles (where sources have no doubt been permanently exhausted, but the sources we have today make room for a solid 100 word article).

I my have read too much into the word "defend", but before my inner eye I saw all-out war against "them".

All over some moderately important issue, at best.

If that were true, we'd refuse to have articles on Middle East topics and tell people to look elsewhere, because it's an absolute nightmare and NPOV routinely loses to people with agendas. But it's worth it in the mission to be a comprehensive encyclopedia.

If this is really a problem, why not just lock the article at a stub with a few verifiable facts? How is this more editorial work than deleting, and fighting a subjective battle over notability?

Because it's obviously (well, to me) better to leave the article in the default state of not existing and have the option of allowing anyone to quickly add coverage, rather than needing a committee to unlock a topic if it does become relevant. This is good adherence to the "Wikipedia Is Not Paper" idea.

Except that there already exists a whole special mechanism for patrolling frequently created-then-deleted pages.

You only need to lock stub articles that repeatedly have people add unverifiable info to them.

Finally, if the pages doesn't exist, then anyone who wants to exercise the "option...to quickly add coverage" doesn't have access to the info that would have been contained in the stub!

In my opinion, there is absolutely no reason to have a tiny stub article with information of no interest to anyone. Keeping the band example going, people come to Wikipedia to read about a band without diving into everything that has ever been written about them; if there's nothing to say, we can't help. But I guess your question is more "why not?" Editors will spend more time per year reverting vandalism and removing original research than readers will ever spend using it. And that's really, really optimistic: what actually happens with stubs on little-known topics is that they fill to the brim with original research and info from bad sources, and anti-vandalism editors don't stop it because either they don't know if the sources are good, or they're rightly afraid of being yelled at for removing content, since anything looks like a potentially constructive addition to a shell of an article. If you require a decent amount of sourced information, someone adding a wall of text without adding references looks suspect and is (somewhat) more likely to be removed in a timely manner.

If this is really a problem, why not just lock the article at a stub with a few verifiable facts? How is this more editorial work than deleting, and fighting a subjective battle over notability?

I can't understand why you think one can't defend against this stuff using mechanism that don't lead to effects like the one described by rsync https://news.ycombinator.com/item?id=13159057

This is answered here, in the second place you asked this question:

https://news.ycombinator.com/item?id=13161015

(better if replies go there too)

OK. I explained there why I think resfirestar's answer is unsatisfactory, i.e., why there are easier, cleaner, and less destructive ways of dealing with that problem than using notability. Would still be interested in your take there.

Addressed the locking below. I'm sympathetic to rsync.net, and maybe I spent too long in the Wikipedia bubble, but what exactly is the argument for it having a Wikipedia article?

>rsync.net has been mentioned in the press widely over the course of over 10 years - everything from articles about our warrant canary to articles about our ZFS support. In fact, other wikipedia pages mention and discuss rsync.net.

So it's had some coverage related to first commercial use of a warrant canary and is discussed in that context. It commercially implemented a feature of rsync (the application) that should be talked about on the page about rsync the application. But what can be said about rsync.net? Maybe someone read about their warrant canary and wants to know more about this company...but no independent source has written about who they are and what makes them so savvy with opsec and rsync. Anything outside those narrow topics is original research or primary sources. I think things are working as intended.

You're arguing that because the info on rsync.net is contained in other Wikipedia pages, there's no point in having an rsync page. But the page discussing ZFS support doesn't link to the discussion of the warrant canary, i.e., there's nowhere to go to find all the rsync.net info on Wikipedia. And the reason to not have this page is...because it's too much of an exposed surface for bad actors?

Reply on news.ycombinator.com