[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
bechmann.ca
-------------- 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