Feature Proposal: Group extensions by some indication of quality

Motivation

Extensions are of varying quality and there is little control over what constitutes an extension that is ready for release. In addition, some extensions are tested on multiple platforms and releases, others are written for a single platform and there is no indication of this in the interface. The whole area of Extensions became very unreliable and inconsistent on T.O over time, we should avoid similar degredation on Foswiki.

Description and Documentation

Extensions should be categorized by "Core", "Proven", "Beta" or other categorization. Also, the configure FindExtensions interface should not show extensions that are not usable on the users current platform.

By publishing an extension in the FindExtensions list, there is an implied endorsement of the extension by the Foswiki community, even if it is actually disclaimed. The "first impression" of someone considering Foswiki needs to take into account the impression given by the available extensions. We need to make sure that extensions don't slowly degrade into a list of dubious quality.

Also there should be some indication of the advisabilty of using the configure interface for installation. (Plugins with 100's of attachments may take many minutes to hours to install. This could have a serious impact on the admin and server. ) Potentially omit the "Install" link for any plugin that is expected to have difficulty during installation.

Examples

• FamFamFamContrib attaches 100's of files and can take 40 minutes or longer to install. This should probably only be installed from the shell.
• ToPDFPlugin was only written for Linux and is not fully functional with the default skin.
• Other plugins require shell access to tailor code. (GenPDFAddOn, ToPDFPlugin)
• DirectedGraphPlugin was not functional on Windows until recently

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

• Consider sorting "core" extensions to the top. These extensions are critical to Foswiki functionality. They are generally subjected to good release controls and updates should be obvious and encouraged.
• High quality, widely used extensions should be listed next. These plugins should generally be cross-platform, usable on any platform supported by Foswiki. They should be developed in SVN with test cases, and subject to some level of rigor during the release process. Extensions in this category also need to have been subject to a security audit by the core developers.
• Less proven but well tested and/or platform specific plugins should be listed next. A plugin that has not been tested on a new release should drop into this category until it has been tested on the current release.
• Final section would be beta quality or unproven plugins. User should have to explicitly select a "Include beta/unproven Extensions" to include these in the list. Obsolete extensions should also be listed in this section. Any extension that has not been tested 2 releases back should drop into Obsolete automatically.

Release Managers or core developers other than the plugin author should make the determination on the category of the plugin. Alternative might be a community rating system, but this seems too complex for now.

-- Contributors: GeorgeClark - 27 Jan 2009

Discussion

I support this proposal. I think it needs to get one step more concrete/actionable. Which is part of a programming job, which is community driven. What will be the list to rate extensions, and how do we maintain quality when an extension gets updated?

-- ArthurClemens - 02 Feb 2009

I highly support this effort also. I would also offer to create one or the other Screencast to present the Extensions decently.

-- MartinSeibert - 02 Feb 2009

Changing to a ParkedProposal.

-- Main.GeorgeClark - 03 Nov 2015 - 15:54