Very cool requirements. I am more then happy to take the lead on this and even sponsor the hosting on my servers, or work on others servers.
Mike
On 10/5/06, Jörn Zaefferer <[EMAIL PROTECTED]> wrote:
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
discuss@jquery.com
http://jquery.com/discuss/
--
Mike Hostetler
[EMAIL PROTECTED]
http://www.amountaintop.com
_______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
