DarTar, this is a great step forward, and long overdue! I would suggest #1 for maximum flexibility: By giving the owner of their own node (in your example, DarTar) full access to subnodes, admins would only have to intercede once on behalf of contributors. #2 requires admin interaction each time a new plugin is introduced. #3 is simply not useful for navigation purposes, and #4 is too constrained.

What would even be more useful is the ability to link directly from a WikiLink to the node in question.

One more comment: I hope that this topic also fosters renewed discussion on the InstallableActionTemplate (I've added a See Also link). They really should be developed together, or at least in parallel with one another.

I vote for #1. I agree with Brian's comments, and would also like to mention that #4 offers a greater potential for mistakes and bugs to be introduced into the code.

I'd agree on #1, too.

Thanks for your feedback - if I don't have any objection, I'll drop options #2-4.

As I've already commented on Skype - I prefer option #2 (organize by plugin, not by user) since this would easily allow for several users cooperating on a plugin, or one user transferring maintenance to another, without having to transfer teh whole thing to another user.

It does not make logical sense to allow different users access to a single user node, or allow access to a user node for a different user instead of the original one. With an organization based on plugins though, this logical difficulty simply disappears.

So I definitely have an objection at least to option #2 being dropped!

I gave the above options some more thoughts. After looking at the structure of http://dev.wp-plugins.org/browser/ I think we should adopt a similar layout.

It's basically an extension of #2 (first level nodes are plugin folders), within which the trunk/branches/tags division is reproduced. This allows the development and tracking of a plugin as an independent package.

The main advantage of this layout, on top of what Marjolein suggested for #2, is that it allows for easy maintenance of different versions for compatibility reasons (e.g. a plugin branch for Wikka 1.1.6.1, 1.1.6.2, 1.1.7, etc. ) or just different versions for different target users or applications.

The only disadvantage with #2 pointed out by Brian sounds easily manageable, whereas the disadvantage for #1 noted by Marjolein is more difficult to deal with.

To get a taste of how this would work, take a look at: http://dev.wp-plugins.org/wiki/RepositorySetup

>> It's basically an extension of #2 (first level nodes are plugin folders), within which the trunk/branches/tags division is reproduced. This allows the development and tracking of a plugin as an independent package.

Very nice - that makes perfect logical sense!

It makes "perfect logical sense" so long as there remains a parallel set of directories that will allow individual users to manage their own projects (adding, deleting, etc.). There are many small hacks I do that really don't warrant "plugin" status, yet I would like to make available to the Wikka community. Take a look at how Moodle (an open source CMS) handles it: Modules are "self-published" by the developers, and developers maintain their own projects without having to involve admins (other than for an initial CVS account):

http://docs.moodle.org/en/Developer_documentation#Documentation_for_contributed_code

So there's really no need to throw out #1 or #2. Keep things organized by contributors; give individual access to the contributor's own tree. Create a separate repository that allows contributors to register their plugins when they feel a plugin is ready to be released. That way, contributors can plan on "releases" to their plugins (all of this is assuming contributors are given SVN or CVS access, whatever Wikka is using).

Brian - if I understand your suggestion, you are proposing something like a user folder on top of the plugin repository. I think these are really two different things, which are not mutually exclusive. But since my proposal is mainly about creating a platform for plugin development and tracking, we should be aware of two issues:

1. the idea of offering SVN access for plugin development is not meant to provide users just with server resources for hacking and testing code, but to create a (possibly) self-maintaining infrastructure for plugin development and release. This requires that versioning and identification of components be clearly understandable to the end user willing to install a specific plugin as well as to other developers willing to contribute to the same plugin. An informal 'user folder' to 'self-publish' modules -- something like the current code contribution pages on this server -- is really a different thing, and certainly not an optimal solution for plugin development: code contributions are very often unstructured, they lack versioning information, and allow very limited contributions by multiple developers, which leads me to the second point;

2. the very idea of a *SVN* repository for plugins - as opposed to simple server space - is to promote collective development and allow users to track updates of single components and diff them with previous versions. What you are suggesting is that we should keep all the development in a user-folder and basically offer the possibility to publish plugins ("tag" them in a directory) as soon as it's ready to be released. This is really different from what I have in mind: I would like to see plugin development both *structured* (so users can install and test specific revisions without needing to ask instructions to the maintainer) and *exposed* (so developers can keep an eye on a plugin and join in and contribute code).

To sum up, I think your idea of "self-published" modules is not so different from what Wikka contributors are *already* doing (using their own servers as informal code repositories) - which allows only limited interaction between developers and makes plugin installation extremely chaotic for the end user.

My 2 cents.

Earlier, I posted this:

"There are many small hacks I do that really don't warrant "plugin" status, yet I would like to make available to the Wikka community."

Allow me to clarify: All plugins start out as hacks. Some hacks, while useful, may never achieve the status of a plugin. Let's say that I know user X writes some useful hacks. Right now, I must rely on User X to continue to update her pages, without benefit of source code history. Or, if I knew she had an SVN directory under contrib/UserX/ (or whatever), I could simply download all of her latest code, including source history, and possibly find some other quality gems as well.

I think the point here is that not all hacks are destined to become plugins, but are still useful for those who want to take advantage of them. Hacks seem better suited to be categorized under the user who wrote them, rather than scattered randomly throughout SVN.

I think categorizing plugins via #2 is fine. One would expect multiple developers to continue to enhance existing plugins. Hacks, while just as useful, probably won't garner the same level of developer support, and there are only a handful of developers who are responsible for multiple hacks. So instead of littering the SVN landscape with small single-use hacks, pull them all together under user branches. Those who want a specific hack will know where to go to find it, and might find some other useful stuff as well.

Perhaps something like this:

wikka
....../plugins
.............../Plugin1 (author: UserX)
.............../Plugin2
....../contrib
.............../UserX
................../foobar_hack
................../toasty_morsel_hack
................../../../plugins/Plugin1 (link)

Brian, I am not sure that two different models of directories (one sorted after plugins, the other after authors) is a good idea. Even if a hack may be small, it should be placed in its own directory.

So perhaps:
wikka
.../plugins
....../ExamplePlugin
.../hacks
....../ExampleHack
?

I'm just thinking of admin workload here...personally, I'm probably not going to bother you all to create a new dir everytime I create a new hack, and I doubt that some of the more prolific Wikka hackers will do so either.

I think this is a good start for the plugins, though.

While I understand the difference between plugins and "hacks" I think it would be quite confusing for there to be a plugins directory as well as a contributors' directory. If we do go with facilitating publishing & maintaining hacks in the SVN repository, I would much prefer Nils' solution with a /hacks directory at the same level as a /plugins directory.

Prolific Wikka hackers who don't want to use that facility are always free to self-publish their hacks of course, or simply use the Wikka site to publish and promote dicussion about them.

I'd say we should start with the plugin directory and see how comfortable contributors are, later we can add another directory if needed.

I'd say...when in doubt...KISS (keep it simple stupid).

The plugins should be one directory deep

/plugins
................../plugin1_name_version
................./plugin2_name_version

Versions should be at the end of all plugins AND should be of the same branch number that wikka is...that way, you'll know that your plugin is compatible with the wikka version you're using. If authors/contributors all number the stuff they do with no point or direction, you'll end up with a mixed up bunch of plugins (similar to those at e107coders.org, the plugin site for e107 CMS...my old cup of tea when I first started out...they were a mess until they organized things). Anyway, if you don't implement a numbering system you'll be lost.

For example, I make devnetplugin and release it. I'd version it 1.1.6.2.1 or something similar...maybe 1.1.6a or something like that. This would keep people who don't use SVN from installing plugins that aren't compatible with their installs.

DevNet,

thanks for your feedback, and apologies for the late reply.
KISS is an option only when you can easily overhaul a system. The reason of this long discussion on the layout of a plugin directory is that we want it to be scalable from the beginning. In this way, once we opt for a specific solution, we won't need to manually rewrite everything at the first problem we experience.

WRT directory structure and naming convention.
Version numbering will apply to stable plugin packages, following the same conventions adopted in Wikka (package name + plugin version number). I don't see the utility of specifying "plugin" in the name. As soon as a plugin is stable and ready to be released, it will be tagged using its own versioning number. I'm in favour of instructing contributors (who will commit plugins through SVN) to correctly distinguish between unstable versions and production versions, so I maintain a distinction between, say: /plugins/beautifier/trunk (the unstable development code) and /plugins/beautifier/tags/1.0 (a stable release, that users can safely install). Consider the advantage of this distinction once we'll have an interface allowing users to download and install plugins and to decide whether to include unstable packages or not.

WRT version numbering.
I'd personally prefer avoiding a reference to Wikka version number for the plugin version numbering for the following reasons reasons:

1. A plugin might still be valid across several Wikka updates, in which case using your convention for version numbering might be misleading.

2. Using a dedicated version number for each plugin makes it easier to track the history and updates of that specific plugin (including automatic version checking similar to PHP's version_compare() that we might implement in the future).

3. There will be anyway a user-friendly interface to the directory (e.g. a wiki page per plugin) and compatibility with Wikka versions will be available in this interface. If we use phpdoc tags, compatibility will be easily self-documented using @since (or another custom tag). The user interface to the plugin could read the compatibility information and automatically categorise plugins as a function of the Wikka engine they have been tested with.

I know all this might sound overkill at the moment, but I'm convinced it will be useful as soon as the number of plugins grows. The WP plugin directory is the best demonstration that a layout like the one described in http://wikkawiki.org/PluginDirectory?show_comments=1&showall=1#comment_4547 can do the job.

So what's the status on this? An ETA, perhaps, on when something might be publicly available to developers?

Hi Brian,
at the moment our priority is to release 1.1.7, which should be out within the next two weeks. Soon after that I think we'll get back to site-related issues:
- documentation server (on its way: it should be up as soon as we have fixed some minor issues with our hoster);
- plugin directory;
- support forum;
thanks for bumping this anyway - I just wanted to let you know that we haven't forgot this idea.

No problem...anxiously awaiting 1.1.7!

We should have both lay outs. The actual, physical, organization should be like #1 - while there should also be provisions for a "plug-in directory service" so it would be possible to easily get a feel of what plug-ins exists.

This will endure that if developer A develops a plug-in called "webget" (just an example) and developer B does the same (but with a different feature set) - these can happily co-exists without having different names.