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

[john.rankin at affinity.co.nz]

>  >>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...

Yes, although it may be several such pages eventually!

One reason I used the LaTeX terminology of package is that it
embodies the idea of not just code, but documentation too. To me,
plugin is a code-centric word, but that may just be me. So the
above wiki page would have not just activation/deactivation
power, but also links to each package's documentation.
>
>  >>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.

I think I agree, but it may be useful to expand this a bit.

How would "a public subsite for development" work and to
what extent is this compatible with my suggestion of a smaller
*and stable* core, with an "organized community" to provide a
replicable process for adding new packages to the distribution,
provided that they meet an agreed quality standard?
>
> - 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.

The key change is that the community would have a process for
people other than Pm to make contributions to the distribution,
without affecting the core. So yes, I took the existing model and
tried to generalise it a bit, learning from the LaTeX model to do so.

So I distinguish between the core, which is stable and as small as
possible (but no smaller), and the distribution, which contains a
range of packages, documented and tested, by many authors. The
core could well continue to have a single author, i.e. Pm.
>>
>> 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.

I think we could devise a robust scheme for what "thoroughly tested"
means for this community. I would add "and documented".
>>
>> 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.

I think we need to distinguish between the success of the community
(and the PmWiki community is great because people are almost
always constructive, even when they disagree, as reasonable people
do from time to time), and the strength of the community's processes.
I think the point Henrik and others have made (and the reason I
wrote such a long post before) is that the community now has an
opportunity to take PmWiki to the next level of maturity, but that
will require care so as not to kill the magic. So I proposed the
LaTeX community model, because they make distributions with
contributions from many, many authors, all of which meet
certain standards. While I don't think PmWiki needs their level
of structure, there is much we can learn from them.

There may be a more suitable model, of course.

JR
>>
>> 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:

<deleted/>
>>
>>     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>
>>
>
> --
>
> Henrik Bechmann
> bechmann.ca
>
>