[pmwiki-users] PmWiki past, present and future (was: Any hope for 2.2.0 stable release?)
radu at monicsoft.net
Thu Jan 15 18:04:08 CST 2009
Now that was a message I thoroughly agree with.
And, luckily, it presents things just as they are now, with core scripts
which are there in the distribution, but are not activated.
What I would like to finally see would be a core distribution containing all
thoroughly tested scripts, and several default config files: one with the
bare minimum functionality for a wiki (view, edit, track and manage wiki
pages with a minimum of formatting and markup), and one sample config for a
few types of use the wiki may be applied to, each config having an active
supervising developer. That would provide new users with the maximum return
to the minimum amount of invested time and make pmwiki a real breeze to
But that wish is probably too ambitious, for 'thoroughly tested' is never a
As for a successful community model to fit Pmwiki's philosophy, I could
quote ours :)
We just need to be doing more of what we have so far.
On Thu, Jan 15, 2009 at 3:39 PM, John Rankin <john.rankin at affinity.co.nz>wrote:
> First, I agree that taking Pmiki 2.2 out of beta would be excellent.
> Even though it is far more stable than many so-called "production"
> releases of other software, risk-averse organisations may simply
> have a policy not to use "beta" software. This is a shame.
> I propose an updated release page to list things that will be
> added to turn the current beta into 2.2.1. This could be an empty
> list, as several people have suggested. I own up to one change
> I'd really like to see, that would prevent my having to patch
> every release so that pagelists work with the PublishPDF recipe.
> However, this is selfishness on my part. The change is trivial
> and does not affect functionality in any way. I am sure others
> have their own pet change requests. The criterion for inclusion
> could be, "Pm deems it trivial".
> Turning to the question of PmWiki's future... I look back at
> the past.
> One of the things that attracted me in the first place, and
> has kept me actively using the engine and enhancing various
> recipes, is that PmWiki has a very low barrier to entry. A
> user does not need to know Php to make local customisations.
> In my case, I hadn't written a program for (mumble) years and
> knew nothing about Php. I believe this is one of the reasons
> Pm chose Php -- non-developers could be empowered. Would I
> need to learn object-oriented programming to create complex
> recipes in future, for example? While this may be a good
> thing, it is also a barrier for the non-developer. And would
> many existing recipes break?
> Also, PmWiki runs on just about anything. My hosting service
> only upgraded from Php 4.1.2 [sic!] to Php 5 about 2 weeks ago.
> Mac OS X Tiger still runs Php 4.something, I believe. There is
> a balance between moving with the times and creating a barrier
> to entry. Perhaps by the time PmWiki 3.0 comes out, Php 5 will
> be ubiquitous and it will not matter. Is Php still the best
> tool for the purpose? I do not have an informed opinion.
> The other thing that attracted me was the idea that the core
> functionality is kept tight, with plug-ins to do other things.
> Much as I like the functionality added in 2.2, I find PmWiki
> has become somewhat daunting in its breadth of capability.
> In my case, 2.1.27 is a pretty sweet balance of power while
> still small enough to hold it all in my head. Adding more
> functionality can make a good product worse. An example is
> the Ford Thunderbird which morphed from cool to beige through
> 20 years of improvements. So I am cautious about adding more
> things to the core, and a case could be made for a PmWiki
> starter option, where most of the advanced features are off
> by default. There is now a huge amount of stuff for new users
> to get their heads around.
> There is a saying, "House finished, man die." But if a piece
> of software fulfills its purpose, it is finished and need not
> be "enhanced". Adding features is easy, but results in bloated
> software (insert your favourite bloatware here). Deciding
> which features to leave out is hard, but much more useful.
> Pm has, in my view, been exemplary here.
> Looking forward...
> As a starter for 10... "Smaller core, bigger optional feature
> set, cookbook a hotbed of innovation."
> I'd like to suggest that PmWiki would lend itself very well
> to moving in the direction of the LaTeX model of "packages".
> That is, the distribution consists of a relatively small core,
> that does all many people need "out of the box". Included in
> the distribution is a wide range of "approved" (to be defined)
> third party packages, all disabled by default. To be approved,
> a package would have to meet various quality criteria and meet
> agreed documentation standards, for example. Packages could add
> functions or skins, of course. The Cookbook would continue to
> be the route by which innovation happens at the leading edge.
> This structure would also facilitate creation of "A short guide
> to PmWiki" documentation. Choosing what forms the core would
> no doubt be hard; my guiding principle is "better out than in".
> This model could let a distributed community organise itself
> in very flexible ways, while retaining the open and inclusive
> nature of the community that Pm has nurtured over the years.
> It also sounds similar to the Drupal community Ben Stallings
> so eloquently describes. I do think that PmWikihas reached a
> critical mass of capability where something between the
> tightly-managed core and the wide-open Cookbook may be needed
> to manage future developments, while still encouraging innovation.
> I think this could also help to improve the documentation.
> For example, to be accepted as a package, documentation would
> have to meet a minimum standard. To be part of the core feature
> set, the documentation standard would be higher.
> So I think my fundamental question is this: Is there an existing
> successful community model that aligns with the PmWiki philosophy
> and would help PmWiki evolve to a new stage of development?
> Finally, it's great to see this topic being aired with so many
> constructive contributions. That's one of the nice things about
> the PmWiki community. This is just my 10¢ worth.
> John Rankin
> Affinity Limited
> T 64 4 495 3737
> F 64 4 473 7991
> 021 RANKIN
> john.rankin at affinity.co.nz
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users