Nvim-treesitter (13K+ Stars) is Archived

You could probably make things work without nvim-treesitter, but it's an additional maintenance burden you're taking on. As the repo itself says, it's an abstraction layer. You don't _need_ it, but it's nice to have.

tree-sitter still works. Many features are implemented in neovim itself. This project provides an easy way to set up parsers for various languages (including installation and retrieval of necessary queries), along with some quality-of-life features. You can just fork it, and it will work perfectly fine for the 0.12 cycle (barring any underlying parser changes), or you can fork the previous version on the master branch if you want to keep using 0.11.

Considering this is a very common plugin in the neovim ecosystem, it will probably get forked and maintained by someone else, like null-ls was forked into none-ls.

Think of the average person, in terms of communication skills, education, critical thinking, emotional regulation, etc. Now realize that half the population is below that.

If you're in a social bubble, which is hard to avoid nowadays, I recommend watching police body cam videos to help recalibrate where the ends of the spectrum are. It's also given me sympathy for police in general

Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!)

Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover?

1a) A project that has recent commits, but has pull requests and issues disabled.

1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it.

2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled.

2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it.

As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub.

Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.

You could add your own banner that makes it clear what the status and expectations of the project are. In fact, that is probably a valuable thing to do if the project is archived too.

If you archive it, then sure user's are less likely to send you disrespectful messages by whatever means (assuming they can find such means), but they are also less likely to use it, because you have basically said "this project is abandoned". Which if you don't want users at all, I guess that's fine, but then I'm curious why you bothered to publish it publicly at all.