Vim.org relaunch

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. :-)

comment

There would be no problem with commiting from the web-frontend to a VCS in the background. It would offer a lot of possibilities for those who want it. A bi-directional approach would also work. Think trac or gitweb. -- RichiH 12:26, 6 November 2008 (UTC)

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.

comments

preserved is nice but it could be made a bit more user intuitive. such as using stars. --Xenoterracide 12:32, 4 November 2008 (UTC)

I like the system on cpan where you have to leave a comment if you want to rate something --samvimes

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.

comments

A forum would be too much of a break between the script page & the forum page. Also, most scripts don't need a full forum. Threaded discussion on the script page would be good, though. -- RichiH 12:28, 6 November 2008 (UTC)

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:

1. The original script maintainer lost the ability to control what changes were uploaded
2. 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, "stay logged in")

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)

Please elaborate on your issues with OpenId since I'm strongly pro OpenId and wouldn't like to build any site in 2008 without it.

Here's a link to one article on OpenID's security issues http://idcorner.org/2007/08/22/the-problems-with-openid/ googling "openid security issues" will return many, many more. If OpenID is deemed to be necessary I highly suggest we don't allow any more than general commenting on scripts, for access to uploads and bugtracking, etc. You'd need a full account --Xenoterracide 05:18, 5 November 2008 (UTC)

This [ Google Talk] very well describes the issues that are mentioned in your linked artikle and how to get it right. It's right that you can run into trouble, if you don't implement OpenID right. You should have mentioned, that the article is written by an employee of a company which provides a commercial, non-open alternative to OpenID.

For more informations on OpenID:

• Yahoo! Developer Network. OpenID
• Google OpenID
• Wikipedia

Is there a transcript or a text document addressing the concerns? The talk is one hour.. Setting aside the Phishing issues, I see spamming of the new site with a billion of OpenID accounts as a real problem which, ttbomk, has not been addressed. I _am_ very much supporting the ideas behind OpenID, btw. I just think there are issues that need to be resolved. -- RichiH 11:14, 6 November 2008 (UTC)

A timeline of the openid video:

1:20 Begin - OpenId what does it do for me?
10:59 How does your Identity provider know who you are
12:34 Delegation: What if I hate my provider
13:53 multiple openids for one person
15:00 additional informations bundled with openid
17:51 Discussion of concerns with OpenId
38:12 End - questions

I just sat through it. Basically, they are saying that the spam problem with OpenID can be solved with whitelists & CAPTCHAs. This does not really give an advantage over logging in or not logging in at all and just using CAPTCHA. Phishing is sidestepped completely, but as this is not up for discussion here, I will not go into detail, here ;) -- RichiH 11:58, 6 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

comments

All this would be doable both with Bugzilla & RT. As I said, I volunteer for all work with RT if it is chosen. -- RichiH 11:03, 6 November 2008 (UTC)

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.

comments

I would piggy-back the licences onto the tags. There is no real difference and doing it this way would enable dual-licencsing, etc. A dropdown & a default licence would be very good. -- RichiH 11:05, 6 November 2008 (UTC)

To look at

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