Hi, >>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> The issue isn't trust. The issue is understanding. I think I am willing to give new maintainers the benfit of doubt as to whether they can excercise enough judgment to know if they understand a subject well enough to go and try to amend policy. In a sense, then, this is a kind of trust, a trust that the new guys are not off the wall and won't pepper the plicy list with frivoulous amendment attempts. >> Length of time with Debian is a poor metric of competence. Raul> True. Raul> However, there's a lot of documentation you must digest before Raul> you understand how to do a debian package, and how a debian Raul> system is supposed to work. Raul> And, we're going to get beginning programmers who also want to Raul> help us out. Or, more generally, we'll get people who can offer Raul> some incredible insights in some areas, while being largely Raul> unaware of other areas. I fail to see the problem. They file a bug report. People on the list discuss it, and let the new maintainer know the fallacy. Possibly a rationale is added to the policy documents so it is easier to understand. I think that objecting to the statement that Budha Buck made on these grounds is being overtly paranoid, and slightly insulting to new maintainers. Raul> After we figure out how and why, yes. If we make the imperative Raul> to modify policy really strong, and just plain ignore our goals Raul> for the project, I can see this turning into a real mess. >> What do you mean by that? How can having a policy that conforms to >> correct behaviour be against the goals of the project? Raul> The risk is that we'll apply spot fixes which make other Raul> problems worse. I think you do us a disservice here. And, anyway, there is no escaping this. We can alsways make decisions that are bad in the long run. Unless you have a reliable crystal ball, this is impossible to avoid. Raul> Just as software can wind up hacked up and garbled, when people Raul> go in and "fix" problems without really thinking about the Raul> design, so can policy. If you don't know [in simple terms] how Raul> the whole thing is supposed to work, this is a very big risk. You suddenly seem to be arguing that policy never be amended since we may just be screwing it up. If we can't depend on the wisdom of the people on the mailing list, or in the project in general, we may as well give up on systems integration and take up knitting. Raul> I'm going to try to draft up an introduction to the policy Raul> manual, that at least touches on the points I think are Raul> important. I think that should be a separate document, to be ratified under the proposals of the constitution. Policy should remain a set of technical dos and don't. Anything other than that should be considered for removal from the policy. Anything else shall be overloading the purpose of the policy documents. Maybe we should rename the current set "The *TECHNICAL* policy documents", and let non-technical policy be drafted and ratified. manoj -- If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. Gerald Weinberg (sysop's note: bull) Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]