On Dec 31 2010, 1:44 am, Marc Weber <[email protected]> wrote: > Bram was so kind adding me to the list of contributors to the Vim project > which > means that I can propose Vim web page changes by sending Bram patches. > If you have any urgent feature requests its the time to start talking about > them. > > I'd like to implement: > > A:a way to change the script type afterwards (because Bram had to do this > manually using SQL) >
Great idea, and probably very easy to implement and low risk. Go for it. > B:a "repository" field. This way you can register a > git/mercurial/whatsoever repository along with your plugin. > Also a great idea. It would allow users to get the cutting edge version if needed. Maybe don't limit it to a version control field. I know people like Dr. Chip like to host script versions on their websites before publishing to vim.org. Also as someone mentions, a "bug tracker" field could be useful as well. > C:an opt-in collaboration feature: You can add other users as collaborators > to > your scripts which means that they can change the description and upload > new > versions as well (This is similar to what can be done on github) > > I'm not sure whether a collaborator should be able to add/drop other > collaborators. > I like this, but I don't think all collaborators should be able to add/ drop other collaborators. Maybe you could give two levels of access, not just one, but that would be harder. Another possibility would be all collaborators need to agree with the addition/removal of another collaborator (except for the person being removed, obviously). > There was a request on the mailinglist for transfering > maintainership to someone else. If this should be possible a > collaborator should be able to add drop collaborators? > > I think yes because you have to trust collaborators anyway. > > D:change the voting system this way: > > 1) votings should be tight to a specific versions. If a plugin fixed bugs > there is no reason why bad ratings of version 0.0 should still affect > the > latest version ( which might be 10.0 ) > > Because you can delete specific version archives later there may be > votings > for versions which can longe be downloaded > > I'm not sure which voting to show by default. Maybe the current figures > should be kept but an optional "detailed" few should be added? I like the idea of starting voting over on a new version, though obviously it would be open to abuse. Maybe showing the voting of the version next to the entry in the history would limit the abuse. Show the most recent vote tally, or a weighted average of all the versions (newer versions weighted higher). > > 2) force users to give a reason if they vote something down. This will be > kind of dialog and it'll help devs to understand user requirements > I don't like this. Maybe highly encourage it but don't force it or it will discourage legitimate negative votes. The voting is really meant for people considering trying out the script, not for the script author. -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
