Hi Mike! > A thread a while back mentioned a jQuery Forge website. I have built > a forge type website with Drupal for another open source project I'm > involved with called Qcodo. That website is at > http://qforge.qcodo.com <http://qforge.qcodo.com>. > > I wanted to bring the issue back up because I still see people asking > about it. If this is already in the works, I don't want to step on > anyones toes. Additionally, if John is working on something like > this, I'd be happy to take the back seat to whatever he wants to do. > > So, is there any interest in a forge type website with Subversion > hosting, written on top of Drupal? Each project (or plugin) would > have it's own site along with issue tracking and control of their > piece of the SVN repository. > > Is there anyone out there that would be willing to help with this too? To my knowlegde, there are several plans for something like this, but so far no implementations, though I'm not sure what Paul and John are up to about the new jQuery site. I think it would be great if you could provide a prototype for a jQuery forge. Apart from hosting projects and providing (restrictable) subversion access, there should be some way to integrate the jQuery build system. Apart from some small issues, the current ant build can be easily used to build plugins and bundle them with jQuery into one file. It would be great if this build could be triggered by the jQuery forge... The most basic requirement would be the ability to launch a java process on the server.
From what I have seen after a quick look at the qcodo forge: Groovy! Seems to provide most of the requirements I had in mind. See below for details. -- Jörn *'jQuery community' is my working name for the basic idea of a central plugin repository.* It provides the following use cases or rather roles. Parts in italic are more experimental thoughts. *Anonymous user* An anonymous user browses for plugins, either by listing them (alphabeticaly; ranked by votes or downloads; category), searching by keywords (title; title & description) or looking for dependencies (list all dependencies of a certain plugin; list all plugins, that depend on a certain plugin). For a given plugin, he can download all released version of that plugin and can give an anonymous vote. He can read the provided documentation and examples. He can try out the plugin in a sandbox enviroment without downloading any code (see w3schools.com for examples, eg. http://www.w3schools.com/js/tryit.asp?filename=tryjs_function2 ). /The sandbox provides either enough generic markup to demonstrate the plugin or provides markup created with the plugin in mind./ He can read the public forums. He can register to become a registered user. *Registered user* In addition to the possibilites of the anonymous user (minus the registering), the registered user vote for plugins. He can vote only once per plugin, but can modify he vote later on. This allows him to correct his vote if he knows more about the plugin or if some serious bugs were fixed, new features added etc. The vote of a registered user weighs either more than the anonymous one or is registered/counted as a seperate vote. He can both read and write in the public forums. He can check out trunk versions from the svn repository, if one is used (see below). He can write comments (praise, flame, feature requests) and bug reports for every plugin. In addition, he can write comments for every plugin project (explained soon). He can create a new plugin project. A plugin project consists of one or more plugins (eg. Interface is a plugin project, draggable is considered a plugin). To create the project, he must provide at least a short description of the purpose of the project. The create request is then reviewed by a moderator (see below). With a created and approved project, he can do the following: Upload files via forms or SVN. When uploading via forms, he can choose wheather warnings should be displayed when overwriting files; his decision is remembered. To use SVN, he must request svn access. This can be either approved automaticaly or by a moderator. /There is no need to create a repository when it isn't used. On the other hand, it can be considered to commit files uploaded via forms to a svn repository on the server side./ After commiting files, he can create a release. The initial version number is either 1.0 or 0.1. When creating new releases, he can choose between creating minor and major releases. Minor releases increase minor version, eg. 1.0 to 1.1 or 1.59 to 1.60. Major releases increase the major version, eg. 1.2 to 2.0. He should choose a minor release when users can update the plugin without changing their own code. He should create a major release when users have to change their own code in order to upgrade. When creating releases, API documentation should be parsed from the plugin code, just like its happening with jQuery. Those docs can be read by everyone (see 'Anonymous user'). In addition to API docs, the user can provide more documentation, including examples. Those should be more sophisticated then the currently available inline examples from jQuery source. Any bugs reported by the user himself or other registered users are to be updated by the user. He should also reply to comments, where appropiate. /This activity could be reflected via activity stats, similar to those on sourceforge.net./ /Currently, most plugins are developed and maintained by a single developer (Interface by Stefan Petre, Thinkbox by Cody Lindley, Tablesorter by Christian Bach etc. pp.). It's likely that this behaviour changes, thefore the project structure should allow more then one developer to work on a single project. To allow more then one user to work on a single project, the project creator must have the abilitiy to allows others to commit to the project. It may be necessary to restrict this ability. For small projects, providing patches should suffice. To prevent that a project dies when a single developer vanishes (whatever maybe the reason), he can promote a second project lead. There should be hardly any need for more then two project leads./ *Moderator* A moderator receives project creation requests. When processing these, he checks if the description of the project suffices and if the project is not a clone of an existing one. There should be a good reason to approve a clone. When approving or rejecting projects, he can write a message to the project creator. If he rejects a project because of an existing clone, he should refer to that project. Apart from this task, the moderator makes things run smoothly. He keeps a lookout for spam, flames, fake projects, /maybe copyright infringements/. /He could also play a role when controlling access to svn. Maybe access to svn has to be restricted in general and only approved when necessary. Or he checks if a projects needs access to svn for more then one user./ He checks for dead projects. This would be easy with project activity stats. Small projects that run just fine as they are should not be considered dead when having low activity. Projects with low or no activity and lots of bug reports or feature requests should be checked. Maybe the project lead has no more time to maintain the project and can promote another developer or maintainer. The moderator keeps an overview of the community. He can award projects or users, eg. 'project of the month', 'most helping user of the month'. Naturally, the moderator also moderates a (part of the) public forum. *Administrator* This is the most abstract role. The administrator keeps the system running. He has to monitor server load to make sure every part of the system is available all time. /Especially svn down time can be very frustating for developers. *Infrastructure* As all this requires at stable infrastructure, the hosting should be provided by some company that is interested in sponsoring jQuery. John mentioned that he already some contacts who would do this./ _______________________________________________ jQuery mailing list [email protected] http://jquery.com/discuss/
