Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback #3

Open
starcraftman opened this issue Feb 5, 2016 · 7 comments
Open

Feedback #3

starcraftman opened this issue Feb 5, 2016 · 7 comments

Comments

@starcraftman
Copy link
Owner

Thread for some feeback.

@starcraftman
Copy link
Owner Author

@junegunn When you get a moment, I was wondering what you thought of my little plugin here. Should allow people to find/discover relevant plugins without even leaving vim.

@junegunn
Copy link

junegunn commented Feb 6, 2016

Hi, thanks for the ping. Just tried it, it looks simple and it works. What I'm not sure about this though is whether if it's going to be sustainable for you to maintain a centralized plugin registry here. Some questions: How do you plan to encourage the others to contribute? How do we know if a plugin is better than its alternatives without rating system? Are you going to curate the list yourself as the maintainer of the db and keep the list short only with quality plugins? If so, what if the others disagree? If you're open to any additions, how are you going to filter out broken, unmaintained, or unqualified plugins?

It's pretty unfortunate that the maintainer of VimAwesome finally gave up and no one tried to take over the project, or start an alternative project. It had the potential to become the de-facto stardard registry of Vim plugins. The experiment has failed, but I still believe it was heading in the right direction. One more point I like to mention is that the registry should be "plugin manager-agnostic" (this plugin is currently so, but I'm just saying), though we are naturally biased towards vim-plug. So we can have a standard registry that all plugin managers share, and the adapter for each plugin manager.

@starcraftman
Copy link
Owner Author

How do we know if a plugin is better than its alternatives without rating system?

A very good question. I'm not sure there is any easy way of comparing one plugin vs another. Do you have a suggestion? By ratings, did you mean like scraped usage metrics off github pages? Or some other mechanism like voting on a site?

I was thinking plug-search should mainly be an indexing service, allowing people to search for new plugins by name/tag and examine them by looking at readme/vimdoc. Probably should have a "new plugins" list too. Rating plugins is quite subjective.

Vimawesome didn't really handle this well either, it promoted plugins based on inclusion in vimrcs/stars/watches right? Many quality plugins don't/didn't have high usage/stars and got bumped down the pages. Worse, some inactive projects got promoted while their active forks buried, i.e. ctrlp, gundo.

How do you plan to encourage the others to contribute? Are you going to curate the list yourself as the maintainer of the db and keep the list short only with quality plugins?

This is the really big bother, how to manage the db long term. I think I'm going with curation, where I'll add some and ultimately accept PRs so long as they stick to my informal structure/rules. I think clearly plugin authors should have a say on what their own plugin entries are so I would probably take their PRs over say strangers. While it will take some effort, I think its for the best, without some level of curation stores/indexes kind of devolve.

If it got popular, I'd probably have to form an organization and add collaborators with some clear rules. That's a bit ahead of self though.

Regarding broken/unmaintained plugins, bit more tricky. Even if curated, its a bit of a judgement call when a project's reached a poor state. I put in an optional 'fork' entry on plugins that indicate that the original author has abandoned his project and said fork is now continuing. You can see it on 'kien/ctrlp.vim''s info box. Some good judgement would be required, unless author clearly states "I'm done".

If so, what if the others disagree?

I think I'm a pretty reasonable person, so we'll have to see if it ever gets to a major disagreement.

It's pretty unfortunate that the maintainer of VimAwesome finally gave up and no one tried to take over the project, or start an alternative project. It had the potential to become the de-facto stardard registry of Vim plugins. The experiment has failed, but I still believe it was heading in the right direction.

I found this sad too, project just seemed to fizzle after a nice start. One of the other problems was duplicate entries due to repeat submissions (sometimes even to different categories). Also, the metrics seemed to be frozen once an entry added, so even if a plugin got popular it'd be stuck at its position. Would make my life easier, if I could have just point this plugin to a database.

One more point I like to mention is that the registry should be "plugin manager-agnostic" (this plugin is currently so, but I'm just saying), though we are naturally biased towards vim-plug. So we can have a standard registry that all plugin managers share, and the adapter for each plugin manager.

I had thought of this before, I just deemed it low priority. Clearly it wouldn't be too hard to make said adapters. Though we know my preference :)

@junegunn
Copy link

junegunn commented Feb 6, 2016

Do you have a suggestion? By ratings, did you mean like scraped usage metrics off github pages? Or some other mechanism like voting on a site?

Both. GitHub activity + votes from the users. There also should be a way for a user to mark the plugin as "broken" or "unmaintained", stronger form of downvote? Just a thought.

My main concern is the maintenance burden you're going to carry forward. Users will also want to know if it's going to be maintained. I basically think that building the database should be a community effort, and I doubt that GitHub PR is the easiest way for the users to contribute.

Vimawesome didn't really handle this well either, it promoted plugins based on inclusion in vimrcs/stars/watches right? Many quality plugins don't/didn't have high usage/stars and got bumped down the pages. Worse, some inactive projects got promoted while their active forks buried, i.e. ctrlp, gundo.

The ranking system can be improved, and we can think of different ways to sort the list, such as "Most active" or "Trending" based on the number of commits/issues/stars during the last few days or weeks.

By the way, are you not interested in taking over VimAwesome? They're looking for the maintainer, and t he project looks python-heavy.

@starcraftman
Copy link
Owner Author

My main concern is the maintenance burden you're going to carry forward. Users will also want to know if it's going to be maintained. I basically think that building the database should be a community effort, and I doubt that GitHub PR is the easiest way for the users to contribute.

This is true. I don't relish editing a json by hand when it gets to 1000s of plugins. Though vim does make it quite easy to zip around with folds.

By the way, are you not interested in taking over VimAwesome? They're looking for the maintainer, and the project looks python-heavy.

Hadn't thought of doing that to be honest. I'll think on it, though it isn't a small commitment. If we fixed the aforementioned bugs and cleared up the existing db of dupes it might work. Maybe even add a page that serves the db in json format for other plugins/managers to make use of. I'll look at the code and see how it is.

@junegunn
Copy link

junegunn commented Feb 7, 2016

it isn't a small commitment

Yeah, it's a huge commitment. The project looks like a one-off university project and probably the author didn't think through how to maintain it in the long run. This also makes me wonder about the quality of the code. 😐

@starcraftman
Copy link
Owner Author

Yeah, I think unfortunate is the word. It was probably done under heavy time constraint as most projects are. Also, there are quite a few TODOs left in it. What little I've looked over certainly hasn't seemed like the worst code. Tests are a bit bare though. I think it is the classic bit too rushed leading to programming for "today" instead of "tomorrow".

On the positive, I made a working Vagrantfile that automates a whole dev server setup. It works, barring one small db issue. I do like that he used flask and rethinkdb, an ok pair. I'll spend some time evaluating it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants