On Wed, Oct 16, 2002 at 09:07:19PM +0100, Ian Jackson wrote: > I've noticed, mainly due to getting closer to disputes due to greater > tech-ctte activity, that some disputes are getting really quite > dysfunctional. So, I wrote the draft below. Let me know what you > think. If people like it we can post it to d-d-a and I'll write it up > for a web page, or we can put it in the developers' reference, or > something.
Overall, it looks great. Thanks for working on this. I have a few suggestions, raging from stylistic and spelling corrections to the more substantive, reflecting my own observations of disputes (some of which have gone to the Technical Committee, and some which haven't). I'm also confused by one thing, which I've placed in brackets. I'm attaching a diff, and my revised version in the event that it is useful. -- G. Branden Robinson | If you have the slightest bit of Debian GNU/Linux | intellectual integrity you cannot [EMAIL PROTECTED] | support the government. http://people.debian.org/~branden/ | -- anonymous
--- disputes~ 2002-10-16 16:29:11.000000000 -0500
+++ disputes 2002-10-16 17:01:10.000000000 -0500
@@ -1,27 +1,27 @@
- DISPUTES BETWEEN DEVELOPERS
+ DISPUTES BETWEEN DEVELOPERS
A *DRAFT* joint recommendation of the the Technical Committee, the
-Project Leader and the Bug Tracking System Administrators.
+Project Leader (DPL) and the Bug Tracking System (BTS) Administrators.
1. Motivation
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.
+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
+2. Distinguish flamage from technical disputes and procedural errors
Distinguish problems working constructively due to an interpersonal
-dispute (`not getting along'), from technical disagreements about how
+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.
@@ -30,10 +30,10 @@
and useful way. The best designs result when all the issues have been
considered.
-Useful technical discussions can become derailed by flameage. To help
+Useful technical discussions can become derailed by flamage. To help
avoid this, please phrase your technical disagreements moderately.
-If you receive a heated complaint about some technical matter please
-try to respond to the technical, not emotional, content !
+If you receive a heated complaint about some technical matter, please
+try to respond to the technical, not emotional, content!
3. Interpersonal behaviour
@@ -54,29 +54,41 @@
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 (meaning the DPL or a
+delegate of the DPL with jurisdiction over the issue). If you do
+this, be prepared to be told to go away and grow up!
+
+[??? The person who *doesn't* refuse constructive discussion may be
+told to go away and grow up? Doesn't this reward those who refuse to
+discuss things constructively, by letting them have their way by
+default? ]
4. Procedural mistakes and disagreements
The Project has many rules and conventions, written and unwritten,
-about when certain actions are appropriate and are inappropriate. For
-example, sending a non-maintainer-upload of another Developer's
-package, closing and reopening a bug report, and forwarding mail from
-one place to another, are all sometimes appropriate but sometimes not.
+about when certain actions are appropriate and are inappropriate, and
+which fall outside the purview of the Technical Committee. For
+example, making a non-maintainer-upload of another Developer's
+package, closing or reopening a bug report, and forwarding mail from
+one place to another, are each sometimes appropriate but sometimes not.
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.
If you can refer the other Developer to some documentation saying when
-they should and should not do something, do so.
+they should and should not do something, do so. If such documentation
+does not exist, take it upon yourself to write 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 +98,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 Developers' expulsion.
5. Technical disagreements
@@ -99,10 +111,10 @@
where necessary. When you're short of time you should reduce the
quantity, not the quality, of your contributions.
-Be flexible; try to avoid categorical statements such as `I will never
-implement that'. There is no shame in being convinced, by good
+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 !
+propounding 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,49 +124,65 @@
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.
6. Bug report etiquette
Sometimes bugs are reported inappropriately; likewise, sometimes
-maintainers close bug reports inappropriately. Bug reports are `todo
-list' items for the whole Project; they should be closed when there is
-rough consensus that the whole system is working as well as it could.
+maintainers close or change the severities of bug reports
+inappropriately. Bug reports are "to do list" items for the whole
+Project; they should be closed when there is rough consensus that the
+whole system is working as well as it could.
For example, here are some examples of situations where a bug report
should not be closed:
-* The bug was reported against A, reassigned to B, but the maintainer
-of B feels that B is working correctly (and by implication that the
-bug is in A). The maintainers should talk about it to decide which
-package needs to change, without closing the bug until it's fixed.
+* A bug was reported against package A, then reassigned to package
+B, but the maintainer of B feels that B is working correctly (and by
+implication that the bug is in A). The maintainers should talk about
+it to decide which package needs to change, without closing the bug
+until it's fixed.
-* The bug was reported; the maintainer felt immediately that it was a
+* A 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
-happy.
+discussion. The matter should be debated until both parties are
+happy. In the meantime, the maintainer can use the "wontfix" tag in
+the BTS to indicate to interested parties that a resolution is not
+being actively worked on. (In some circumstances, the "help" or
+"moreinfo" tags may be more appropriate, depending on the nature of
+the disagreement and specifics of the situation.)
+
+* A bug was reported; both the maintainer and the submitter agree that
+it's a defect, but disagree in their interpretations of the
+definitions of bug severities. The bug should be left at the severity
+determined by the package maintainer, but the report should not be
+closed. The parties should discuss their disagreement within the bug
+report until some mutual agreement can be reached. Note that the
+Release Manager may regard a bug as "release-critical" (or not)
+irrespective of its severity in the BTS.
While a situation is being discussed, any relevant bug report(s)
should remain open. If a package maintainer closes your bug report,
you may reopen it if you wish to continue the discussion.
-At no other time should you play `bug report tag' with anyone else.
-If someone makes a change to a bug report status which you disagree
-with you should *discuss* the matter with them but *not* immediately
-undo their action in the BTS, except to reopen the bug to stop it
-getting lost. If you are unable to reach a conclusion through
-constructive discussion, you should ask for outside help with
-resolving your dispute, as outlined above.
+Under no other circumstances should you get into a back-and-forth with
+a package maintainer, changing the state of a bug in the BTS. If
+the maintainer of the package against which a bug is filed makes a
+change to that bug report which you disagree, you should *discuss* the
+matter with them but *not* immediately undo their action in the BTS,
+except to reopen the bug to stop it getting lost. If you are unable
+to reach a conclusion through constructive discussion, you should ask
+for outside help with resolving your dispute, as outlined above.
Note that while the Technical Committee is also happy to help resolve
disputes over individual bug reports, you should not refer a matter to
the Committee until you have tried to explore the issue yourselves.
When this has been done, the bug report logs should contain detailed
description of the problem and records of your discussions, and you
-may then reassign the bug report to the pseudo-package `tech-ctte'.
+may then reassign the bug report to the pseudo-package "tech-ctte".
-For more information about the committee, see
-http://www.debian.org/devel/tech-ctte.
+For more information about the Committee, see
+<URL:http://www.debian.org/devel/tech-ctte>.
DISPUTES BETWEEN DEVELOPERS
A *DRAFT* joint recommendation of the the Technical Committee, the
Project Leader (DPL) and the Bug Tracking System (BTS) Administrators.
1. Motivation
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 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.
2. Distinguish flamage 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.
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
and useful way. The best designs result when all the issues have been
considered.
Useful technical discussions can become derailed by flamage. To help
avoid this, please phrase your technical disagreements moderately.
If you receive a heated complaint about some technical matter, please
try to respond to the technical, not emotional, content!
3. Interpersonal behaviour
If you are having problems getting along with another developer,
firstly consider whether there's anything you can do to try to improve
the situation. Send only moderate, reasonable messages; offer to talk
in some other way, perhaps even by phone (it's much easier to give
offence accidentally by email or on IRC than on the phone).
Check that there is some purpose to continuing the dispute besides
trying to extract an apology. If you just want an apology, and aren't
getting it, then you will probably just have to put it down to
experience and move on. Some people - particularly expert
programmers! - are just a bit difficult, and it's usually best just to
put up with them.
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
shouting match.
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 (meaning the DPL or a
delegate of the DPL with jurisdiction over the issue). If you do
this, be prepared to be told to go away and grow up!
[??? The person who *doesn't* refuse constructive discussion may be
told to go away and grow up? Doesn't this reward those who refuse to
discuss things constructively, by letting them have their way by
default? ]
4. Procedural mistakes and disagreements
The Project has many rules and conventions, written and unwritten,
about when certain actions are appropriate and are inappropriate, and
which fall outside the purview of the Technical Committee. For
example, making a non-maintainer-upload of another Developer's
package, closing or reopening a bug report, and forwarding mail from
one place to another, are each sometimes appropriate but sometimes not.
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.
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, take it upon yourself to write 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
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 Developers' expulsion.
5. Technical disagreements
Most disagreements in the Project are technical; this is good.
The vast majority are useful, and can be resolved by constructive
discussion where all aspects of the problem are considered. All
Developers should participate constructively in technical discussions
where necessary. When you're short of time you should reduce the
quantity, not the quality, of your contributions.
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!
In the case of a tradeoff between one good property and another, there
are often value judgements to be made; these value judgements are
usually best made by package maintainers, and other developers should
allow the maintainer of a package some leeway.
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
be very helpful, too.
6. Bug report etiquette
Sometimes bugs are reported inappropriately; likewise, sometimes
maintainers close or change the severities of bug reports
inappropriately. Bug reports are "to do list" items for the whole
Project; they should be closed when there is rough consensus that the
whole system is working as well as it could.
For example, here are some examples of situations where a bug report
should not be closed:
* A bug was reported against package A, then reassigned to package
B, but the maintainer of B feels that B is working correctly (and by
implication that the bug is in A). The maintainers should talk about
it to decide which package needs to change, without closing the bug
until it's fixed.
* A 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 parties are
happy. In the meantime, the maintainer can use the "wontfix" tag in
the BTS to indicate to interested parties that a resolution is not
being actively worked on. (In some circumstances, the "help" or
"moreinfo" tags may be more appropriate, depending on the nature of
the disagreement and specifics of the situation.)
* A bug was reported; both the maintainer and the submitter agree that
it's a defect, but disagree in their interpretations of the
definitions of bug severities. The bug should be left at the severity
determined by the package maintainer, but the report should not be
closed. The parties should discuss their disagreement within the bug
report until some mutual agreement can be reached. Note that the
Release Manager may regard a bug as "release-critical" (or not)
irrespective of its severity in the BTS.
While a situation is being discussed, any relevant bug report(s)
should remain open. If a package maintainer closes your bug report,
you may reopen it if you wish to continue the discussion.
Under no other circumstances should you get into a back-and-forth with
a package maintainer, changing the state of a bug in the BTS. If
the maintainer of the package against which a bug is filed makes a
change to that bug report which you disagree, you should *discuss* the
matter with them but *not* immediately undo their action in the BTS,
except to reopen the bug to stop it getting lost. If you are unable
to reach a conclusion through constructive discussion, you should ask
for outside help with resolving your dispute, as outlined above.
Note that while the Technical Committee is also happy to help resolve
disputes over individual bug reports, you should not refer a matter to
the Committee until you have tried to explore the issue yourselves.
When this has been done, the bug report logs should contain detailed
description of the problem and records of your discussions, and you
may then reassign the bug report to the pseudo-package "tech-ctte".
For more information about the Committee, see
<URL:http://www.debian.org/devel/tech-ctte>.
pgpMG6s7bZnbQ.pgp
Description: PGP signature
