Re: Disputes between developers - draft guidelines
Manoj Srivastava writes ("Re: Disputes between developers - draft guidelines"):
> Man, talk about being talked down to.
You're absolutely right, it's a very patronising document. But I
think that's unavoidable given the content, and I think we do need the
content because we have, unfortunately, a very bad track record at
being civil and productive in our disagreements.
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > DISPUTES BETWEEN DEVELOPERS
>
> > A *DRAFT* joint recommendation of the the Technical Committee, the
> > Project Leader and the Bug Tracking System Administrators.
>
> Since this is not a technical issue, I do not think the
> technical committee is the appropriate body to b doing this (though I
> realize we can pontificate on anything we choose to.
I think that it's important that the tech ctte put its name to the
document; quite a bit of it is about how and when to refer things to
the committee, and the rest of it while not in the committee's
official remit does get very intimately entwined with the disputes we
end up with.
> > 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 !
>
> If and only if the dispute is about technical issues. If it is
> not, the technical committee has no jurisdiction.
I do say `... or the Project Leadership'. Do you think that's
unclear ? I don't think the committee is likely to get inundated
with name-calling shouting matches, but if it is we can just refer
them to the DPL.
> > 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.
>
> Can we, really?
This is in the section on technical disagreements, so I think yes, we
can. Not quickly, it seems, but we do get round to it eventually.
If nothing else it gives somewhere else for the work item to sit and
lets everyone get on with the rest of their lives.
> > 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.
>
> No. The BTS is a means of tracking problems with the package,
> it is not a glorified PIM. There are better ways of keeping a TODO
> list.
But what are problems with the package, except TODO list items ? I'm
not sure I understand the distinction. And a Personal Information
Manager is just that - Personal - so not really any good for a joint
enterprise.
> You are also discounting the fact that a package maintainer is
> often the person closest to th software, next to th authors, and may
> have a better idea about the real status of the problem report.
All I'm saying is that the package maintainer ought to discuss things
with people, or document them if they come up lots. They shouldn't
dismiss bugs out of hand. If agreement can't be reached, that's what
the tech ctte are for.
> Having spurious and incorrect reports cluttering up the BTS
> helps no on; and makes it harder for volunteers to target effort.
Certainly I agree with that.
Can you suggest an alternative wording for this part that you'd be
more happy with ?
> > * 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.
>
> Both developres? What if the reporter is not a developer? Is
> it OK to close the bug then?
I do think we have to place developers in a privileged position. This
isn't really because they're necessarily better than nondevelopers,
but because we have (or should have!) in the project other ways of
dealing with developers who persistently submit junk bugs and engage
in other kinds of unhelpful activity.
Writing a requirement that developers have to treat every junk bug
from a nondeveloper seriously may end up wasting a lot of people's
time.
That's not to say that I think that developers ought to make a habit
of dismissing nondevelopers' bug reports. I think that would be bad.
I just don't want to make a rule forbidding it.
Of course in most cases people won't bother looking to see whether
someone is a developer - with anything but the most obvious abuse
it'll be much easier just to take things at face value. So
nondevelopers will probably get the benefit of any courtesy
recommendation anyway.
> In any case, generalization like this are often unsuited to
> specific cases; and the determination needs to b made on a case by
> case basis if the maintainer is justified in managing the TODO list
> for his package, neh?
Isn't that what the severities are for ? That's what I thought they
were for.
> > 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.
>
> Ropening spurious bug reports is unlikely to be helpful. The
> maintainer often does know better; and it is suboptimal to ignore
> that fact.
How do you propose that we make sure that we end up not forgetting
about bug reports that need some discussion to resolve ?
> > Note that while the Technical Committee is also happy to help resolve
> > disputes over individual bug reports,
>
> Really? I recall we punted on th last such dispute.
The last times we were asked to decide how a particular bug should be
fixed (or whether it was a bug at all) was #119517, in July.
The Gnome question wasn't an existing bug (and we seem not to have
been able to find out what the dispute really is!), and people don't
disagree about how the original problem in #97671 should be fixed
(indeed, it has been fixed long ago and the only remaining question is
to make a rule about when bugs should have which severities).
Ian.
Reply to: