<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
>>Who's going to make the final decision<br>
<br>
Pm, particularly if there is a dispute<br>
<br>
>>Who does what and when?<br>
<br>
Determined by consensus. I favour the notion of a meritocracy. People
develop influence based on their contributions.<br>
<br>
>>each dev (or group sharing the same goals) works on a different
recipe.<br>
<br>
I think John Rankin's idea of plugins that can be turned on/off is
interesting.<br>
<br>
>>How's that? If you have followed this list for a while, you can
see
that pretty much every member has a different goal, different needs,
different types of user bases. So they would make decisions based on
what their own goal is.<br>
<br>
So we work at consensus....<br>
<br>
>>I thought you were asking for opinions from Pmwiki users :) <br>
<br>
I just meant that if you're not interested in future changes, then
logically it doesn't matter to you what happens with future versions.<br>
<br>
>>I am happy with the development as it goes now. <br>
<br>
In case you haven't noticed it's not working. IAC in the long run any
product is going to be more reliable if it is supported by a group.
Deals with attrition, personal issues, etc.<br>
<br>
>>If you want to OOP pmwiki, it will be something else
altogether, and all recipes will have to be rewritten too. Brrr!<br>
<br>
True. I would estimate the core could be re-written at about 50 lines
per day (it's pretty dense), which would be about 100 person days, say
600 to 1200 person hours. Personally I think it would be worth it
(subject to a thorough vetting of course).<br>
<br>
Recipes could probably be adapted much more quickly, particularly when
standard interfaces were developed.<br>
<br>
- Henrik<br>
<br>
Radu Luchian wrote:
<blockquote
cite="mid:74366fbf0901151516p47f5bad3l1f6ff6c72801c838@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Thu, Jan 15, 2009 at 1:25 PM, Henrik
Bechmann <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:henrik.bechmann@sympatico.ca">henrik.bechmann@sympatico.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Did I call them committees?
Can you give references? <grin></div>
</blockquote>
<div><br>
Any group that works together on making decisions is a committee...
Bah, semantics... New problems arise: who's going to make the final
decision on everything? Who does what and when? Why didn't they do it,
if they said they will? The way it works now, is that if there are goal
differences in implementing a feature, each dev (or group sharing the
same goals) works on a different recipe.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> I
think more in terms of teams, and yes I think that discussion and
design are worth the effort, ie they save time in the long run. </div>
</blockquote>
<div><br>
How's that? If you have followed this list for a while, you can see
that pretty much every member has a different goal, different needs,
different types of user bases. So they would make decisions based on
what their own goal is.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Doing
random things on a complex codebase "if you have five minutes" is nuts.
I presume you're not serious.</div>
</blockquote>
<div><br>
No, I'm not. Seriousness is overrated :) And in determined people, it
leads to ulcers :) I like to have fun programming. Which is why I don't
work for a programming house.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Sounds like you're a
developer (as am I). Glad you like it as is. So do
I. But I think there are lots of areas for improvement, particularly
WRT usability. And if we're going to do it as a group we better get
organized about it, or do you really promote the idea of random people
doing random things to the core codebase if they have five minutes?!?</div>
</blockquote>
<div><br>
Yes. That's what I do with my pmwiki farms. That's what many other
pmwiki devs do on theirs. But we're not imposing our solutions on
others. The core is PM's to do what he needs with. He usually takes
good suggestions and explains why he rejects other ones. A couple of
times what I needed (and thought was ok with respect with PM's
Philosophy statements), did not meet with his approval, and he had his
reasons. Remember, the project is his, and he chooses what to do. We're
only along for the ride. If I disagree with some choice of his, I fix
it in my cookbook folder, not in the core. When the core changes
radically, sometimes I have to change my recipes. Luckily, not very
often at all.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">IAC you're certainly entitled
to your opinion. But if you're really
happy with it as it is, then take a copy, and step aside. This
discussion isn't relevant to you.</div>
</blockquote>
<div><br>
I thought you were asking for opinions from Pmwiki users :) <br>
</div>
I am happy with the development as it goes now. The core belongs to PM
and until he decides he doesn't want to deal with it anymore, I trust
his coordinating vision (One man, one vision; a group brings
dissension, even if only potentially). On recipes, we all have free
range. BUT. If you want to OOP pmwiki, it will be something else
altogether, and all recipes will have to be rewritten too. Brrr!<br>
<br>
Cheers,<br>
Radu<br>
</div>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
bechmann.ca
</pre>
</body>
</html>