On Wed, 2006-01-11 at 14:08 -0700, Duncan wrote:
> Ferris McCormick posted
> <[EMAIL PROTECTED]>, excerpted below,  on
> Wed, 11 Jan 2006 19:04:19 +0000:
> 
> > 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.)
> 
> An enumeration or list of examples would be rather helpful, here.  Since
> you say it could be a predefined list, enumerating it in the RFC, or at
> least giving a couple examples, shouldn't be unreasonable.  Keep in mind
> that it's possible/likely the filer will have never filed something like
> this before, so the vague guideline as stated simply isn't all that much
> help.   You want it concrete, make it so.
> 

This is a reasonable request, but I don't have such a list right now.
Here are some annotated examples of the sorts of things devrel is
interested in, so you can use these as guides:

1.  Abusive behavior, IRC.  (Recurring abusive behavior)
2.  Abusive behavior, email.
3.  Abusive/inappropriate responses on normal bug reports.
4.  Abusive behavior, forums. (The forum moderators almost always handle
this sort of problem pretty quickly.)
5.  Other etiquette violation, IRC.  (Recurring violation of a #gentoo
IRC channel's etiquette policy, not covered by abusive behavior.  If you
wish to report such a violation, please keep language and cultural
differences in mind.)
6.  IRC policy violation (abuse of operator status in violation of
policy on particular channel).
7.  Disruptive behavior, IRC (Well, maybe.  An example might be a
running feud between two developers where the participants don't mind,
but the cumulative effect is to make the channel unusable for others.)
8.  QA dispute between developers.  (One developer (or user) believes
another has violated policy, and they cannot resolve their differences
by normal means (discussion, appeal to project lead, etc.))
9.  QA violation, reported by QA.  (QA believes developer has seriously
violated policy but cannot resolve the issue with the developer
directly.)

This list is not necessarily complete, nor is everything on the list
necessarily appropriate for reporting to devrel.  But it should give
some idea of the sorts of things that are helpful for briefly explaining
why devrel has jurisdiction and to give a clue how the reporter wants
the bug to be processed.
  
> Otherwise... unpleasant subject matter, but I'm glad someone's dealing
> with it.  The rest seems reasonable enough.
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
> 
> 
-- 
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Sparc, Devrel)

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to