Definitely yes to releasing a new stable version, even if some features aren't ready. But NOT if that requires too much time to be added to anyone's schedule for pruning code.
About the rest of the discussion,... Jeez. I would look up some Dilbert cartoons on decisions by committee, but I have other things to do right now :) In a word, Pmwiki is just fine, and just stating that it's backward (laggard, in need of unnecessary development just to add extra overhead for OOP or some such), doesn't make it so. Less development in a product that boasts so much functionality and such flexibility as Pmwiki, is just a measure of stability. More of my opinions below. Cheers, Radu On Thu, Jan 15, 2009 at 12:08 PM, Henrik Bechmann < [email protected]> wrote: > My own installation of PmWiki will probably serve as is for another couple > of years, but then it'll really start to get tired without further > development. > What's with all this need for development? I find the current model used just dandy. If I need something new, I develop. But I like simplicity, and I try to keep functionality and resources used to a minimum. In the beta core I tend to undefine functions more than add new ones. So adding stuff to the core and even more, to the default setup sort of goes against the PmWiki Philosophy. If you need something that's not yet available, discuss, implement and if you have the time, release as recipe. If you have problems with the docs, talk it over on one of the lists, then go ahead and make the changes. What's with the need for formal organization?? Open Source is great for its informality. Got five minutes? Do something. There's no deadline, no headache and very limited stress. But that gives us time to get organized for moving forward. > Jeez. Do you suffer from the effects of too many management courses? ;) > The question is, is there sufficient interest and energy to assemble an > effective group. > The group is as effective as we have time for. > What I see: > > Step 1: declare current release out of beta > It's not only a matter of declaration... SomeONE (PM obviously) has to use a sizeable chunk of his time to make sure the code and docs are consistent enough for a release. And I say ONE because all decisions by committee (like OOP, BTW), suffer from a heluva lot of overhead and in the end require far more resources than if they are done by one person. If PM needs help with something, he'll ask. > Step 2: identify a (for real) webmaster to take responsibility for > pmwiki.org > I used to like Wikipedia a lot before they introduced the commitee system. Now we got censure and repeated requests for funding. All developers are webmastering the wiki site whenever we can. We identify ourselves by doing stuff. Which is the point of a wiki. > Step 3: create a development.pmwiki.org subsite, where we can set up a > wiki to begin a formal planning process (and set up a TRAC repository for > the current code base) > What's wrong with the current svn? Why do we need to spend more server resources on a python web interface? Step 4: fire up pmwiki-devel for *lively* discussions about related issues: > planning, feature discussions, organization, decision making, etc. > Go ahead. Organize :)
_______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
