Tags:
create new tag
, view all tags

How can we maintain the quality of published extensions?

A while ago, before CDot and I put in the TWikiTag code into develop I wrote a small plugin called ImgPlugin, which was just a TML-equivalent to the HTML img tag. It got "improved" to the point that Micha had to do massive clean-up and break the plugin in two, which was possible since the improvements were all related to a different tag. (Thanks, Micha!) This, in combination with the plugin API discussion, brought to my attention the difficulties and dilemmas the project faces regarding extensions.

On the one hand, it's a good thing when people contribute extentions. On the other hand, the quality and reliability of plugins vary widely and, as I understand it, several people have put in a lot of time fixing contributed plugins. And, obviously, it does not make TWiki look good to have people install plugins only to find things breaking.

Explictly stating the PluginApiPolicies is a good first step. That doesn't mean that casual developers will find them, understand them, or be willing to follow them. It doesn't even guarantee that non-casual developers will follow them.

Other than rigorously testing each and every one, there's no way to guarantee quality, and that's impossible in an OSS project. We should still try to come up with tools/scripts to come up with some sort of metric that users can use to help with their decision. The plugins_conformance_analyser is one such tool.

-- Contributors: MeredithLesly

Discussion

-- MeredithLesly - 12 May 2006

The main reason I chose TWiki for my current project was the ApprovalPlugin which, as it turned out, didn't work with Dakar. If I were a corporate customer, I would have been quite upset if I had committed to TWiki and only later found out that a plugin key to my project didn't work.

-- MeredithLesly - 12 May 2006

Pehaps we should have an area for "staging" or "incubating" plugins thrown over the wall, and put an "approval" process by the core developers to move them to the "approved" plugins area.

-- RafaelAlvarez - 12 May 2006

Another tension here: encouraging people to contribute plugins while also trying to promote reliability.

-- MeredithLesly - 12 May 2006

Perhaps not the best model for some, but the Apache group uses an "Incubator" area for new project to prove themselves "worty" of the Apache seal.

That's kind of the model I'm refering to.

-- RafaelAlvarez - 12 May 2006

Oh, now I get it. That way people could distinguish between well-tested plugins and ones that may be shaky. Not a bad idea.

-- MeredithLesly - 13 May 2006

A good point in focusing on what's maintainable / automatable. Mechanism instated should at least be able to survive rotations in userbases (both in plugin developers and in an eventual "approval committee").

-- SteffenPoulsen - 14 May 2006

It would definitely help to have the "desired" coding practices/standards published here (maybe from the EmptyPlugin). Something like a FAQ or HowTo.

  • Docs/Examples of Sandbox.pm sysCommand() for "safe" subprocess usage.
  • Discussion of Object oriented vs. Procedural coding styles.
  • Discussion of protocol for submitting a new/extended Plugin for evaluation.
  • Examples of "proper" LazyComplilation for supporting code.
  • Having "approved" Plugins would provide great examples of desired coding styles and conventions.
  • Location for "New/Prototype" Plugins to be submitted for evaluation and comments from established TWiki developers

Someone who spends the time to extend or develop a new Plugin certainly wants to see it be used and accepted. And so, would be supportive of constructive comments which would assist them in creating a fully compliant and useful plugin. Having these comments/suggestions publicly available would provide a dynamic supportive climate for new ideas, while still enforcing desired coding practices. This would benefit the TWiki effort by increasing the number of active developers.

-- CraigMeyer - 14 May 2006

Craig, you bring up a good list. The official doc for authoring Plugins is TWiki.TWikiPlugins; it also has this: TWiki:TWiki.TWikiPluginsSupplement on TWiki.org has supplemental documentation on TWiki Plugins. . The official doc and the supplemental doc should be enhanced to foster Plugin development.

-- PeterThoeny - 15 May 2006

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2006-05-15 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.