Looking at the problem a bit more, is there a general pattern or patterns behind the idea of collecting information in a structured way with collaboration involved? It just happens to be plugins we're talking about now that have physical files envolved. Issue lists, recepies, logo library, UI pattern library, API documentation... A pattern that may be worth while to address the wiki way? That would mean simple, easy to use, and in DW's situation local file storage. I suppose it would need a little more definition around the problem to grasp the larger pattern behind it. Things like, common/structured content capture, vote and review option, sharing of files/source code, search capability, tagging, aggregation of content in various ways e.g. listing of content accross wiki pages, commenting, notification (rss, email), user control of namespaces, group building, idea sharing... Food for thought...martin On 2/8/07, Esther Brunner <wikidesign@xxxxxxxxx> wrote:
Hi all > Which I can perfectly understand :-). I'm thinking about this my self for a > while... I have an idea about a plugin repository outside the Wiki (maybe > connected to the same auth backend). I'll just scribble away some of my > ideas how I imagine it: > > - database driven > - located at plugins.dokuwiki.org > - developers can upload plugin > - developers can upload updates to existing plugins > - maybe users can upload corrections as well > - users can comment > - user can vote: works for me with Dokuwiki version X, does not work for me > with Version X > - The plugin manager connects to plugins.splitbrain.org to list available > plugin, and to check for updates > - plugins can be tagged to categorize them > - probably more I just forgot > - users could easily see the health status of a plugin based onthe user > votes (work/don't work) > - maybe special users could even do security audits, which would give a > plugin an extra point or something > - probably more I just forgot > > What do you all think of it? Great! I was about to propose a plugin repository as well. The plugin page, to be frank, is a mess. And the wiki is not suited that well for all the things we need to maintain a plugin project. That was also the reason why I started mailing lists, code repositories, issues trackers, etc. for my plugins. I do this with a combination of Google services (Google Groups and Google Code) and custom made plugins for my wiki site about the plugins. – But I would still prefer a centralized solution at dokuwiki.org. The reason why I didn't send this proposal to the list up to now, is simply that building a full fledged plugin repository takes a considerable amount of time. And my spare time is limited. Now I just finished the semester at university and should have a bit more time in the next weeks to help on this project, if my help is needed. I'd vote for a combination of database and wiki. A database alone is inflexible and for documentation we need some kind of wiki markup anyway. Maybe something like in WikiMatrix, where every project has it's own namespace. The database could store a bunch of pages a plugin project usually has: desctiption, configuration, change history, discussion, issue tracker, available languages and source code (and maybe more). Every plugin project should have a project owner, usually the plugin author, who can add other project owners and members, who then are allowed to make changes to the wiki pages and contribute patches to the plugin's code repository. If the sole project owner doesn't want to maintain the plugin any more and no other member wants to take over the project, it is tagged 'abandonned' and a warning message is presented to users. > Should I spend time on writing this system? Or should I use the little spare > time I have to go outside looking at the sun? ;-) I wish you still have time to go outside and enjoy looking at the sun - you deserve it! -- esther -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist