Re: Document on dispute resolution
Hi,
Here is my response, with a bit of context added for people
who shan't be bothered to go look on -project.
>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> writes:
Ian> So, let me explain: as the technical committee chairman, I've been
Ian> seeing a lot of the less functional side of the project lately :-),
Ian> particularly people getting into really unhelpful spats; it makes it
Ian> hard to see what the actual the issues at stake are, and hard to fix
Ian> anything.
Ian> So, I wrote up my personal view of a set of guidelines for how we
Ian> developers should try to resolve our disputes with each other. I was
Ian> hoping to get the Project Leader and the BTS admins on board, so that
Ian> we could have it as a joint recommendation, but our illustrious leader
Ian> isn't answering his mail and the BTS admins want nothing to do with
Ian> the politics.
And proceeded to label it as a joint draft resolution by the tech
ctte, the BTS, and the project leader, without asking them. I find
this funny -- to coopt a bunch of people to lend weight to the draft without
their knowledge. And, to me at least, appear to ignore constructive
criticism by dismissing it as something you disagreed with.
I state then that there is no indication that these are
anywhere close to the views of the techmnical committee, since there
has been absolutely no discussion of far less the contents, but even
the intent of creating such a document on the committee mailing list.
Ian> Well, no-one but me is doing this.
And there lies the rub. This is a social problem, and the
solution must needs be social, not something that no one but you is
doing.
Ian> Branden and Manoj can complain until they're blue in the face that
Ian> obviously I'm being arrogant and cabalish and what have you by
Ian> disagreeing with them on some points, and declining to change my
Ian> working draft (and even, in Branden's case, declining to deal with any
Ian> more of his dysfunctional flameage). Shock horror, I even admit to
Ian> being swayed by private email ! But, it's not their decision. It's
Ian> currently my draft, and I'll put what I like in it.
That is precisely the attitude that raises my
hackles. Contributors can complain until they are blue in the face,
but it is your draft, and it shall be put together as you want it.
Do I really need to say any more?
Indeed, the dispute resolution seems over the document seems to
have failed. In general, people writing a HOWTO have demonstrable
expertise in the area of the howto, or they listen to and gather
nuggets of wisdom from those who are competent.
If the authors of the conflict resaolution document can't
resolve conflicts with people who are trying to help create a better
document; if the best they can come up with is that I won't listen to
you, then I posit that such competence has not been demonstrated
(this is especially funny given the paternalistic tone of the
document).
Incidentally, my concerns have not been addressed, as
dismissed, in typical high handed fashion
Ian> But, I still think it's a good idea, and I'm planning to try to get it
Ian> approved and published by the Technical Committe at least.
Ian> So I'm going to press ahead.
Wonderful. I am in a dispute, I can't work it out, so I'll
just press on ahead and do what I want. I notice that that is not
what this document recommends -- so it is do what I say (even though
it did not work for me), not as I do.
Ian> Of course, I want to know what people think of it first ! I've had a
Ian> lot of heat (and, I have to say, not much light) from two of our more
Ian> awkward types, but what I really want to know is whether people agree
Ian> with the contents. There's no point putting out some recommendation
Ian> that everyone thinks is wrong, because there'll be little social
Ian> pressure to do as it says.
See <URL:http://people.debian.org/~branden/iwj_disputes_draft_dispute
The conflict resolution protocol falling on its face. And,
while I may be a awkward type (how the hell do you know how gauche I
am, without ever seeing me?), I do not misrepresnt my work as being
co-authored by influential people, and I do not start calling my
opponent names.
And this is how you interact with people who make
contributions to the project, and your document, by dismissing them
as ``awkward types''? You still think people shall consider you a
steward for this document after such a lapse of judgment during a
minor conflict on a mailing list? I would say that Branden has done
far more, awkward though he is, for SPI and Debian in the last
couple of years than most people (including you); and you have
little right to belittle him so.
I would also not retreat, as you did, on project:
Ian> So, in the absence of anything convincing me otherwise, after I think
Ian> everyone's had a say here, I'll go back to the tech ctte very shortly
Ian> and propose it as a resolution there - and obviously it'll have the
Ian> names of the DPL and BTS admins taken off it.
You get criticism, and a lot of disagreement, and your
response is to go off behind closed doors and impose a standard of
conduct on the project from up on high.
Ian> A *DRAFT* recommendation by the Technical Committee.
Which has not yet said it approved of this document being
presented by them.
Ian> 1. Motivation
Ian> Debian is a very large project. We will inevitably disagree, and
Ian> occasionally get annoyed with each other. To allow us to work well
Ian> together a bit of give and take is needed, and we must be willing to
Ian> present coherent reasons for our views, and to listen to and engage
Ian> with counterarguments.
Well, belabouring the obvious, I would think, we are all
supposed to be well nigh adults here. But let us see how this goes.
Ian> This document gives some general advice about friendly interaction.
Ian> It also says what you can do when this fails: if you are having
Ian> problems working well with another Developer; or if, despite talking
Ian> to them constructively, you cannot agree.
Ian> 2. Distinguish flameage from technical disputes and procedural errors
Ian> There are basically three kinds of dispute:
Ian> * Technical disagreements: these are largely about how software should
Ian> work, and form the meat of many of the Project's discussions.
Ian> * Procedural disagreements: these are about how the project should
Ian> work, rather than about software.
Ian> * Interpersonal disputes - just `not getting along'. In any large
Ian> community like Debian there will be personality clashes, and people
Ian> you find difficult to deal with.
Ian> Try to keep these separate, and to get along as best you can.
Excise the last sentence. Platitude.
Ian> For Debian to be able to construct good software, we must be able to
Ian> disagree with the way something is done or proposed in a constructive
Ian> and useful way. The best designs result when all the issues have been
Ian> considered.
Platitude.
Ian> Useful technical discussions can become derailed by flameage. To help
Ian> avoid this, please phrase your technical disagreements moderately.
Ian> If you receive a heated complaint about some technical matter, please
Ian> try to respond to the technical, not emotional, content !
Hmm. If that were feasible in a particular situation, I don't
think we would be at the point of reading this document. Singing the
Barney theme song may be good advice, but I think is is a mild insult
to ones intelligence, ands again, belabours the obvious.
We do not need a document for 5 year olds; we need a document
that is helpful when adults, who generally know a modicum of the
tenets of social behaviour, are locked in a dispute.
I suggest we get rid of the teaching pre schooler bits of
aphorism, and get on with information that developers can use.
Ian> 3. Interpersonal behaviour
Ian> If you are having problems getting along with another developer,
Ian> firstly consider whether there's anything you can do to try to improve
Ian> the situation. Send only moderate, reasonable messages; offer to talk
Ian> in some other way, perhaps even by phone (it's much easier to give
Ian> offence accidentally by email or on IRC than on the phone).
Same as bove. I would assume we all have actually interacted
with other humans, and we know that you can get flies caught with
honey. If I am reading this document, vacuous banalities are not what
I need.
Ian> Check that there is some purpose to continuing the dispute
Ian> besides trying to extract an apology. If you just want an
Ian> apology, and aren't getting it, then you will probably just have
Ian> to put it down to experience and move on. Some people -
Ian> particularly expert programmers! - are just a bit difficult, and
Ian> it's usually best just to put up with them.
If we edit this down to a single sentence, this would be fine.
Ian> If it's a technical dispute, try to talk only about the technical
Ian> questions at issue. Avoid complaining to the other Developer that
Ian> they are being unhelpful; that'll turn the conversation into a
Ian> shouting match.
Umm. The irony.
Ian> If you really can't engage helpfully - for example, because the other
Ian> Developer refuses constructive discussion - you can refer the question
Ian> to the Technical Committee (including, possibly, reassigning a bug
Ian> report to them) or the Project Leadership.
Ok. This is good -- the first constructive mechanism that my
mother did not tell me about.
Ian> 4. Procedural mistakes and disagreements
Ian> The Project has many rules and conventions, written and
Ian> unwritten, about when certain actions are appropriate and are
Ian> inappropriate. For example, sending a non-maintainer-upload of
Ian> another Developer's package, closing and reopening a bug report,
Ian> and forwarding mail from one place to another, are all sometimes
Ian> appropriate but sometimes not.
Ian> If you feel another Developer has erred, by failing to go about things
Ian> in the right way, you should of course tell them about it. But,
Ian> please try to make your message helpful and friendly. Probably they
Ian> didn't know about the rule in question, or understand it differently.
Ian> If you can, refer the other Developer to some documentation explaining
Ian> what the right process is. If such documentation does not exist,
Ian> consider writing it - it is difficult for nonexistent documentation to
Ian> be authoritative, and a misunderstanding that arises once in the
Ian> absence of a documented procedure is likely to arise again. The
Ian> Debian Developers' Reference is usually an excellent place to document
Ian> common practice.
Verbose.
The Project has many rules and conventions, written and unwritten,
about when certain actions are appropriate and are
inappropriate. Often, these rules are not absolute, and context is
important. If you feel another Developer has erred, by failing to go
about things in the right way, please start by pointing out politely
that they may have missed the rule, and accompany your message with
references to the specific procedure, or pointing to precedents that
establish an unwritten rule. If possible, accompany your request with
a rationale for the correct procedure, and why yuo feel it applies to
this case.
A conciliatory request may work better than a confrontational
one, and one should not assume that the error was deliberate, it
could well have been an oversight.
Ian> If the other Developer disagrees, you should seek guidance from the
Ian> wider Project, so that everyone has the same ideas of how things are
Ian> supposed to work. In the end, if a firm decision needs to be made,
Ian> the Project Leadership will have to decide.
In case of a disagreement over the rule or practice in general,
please seek guidance from thewider Project, and start a discussion on
the merits of the rule or practice; often, it may be that the rule or
practice needs to be amended or have exceptions added; and the result
may be a better dcumented rule with the rationale that may prevent
such a disagreement in the future.
Ian> If a Developer persistently flouts the Project's rules - written or
Ian> unwritten - then you should consult the Project Leadership for advice;
Ian> the Project Leadership will, if appropriate, warn them about their
Ian> behaviour, and in extreme cases may seek the Developer's expulsion.
I think we should excise this stick. We do not need to talk
about chastisement and punishment in a dicument about reconciliation
-- the project leadership can act on such flouting after qa genberal
discussion on its own.
Ian> 5. Technical disagreements
Ian> Most disagreements in the Project are technical; this is good.
Chatty and paternalistic.
Ian> The vast majority are useful, and can be resolved by constructive
Ian> discussion where all aspects of the problem are considered. All
Ian> Developers should participate constructively in technical discussions
Ian> where necessary. When you're short of time you should reduce the
Ian> quantity, not the quality, of your contributions.
Again, I wouldn't be reading this if that were still feasible,
and this is redundant. We are not all social misfits that need be
reminded of basic rules of interpersonal interactions.
Ian> Be flexible; try to avoid categorical statements such as `I will never
Ian> implement that'. There is no shame in being convinced, by good
Ian> arguments, to change your mind, even if you have just been vigorously
Ian> promoting the opposite view !
There are things I shall never implement, and I am not going
to muzzle myself. Usually, there are good solid reasons for my
statements. (I shall never include a remote root exploit into my
code).
If we excise these avuncular comments, we shall have a decent
skeleton of a useful document.
Ian> In the case of a tradeoff between one good property and another,
Ian> there are often value judgements to be made; these value
Ian> judgements are usually best made by package maintainers, and
Ian> other developers should allow the maintainer of a package some
Ian> leeway.
Umm, unless we happen to disgree, or the maintainer is Herbert Xu?
Ian> If discussing the issue with all the relevant people hasn't
Ian> produced a conclusion and doesn't look like it will, the
Ian> Technical Committee can decide. You can refer it to the
Ian> Committee in the form of a bug report (see below); sending a
Ian> summary of the situation to the Committee would be very helpful,
Ian> too.
Ian> 6. Bug report etiquette
Ian> Sometimes bugs are reported inappropriately; likewise, sometimes
Ian> maintainers close bug reports inappropriately. Bug reports are
Ian> `todo list' items for the whole Project; they should be closed
Ian> when there is rough consensus that the whole system is working
Ian> as well as it could.
I strongly disagree. The Bug list is a communications
mechanism that allows us to improve debian, and as such, it is far
more, and in some aspects, less than, a TODO list.
The BTS allows users of our packages to communicate with us,
and enables contributrs to work on the problems with the package. As
such, the bug severity is a simple mechanism to allow allocation of
scant resources; and it is important that there is a common
understanding of what a priority implies.
Ian> For example, here are some examples of situations where a bug report
Ian> should not be closed:
Ian> * The bug was reported against A, reassigned to B, but the maintainer
Ian> of B feels that B is working correctly (and by implication that the
Ian> bug is in A). The maintainers should talk about it to decide which
Ian> package needs to change, without closing the bug until it's fixed.
In this case, obviously the BTS is recording a problem, and
not merely a todo list of either package. You may argue that all
problems should be fixed, and thus are todo items, but that
abstraction loses a llot of the characteristics of the phenomena that
a bts represents.
Ian> * The bug was reported; the maintainer felt immediately that it was a
Ian> spurious bug report of some kind, and closed it, but the submitter
Ian> disagrees with the explanation and has reopened the report for
Ian> discussion. The matter should be debated until both Developers are
Ian> happy.
Ian> While a situation is being discussed, any relevant bug report(s)
Ian> should remain open. If a package maintainer closes your bug report,
Ian> you may reopen it if you wish to continue the discussion.
Ian> At no other time should you play `bug report tag' with anyone
Ian> else. If someone makes a change to a bug report status which
Ian> you disagree with you should *discuss* the matter with them but
Ian> *not* immediately undo their action in the BTS, except to reopen
Ian> the bug to stop it getting lost. If you are unable to reach a
Ian> conclusion through constructive discussion, you should ask for
Ian> outside help with resolving your dispute, as outlined above.
Ian> Note that while the Technical Committee is also happy to help resolve
Ian> disputes over individual bug reports, you should not refer a matter to
Ian> the Committee until you have tried to explore the issue yourselves.
Ian> When this has been done, the bug report logs should contain detailed
Ian> description of the problem and records of your discussions, and you
Ian> may then reassign the bug report to the pseudo-package `tech-ctte'.
This last bit sounds fair enough.
manoj
--
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: