[pmwiki-users] Pre-announcing 2.2.0 non-beta release

[john.rankin at affinity.co.nz]

> On Wed, Jan 21, 2009 at 01:15:36PM +1300, John Rankin wrote:
>> >Therefore the first (before adding "automatic" installation) step
>> >should be a quality control or rating of PmWiki extensions. This would
>> >be more beneficial for the unexperienced user than automatic
>> >installation.
>>
>> I agree almost 100% (and my earlier post raised this very issue).
>> Personally, I'm not a big fan of rating systems as a method of
>> quality control, [...] So while it's harder,
>> I would prefer a system based on a lightweight and transparent
>> quality control process. Ratings would be good for other reasons,
>> of course, but are not necessarily a mark of quality.
>
> I find this to be a particularly insightful comment about
> rating systems -- for any given extension, a rating system
> (based on comments from others) is good for saying "How useful
> is X?" or "How easy is it to use X?"  But very few people are
> going to have the time and/or ability to usefully evaluate
> the "quality" of a recipe with respect to its security
> or stability.
>
> So, "[there] should be a quality control [...] of PmWiki
> extensions"  is another one of those places that I fear
> handwaves away the difficult part of the whole problem.  :-)
>
> Indeed, if it was easy, we'd probably already be doing it.  :-)
>
> Pm
>
The principle that one has to build quality into the process,
rather than inspect for quality at the end, is well known and
widely accepted. One simple change we might think about is
that recipes optionally have named "independent quality
advisor(s)" as well as "maintainer(s)". Time and again, I have
found that having an independent person actively involved
during development to challenge thinking and critique code
produces better results, faster. It is clear from the mailing
list that others do the same (although they may describe it
in different words).

Formalising this existing informal process has a couple of
advantages that I can see:

- it gives visibility to the important role such people play in
   the evolution of a recipe

- it tells others something about the kind of process used
   to create and maintain the recipe, so they can take this
   into account in their evaluation

Implementing this would be as simple as the recipe
maintainer asking the independent advisors to identify
themselves in the recipe summary. In social networking
terminology, these are like the recipe's "friends". Indeed,
it may be better to call them "friends" rather than
"independent quality advisors". I suspect many people
already informally take account of a recipe's implied
friends when evaluating it. A "Friends:" recipe descriptor
would open up all sorts of interesting capabilities.

JR