>>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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
www.affinity.co.nz <http://www.affinity.co.nz>
_______________________________________________
pmwiki-users mailing list
[email protected] <mailto:[email protected]>
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
------------------------------------------------------------------------
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
--
Henrik Bechmann
bechmann.ca
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
