Changes: Vim.org relaunch

Revision as of 12:30, 4 November 2008

This page is intended to discuss possible improvements for vim.org or for a relaunch of the vim.org site. refer to the discussion on vim-use.

Problems with current vim.org/scripts

you won't get informed of updates for your scripts
collaboration on script development is next to impossible, because
- I can't upload a new version, must open a new script page
- No script I saw is under version control
- Many scripts lack licence informations
scripts can not be browsed online, there are only downloadable zip/rar/tar.gz/vba/vim
User Feedback on scripts is not possible: no comments, mailing list to much a barrier
No issue tracker

Requirements for vim.org/scripts

nice to have

save scripts in a VCS (GIT?)

I'd love it, but I do not have much of an argument for it. :-)

Normalize script packages

By now scripts come in different formats: zip, tar.gz, vba, plain file...
Scripts do include paths or come as one file and a description where to place the file

If we'd enforce that all scripts must be uploaded as either zip, tar.gz, vba and that they must come with the right directories, then we could

unpack the scripts on the server
repack the scripts in different formats to please everybody
provide different download links: zip, tar.gz, vba
make the script code browesable
distributions can provide automated systems to install scripts

tags for scripts

Tags makes it more easy to search for scripts.

script rating

This is already on vim.org and needs to be preserved.

important

User Feedback/Discussion

A kind of forum or comments to scripts like on addons.mozilla would give me additional informations about the usability of a script or could give feedback to the author.

collaboration on script development

Currently I need to create a new script page to upload a new version of a script I do not own. This has several flaws:

There is no hint on the old script page about the new version on another script page
If I do not want to take over the script I may not want to create an entire new script page.
If the current maintainer comes back to include the patches and add new patches the most recent version goes back to the original script page.

It should be possible to have one page for one script, but to allow different people to upload patched versions.

comments

In the past it was possible for anybody to upload an updated version of any script. This was problematic for various reasons, the chief two were:

The original script maintainer lost the ability to control what changes were uploaded
It was possible for unscrupulous people to upload new versions (I think there might have been a spam problem)

It was decided that new versions of a script should only be uploadable by the original creator of that script ID--if someone wanted to "fork" the script and upload it under a new ID that was acceptable. Unfortunately no consideration was made for the possibility of the original owner of a script ID to surrender control of the script ID to a specific user or to "orphan" it entirely (open it to let anybody upload new versions).

--Heptite (T) (C) (@) 10:09, 4 November 2008 (UTC)

we need to implement a upload permissions system and perhaps something like githubs fork. We could make it so that the script maintainer must allow others to upload scripts, in the event that the script creator can't be reached within a certain period of time an admin could assign a new person as the maintainer. --Xenoterracide 12:23, 4 November 2008 (UTC)

script removal

Currently there is no way to actually delete scripts--you can only delete all but one version--so the repository is starting to get cluttered with "scripts" such as this one: http://www.vim.org/scripts/script.php?script_id=762

(It is possible this has been implemented and I've somehow missed the fact. -- Heptite (T) (C) (@) 10:09, 4 November 2008 (UTC))

trust for developers

It would be good to have a kind of trust system in place that could give me informations, whether I may trust the script author or not.

crucial

Proper authentication

The current user management needs improvement. (Lost password email, OpenId, captcha)

comments

I'm personally against OpenId (I think it presents it's own unique set of security issues), and I really don't think that OpenID users should be able to upload scripts, maybe comment and vote but that's it. When we implement lost password it needs to be with password reset not emailing it. I see too many foss sites that email passwords this is a security issue. --Xenoterracide 12:29, 4 November 2008 (UTC)

bug tracker

it must be possible to report bugs/issues/feature requests against a script
to see which bugs have been reported
to see whether someone is working on this bugs

licenses

It is important for distributions to know the license of scripts. Script authors should be reminded to specify the license of their scripts. Some licenses could be recommended as a drop down box. The license could be saved as a separate database field to enable filtering/searching by license.

To look at

GetLatestVimScript - Look for new versions of your installed scripts
VimBall - Vim Script Packaging system

@@ Line 40: / Line 40: @@
 ===== comments =====
-In the past it was possible for anybody to upload an updated version of any script.  This was problematic for various reasons, the chief two were:
+:In the past it was possible for anybody to upload an updated version of any script.  This was problematic for various reasons, the chief two were:
 # The original script maintainer lost the ability to control what changes were uploaded
 # It was possible for unscrupulous people to upload new versions (I think there might have been a spam problem)
-It was decided that new versions of a script should only be uploadable by the original creator of that script ID--if someone wanted to "fork" the script and upload it under a new ID that was acceptable.  Unfortunately no consideration was made for the possibility of the original owner of a script ID to surrender control of the script ID to a specific user or to "orphan" it entirely (open it to let anybody upload new versions).
+:It was decided that new versions of a script should only be uploadable by the original creator of that script ID--if someone wanted to "fork" the script and upload it under a new ID that was acceptable.  Unfortunately no consideration was made for the possibility of the original owner of a script ID to surrender control of the script ID to a specific user or to "orphan" it entirely (open it to let anybody upload new versions).
 --[[User:Heptite|Heptite]] [[User talk:Heptite|<small>(T)</small>]] [[Special:Contributions/Heptite|<small>(C)</small>]] [[Special:Emailuser/Heptite|<small>(@)</small>]] 10:09, 4 November 2008 (UTC)
-:we need to implement a upload permissions system and perhaps something like githubs fork. We could make it so that the script maintainer must allow others to upload scripts, in the event that the script creator can't be reached within a certain period of time an admin could assign a new person as the maintainer. --[[User:Xenoterracide|Xenoterracide]] 12:23, 4 November 2008 (UTC)
+::we need to implement a upload permissions system and perhaps something like githubs fork. We could make it so that the script maintainer must allow others to upload scripts, in the event that the script creator can't be reached within a certain period of time an admin could assign a new person as the maintainer. --[[User:Xenoterracide|Xenoterracide]] 12:23, 4 November 2008 (UTC)
 ====script removal====