Re: Disputes between developers - content, draft #4
Manoj Srivastava writes ("Re: Disputes between developers - content, draft #4"):
> Well, here is a detailed critique. Unfortunately, there is a
> lot of ground to cover between our positions; here is a start.
Thanks.
Much of what you say can be summed up, I think, by the sentiments from
these comments:
> Well, belabouring the obvious, I would think, we are all
> supposed to be well nigh adults here. But let us see how this goes.
...
> 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.
I think you must have a different experience to me. I've found that
many developers don't seem to share enough of the context and unspoken
rules. I think writing them down will help. I also think it might
produce some useful pressure on those people who ought to know better
but lapse occasionally. (And I'm not excluding myself here.)
If you still disagree with me on this, I don't really see that I'm
going to make much headway with addressing that point, because it's a
fundamental part of the purpose and style of what I'm trying to
achieve - ie, I don't think I'd do justice to your opinions even if I
put aside my disagreement.
It's also really difficult to have a sensible conversation about these
questions, because they are so subjective.
I would say: does it really hurt so much to have a few platitudes, and
some motherhood and apple pie ? It seems that you're not actually
disagreeing with what's said, but just saying that it shouldn't be
said at all even though it's true - which seems strange to me.
> > The Project has many rules and conventions, [etc]
>
> Verbose.
Yes, I'm afraid it is.
But, you also make a number of very helpful comments, which I shan't
quote in detail because I think you're largely right. I've made some
changes to my working draft, including taking some of your text. The
resulting section 4 is at the bottom of my mail. What do you think of
it ?
> > 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 !
>
> 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).
My experience is that sensible conversations about eg bug reports can
easily become derailed by categorical statements like that by the
maintainer. The results are often that the submitter just gets angry,
and things go downhill from there.
So, I strongly disagree - I think these comments are important, and
the fact that you disagree with them shows that at least they're not
content-free ...
> > 6. Bug report etiquette
I've run out of time for this in-detail writing now, but I'll deal
with this section of your mail later.
Ian.
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.
Reply to: