The attached note in form of RFC contains some thoughts on how to make a devrel bug reporting inappropriate behavior more effective. The original has been reviewed by the people most immediately involved in processing such bugs (devrel, qa, ombudsman), and the attached version incorporates improvements suggested by ferringb, kingtaco, and plasmaroo. I am now distributing it to the gentoo-dev community for comments and for consideration when submitting new bug reports against personnel.
The reason for the RFC is that recently there have been several new developer bug reports submitted, and some of them are hard to interpret and process correctly because of incomplete context. The theme of the RFC is that a report of a misbehaving developer is similar to a report of a misbehaving package, and should contain analogous information. The RFC itself is much less pretentious than this introduction. The RFC is also available on-line at http://dev.gentoo.org/~fmccor/devrel/DevrelBug.rfc.txt --- if you wish to compare, the original version is present in the ~fmccor/devrel directory too. Regards, -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel)
THOUGHTS ON EFFECTIVE DEVREL PERSONNEL BUGS
======== == ========= ====== ========= ====
I. BACKGROUND
A bug reporting some developer's inappropriate behavior is similar to a
bug reporting some package's inappropriate behavior. And for devrel to
process such a personnel bug effectively and correctly, we need as much
context information as posible, just as the package maintainer needs as much
information as possible to process a failure report.
("fmccor is a disrespectful and incompetent developer" is as hard to do much
with as is "gcc is broken because it won't compile any of my programs".)
However, now that I have had time to gain some experience reviewing
devrel personnel bugs, I can say that this background information is sometimes
missing. Because of this, we (devrel) can miss the point of the report,
misclassify it, underreact (leading to "devrel never does anything"), or
overreact (leading to "devrel is just looking for reasons to hammer me").
This is frustrating, it slows the process, and it works to no one's benefit.
Consequently, here are some thoughts about information to include in a
bug reporting a misbehaving developer.
II. CONTENT
Generally, conform to the analogy to a product bug, or consider the form
of a legal brief for that matter. In some rational order (not fixed, but
perhaps depending on the bug), some or all of the following information can be
useful.
A. Brief (one or two sentence) summary of what the bug is about. If
possible, use the Bugzilla Summary field for this.
B. "Jurisdiction" --- why this is something for devrel to consider (policy
violation or whatever). This is a categorization of the report, not an
argument why it is valid. (This could be handled by a predefined set of
reasons by an existing Bugzilla field similar to "Component," but currently
it is not.)
C. What happened --- what specifically you are reporting. This is a
recounting of the incident(s) triggering the report. It should include
context and background information, as explicit as possible description of the
problem, and generally what you believe to be relevant. If you are reporting
a specific instance of a pattern of inappropriate behavior, this would be a
good place to mention it.
D. Why devrel cares. Not every infraction is worth pursuing. If you have
specific reasons for why this particular instance should be processed, make
the case for it here. This is another good place to talk about things like
patterns, why this bug reports an especially egregious violation, and such
like.
E. What you have done to solve the problem. For example, have you spoken
directly to the developer whose behavior you are reporting, have you spoken
with the appropriate top level project leads, have you spoken with an
ombudsman, and so on. It is important that we know what you have already done
in order for us to proceed most effectively.
F. What devrel should do. If you are reporting a bug against a developer,
you want something to happen. Give us a clue what you have in mind.
Examples: (1) Nothing --- just establish a tracker for this developer because
you think this is part of an emerging pattern; (2) Issue a warning; (3) Issue
a "cease and desist" note (like an injuction) violation of which will result
in more serious consequences; (4) Suspend the developer (or perhaps some of
the developer's access privileges); (5) Terminate the developer.
If you provide guidance here, please be aware of devrel policy, as explained
at http://www.gentoo.org/proj/en/devrel/policy.xml --- unless there is history
or evidence supporting other action, your bug will almost certainly be refered
to an ombudsman for mediation and resolution. If this is unsuccessful, you or
the ombudsman will have to comment on the bug requesting further processing.
III. MISCELLANEOUS COMMENTS
A. Often supporting documentation such as IRC logs is useful if not
essential. If possible, please include it as an appendix (ideally, an
attachment. If I knew how to attach something to a new Bug report, I would
say that making such information an attachment was mandatory. But in any
case, for me at least bug processing is much easier with this sort of
supporting documentation attached to the bug rather than in-line.)
If you provide supporting documentation such as logs, please make sure to
include enough context for someone unfamiliar with the incident to figure
out what the dispute is about. (And of course do not edit out any parts you
do not like.)
B. Keep the audience in mind. Although the bug is reported to devrel, it
is
almost certainly going first to a top level project manager or an ombudsman
for mediation. So expect a conversation with an ombudsman to be in your
future. (See point (F) in the previous section.)
C. Remember that once you open a bug, you and your own behavior are part of
it. Your bug will be viewed more favorably if your description of the problem
is complete. (Translation: If you are reporting out something like an
inappropriate escalation of an ongoing disagreement, let us know that at the
beginning.)
D. I understand that not everything I mentioned in (II) applies to every
bug,
QA bugs are perhaps different from reports of disrespect, and so on. Common
sense and specific circumstances determine content for any particular bug, and
the points I noted are examples of the sorts of things I would like to see in
a devrel bug generally.
E. Of course this does not apply to new developer bugs, documentation bugs,
and so on.
F. Doubtless lots of things I haven't thought of while writing this.
signature.asc
Description: This is a digitally signed message part
