[Collaborators] Repository Cleanup, rules and other stuff

[Penaz91]

Hello @rockerBOO ,

I noticed that there are quite a few requests for plugins (via opened issues) as well as kind-of-stale pull requests (some are from mid-2024).

I would be willing to comb through those and add them in the right sections to close and clean up the repository situation a little bit as a one-time thing.

Any thoughts on this?

---

On a different note, I noticed that there is no real rule on where to put plugins in sections, so some people put them in any place that happens to be around.

There are some possible positions:

• Alphabetical order: technically fair, no "first-come-first-served" policy, but hard to maintain
• At the end: essentially a first-come-first served fashion
• On top (prepending), allows us to see the title of the section any time we review a pull request, but gives "an advantage" to the newer plugins.

I would like to know you thoughts on this.

---

What are the rules on archived repositories?

By keeping around archived repositories for a long time inside the list, I feel that the quality of the list as a whole will diminish as more and more unmaintained plugins stop working.

[DrKJeff16]

(#1507 👀)

Yeah, I've come across with a few stale repositories...

[rockerBOO]

We can go through the different plugins for any invalid ones or archived. Archived might have people who are maintaining a fork but they can add their fork after? There is an issue where multiple people make forks but that is more rare and can be considered as they come in.

Plugins without recent development might be working fine (like I have a colorscheme I use but I don't update it that often).

I have some scripts that can evaluate the plugins repos for their status to automate checking if any are archived and add it to the daily/weekly check. They are shell scripts in scripts/ but they can be improved too. Put them together with some AI but they could be improved if that helps with the maintaining.

Originally I wanted to set the order to be at the end for new plugins, but over time didn't want to add friction to adding things to the list. I think we can see how it goes by setting some order rule in there and see how it goes.

The list should probably be in alphabetical order (the main categories) as that will help with finding the thing you want easier. I think Neovim Plugin manager might make sense to have at the top still, but I could see it just be as part of the overall alphabetical order.

So what I'm thinking is along these lines:

• Add automation script or validate for any archived/404 plugins.
• Add rule for "end of section"
• Reorder list to be alphabetical in sections

Let me know if there are any questions on these.

Of course no pressure for anyone to do these but it could clean it up quite a bit.

Thanks for this!

[DrKJeff16]

Plugins without recent development might be working fine (like I have a colorscheme I use but I don't update it that often).

I'd wager some plugins may require more active maintenance than others (given how Neovim development could break stuff, or not), complicating this issue.

Unless we rely on users raising an Issue here to remove/replace them (which might not be as common as I consider), or periodically check them manually (an increasingly harder task for obvious reasons), I am not very sure about what'd be prefferable here.

I'm unaware of a convenient way of automating this. No, it doesn't have to be perfect but I think there could be a bit of margin of error. I'd prefer to know what you think of it, or if you disagree, your reasons.

---

We can go through the different plugins for any invalid ones or archived. Archived might have people who are maintaining a fork but they can add their fork after? There is an issue where multiple people make forks but that is more rare and can be considered as they come in.

Should visibly unmaintained (though unarchived) repositories be cleaned up aswell?

My reason here is that some repositories listed here haven't been archived yet seem very unlikely to be maintained again. In fact many repositories just stop being maintained, even without a notice in their README.

Examples

• https://github.com/nvim-lua/lsp-status.nvim
• https://github.com/ahmedkhalf/project.nvim

[rockerBOO]

For unmaintained maybe we can use our discretion but maybe 2 different maintainers can agree.

Reviewing the issues and see if they have people asking about maintenance, and if the maintainer fails to respond in a long window it might indicate it won't be.

I think it will be up to best effort to check these plugins, but I do not expect that we'd check them generally.

We can probably make a script to review the last commit from the plugins, and then that would help indicate some to look at. Then review issues for any unmaintained, or just maintain terms in general. That would isolate the number of plugins to check and can be run to check any new unmaintained plugins.

There will be some limits to API usage probably, so would need to manage what is reviewed in this way.

[DrKJeff16]

I've taken the liberty to start checking one by one to see which ones might need cleaned up in #1710.

If warranted, any feedback is welcome.

[Penaz91]

I see you're doing a lot of heavy lifting already @DrKJeff16, very clean issue!

Threw my 2 cents in there. Thank you!

[wsdjeg]

Alphabetical order: technically fair, no "first-come-first-served" policy, but hard to maintain

How about using toml file? and generate the readme via github action.