Mailing List Archive

On Wed, 2006-01-11 at 14:08 -0700, Duncan wrote:
> Ferris McCormick posted
> <1137006259.24481.28.camel@polylepis.inforead.com>, 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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Devrel)

Ferris McCormick posted
<1137006259.24481.28.camel@polylepis.inforead.com>, 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.

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


--
gentoo-dev@gentoo.org mailing list

Ferris McCormick posted
<1137074383.24477.54.camel@polylepis.inforead.com>, excerpted below, on
Thu, 12 Jan 2006 13:59:43 +0000:

> 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.

Thanks. That list at least provides a decent set of examples. When I
read "jurisdiction", I thought the usual US/legal sense, as in courts
ruling whether they have jurisdiction over a case or not, and my mind was
boggling... I couldn't quite figure out how to boil such a concept down
into the itemized list you were describing. The examples definitely help
me get my mind around the concept you intended!

I'd suggest putting at least one or two examples in whatever bug template
or HOWTO might result from this, if the thing isn't made an itemized list
as you suggested, anyway.

I know I had a /terrible/ time figuring out Gentoo's bug system for
regular bugs, and can easily envision myself having the same issues trying
to fit square pegs into crescent-moon-shaped <g> holes here, so some
sort of guide is SURE to prove beneficial.

--
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


--
gentoo-dev@gentoo.org mailing list