[pmwiki-users] PmWiki past, present and future (was: Any hope for 2.2.0 stable release?)

Henrik Bechmann henrik.bechmann at sympatico.ca
Thu Jan 15 18:10:26 CST 2009

 >>and several default config files

It wouldn't be that big a reach to have a wiki page with some checkmarks 
to activate or de-activate plugins...

 >>We just need to be doing more of what we have so far.

I am really proposing one key change: a public subsite for development, 
with some kind of organized community support.

- Henrik

Radu Luchian wrote:
> 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 adopt.
> But that wish is probably too ambitious, for 'thoroughly tested' is 
> never a final definition.
> 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.
> Cheers,
> Radu
> On Thu, Jan 15, 2009 at 3:39 PM, John Rankin 
> <john.rankin at affinity.co.nz <mailto: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.
>     JR
>     --
>     John Rankin
>     Affinity Limited
>     T 64 4 495 3737
>     F 64 4 473 7991
>     021 RANKIN
>     john.rankin at affinity.co.nz <mailto:john.rankin at affinity.co.nz>
>     www.affinity.co.nz <http://www.affinity.co.nz>
>     _______________________________________________
>     pmwiki-users mailing list
>     pmwiki-users at pmichaud.com <mailto:pmwiki-users at pmichaud.com>
>     http://www.pmichaud.com/mailman/listinfo/pmwiki-users
> ------------------------------------------------------------------------
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Henrik Bechmann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090115/0e000886/attachment-0001.html 

More information about the pmwiki-users mailing list