Disputes between developers - content, draft #5
This is my current working draft. As ever, do please send this list,
or me privately, any substantive comments you have on it.
Changes in this version
- Put the Project Leader back as a person who might approve of
it, since I found Bdale's email after all. (duh)
- (Hopefully) improvements to Procedural stuff section (4),
some text courtesy of Manoj, but heavily reworked by me.
- Change `both Developers' to `both parties' in the
bug reports section.
____ ____ _ _____ _____
__/\____/\__ | _ \| _ \ / \ | ___|_ _| __/\____/\__
\ /\ / | | | | |_) | / _ \ | |_ | | \ /\ /
/_ _\/_ _\ | |_| | _ < / ___ \| _| | | /_ _\/_ _\
\/ \/ |____/|_| \_\/_/ \_\_| |_| \/ \/
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.
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 flameage from technical disputes and procedural errors
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
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
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.
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 -
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,
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.
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
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
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
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 parties 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: