[pmwiki-users] on over-bundling

Patrick R. Michaud pmichaud at pobox.com
Tue Mar 8 22:41:08 CST 2005


On Tue, Mar 08, 2005 at 09:31:52PM -0600, Jonathan Scott Duff wrote:
> On Tue, Mar 08, 2005 at 09:51:49PM -0500, Radu wrote:
> > Q: how can we keep pmwiki as effective for each application as possible?
> [deletia]
> > One of the PmWiki Philosophy points I like a lot is basically KISS (keep it 
> > simple sir ;). However, many issues in the PITS are clamoring for more and 
> > more functionality to be included with the default distribution.
> 
> Sure, but isn't that what the cookbook is for?  People prototype
> features in the cookbook and then when enough "clamoring" happens, Pm
> adds features to pmwiki.

There's several sides to this.  First, PITS isn't so much a request list
as it is a community memory of things we've talked about doing but,
for whatever reason, haven't gotten around to yet.  I know that prior
to PITS I sometimes felt as though some good ideas were being proposed
but then would be "forgotten" as time passed.  PITS gives me a ready
list of "things to think about" when extending PmWiki, as well as
providing an indication of the relative interest for each item
within the community.

Also, there are a lot of people who may want a feature but who don't
have the time, inclination, or experience to write a cookbook item.
PITS is a good place for them to record the request.

> > Now, I had suggested to Pm that a more modular distribution might be a
> > good idea. 
> 
> Perhaps.  You know, there's nothing stopping you from building your
> own pmwiki-as-blog or pmwiki-as-cms distributions.  I'm sure if you
> did it, Pm would make a special place for them on pmwiki.org.

I think the suggestion of creating wikitrails for each application
is an excellent idea, and I hope to see it happen.  There's already
a start with the PmWikiAsACMS page, but making it a trail is nicer.  
Another option, as opposed to separate and full PmWiki distributions, 
would be to package related cookbook recipes together into a "CMS bundle",
"blog bundle", "publishing bundle", etc.  Each bundle would be pre-tested
and pre-configured with the most common options and skin(s) for that 
application, so that a site administrator could download and install 
PmWiki and a bundle and be ready to go.

I think that overall it's a bit easier to keep the bundles separate
from the core distribution, if only because we don't have to update
each bundle each time a new core release is issued.  ("Release early,
release often" still applies.)

> > Different people want to use the wiki for different things, so why not
> > separate (possibly sort?) PITS issues based on use-niche (e.g. CMS,
> > blog, project development...)
> 
> Sure.  You can use the category feature to bundle related PITS
> entries.  Also, once everything is categorized, an "issue map" could
> be made relatively easily (showing interdependencies among other
> things).

We can also categorize cookbook recipes.  In fact, this would probably
be an excellent demonstration of how categories work, which is something
we've needed on pmwiki.org.

And each PITS entry already has a "Category" line -- there's nothing
to stop that line from begin augmented with additional categorizing
information.

> > Of course, maybe I'm wrong and we should all concentrate towards
> > building a unique distribution that does everything for everybody...
> 
> No. Way.

Amen -- I'm not going there, if only because there are some
applications and environments that are mutually exclusive.  Plus,
PmWiki's forte has always customization, not universality.  
However, there's no need for each site to have to reconstruct
the wheel -- categorizing and bundling recipes and features into 
"best practices for application XYZ" could really help site 
administrators get to where they want to go.

Pm



More information about the pmwiki-users mailing list