[Collaborators] Repository Cleanup, rules and other stuff #176

New Issue

2025-11-06T06:36:26-06:00

GiteaMirror commented

2025-11-06 06:36:26 -06:00

Originally created by @Penaz91 on GitHub (Sep 28, 2025).

Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.

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.

Originally created by @Penaz91 on GitHub (Sep 28, 2025). Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub. 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.

GiteaMirror added the discussion enhancement maintenance labels 2025-11-06 06:36:26 -06:00

GiteaMirror commented

2025-11-06 06:36:28 -06:00

@DrKJeff16 commented on GitHub (Sep 29, 2025):

(#1507 👀)

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

@DrKJeff16 commented on GitHub (Sep 29, 2025): (#1507 :eyes:) Yeah, I've come across with a few stale repositories...

GiteaMirror commented

2025-11-06 06:36:28 -06:00

@rockerBOO commented on GitHub (Oct 17, 2025):

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!

@rockerBOO commented on GitHub (Oct 17, 2025): 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!

GiteaMirror commented

2025-11-06 06:36:29 -06:00

@DrKJeff16 commented on GitHub (Oct 17, 2025):

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

@DrKJeff16 commented on GitHub (Oct 17, 2025): > 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

GiteaMirror commented

2025-11-06 06:36:29 -06:00

@rockerBOO commented on GitHub (Oct 17, 2025):

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.

@rockerBOO commented on GitHub (Oct 17, 2025): 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.

GiteaMirror commented

2025-11-06 06:36:29 -06:00

@DrKJeff16 commented on GitHub (Oct 17, 2025):

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.

@DrKJeff16 commented on GitHub (Oct 17, 2025): 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.

GiteaMirror commented

2025-11-06 06:36:30 -06:00

@Penaz91 commented on GitHub (Oct 17, 2025):

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

Threw my 2 cents in there. Thank you!

@Penaz91 commented on GitHub (Oct 17, 2025): I see you're doing a lot of heavy lifting already @DrKJeff16, very clean issue! Threw my 2 cents in there. Thank you!