Unfortunately, the audience for this note most likely comprises people who will not see it, but perhaps it will be useful anyway. However, it's been a while since I've sent a long, rambling note, so here we go....
Once or twice a week, devrel ((Gentoo) Developer Relations) is assigned a new bug of the form "I updated sci-calculators/units and it now claims that 1 light year = 4 mm." While this would be a bug, it is not one devrel can do anything about: As the name suggests, devrel is concerned with people, not with packages, and devrel does not address problems like a misbehaving "units" package. When we get such a report, we have to notice we have an inappropriate bug, then reassign it. This serves only to annoy us and to delay a resolution for the reporter. Please do not assign software bugs to devrel. That said, now that I have your attention, I'll continue a bit with some suggestions describing what a good devrel bug might be. Devrel bugs are concerned generally with recruiting developers, retiring developers, and conflicts between developers. I am focusing on the last of these. A few months ago I floated an RFC (attached, and at http://dev.gentoo.org/~fmccor/devrel/DevrelBug.rfc.txt ) outlining some thoughts on what information is useful for helping devrel sort out a bug in which one developer is complaining about some other developer's behavior and is requesting some sort of devrel intervention. The RFC was not met with hostility, so I am sending it on to this mailing list for feedback and suggestions. Please note that the RFC refers to devrel policy, and that the policy is undergoing revision. However, this does not affect the RFC; it affects only what the RFC is referring to. Although it is not emphasised in the RFC, I should add that when you have such a complaint, it really helps everybody (including you) if you try to resolve it by other means before filing a bug. In case you do not remember, we have an ombudsman group ([EMAIL PROTECTED]) within devrel whose charter is just that: help to mediate a solution before escalating the problem to a level where you probably don't want it. I note in passing that actually most devrel members will help resolve such problems if you ask them (in case you have a favorite devrel member whose style you are comfortable with), but if you do that, be prepared for a referral to the ombudsman or working with that particular devrel member's own eccentricities (e.g., if you ask me, be prepared for very long ("may I have 5 minutes please?") discussions on IRC; others prefer to work with email, etc.). If you are still with me, thanks for your attention. Regards, Ferris -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc)
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
