Hacker News Title Edit Tracker | Hacker News Reader

Hacker News Title Edit Tracker

hackernewstitles.netlify.app

33 pointsspa3thyb36 comments

It looks like the mods are sticklers for capitalization. I’m looking forward to seeing this post’s title edited.

One could add "(2019)" to the end of it.

Perhaps a bothersome aspect of title changes is we are not told the reason(s) behind the edits. For example, if an HN reader is emailing the moderator and asking them to change a title, other readers might want to know that, along with knowing what was the original title. Whereas if it is a small correction, like adding "(2019)" to the end, perhaps few readers would really care. Sometimes we can decipher the reason, other times not.

Another bothersome aspect might be the arbitrtary applicaton of title changes. Some titles get changed based on some discernible criteria while others do not despite meeting the same criteria.

It is quite common for HN titles that exactly match the submitted web page's <title> to be subsequently changed to something else after submission, even though HN guidelines state that titles should not be editorialised.

The guideline also includes when titles should be changed: "Please use the original title, unless it is misleading or linkbait; don't editorialize." - https://news.ycombinator.com/newsguidelines.html

Editorializing is when the submitter uses the title to express the submitter's own point of view about what's important in the article or the story. When we change a title, we're scrupulous about not doing that. We always look for an accurate, neutral title using representative language from the article itself (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).

Under this definition of "editorialize", instances where someone else besides the submitter uses, i.e., changes, the title to express their own point of view about what's important in the article or the story are not examples of editorializing.

Why not let people make up their own minds. The source of the article or story chooses a title; it is their right to do so. Readers may or may not agree with that choice, and they are free to point out where they believe it may be misleading or "linkbait". What is the harm in allowing readers to draw their own conclusions. By changing the title, that process of review by a variety of readers is prevented. Why not let readers be independent thinkers.

I don't understand your first paragraph.

The whole point of HN's approach to titles is to let people make up their own minds. The title is by far the most important influence on a thread. Nothing else comes close. Letting submitters rewrite titles to suit their own point of view amounts to conferring the power to control the entire discussion, or at least strongly influence it. On HN, being the person to submit an article does not convey any particular authority over the content.

HN's moderation practice around titles has been well established for over a decade. Accurate, neutral titles, preferably using representative language from the article itself, are probably the single biggest thing that keeps this site the way it is.

Ultimately, the title rules cannot be coded into programming logic and fully documented; they’re a mix of predictable (No Studly Caps) algorithms, submitter’s edits, and moderator’s edits. Human judgment calls are expected - for example, titles should be edited to be succinct when necessary, but never to present the submitter’s opinion. Criteria will not always be applied consistently, each submitter and moderator is a different person, and not everything is seen and fixed when it’s slightly or greatly wrong.

It is what Y Combinator is about after all.

This is probably just evidence that I care about something unimportant, but sharing this after noticing a diminishing change today:

In first, US surgeons transplant pig heart into human patient

↓

U.S. surgeons transplant pig heart into human patient

in reference to https://news.ycombinator.com/item?id=29882912

You aren’t alone. I’ve noticed a major uptick in these types of editorial changes that remove or obscure the intent of the underlying content. They don’t seem to follow a consistent editorial standard or voice, and are having a noticeable effect on the quality of the HN UX.

There's no uptick. The mod practices around titles haven't changed in many years.

It's also probably a lot more consistent than it seems. That doesn't translate into perception, though, because people tend to notice the ones that annoy them. I wrote about this here: https://news.ycombinator.com/item?id=23954907

Do we know who is doing these edits and why?

It could be the submitter, the software, or the mods. For example, the submitter did this one:

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

but the mods did this one:

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

Peter's tool doesn't tend to pick up software edits because most of those happen on submission, which is before the tool picks them up.

Since you seem to be logging edit history internally, how about making that visible to users? There would be a lot less confusion and paranoia around if it were obvious when an edit was made and by whom.

Alas, I think the odds are that there would be more, not less. Certainly there would be a lot more fodder for it. These things don't explain themselves, after all; we still have to do that, and it's a ton of work. It's also stressful—it's all public, and if you screw up in any way, you can easily generate more hostility and more work for yourself.

I think the current approach, in which we don't publish everything we do but are happy to answer specific questions when people ask them, is the right balance.

You could ask the mods why directly about the pig heart article, if you’re seriously interested, using the footer contact link. I wouldn’t do this for every edit and expect a reply, but it seems like asking them to chime in here for a single case study would be simpler and more factual than guessing at reasoning, and I imagine they’re probably willing.

I like the latter title better; I can understand the editorial stance because “first” does sound a bit click bait like.

And that's the problem: it's an editorial stand that finds the thought offensive that any news headline is ever clicked on. So it removes anything that makes it sound "too interesting" even if it happens to also be an accurate statement.

In the case of the pig's heart, there is no doubt that it is the first such transplant. Arguably, people know as much and it doesn't need to be pointed out. But it's borderline and with a bit of appreciation of the fact that headlines are creative works just as much as the text, I'd argue for a bit more deference to the people who have probably put a lot more thought into the headline.

Anyone have a browser extension or alternate UI that integrates this into the main page? I hate seeing an interesting-sounding new story that turns out to just be the one I read this morning with a different title.

Curious how something such as this is actually implemented. Is there a feed that you are subscribing to? Are you consistently polling posts looking for changes? Or is it some third option?

You could ask https://news.ycombinator.com/user?id=petercooper, who wrote it.

I thought it had been submitted more often but I guess it has mostly been mentioned in comments: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

A lot of title changes are apparent in the RSS feed, the new title appears as a new item with the same URL.

I’m not sure how you’d disambiguate merges that way, as they have the same symptom, but the process isn’t invisible.

There is an API link in the footer of the page.

Why doesn't HN have an auto-title suggester that si ply pulls in the title of the target URL? Would save a lot of heartache.

There's no "the title" - there are lots of choices, including the HTML doc title, the URL itself (which sometimes-has-a-hyphenated-title-like-this), headings on the page. None is reliably the best choice, and all of them are frequently crap; frequently enough that it wouldn't make sense to have any of them be an official suggestion.

And yet the guidelines suggest you use "the original title":

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

I don't think that ends up being confusing even though "the original title" could mean HTML element or biggest heading on the page, it works out, we know what you mean. (I think it's usually the biggest visible heading on the page, rather than mostly invisible HTML title element).

Since the guidelines literally do say to usually, if there isn't a reason not to, use, or at least start with, the original title... I agree it would be helpful if the submit form had an option to pre-fill the "title" field with the original title scraped from the article, like reddit does. You can always edit it before submission, it's just a pre-filled convenience. Which is how reddit UI works.

I think this would be a convenience to those following the guidelines (which totally tell you to start with the original title!), plus perhaps increase compliance with the guidelines by making it the path of least resistance.

On the other hand, it may reasonably not be the highest priority for development, I know you have a backlog. But I don't follow the argument that it would be counter-productive or impossible.

The bookmarklet fills the title field with the HTML document title.

You're not wrong. I've seen subreddits do it though and it worked really well. You can always alter the "suggestion" before submitting

Bookmarklet in Safari:

    javascript:window.location=%22http://news.ycombinator.com/submitlink?u=%22+encodeURIComponent(document.location)+%22&t=%22+encodeURIComponent(document.title)

Might need some change in encoding/quoting for other browsers, IIRC.

A filter at the top for common changes would be nice to have. Maybe one for case changes, and year additions.

Note that not all title changes are mod edits. They could be from the original submitter.

Only within the first ~10 minutes post-submission

The edit window is usually 2 hours.

In my experience the title edit window is shorter than the post edit window. I could be mistaken. You are an authoritative source.

When can we expect a browser extension that restores the original titles? :)

That would be great :)

Brilliant.

Reply on news.ycombinator.com