Disputes between developers - draft guidelines
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.
Ian.
DISPUTES BETWEEN DEVELOPERS
A *DRAFT* joint recommendation of the the Technical Committee, the
Project Leader and the Bug Tracking System 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.
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 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.
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 flameage. 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
slanging 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. If you do this, be
prepared to be told to go away and grow up !
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.
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 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
behavour, 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 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.
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.
* 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
happy.
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.
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
http://www.debian.org/devel/tech-ctte.
--
Ian Jackson, at home. Local/personal: ijackson@chiark.greenend.org.uk
ian@davenant.greenend.org.uk http://www.chiark.greenend.org.uk/~ijackson/
Reply to: