[pmwiki-users] How to submit patches to PmWiki?
nzskiwi at gmail.com
Fri Jun 26 18:08:11 CDT 2009
I have noticed that PITs entries don't seem to be much exposure (eg on
mailing lists), discussion (eg comments on the page), or support (eg votes).
I'd like to see a bit more boldness and vitality in the PmWiki community,
the pace of change when I started using PmWiki was exciting,
and encouraged me to hop on board the train.
I worry that we have changed to an era where we should be more progressive,
and now have a philosophy of being overly conservative about changing the
Perhaps we have an opportunity for the committers to lead a discussion about
the road map for the core, and for extensions.
I'd like to see more submissions from code submitters taken on board and
Particularly where those enable recipe writers to improve there recipes,
and where they fix identifiable issues in the core.
While I wouldn't like PmWiki to because a swiss army knife (one of the
reasons I chose it), on the other hand I didn't want UseMod (as an example
of a low feature low change wiki) either.
When it gets to the point that I have to individually select and install 20
or so recipes to get the functionality I want I have to wonder if the
balance has swung too far in the other direction.
I don't have a problem with changing PmWiki behaviour, or removing some
backward compatibility between major releases, especially if it supports a
clean code base, and a more consistent experience for authors.
I recognise that adding to the core adds to complexity, and the the load of
the maintainers - my suggestion, increase the community of submitters.
I also recognise that in in some areas - eg images - there are a number of
great recipes, in others there are exactly one that do a good job of
enabling some 'basic' functionality,
I can think of several, but examples to me (off the top of my head) are
and the jt patch to
all of which, to me, add what I consider to be needed and basic
I also do appreciate the responsiveness of the current committers and the
size of the task facing them, its partially for this reason that a good
discussion from the PmWiki community is required.
PmWiki is a fantastic product, lets keep it that was through keeping it
active, evolving, and through the participation and contributions of us, its
2009/6/27 Chris Cox <ccox at endlessnow.com>
> I think there are two sides... I like PmWiki as a set of lower level
> tools... a toolkit upon which we can build extensions (we often call
> these recipes).
> The other side are those looking for a feature rich deployment platform
> where little to no configuration (even downloading a "recipe") is
> So, with that said, I think the idea of "recipes" in the core is
> possible, but I'd like to see it done in a way that does not require
> adding bloat to the base PmWiki. Perhaps some automated way to pull in
> "signed" extensions afterward (?)... or maybe a large add-on download.
> Of course, there will also be the normal "recipe" way of pulling in othe
> rextensions (along with the problems and conflicts that they might
> So, for example, I download PmWiki, which allows ME to build great
> things. But let's say there's feature-full blogging package that is now
> part of the core (a "signed" extension). And it has all the bells and
> whistles of the major blogging packages out there, perhaps is close to
> the size of the PmWiki core itself. That piece could be optionally
> added using some kind of automatic PmWiki package install command... or
> it might be part of the larger inclusive extension package that I could
> Obviously, things like this would require some work.
> Bug fixes though are fine. And additions to the core that make it a
> better more flexible toolkit is also fine.
> Just some ideas...
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users