Looking for new maintainers

[majutsushi]

You've probably noticed that there hasn't been much activity here lately, and I'm really sorry about that. The last thing I would want for Tagbar is to just slowly die or become fragmented by forks. But I just hadn't had the time for a while now to keep up with all the issues and feature requests, and I have to face the fact that that's not likely to change, especially since I don't even use Tagbar myself that much at the moment.

So I would like to ask if there are any people who would like to take over as maintainers of the project. There have been some great contributions in the past, but of course I don't know how people feel about taking on this responsibility. I think ideally Tagbar would be moved to an organization like ctrl-p did, but that's of course just one possible way.

For anyone interested in this, please let me know here, and sorry for ignoring this for so long.

[wsdjeg]

I would like to help with this plugin, here is a list of features I want to implement.

• use job to run catgs, and make it more fast.
• use neovim buffer API to update plugin buffer without switch to tagbar window.

[alerque]

I would be willing to step in as a maintainer at least to keep bug fixes under control, make sure PRs get some testing and accepting if they are good, and triaging issues. I do actively use tagbar ever day so it's survival matters to me, but I would not be seeking to actively develop it.

For reference see what I've done with taking over maintenance of nerdcommenter a while back, and also vim-pandoc, vim-ledger, etc. Note that nerdcommenter in particular had stagnated badly and dozens of forks had cropped up fixing various problems. I successfully worked through the PR backlog and got almost all the forks reintegrated, and have kept things tidy since.

The namespace isn't hugely important, but I wonder if there are any existing orgs out there that have vim plugins of assorted flavors (not topically related to something else in the org) hosted under a namespace for facilitating exactly this kind of thing...if not I'd be interested in starting one if there are some other devs with vim-plugin history that would like to join the effort.

[alerque]

I looked around a bit and didn't find any orgs like what I was describing, so I stared one. Feel free to suggest a better name if you can think of one. @majutsushi I have invited you to the org, and my personal recommendation is that this repository me migrated there and (eventually) at least 2 people besides yourself be made owners.

Feel free to not join if you'd rather put this under a dedicated umbrella just for this plugin or whatever, but this is hardly the first highly rated and widely used vim plugin that has needed an org home, and I think they could probably mutually benefit from having a common space.

[wsdjeg]

I recommend to keep repo under author's account， that will be easy to searching.

[wsdjeg]

and if people really want to use org, @vim-tagbar is better

[alerque]

@wsdjeg Are you aware GitHub connects migrated repositories from their old address with redirects? Even git checkouts and pulls are covered. That being the case I'm curious what you mean my "better for searching"?

[bam80]

Can we migrate to GitLab maybe?

[alerque]

@bam80 I'm quite happy using Gitlab (and use both the company hosted free instance and self-host it for my own private projects) in general, but I'm not sure its the best idea for vim plugins to not be on Github. It's unfortunate in many ways that the OSS world has become so centralized, but in the interest of promoting the project to both users and potential contributors GitHub is currently the best home. Of particular relevant to vim plugins is the fact that almost all plugin managers have build in aliases for installing from and understand GitHub repositories out of the box. While most can adapt to other sources it is usually not well understood how to.

In the interest of contributors, maintainers, and users I'd suggest for now sticking to this realm is probably best.

[bam80]

almost all plugin managers have build in aliases for installing from and understand GitHub repositories out of the box

Probably they can also install from any Git repo with the same success?

[alerque]

@bam80 Not exactly. The typical installation looks like this:

Plug 'majutsushi/tagbar'

Yes most plug-in managers can handle full git repo addresses as will, but the built in assumption about default repositories is the path of least resistance.

For some projects I work with that have technical or ideological reasons not to stay on GitHub (e.g. PRISM-Break) I fully supported the migration to Gitlab. For this project I just don't see the benefit of moving. Less visibility to users, less buy in from contributors, and no relevant bentfits.

[majutsushi]

Thanks @alerque and @wsdjeg ! I've added you both as collaborators since you're both clearly already experienced. I've actually been wanting to change Tagbar to run (u)ctags asynchronously as well if the functionality is available, I just never had time for it. I'm not really familiar with Neovim's buffer API but it sounds like it would be useful, I just think it would be good to not make Tagbar Neovim-exclusive.

I agree that it's probably better for now to leave the repository where it is, it can always be moved later if necessary.

[gryf]

@majutsushi thanks for this plugin and good luck with whatever you up to :)
@alerque, @bam80 it might be pretty simple to set up mirroring facility between github and gitlab, just to automatically propagate commits.

[majutsushi]

I was just about to close the issue and update the readme, but I see that you're ahead of me! Thanks for all of the work already :)