A unified diff of the changes Ian made to reflect people's feedback on draft 4 of his proposed disputes resolution document is MIME-attached. -- G. Branden Robinson | When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. branden@debian.org | -- Robert Anton Wilson http://people.debian.org/~branden/ |
--- iwj_draft4 2002-11-06 12:07:59.000000000 -0500 +++ iwj_draft5 2002-11-07 04:25:23.000000000 -0500 @@ -1,6 +1,18 @@ - DISPUTES BETWEEN DEVELOPERS + ____ ____ _ _____ _____ + __/\____/\__ | _ \| _ \ / \ | ___|_ _| __/\____/\__ + \ /\ / | | | | |_) | / _ \ | |_ | | \ /\ / + /_ _\/_ _\ | |_| | _ < / ___ \| _| | | /_ _\/_ _\ + \/ \/ |____/|_| \_\/_/ \_\_| |_| \/ \/ + + DISPUTES BETWEEN DEVELOPERS + +A *DRAFT* recommendation, which Ian Jackson hopes will be approved +in some form by the Technical Committee and the Project Leader. + +THIS DOCUMENT IS NOT YET APPROVED BY ANYONE. IT IS A FIGMENT OF YOUR +IMAGINATION. IF YOU POSSIBLY SUSPECT THAT ANYONE EXCEPT IAN JACKSON +AGREES WITH IT THEN PLEASE GO WASH YOUR BRAIN OUT WITH FLAMES. -A *DRAFT* recommendation by the Technical Committee. 1. Motivation @@ -80,7 +92,8 @@ If you feel another Developer has erred, by failing to go about things in the right way, you should of course tell them about it. But, please try to make your message helpful and friendly. Probably they -didn't know about the rule in question, or understand it differently. +didn't know about the rule in question, or understand it differently - +do not assume that the error was deliberate. If you can, refer the other Developer to some documentation explaining what the right process is. If such documentation does not exist, @@ -90,15 +103,18 @@ Debian Developers' Reference is usually an excellent place to document common practice. -If the other Developer disagrees, you should seek guidance from the -wider Project, so that everyone has the same ideas of how things are -supposed to work. In the end, if a firm decision needs to be made, -the Project Leadership will have to decide. - -If a Developer persistently flouts the Project's rules - written or -unwritten - then you should consult the Project Leadership for advice; -the Project Leadership will, if appropriate, warn them about their -behaviour, and in extreme cases may seek the Developer's expulsion. +Often, the Project's rules are not absolute, and context is important, +so be prepared to explain the rationale, explain why the rule applies +in the particular case, and/or point out precedents. + +If the other Developer still disagrees, you should seek guidance from +the wider Project. For example, start a discussion on the merits of +the rule or practice; often, it may be that the rule or practice needs +to be amended. The result may be a better documented rule with a good +rationale, that may prevent such a disagreement in the future. + +In the end, if no decision can be reached by consensus and a firm +decision needs to be made, the Project Leadership will have to decide. 5. Technical disagreements @@ -146,7 +162,7 @@ * The bug was reported; the maintainer felt immediately that it was a spurious bug report of some kind, and closed it, but the submitter disagrees with the explanation and has reopened the report for -discussion. The matter should be debated until both Developers are +discussion. The matter should be debated until both parties are happy. While a situation is being discussed, any relevant bug report(s)
Attachment:
pgpBUHkx8tONX.pgp
Description: PGP signature