The fact that you felt that you needed seven lines of pull-quotes to repudiate the "misleading" title is a pretty good indicator that titles are, um, titles and thus cannot carry as much information as one might want. But even after reading the material you quoted, I don't see the title of this submission as inaccurate.

I think removing the word "deprecated" would go a long way towards making the title less misleading.

Well deprecated may not be exactly the right word, but there's not a single word that is totally accurate. Maybe "sunsetting"? :P

That's essentially what deprecated means. It is discouraged to start new projects with it. It doesn't mean that it's dead, but we seem to always take it that way.

Deprecated implies "will stop being supported soon, so you should stop using it as soon as you can". Maintenance mode implies "will continue to be supported for critical things like security fixes, but won't get new features, so there is no hurry to stop using it if you are fine with it staying in its current form forever".

Actually deprecated implies a deprecation timeline, which can be on the order of years.

Python 2 was deprecated when Python 3 was released, but the timeline of transition was over 10+ years.

Django has deprecation timelines that last over 1.5 years.

In Enterprise, its often seen to have deprecation last 7 years.

During deprecation, only maintenance is performed. That is---security fixes.

The real difference between deprecation and "maintenance mode" is that the later is indefinite and implies continuation until profit-loss. AWSv2 isn't in maintenance mode, its deprecated. Eventually Amazon may stop offering it, and doesn't want you to start using it, but while its in operation that doesn't mean they won't close security holes in services that offer it.

Well, how about using the original title - "Surge Focus on Material 2"? It seems more appropriate as nothing in the discussion included a notice on deprecating the 1.x branch.

Since people are concerned with Material 1, we've replaced the title with what seems to be the most representative phrase from the article about Material 1. I couldn't fit in the bit about bugs in the 80 char limit.

(Submitted title was "Google deprecating Angular 1.x Material library and is just closing issues and PRs", which was wrongly editorialized, since the article apparently doesn't say they're 'deprecating' the library, and 'just' is just spin. Submitters: please don't rewrite titles to put your spin on a topic, especially not to gin up controversy. If a title is misleading or linkbait, it's ok to rewrite it (see the HN guidelines), but the new title needs to be accurate and neutral, and should preferably use representative language from the article itself.)

Given the exact words of the post, I'd've added "for Q3", since they didn't say the maintenance mode is permanent.

Not sure if that helps that much though.

I think the issue is saying they are "just" closing issues and PR's.

I understand closing PRs if they're complicated and out of scope, but closing issues doesn't make sense. These bugs don't go away just because the primary developers are leaving.

Closed issues don't go away. Lots of bugs are edge conditions that not enough people care about for the developers to ever pay any attention to fixing. They fall under the category of "sure, and if you submit a PR, we'll merge it". I imagine there's also issues for architectural problems with 1.x which will never, ever get fixed because nobody will be willing to spent the time massively refactoring the codebase. From a developer perspective its pointless to keep those open.

How you feel about this probably depends on if you're a user or developer. If you're a developer you view the issue tracker as a TODO list. If you're literally never going to bother fixing an issue, its best to just close it and move on.

Users seem to view issue trackers as defect trackers and believe that bugs should stay open until they're fixed.

Relevant link that just popped up on HN 24 hours later:

https://blog.jessfraz.com/post/the-art-of-closing/

If active project are always supposed to be closing, then deprecated 1.x branches of projects should have an even higher bar for anything they keep around open.

I apologize, but there's only so much you can do in 80 character titles. It was not my intention to be unclear.

When you:

* Move all of your developers / resources from Project A to Project B

* On the page for Project A you state "Project A development efforts are focused on bug fixes and minor improvements."

* THEN you go and close a bunch of valid even minor / easily fixed bugs (ex https://github.com/angular/material/issues/1659) and PRs stating "This issue is closed as part of our Project B efforts."

...it's my opinion that Project A is now deprecated, even if they don't expressly state that it is.