[pmwiki-users] New PmWiki Features Page . . .
dausha at gmail.com
Mon May 29 11:38:36 CDT 2006
On 5/29/06, Neil Herber <nospam at eton.ca> wrote:
> At 2006-05-28 11:51 AM -0500, Ben Wilson is rumored to have said:
> >Assume we agree to use "Not Yet" for the "No" features. In the
> >beginning we say "Not yet: This feature is not yet implemented by
> >PmWiki because there has not been enough interest by the Community to
> >create a suitable plug-in."
> The set of "Not Yets" is potentially infinite. How does one decide
> which features should be included or excluded from the "Not Yet"
> list? This becomes an entirely subjective list which does nothing to
> promote the use of PmWiki on PmWiki.org.
Why Pick the List?
Removing references because they might turn some people away from
PmWiki or because those references make PmWiki look incomplete is a
subjective decision. Including a list of features from a disinterested
third party makes the list more objective.
When given a set of infinite choices, I chose to focus on those that
the Wiki Matrix (WM) web site concentrates on. That web site has
canvased the legion wiki products and reduced the set of common
features (or at least commonly sought after features) from which one
may base a technical or business decision. By choosing a disinterested
third party's list of comparison features, I sought to remove my own
Following WM's Lead
It is worth noting that somebody, probably Pm, maintains the PmWiki
entry on that web site. As such, one may wonder why repeat the list
here? For one reason, the WM site is a simple list with very little
commentary, and no links for further information. By expounding on the
features on the PmWiki site, we are able to give features better
treatment and link to relevant pages.
Second, this is not true duplication. The list of features themselves
are addressed, and the initial answers I posted were based on the
entries on that list. However, the expounding was meant to provide
a clearer, narrative answer and link to more information. The WM site
does not give a clean interface for such narrative discussion.
Another reason for repetition (so to speak) is that not all potential
PmWiki users will use the WM site for their initial survey of wikis. I
happened upon PmWiki because of the great-granddaddy of all wiki
sites. As a once was and shall be again software engineer, I want a
full grasp of what a wiki has to offer from which to base a decision.
By removing features common to wiki engines generally, this reduces
the "full grasp."
Finally, I opine that removing references to such unsupported common
features is professionally or academically dishonest. This is not a
dating relationship where we may hold back our warts a bit until the
prospective partner has come to like us and is therefore more likely
to accept those warts. This list was put together for prospective
users to make a technical or business decision. Those decision makers
need as many relevant facts as possible in a concise fashion so they
may make a sound decision. As such a decision maker, I prefer to see
warts and all.
Removing features creates what is called a negative implication.
Because it is not mentioned, it must not be supported. Therefore, one
could infer PmWiki supports only what is mentioned on this page.
PmWiki is not itself diminished by revealing that it does not do
(ususually by choice) certain things. Some of the absent features,
noteably the database storage, was based on a very sound technical
decision on Pm's part. Those decisions should be clearly explained,
and as necessary linked to the core PmWiki Philosophy. These
unsupported features explain PmWiki more completely than would a set
of "here's all we do" features.
A Chance to Support
Having a list of "not yet" carries an implication that we as a
Community know there are certain things we do not support. It gives us
a chance to decide "do we want to enable PmWiki do to Feature-X?" The
power of PmWiki is there are few features on that list that _cannot_
be done by recipe. I think the Right-to-Left language support is
perhaps the only one--assuming it is not supported. Having "Not Yets"
allows us to showcase this power of PmWiki by saying "hey, we don't
support it now, but with PmWiki it is likely possible that we can in
Pm has made a quality wiki engine because we developers in the
Community can--and have--done some amazing things. I could foresee a
developer saying "Huh. We don't provide Feature-X? Let me see about
that." An example of that would be my rather quirky Google Map API
recipe--I needed a way to embed a Google map but couldn't in PmWiki.
So, I wrote a recipe. That's the nature of our Community--we scratch
our itches with an itch-scratcher that might help others scratch their
Why Leave Some Features Out?
So, to return to the earlier question Mr. Herber posited: why include
Feature-X but not Feature-Y? After all, if PmWiki can do Google Maps,
why not include that in the list of features? First, that would be
grand-standing on my part, and I was trying to be impartial. Second,
every developer would want their recipe's feature in the list. Both of
these reasons are subjective in nature. Sure, we can address the
plug-in status by saying "see Recipe-Z." We can just as readily say
"see Recipe-Y and Recipe-Z" while still explaining the core issue
which is PmWiki supports this feature by plug-in.
As for "grandstanding," in my initial email on this issue I asked
recipe authors to review the list of features and add links to their
recipes. This takes me out of the subjective "pick my recipe" decision
making. Of course, if PmWiki has a rating system for pages, then we
would know which recipes are more commonly preferred and more
deserving of being listed on that page. The Features list I posted
mentions that PmWIki does not yet support this feature. People have
lamented on this list about the absence of such a feature. So, I've
been working on a recipe to give the ability to rate a page.
By implication I think this addresses a related issue. I have seen
some on the list complain that they have a hard time finding recipes
by feature. Well, by having a feature list, it is easier to create a
map in the Cookbook to that feature. For example, for the "Database"
feature, we could have "Cookbook.DatabaseRecipes" At the very least
such a page would include a simple pagelist. Alternatively, it gives
us a list of "objective" categories for recipes above the ones we
have. As a final, less attractive option, it gives us another way to
organize the Cookbook page by mapping to a list of features.
> The only things that make any sense to me on a "PmWiki doesn't do
> ..." list are items that have been purposely omitted, such as a
> database back-end. It gives an opportunity to explain why.
For the foregoing reasons, I submit that it is more objective to
include all features, rather than only ones Pm and the Community chose
not to support. I agree with you that it gives the opportunity to say
why. However, by the fact I hammered out several pages in rebuttal, I
do not agree that a feature in the feature list should be cut simply
because PmWiki does not support that feature.
A Better Argument to Exclude
It would be more compelling to remove a feature by showing that the
feature is universally unsupported by wikis and is likewise
universally undesireable. This is a more objective argument to exclude
a feature because it says "nobody supports or cares about this
feature, so why make an issue of it?" Thus far the trend in opposition
to the list of features I put together has been more along the line of
"I don't like this feature in there because it puts a smudge on
: One added benefit is the features list provides a map for
individuals to find more information about PmWiki's features and
recipes. Perhaps that is duplicative, but some people need that sort
of mapping. I go into detail a bit more later.
: Somebody has since edited the features to correct a feature that
was supported (by recipe, I think) but recorded as not. Had this
feature been removed, we would never have known it was supported.
: Perhaps perversely, I tend to delight in making salesmen,
especially technical salesmen and consultants, dance when I find they
are hiding a flaw in their product. They alway want to show only the
good side not realizing that judicious honesty goes a long
way--especially as I have been known to discredit a product by
pointing out the dishonesty. This is the "you lied here, so where else
have you lied" argument.
: This paragraph is an unfortunate side effect of a legal education.
: I just need to rethink a few notions I had early on before I
paint myself into a corner again.
More information about the pmwiki-users