[pmwiki-users] Re: Notes and plans for PmWiki 2.1
Patrick R. Michaud
pmichaud at pobox.com
Fri Oct 21 15:36:45 CDT 2005
On Fri, Oct 21, 2005 at 10:41:15AM -0500, Jonathan Scott Duff wrote:
> Though, really, for any of these I'm not sure how to draw the dividing
> line between 2.1 and 2.2 or later (or even if these are to not make pmwiki-
> core at all). It would help, perhaps, to have some sort of life-time
> estimate for 2.1. If there is a must-have feature for me then I have to
> "support" it myself until it's part of pmwiki-core. If my must-have
> feature doesn't make it into 2.1, how long before it does make it into
> pmwiki? Will it even make it into pmwiki? If pmwiki-2.1 will be here
> in a couple of weeks, will 2.2 arrive a few weeks later?
I understand the comment, but the phrasing of the above seems
to assume that there's a relationship between the introduction of
new (possibly major) features and version numbers. There's not.
I primarily use major version numbers (pmwiki-2.0, pmwiki-2.1, etc.)
as "breakage points", not as feature set identifiers. So, just
because something isn't slated today for 2.1.0 doesn't mean it must
necessarily wait until 2.2.0 to be implemented.
Yes, this method of version numbering is not the way most commercial
software companies do things, but I think commercial software
tends to use version numbers for marketing purposes, whereas
I prefer to use them to indicate "potential difficulty of upgrade".
So, whether pmwiki-2.2 occurs in two weeks or a year doesn't
really indicate how soon new things might be added.
Thus to rephrase your comment, what I think you're really asking is
how can admins determine when their particular "must-have" features
will be implemented or part of the distribution? For that I don't
have a completely clear cut answer. Much of it depends on my available
"free time", energy, and personal need for any particular feature.
But I think I can give some insights into the answer...
First, if a requested feature was easy to implement, I'd have
probably done it already. So, anything that isn't already
implemented must be one or more of:
- difficult to implement by the inherent nature of the feature
- difficult to implement and support on all commonly-used platforms
- presents long-term design, implementation, or integration issues
- causes significant incompatibilities/difficulties for existing
sites and recipes
- insufficiently understood/specified (this commonly happens when
people say things like "I want blogging features" but don't
entirely agree on the meaning of "blogging features")
- contrary to PmWikiPhilosophy
Things that fall in the above groupings tend to accumulate
as feature requests in PITS, and that's a place where one
can get my current thinking on each item. (The other is to
just ask me. :-) If I mark something as "ToDo", that means that
at some point in the future I'm expecting to actually write
the feature myself, but I feel I need to take or find some
time to develop it properly.
If an issue is listed as a "CoreCandidate", that generally means
I want to hear from others about whether an issue should become
part of the core or left as a cookbook recipe.
If an issue is marked as "Awaiting feedback", it generally
means I feel that I cannot move forward on the issue until
I get more commentary or feedback from others.
If an issue is marked as "Suspended", that means that it's
either so difficult and/or seems to have so little priority
behind it that I'm not likely to address it until something
happens that makes it less difficult and/or much more important.
If I think something is contrary to PmWikiPhilosophy or unlikely
to be in the core anytime soon, I'll generally indicate that
the issue is best addressed as a "cookbook recipe" and close the
issue (although I've been thinking about creating a special
"add to cookbook" designation for these).
Throughout all of this, I do keep a very close eye on the
priority votes associated with each issue.
- If an issue has accumulated a lot of positive votes and
still hasn't been done, it generally means there are some
design or compatibility issues involved. This was the
case for user-based authorization (#00010), and continues to be
the case for the issues of page comments (#00045) and table of
- If an open issue has only one or two votes, I take that
as an indication that there's not broad interest in the issue,
and following PmWikiPhilosophy #3 (avoid gratuitous
features) I tend to leave it alone.
Lastly, I'll note that it possible to *buy* features. :-)
So far PmWiki is still mostly volunteer work for me, and
I do have other things on my plate. So, if someone (or a
group of someones) wants to send me some money to fast-track
a particular feature, I'm sure we can arrange it. I've
even thought about putting "Buy it now!" prices on some
features, so that when enough people have committed to
the buy-it-now price, I drop whatever I'm doing and add
the feature to collect my money. The coordination of
funds from multiple donors could be coordinated through
fundable.org, where nobody is charged anything until the
full subscription amount is reached.
And in no way do I mean this last comment to imply that
payment is a prerequisite for *any* feature -- I'm just
indicating that there are ways to get me to make features
happen at a quicker pace than normal. :-)
Hope this helps.
More information about the pmwiki-users