MIME-attached. Ian says he finds diffs confusing, but they helped me to understand the changes much better. Your mileage may vary. -- G. Branden Robinson | The errors of great men are Debian GNU/Linux | venerable because they are more branden@debian.org | fruitful than the truths of little http://people.debian.org/~branden/ | men. -- Friedrich Nietzsche
--- iwj_draft1 2002-10-28 12:14:38.000000000 -0500 +++ iwj_draft3 2002-10-28 12:14:44.000000000 -0500 @@ -8,22 +8,31 @@ Debian is a very large project. We will inevitably disagree, and occasionally get annoyed with each other. To allow us to work well -together a bit of give and take is needed, and we must be willing -willing to present coherent reasons for our views, and to listen to -and engage with counterarguments. +together a bit of give and take is needed, and we must be willing to +present coherent reasons for our views, and to listen to and engage +with counterarguments. This document gives some general advice about friendly interaction. -It also says what you can do when this fails - if you are having -problems working well with another Developer, or if despite talking to -them constructively you cannot agree. +It also says what you can do when this fails: if you are having +problems working well with another Developer; or if, despite talking +to them constructively, you cannot agree. 2. Distinguish flameage from technical disputes and procedural errors -Distinguish problems working constructively due to an interpersonal -dispute (`not getting along'), from technical disagreements about how -software should work, or procedural disagreements about whether some -particular thing should or should not be done. +There are basically three kinds of dispute: + +* Technical disagreements: these are largely about how software should + work, and form the meat of many of the Project's discussions. + +* Procedural disagreements: these are about how the project should + work, rather than about software. + +* Interpersonal disputes - just `not getting along'. In any large + community like Debian there will be personality clashes, and people + you find difficult to deal with. + +Try to keep these separate, and to get along as best you can. For Debian to be able to construct good software, we must be able to disagree with the way something is done or proposed in a constructive @@ -32,7 +41,7 @@ Useful technical discussions can become derailed by flameage. To help avoid this, please phrase your technical disagreements moderately. -If you receive a heated complaint about some technical matter please +If you receive a heated complaint about some technical matter, please try to respond to the technical, not emotional, content ! @@ -54,13 +63,12 @@ If it's a technical dispute, try to talk only about the technical questions at issue. Avoid complaining to the other Developer that they are being unhelpful; that'll turn the conversation into a -slanging match. +shouting match. -If you really can't engage helpfully, for example because the other -Developer refuses constructive discussion, you can refer the question +If you really can't engage helpfully - for example, because the other +Developer refuses constructive discussion - you can refer the question to the Technical Committee (including, possibly, reassigning a bug -report to them) or the Project Leadership. If you do this, be -prepared to be told to go away and grow up ! +report to them) or the Project Leadership. 4. Procedural mistakes and disagreements @@ -75,8 +83,14 @@ 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. -If you can refer the other Developer to some documentation saying when -they should and should not do something, do so. + +If you can, refer the other Developer to some documentation saying +when they should and should not do something, do so. If such +documentation does not exist, consider writing it - it is difficult for +nonexistent documentation to be authoritative, and a misunderstanding +that arises once in the absence of a documented procedure is likely to +arise again. The 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 @@ -86,7 +100,7 @@ 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 -behavour, and in extreme cases may seek the Developers' expulsion. +behaviour, and in extreme cases may seek the Developer's expulsion. 5. Technical disagreements @@ -102,7 +116,7 @@ Be flexible; try to avoid categorical statements such as `I will never implement that'. There is no shame in being convinced, by good arguments, to change your mind, even if you have just been vigorously -propounding the opposite view ! +promoting the opposite view ! In the case of a tradeoff between one good property and another, there are often value judgements to be made; these value judgements are @@ -112,7 +126,7 @@ If discussing the issue with all the relevant people hasn't produced a conclusion and doesn't look like it will, the Technical Committee can decide. You can refer it to the Committee in the form of a bug report -- see below; sending a summary of the situation to the Committee would +(see below); sending a summary of the situation to the Committee would be very helpful, too.
Attachment:
pgpfqOc1w4M_n.pgp
Description: PGP signature