Please, approve co-maintainer

[amerlyq]

I would like to ask you to share write/merge permissions to this repository with somebody interested in from the community. It would allow to boost currently stagnated development of this plugin.
Because your participation in project becomes less and less observable, amount of issues and forks exponentially increases. We need someone to put this in order and quickly respond to requests.

Of course, you could say, fork it and develop by itself. But. Everybody, and newbies especially, chooses trunk with most stars, which currently is yours. There are no distinguishable chances for any other fork to get that many stars in nearest future to outweight this.

I propose @albfan as co-maintainer, if he agrees.
Otherwise, anybody ready to tidy up issues list and revise forks will do.

[albfan]

many thanks but I disagree. With near thousand starts I bet ag.vim is a stable and useful plugin on it's actual shape for many people. @amerlyq let's see if we can organize my fork and persuade @rking about its features, and then let's think on next step.

I will stick on upstream plugin as much as I can, so changing

Plugin rking/ag.vim

to

Plugin albfan/ag.vim

must be an acceptable annoyance meanwhile

[losingkeys]

I haven't heard from @rking in awhile, and as far as I know I'm the only other maintainer (not sure how to check that) on rking/ag.vim. I've been meaning to get to the issues, but haven't found much extra time. I'm hoping to get to them more in the beginning of the new year, and we can discuss merging some forks then if you like.

Some other things this project needs (imo):

• Code of conduct (not that anyone's done anything I've noticed, but it's good to have)
• CONTRIBUTING.md to help codify direction, goals, and help out new contributors

Other than that we should discuss the other forks and see if we can make everyone happy without adding too much code 😄.

[albfan]

Love the idea: lot of talk abd few code changes possible. That implies a lot of code review and some better comunication channel, so I added a room in

https://gitter.im/albfan/ag.vim

And added all of us. Let's see how it goes.

[amerlyq]

Alright, as for necessities, described in initial post on this thread.
I have reviewed all currently active forks, which have diverged/stagnated -- therefore will not be merged eventually, and listed relevant differences in albfan#53 to merge them by ourself.
Also, there was noticed rather often tendency to fork only to change buffer mappings.
Therefore, mechanics to change them will be provided, derived from #76.
I hope such improvement will lessen quantity of minor forks, at least in future.

[losingkeys]

Hmm... I'm not sure what to do here. I'd like to revive this discussion, but there's one thing I'm still confused about. I'm guessing @rking owns the copyright on the changes on this project since it was forked from https://github.com/mileszs/ack.vim, and various other maintainers own the copyright on some code. Because of this, I'm not sure who (other than @rking) is allowed to license this project.

I'm not a laywer, so it'd be nice to get some legal advice on this before adding a license and merging things. As a side note: ack.vim added a license to their project at the start of this year.

[albfan]

Well, then there's two sides for this issue. One is to contact @rking to get permissions to fork or change this codebase. and second (most important for me) is decide what features are interesting to merge (test suite, aggroup, api changes, support for X search native tool, compatibility with nvim)

I guess we can discuss second point meanwhile first point is being resolved.

[tplunket]

@rking hasn't had any activity on GitHub in nearly two years and the website that is listed in the user's profile yields a DNS error. I'm guessing that this person is no longer around.

[losingkeys]

Hey everyone. I'm really sorry but there are a couple of issues that mean I'll be deprecating this repo:

• Though I'm not a laywer, the licensing issues appear to mean this code is effectively not open source, though it's public
• I haven't had a lot of time to maintain this lately, and pull requests and issues have sort of fallen by the wayside
  Because of these issues, I'm deprecating this repo. I think the best move going forward would be to re-open the pull requests in the original fork: https://github.com/mileszs/ack.vim, and to add this config to your vimrc:

let g:ackprg = 'ag --vimgrep --smart-case'                                                   
cnoreabbrev ag Ack                                                                           
cnoreabbrev aG Ack                                                                           
cnoreabbrev Ag Ack                                                                           
cnoreabbrev AG Ack  

[albfan]

Seems all we want to share a great ag vim plugin, but we are stagnated on this repo.

I'm pretty comfortable with this little mess, but would love to share it with others.

Count on me to collaborate in any fork about ag. As you suggest I will try to reopen an issue about group option on mileszs/ack.vim

mileszs#94 (comment)

[ches]

I'm not a laywer, so it'd be nice to get some legal advice on this before adding a license and merging things. As a side note: ack.vim added a license to their project at the start of this year.

I just wanted to clarify FWIW: the issue referenced there was not when the license was actually added, I couldn't have made that decision unilaterally myself without clearing it with previous contributors. I just added an explicit complete LICENSE file for distribution packaging policy. ack.vim was licensed under the Vim license since its first commit.

Unfortunately ag.vim seems to have removed mention of any license from the help doc file at some point after the fork, thus some contributions have happened under no clear license. That is indeed an unfortunate sticky situation 😦

I'm happy to discuss co-maintainers on ack.vim, I'd invite you to open a new issue on the repo about collaboration to start discussion. It might take a bit of time to get help from Miles to make admin changes happen, but he's generally been responsive. I'm sure we can set up Gitter for the project if that makes discussion easier, perhaps even move the project to an organization so it's easier to share management responsibilities.

I will note: improving existing behavior and fixing bugs is most welcome, but ack.vim began as a light wrapper that showed how elegantly Vim's existing grep functionality could be extended, and I personally do not want to see it grow a lot of new features now, in fact after some time working on its maintenance I've developed the philosophy that it should have fewer features. I'm leaning toward using vim-grepper myself because it's very close to a more modular approach I wanted to take if I had made a fresh start before that project did. That said, if the community loudly demands such new features, I'm willing to yield, but I may be more likely to step down at that point if there is new blood helping to maintain the project. For now I have no intention to do that while I'm the only active maintainer.

Anyway, we can continue this sort of conversation in ack.vim's project context if that's a direction people want to pursue.

[losingkeys]

@ches, @albfan: thanks for your comments. I tend to agree that smaller plugins are better. I might open a few PRs, but for the most part using ag with ack.vim hasn't been a problem. I guess we'll see what kind of features people want going forward. Forking again is always an option.