Relations between community and outsiders

[Zack Weinberg]

[I posted this as a follow-up to Mitchell's second proposed CoC, and was
asked in private mail to pull it out to its own thread. If you've
already seen it, no need to reread.]

I would like to see some language [in the CoC] addressing interactions
between people who are more central to the community and people who are
more peripheral; especially, people who consider themselves part of the
community and people who don't. It has been my experience that many
people are scared to get involved because they expect to be treated
badly by established contributors (see earlier message re bug reporting
specifically). It has also been my experience that a small number of
senior contributors regularly abuse other contributors and get away with it.

As an important special case: I don't know that this is *precisely* the
context to address this problem, but there's a self-reinforcing negative
interaction pattern I see pretty often in Bugzilla, particularly in what
I called "infamous bugs" earlier:

- User trips over infamous bug.
- User looks for bug in Bugzilla, finds it was reported many years ago
and has lots of people shouting at each other in the comment thread.

branch 1: User doesn't post anything, but writes us off as uninterested
in bug reports.

branch 2: User posts cranky comment in bug report, gets flamed and/or
lectured on bugzilla etiquette, writes us off as uninterested in bug
reports; probability of future users taking branch 1 goes up by epsilon.

We can't do much about the existence of the infamous bugs (I know all
too well how hard it is to fix some of them), but we *can* change the
bugzilla comment policy so that users who take branch 2 do *not* get
flamed or even lectured.

I don't think it's possible to overstate how easy it is for users to
write us off as *completely* *uninterested* in hearing about their
problems. As such, just about *any* policy change that makes us seem
less uninterested is worth doing IMHO.

zw

[Zack Weinberg]

On 2012-04-06 7:01 PM, Zack Weinberg wrote:
> It has been my experience that many
> people are scared to get involved because they expect to be treated
> badly by established contributors (see earlier message re bug reporting
> specifically).

Since that earlier message was also deep within a long thread:
http://groups.google.com/group/mozilla.governance/msg/9607e954b3a6d735

[Robert O'Callahan]

On Sat, Apr 7, 2012 at 2:01 PM, Zack Weinberg <za...@panix.com> wrote:

> I would like to see some language [in the CoC] addressing interactions
> between people who are more central to the community and people who are
> more peripheral; especially, people who consider themselves part of the

> community and people who don't. It has been my experience that many people

> are scared to get involved because they expect to be treated badly by
> established contributors (see earlier message re bug reporting

> specifically). It has also been my experience that a small number of
> senior contributors regularly abuse other contributors and get away with it.
>

Something needs to be done about this.

Do these people know who they are? (One of my greatest fears is that I will
be abusive and not even realize it.)

- User trips over infamous bug.
> - User looks for bug in Bugzilla, finds it was reported many years ago and
> has lots of people shouting at each other in the comment thread.
>
> branch 1: User doesn't post anything, but writes us off as uninterested in
> bug reports.
>
> branch 2: User posts cranky comment in bug report, gets flamed and/or
> lectured on bugzilla etiquette, writes us off as uninterested in bug
> reports; probability of future users taking branch 1 goes up by epsilon.
>
> We can't do much about the existence of the infamous bugs (I know all too
> well how hard it is to fix some of them), but we *can* change the bugzilla
> comment policy so that users who take branch 2 do *not* get flamed or even
> lectured.
>

>
I don't think it's possible to overstate how easy it is for users to write
> us off as *completely* *uninterested* in hearing about their problems. As
> such, just about *any* policy change that makes us seem less uninterested
> is worth doing IMHO.
>

This is a tough one. A lot of these "cranky comments" are abusive. Letting
them proliferate with impunity itself creates a hostile environment. I can
shrug off invective claiming I'm an evil conspirator for not supporting MNG
or SVG Fonts whatever; I don't want to ask that of all our contributors. So
I don't know what to do.

What do you think we should do?

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

[Majken Connor]

Some people have the patience, others don't. On occasion philor asks me to
deal with "the users" for him because he doesn't have the patience to be
polite (this fortunately happens less now that we have SUMO). Also, I was
guilty of being a bit(lot?) nasty myself once when I was helping to QA a
bug. When you're heads down and frustrated with a problem it can really
distort your perception.

There are some simple principles to dealing with angry customers. I
actually find they're the same as Cesar Milan's tricks for dealing with
"bad" dogs. Basically be "calm assertive." You are the person in control,
that is why the other person is angry or acting out, they don't have
control. You don't have to fix their bug or even acknowledge their reply if
you don't want to. You have no idea what kind of bad day they've been
having. You have no idea what kind of customer service they usually get
(our major cable supplier used to be (is?) notorious for only employing
"supervisors." If someone is not being helpful you can't escalate because
it turns out you're already speaking to the supervisor.

My rule is you show them the treatment they'll get if they calm down. Greet
them in a friendly manner, show empathy for the situation as they perceive
it (it doesn't matter if their bookmarks aren't really gone, if it *seems*
like they're all gone this is a very bad thing). The vast majority of
people calm right down and cooperate. Not all though, some people are just
there to swear at you, and swearing back won't make them stop. But
remember, you have the power. You can get their account suspended. The
thing is it's not personal. They don't know who you are and they don't
care. It's about them and how they feel. So taking it personally just hurts
yourself it changes nothing to them.

On a practical note, someone like myself is great at this kind of thing,
and I don't code, so it works out! Some people are literally wired so that
they're not capable of behaving according to someone else's perception
whent hey know it's not true. Hopefully programs like the Mozilla Reps and
Stewards can help be a buffer and an interpreter for the people who are
good with people, the people who are good with code and the people who fall
somewhere in between.

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

[L. David Baron]

On Friday 2012-04-06 19:01 -0700, Zack Weinberg wrote:
> I don't think it's possible to overstate how easy it is for users to
> write us off as *completely* *uninterested* in hearing about their
> problems. As such, just about *any* policy change that makes us
> seem less uninterested is worth doing IMHO.

So one dilemma I sometimes face is this: I'm reading bugmail and I
see an incoming bug report that I know something about -- e.g.:

* where in the code the underlying problem is

* solution A is both easier and better than solution B so please
stop discussing B as a quicker solution if you don't actually
know how hard it is (e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=693164#c5 )

* how important I think the fix ought to be

* that a discussion somebody proposes we have is unnecessary (e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=480888#c16 , in
response to #c14)

etc. I have the time to write a few sentences in the bug explaining
that -- that multiplies my time reading bugmail by, say, a factor of
two to five. But I don't, that day, have time to defend my short
comment to the inevitable responses, which are sometimes quite
demanding. (And sometimes, even if I don't have the time, Boris
does spend the time, e.g., in
https://bugzilla.mozilla.org/show_bug.cgi?id=713613 .)


So sometimes (frequently?) I decide not to write anything at all
because I don't want to trigger the responses that I won't have time
to deal with (and that I'd rather Boris not spend the time to deal
with even though I know he likely will), even though I do have
something useful to add. I realize this is the wrong response, but
I don't always overcome it.

I'm thinking perhaps I need a set of canned templates to paste into
bug reports for various common situations -- perhaps things with
links to more information so they're easy for people who have seen
them before to skip over -- so that I can add information to bug
reports but also say what kind of responses to that information are
useful vs. what kind of responses are harmful.

(After all, what many people don't realize is that there are *many*
points in a bug's lifetime where *all* the comments on a bug need to
be read (given the way bugzilla currently works, which I'd love to
see improved); therefore by default adding a comment makes the bug
harder to fix, and it's only worth adding if it balances out that
cost.)


So, to sum up, I think part of what I'm saying I need is a way to be
responsive to bug reports that are filed without the act of being
responsive leading to a huge cycle of additional things I need to
respond to.

(Also, maybe bug reports need three separate comment areas: what
the bug is, how important the bug is, and how to fix the bug.
Better state tracking (e.g., to track whether we know those things
and a few others) would also be great.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Robert O'Callahan]

That's helpful and I agree with all of it. But I don't think it resolves
the core dilemma: when someone posts a cranky, abusive, or just plain
redundant Bugzilla comment, how do we make that person understand that even
though we don't value *this* comment, we still want their input in more
productive contexts?

I could paste boilerplate text to that effect, but that's going to look
lame.

[Robert O'Callahan]

http://krijnhoetmer.nl/irc-logs/whatwg/20120325#l-251 :-)

[Teoli]

On 07/04/12 00:42, L. David Baron wrote:

> etc. I have the time to write a few sentences in the bug explaining
> that -- that multiplies my time reading bugmail by, say, a factor of
> two to five. But I don't, that day, have time to defend my short
> comment to the inevitable responses, which are sometimes quite
> demanding. (And sometimes, even if I don't have the time, Boris
> does spend the time, e.g., in
> https://bugzilla.mozilla.org/show_bug.cgi?id=713613 .)
>

When you, or Boris, or somebody else, take the time to write a complete
answer in Bugzilla explaining why a "newbie" or "naive" position is
wrong, or why something has been done that way and not another, it would
help if you add the dev-doc-needed flag (even on a RESOLVED/INVALID
bug!) (and cc :teoli ;-) )

That way, we can check if our documentation is complete or not, and if
needed improve it, and we may be able to reach such users earlier in the
future.

Also, I think it is also more welcoming for the unfortunate user: even
if he was wrong, his 'wrongness' lead to a better doc. He may feel
useful for the project as a whole.

:-)

-- Jean-Yves

[Blake Winton]

On 07-04-12 2:33 , Robert O'Callahan wrote:
> On Sat, Apr 7, 2012 at 2:01 PM, Zack Weinberg <za...@panix.com> wrote:
>> It has also been my experience that a small number of
>> senior contributors regularly abuse other contributors and get away with it.
> Something needs to be done about this.
>
> Do these people know who they are? (One of my greatest fears is that I will
> be abusive and not even realize it.)

I doubt they do, if only because of the Dunning-Kruger Effect. ;)

But, for what it's worth, I haven't seen you be abusive, and if you'ld
like me to let you know if I see you being abusive, I'll be happy to
provide that service. :)

> This is a tough one. A lot of these "cranky comments" are abusive. Letting
> them proliferate with impunity itself creates a hostile environment. I can
> shrug off invective claiming I'm an evil conspirator for not supporting MNG
> or SVG Fonts whatever; I don't want to ask that of all our contributors. So
> I don't know what to do.
>
> What do you think we should do?

The TB-Planning list and comments on the TB-UX blog are moderated for
that very reason, and it's worked out well. (I mean, sometimes I get a
little tired of moderating comments and replying to people as to why
they can't see their post or comment, but the list and blog do seem
nicer as a result.)

I don't think Bugzilla should move to a more moderated status, but
perhaps something like my Nicer Bugzilla Comments add-on
<https://addons.mozilla.org/en-US/firefox/addon/nicer-bugzilla-comments/> could
be part of the solution…

Later,
Blake.

[Mitchell Baker]

I wonder if the Contributor Stewards program might be helpful here, in
one or more of the following ways:

-- figuring out net techniques
-- spreading knowledge about techniques that have worked in one area of
the project to other areas
-- helping provide infrastructure or support for techniques that work
(like moderation, or templates for response, or who knows)


My guess is that the Contributor Stewards program folks are eager not
just to help people get involved, but also to make that experience
productive and possitive for existing contributors.

mitchell

[Gervase Markham]

On 08/04/12 16:34, Blake Winton wrote:
> I don't think Bugzilla should move to a more moderated status, but
> perhaps something like my Nicer Bugzilla Comments add-on
> <https://addons.mozilla.org/en-US/firefox/addon/nicer-bugzilla-comments/> could
> be part of the solution…

For a little while now, Bugzilla has had the Profanivore extension
installed, which "eats" swear words from users (without editbugs) and
replaces them with "****" when the bug is displayed to anyone except the
person who posted them.

Gerv

[davidwboswell]

> I wonder if the Contributor Stewards program might be helpful here, in
> one or more of the following ways:
>
> -- figuring out net techniques
> -- spreading knowledge about techniques that have worked in one area of
> the project to other areas
> -- helping provide infrastructure or support for techniques that work
> (like moderation, or templates for response, or who knows)

Yes, this is definitely an area where the Stewards program can help.
Here's one example that seems relevant for this discussion.

I've been working with the Coding Stewards and we recently identified
a need to improve the experience for new contributors using Bugzilla.
We've put in place a system that sends email to people who have had
their first patch approved by a reviewer in order to encourage people
and to give them more visibility about how to move forward. More at:

https://bugzilla.mozilla.org/show_bug.cgi?id=721206

There could be a number of other key milestones in a new contributor's
experience where we'd want to do something similar -- either by
manually or automatically following up with that person. For
instance, if someone new to Bugzilla has their bug marked invalid, we
could have an automatic message sent out providing more context around
why this happens and what someone may do to go forward at this point.

In general, if you are looking for ways to build community around your
projects or feel that there are things that you could be doing to
improve the experience for new (or existing) contributors but aren't
for some reason, it would be useful to raise that and we can see how
to potentially solve things.

A good forum for these sorts of discussions is the regular Grow
Mozilla meetings that are intended to be a forum for sharing ideas and
asking questions about community building at Mozilla.

https://wiki.mozilla.org/Grow#Meetings

David

[Zack Weinberg]

On 2012-04-06 11:33 PM, Robert O'Callahan wrote:
> On Sat, Apr 7, 2012 at 2:01 PM, Zack Weinberg<za...@panix.com>
> wrote:
>
>> I would like to see some language [in the CoC] addressing
>> interactions between people who are more central to the community
>> and people who are more peripheral; especially, people who consider
>> themselves part of the community and people who don't. It has been
>> my experience that many people are scared to get involved because
>> they expect to be treated badly by established contributors (see
>> earlier message re bug reporting specifically). It has also been
>> my experience that a small number of senior contributors regularly
>> abuse other contributors and get away with it.
>
> Something needs to be done about this.

I assume your 'this' is the 'small number of senior contributors...'
sentence, and on reflection, I overstated the problem there.

What I should have said is, there are a small number of senior
contributors whose somewhat combative tone (in reviews, in discussion in
bugs, etc) we (regular contributors) are all accustomed to, so it seems
like no big deal _to us_, but if that's the first impression someone has
of how we do things, it can be extraordinarily off-putting. This
sometimes also comes up when a regular contributor in one area crosses
over into another area whose group dynamic is different.

I don't want to name names because I see this as a group-culture
problem, not a problem of specific people. Some people are (IMO)
over-aggressive all the time, but lots more people do it sometimes.
_I_ have probably done it to someone without realizing.

Partly I think it comes from a quite justified fear of letting our
standards slip, especially among the contributors who remember the bad
old days (I am still sort of wondering what the San Diego People did
that was so horrible that Shaver made jokes about it years later...)
And while it's possible to have high standards for the _code_ without
crushing egos all around, it's certainly more work for the reviewer, so
that feeds into the perennial lack-of-reviewer-hours problem.

The explicit mentoring process that we've added recently should help, I
think. Other things that occur that might help:

* (more) people whose official job is to talk to bug reporters
(in bugzilla, not just in the support forums)
* mentoring of the process of code reviewing
* finding ways to take load off overloaded reviewers
* written guidelines for how to criticize assertively but not
aggressively -- this *is* a skill that can be trained

> Do these people know who they are? (One of my greatest fears is that
> I will be abusive and not even realize it.)

For the record, you're one of the people who is _least_ likely to do
this, in my experience.

I recall someone else bringing up your quip about throwing people off a
bridge if they tried to port Gecko to a non-twos-complement machine (or
something like that) -- this _could have_ been problematic, but (not
having been there) probably wasn't, in context. It's aimed at a
hypothetical person who almost certainly doesn't exist (as far as I know
nobody's manufactured a non-twos-complement CPU in many years), it is a
standard kind of hyperbole, and it was on IRC. I'd hesitate to post
such a thing in bugzilla, it would be inappropriate in response to an
actual offer to port to a wacky machine, and ironically if you had
merely threatened to punch the hypothetical person, rather than
murdering them, it would be more problematic (because it'd be way more
plausible that you weren't joking in that case).

(In response to an actual offer to port I would probably say something
like "That would be a great deal of work, and we'd want you to do extra
work to keep the changes self-contained rather than being visible
throughout the code, and we're not promising that future changes won't
break it again, but if you really want to do it, go ahead.")

>> I don't think it's possible to overstate how easy it is for users
>> to write us off as *completely* *uninterested* in hearing about
>> their problems. As such, just about *any* policy change that makes
>> us seem less uninterested is worth doing IMHO.
>
> This is a tough one. A lot of these "cranky comments" are abusive.
> Letting them proliferate with impunity itself creates a hostile
> environment. I can shrug off invective claiming I'm an evil
> conspirator for not supporting MNG or SVG Fonts whatever; I don't
> want to ask that of all our contributors. So I don't know what to
> do. What do you think we should do?

Be very firm about _abuse_ of _people_, but allow _venting_ (which may
include put-downs of the _project_). Let's be concrete: here are some
examples from infamous bug 98168:

comment #108
| In February of last year I submitted to comment about this bug -
| disappointed that a seven year old bug had turned into a ridiculous
| idealogical debate instead of a real-world issue deserving of a fix.

comment #116
| I feel disappointed. Sorry, this is not something to help solve
| the bug, obviously you know how to fix it, the problem is that
| you don't want it.

These are venting, which should be tolerated -- i.e. should _not_ draw
responses of the form 'bugzilla etiquette forbids this sort of comment'.
The appropriate response to venting is no response at all.

comment #70
| This again is total ****. If the W3C spec says that it is allowed
| then your XSLT processor should allow it. If you can't do it, it
| just proes what second-rate programmers you are.

This is (just barely) abuse, because of the "what second-rate
programmers you are" line. (I deliberately picked something mild but
nonetheless IMHO unacceptable.) Abuse _should_ receive a polite but
firm rebuke, in this case I'd write "We understand that you are unhappy
about this bug, but we will not swallow insults over it. Please refrain
from calling people second-rate in the future." Note that the rebuke
that's actually in the bug is *not* a good example:

comment #71
| Tony, if you don't mind your wording in the future, we'll consider
| administrative actions against it.

It escalates too fast and is too blunt. This would be an appropriate
level of response to a significantly nastier comment.

Also, *ideally*, rebukes would go in a private email and the offending
comment would be marked hidden-by-default, but AFAIK we can't do that
right now.

zw

[Zack Weinberg]

On 2012-04-07 12:42 AM, L. David Baron wrote:
> On Friday 2012-04-06 19:01 -0700, Zack Weinberg wrote:
>> I don't think it's possible to overstate how easy it is for users to
>> write us off as *completely* *uninterested* in hearing about their
>> problems. As such, just about *any* policy change that makes us
>> seem less uninterested is worth doing IMHO.
>
> So one dilemma I sometimes face is this: I'm reading bugmail and I
> see an incoming bug report that I know something about

....

> I have the time to write a few sentences in the bug explaining
> that -- that multiplies my time reading bugmail by, say, a factor of
> two to five. But I don't, that day, have time to defend my short
> comment to the inevitable responses, which are sometimes quite
> demanding.

Putting this together with what Majken said just above, perhaps we could
have people you could delegate the defense of your short comment to?
I'm willing to be one of those people -- I don't have a lot of *coding*
time these days, but I could fit in reading and replying to a lot more
bugmail than I already get.

zw

[Robert O'Callahan]

On Thu, Apr 12, 2012 at 10:14 AM, Zack Weinberg <za...@panix.com> wrote:

> On 2012-04-06 11:33 PM, Robert O'Callahan wrote:
>

>> Do these people know who they are? (One of my greatest fears is that
>>
> I will be abusive and not even realize it.)
>>
>

> For the record, you're one of the people who is _least_ likely to do
> this, in my experience.
>

I already knew you weren't talking about me (that was the first thing I
checked, as you know :-) ); I'm just saying that people simply may not be
aware that they're being abusive, or being seen to be. There has to be
someone respected who can tell any contributor "that was out of line".

Be very firm about _abuse_ of _people_, but allow _venting_ (which may
> include put-downs of the _project_).

OK.

I'm not convinced we should allow "venting". It gradually makes bugs harder
to fix and denigrates our developer contributors at least indirectly. Maybe
if we could set a "venting bit" on Bugzilla comments so I don't have to see
them...

[Daniel Glazman]

On Apr 12, 12:14 am, Zack Weinberg <za...@panix.com> wrote:

> These are venting, which should be tolerated -- i.e. should _not_ draw
> responses of the form 'bugzilla etiquette forbids this sort of comment'.
>   The appropriate response to venting is no response at all.

I tend to agree with Zack here. And defining "venting" will be really
hard.
People disagreeing with a change are often passionate and that's life.
Furthermore, if moving discussion elsewhere is always possible (for
instance to newsgroups), it's not always easy for all outsiders to
follow multiple information channels sources, and wow yes we have A
LOT,
probably too many, of these.
You can't expect from "outsiders" to fully deal with the rules and
habits of
a community they're not yet members of (since they're outsiders...).

FWIW, I perfectly recall an episode that was extensively discussed in
the community outside of MoCo. That's comment #21 on bug 253722:

https://bugzilla.mozilla.org/show_bug.cgi?id=253722#c21

Then Blake started a thread at MozillaZine with one single word,
"Discuss.":

http://forums.mozillazine.org/viewtopic.php?f=8&t=118119

Contributed only one message at the beginning of 16 pages of
contribs, in short explaining the reason why the change was made and
closing the door. No real discussion ever happened.

That was extremely bad communication, and was of course perfectly
received as such by the community. As Zack said, too fast and too
blunt. After all, the 16 pages in the forum show there _was_ something
to discuss and that the community was not at all homogeneous about the
decision to remove alternate stylesheets selection UI.

</Daniel>

[Asa Dotzler]

On 4/11/2012 3:14 PM, Zack Weinberg wrote:
> Be very firm about _abuse_ of _people_, but allow _venting_ (which may
> include put-downs of the _project_). Let's be concrete: here are some
> examples from infamous bug 98168:
>
> comment #108
> | In February of last year I submitted to comment about this bug -
> | disappointed that a seven year old bug had turned into a ridiculous
> | idealogical debate instead of a real-world issue deserving of a fix.
>
> comment #116
> | I feel disappointed. Sorry, this is not something to help solve
> | the bug, obviously you know how to fix it, the problem is that
> | you don't want it.
>
> These are venting, which should be tolerated -- i.e. should _not_ draw
> responses of the form 'bugzilla etiquette forbids this sort of comment'.
> The appropriate response to venting is no response at all.

I disagree about venting. It may make some drive-by bug commenter feel
better, but it also makes some core contributor less likely to
participate in solving that problem -- or participate at all. It also
makes actually fixing the bug that much more difficult because it
pollutes the technical discussion with comments that do absolutely
nothing to advance the technical discussion. Finally, that kind of
negativity has an impact on potential contributors who might decide that
they don't want to be a part of an effort that's overrun by jerks with
no self control.

Venting isn't innocent. It's draining. It's de-motivating. It's
discouraging. It should not be labeled as OK.

Bugzilla is not a support forum (or support group, for that matter) and
we let it become that at our peril.

- A

[Mitchell Baker]

I wonder -- humans need generally need a way to vent. We know that
venting in bugzilla sucks energy.

Any chance we can find some accepted ways of venting that are less
destructive? Or develop a culture that identifies something as
"venting" without pushing the person identified as venting into rage?
So we could acknowledge some human traits but keep the workspace peole
come back to regularly less draining?


mitchell

[Jason Duell]

On Apr 12, 9:18 am, Mitchell Baker <mitch...@mozilla.com> wrote:
> I wonder -- humans need generally need a way to vent.  We know that
> venting in bugzilla sucks energy.
>
> Any chance we can find some accepted ways of venting that are less
> destructive?  Or develop a culture that identifies something as
> "venting" without pushing the person identified as venting into rage?
> So we could acknowledge some human traits but keep the workspace peole
> come back to regularly less draining?

I've often wondered why we don't allow posts to be deleted in
Bugzilla. I think there's a "broken windows" effect, where when
someone finds a bug that's irritating them and sees other people's
vent-y comments, they are *much* more likely to post something
obnoxious ("OMG you jerks still haven't fixed this").

I'd personally support being able to flag people's bugzilla posts as
inappropriate and have some omsbudman/moderator review them and remove
as seems appropriate. I know this has been suggested (many times?)
but I forget the reasons we've opposed it.

Jason

[David Rajchenbach-Teller]

On 4/12/12 6:31 PM, Jason Duell wrote:
>> Any chance we can find some accepted ways of venting that are less
>> destructive? Or develop a culture that identifies something as
>> "venting" without pushing the person identified as venting into rage?
>> So we could acknowledge some human traits but keep the workspace peole
>> come back to regularly less draining?
>

> I've often wondered why we don't allow posts to be deleted in
> Bugzilla. I think there's a "broken windows" effect, where when
> someone finds a bug that's irritating them and sees other people's
> vent-y comments, they are *much* more likely to post something
> obnoxious ("OMG you jerks still haven't fixed this").
>
> I'd personally support being able to flag people's bugzilla posts as
> inappropriate and have some omsbudman/moderator review them and remove
> as seems appropriate. I know this has been suggested (many times?)
> but I forget the reasons we've opposed it.

If we do not want to delete comments for archiving reasons, we could
also add the possibility of marking them as obsolete (just like
attachments), in which case they would be collapsed.

Cheers,
David

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[L. David Baron]

On Thursday 2012-04-12 02:19 -0700, Asa Dotzler wrote:
> participate in solving that problem -- or participate at all. It
> also makes actually fixing the bug that much more difficult because
> it pollutes the technical discussion with comments that do
> absolutely nothing to advance the technical discussion. Finally,

I'd like to emphasize this point in a slightly different way:

There are many points in the lifetime of a bug where taking the next
step (prioritizing it -- something that's generally done multiple
times before it's at the top of somebody's list, figuring out who
ought to work on it, figuring out how to work on it, what the next
step is, whether it's safe to land on a branch) that require
reading *all* the comments on a bug.

This is a flaw in Bugzilla's design; it's not at all inherent in the
problem of bug tracking. But it's the bug tracker we're using,
unfortunately. (I think the notion of a single linear stream of
append-only comments is the single biggest problem with Bugzilla.)

But it means that every time you add a comment to a bug you're
incrementing N in an O(N^2) algorithm.

[Zack Weinberg]

On 2012-04-12 2:19 AM, Asa Dotzler wrote:
> On 4/11/2012 3:14 PM, Zack Weinberg wrote:
>> comment #116
>> | I feel disappointed. Sorry, this is not something to help solve
>> | the bug, obviously you know how to fix it, the problem is that
>> | you don't want it.
>>
>> These are venting, which should be tolerated -- i.e. should _not_ draw
>> responses of the form 'bugzilla etiquette forbids this sort of comment'.
>> The appropriate response to venting is no response at all.
>
> I disagree about venting. It may make some drive-by bug commenter feel
> better, but it also makes some core contributor less likely to
> participate in solving that problem -- or participate at all. It also
> makes actually fixing the bug that much more difficult because it
> pollutes the technical discussion with comments that do absolutely
> nothing to advance the technical discussion. Finally, that kind of
> negativity has an impact on potential contributors who might decide that
> they don't want to be a part of an effort that's overrun by jerks with
> no self control.

I don't disagree with this assessment of the effects of venting, but I
disagree with your implicit priorities and I also disagree with your
apparent belief that *reacting* to venting is better than ignoring it.

As a matter of (utilitarian) principle, I believe that marginal
improvements to the experience of new and/or potential new contributors
are *more valuable in the long run* than marginal improvements to the
experience of established contributors, and that in this case it is
appropriate to improve the new-contributor experience (by making
bugzilla seem more welcoming to people not already familiar with it)
*even though* this may be at the expense of making a small number of
bugs even less pleasant to deal with for longtime contributors than they
already are.

Further, venting, specifically, needs to be *ignored*. To first order,
any given person will only vent once, but a series of vents and
reactions to vents carry the subtext that venting will provoke a
reaction. Contrariwise, a series of vents *without* reactions carry the
subtext that venting doesn't get any attention. Therefore, posting a
reaction to the venting in the bug where the venting is, is
*counterproductive*. And also means that there are 2*(#vents) noise
comments in the bug instead of (#vents).

(This logic also somewhat applies to abuse, but since we don't have a
way to hide comments in bugzilla, it *is* valuable for abuse to get a
visible "abuse will not be tolerated" response *even though* it
encourages further venting, because it reassures people that personal
abuse is, in fact, not tolerated.)

Having said that, I definitely support adding a "hide this comment by
default" feature to bugzilla. I think it should work on top of the
existing collapse-comment mechanism, so that the hidden comments are
easily accessible to anyone who wants to make sure we're not squelching
legitimate criticism, and I think it should be possible to label each
collapsed comment with a one- or two-word explanation of why it is not
useful ("spam", "off-topic", "venting", like that).

Also, if people with moderator privileges could mark particular
*accounts* as always to be collapsed by default, that would be a useful
intermediate level of sanction for misbehavior (aiui, currently we only
have verbal reprimands and total bans, which makes it hard to deal with
e.g. someone who does report genuine bugs but does it in an
unnecessarily hostile fashion - I recall this happening a couple years ago).

zw

[Majken Connor]

So right now you're talking only about bugzilla, but the community is a lot
bigger than that.

Secondly I don't think venting should be *ignored.* People who care enough
to vent CARE. People who are venting have some sort of expectation that
they don't matter to us and that we won't listen (hence their choice of
communication style). When people are upset, in any situation, the #1 thing
they want whether they realize it or not is for someone to _care_ how they
feel. If people think you care they will be a lot more likely to take a
"sorry we can't fix that now" gracefully and with understanding. They've
venting because they think we don't care, and ignoring them just reinforces
that. If there's something workable in the post that can move the bug
forward, then why not reply to that as if the person had expressed it in an
acceptable fashion? Otherwise why not email the person privately to show
your empathy and see if they're open to working constructively (in my
experience most people are, but not everyone is, some people have their
minds made up that if you cared you'd agree with them 100% there's not much
getting through to those people).

I understand what you're saying about negativity being the first
impression, but not everyone is perfect. What kind of impression do you
think it would make to have a bug where someone is emotional, and someone
else treats them with respect and moves the conversation forward? Showing
people that they don't have to be perfect and we can work through conflict
could be comforting and encouraging.

However, we shouldn't just be looking at bugzilla as people's entry point.
There are many other tools now that we should be thinking about as well.
Bugzilla is not the best tool to start on, hopefully people have gotten to
bugzilla through some other page. There's the get involved page, the
stewards program, the mozilla reps program... If we're taking the topic of
this thread literally we should be discussing those programs and making
sure people spend time reaching out to new contributors (even the ones who
are venting!) to make sure they know they're welcome to participate and
help and that they'll be supported in it.

I also agree about bugzilla, it would be great to be able to mark comments
as progress on the bug, eg patches, someone commenting that they've done x
and are waiting on y, but that's a very *specific* conversation and not so
much about relations and community building per se.

On Thu, Apr 12, 2012 at 2:23 PM, Zack Weinberg <za...@panix.com> wrote:

> On 2012-04-12 2:19 AM, Asa Dotzler wrote:
>

>> On 4/11/2012 3:14 PM, Zack Weinberg wrote:
>>
>>> comment #116
>>> | I feel disappointed. Sorry, this is not something to help solve
>>> | the bug, obviously you know how to fix it, the problem is that
>>> | you don't want it.
>>>
>>> These are venting, which should be tolerated -- i.e. should _not_ draw
>>> responses of the form 'bugzilla etiquette forbids this sort of comment'.
>>> The appropriate response to venting is no response at all.
>>>
>>
>> I disagree about venting. It may make some drive-by bug commenter feel
>> better, but it also makes some core contributor less likely to
>> participate in solving that problem -- or participate at all. It also
>> makes actually fixing the bug that much more difficult because it
>> pollutes the technical discussion with comments that do absolutely
>> nothing to advance the technical discussion. Finally, that kind of
>> negativity has an impact on potential contributors who might decide that
>> they don't want to be a part of an effort that's overrun by jerks with
>> no self control.
>>
>

> ______________________________**_________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/governance<https://lists.mozilla.org/listinfo/governance>
>

[David Illsley]

On Thursday, April 12, 2012 7:38:35 PM UTC+1, Majken Connor wrote:
>
> However, we shouldn't just be looking at bugzilla as people's entry point.
> There are many other tools now that we should be thinking about as well.
> Bugzilla is not the best tool to start on, hopefully people have gotten to
> bugzilla through some other page. There's the get involved page, the
> stewards program, the mozilla reps program... If we're taking the topic of
> this thread literally we should be discussing those programs and making
> sure people spend time reaching out to new contributors (even the ones who
> are venting!) to make sure they know they're welcome to participate and
> help and that they'll be supported in it.

My gut feel is that often people vent or make inappropriate comments in Bugzilla because they're pretty sure developers will see their comments, whereas alternative communications channels tend to add levels of indirection where they perceive their comments are being filtered and won't hit 'someone that matters'.

I don't know that this is an inaccurate perception. I don't know of a great place to 'go' if I had what I perceive to be a a great idea for a new feature, or a convincing reason why a bug should be given a higher priority. There are plenty of places I could go where I'd be shot-down or just fobbed off.

Is there somewhere for people 'with ideas' to go where they'll get engagement from 'someone who matters'? Is there a 'product management office-hours' or a 'bug advocacy list' where thoughts and suggestions are engaged with?

Does this ring true to anyone else?
David

[David Illsley]

On Thursday, April 12, 2012 7:38:35 PM UTC+1, Majken Connor wrote:
>

> However, we shouldn't just be looking at bugzilla as people's entry point.
> There are many other tools now that we should be thinking about as well.
> Bugzilla is not the best tool to start on, hopefully people have gotten to
> bugzilla through some other page. There's the get involved page, the
> stewards program, the mozilla reps program... If we're taking the topic of
> this thread literally we should be discussing those programs and making
> sure people spend time reaching out to new contributors (even the ones who
> are venting!) to make sure they know they're welcome to participate and
> help and that they'll be supported in it.

[David Ascher]

Some of us informally have talked about encouraging leaders of every stripe to set up a mechanism similar in intent to professorial office hours. I think it's worth exploring, but I don't know how to get the mechanics right, especially trying to bias towards geodistributed community members. I do think however that a random user does not de facto "deserve" attention from said leaders, and does not fall under my definition of "community member" (who very much _do_ deserve to be heard as individuals). User feedback should be handled by purpose built tools like input & sumo; we may be missing some?

--da

[Majken Connor]

Someone with an idea though isn't just a "user" giving feedback. They're a
potential contributor. If they're not able to contribute to the
implementing of their idea then that needs a different response than
someone who is ready to write a patch. But everyone who cared enough to
find a channel to engage in the discussion is a contributor if we let them
in.

There have been some things far off the radar for this stuff besides input.
Labs had (has?) an area where people can submit and discuss new ideas like
(I think it was) Dell.

But even if they can't code or don't want to, there is still support, l10n,
engagement, learning, webmakers... if we herd them towards a tool we need
to make sure that the tool still connects them into the community and isn't
a dead end.

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

[David Ascher]

Right -- I think we need to keep refining and enriching our vocabulary,
mental model, tooling, metrics, etc. for understanding our contribution
goals and the steps along the way.

As an example -- Labs has indeed has a variety of mechanisms for
collecting "ideas" and often places to "discuss ideas". But it turns
out in practice that ideas is not what we're short of. What "Labs" has
needed, it turns out, is much more subtle and _precise_ than that, which
is why we've in fact shut down all of those "generic idea pools", as
they were misleading -- people felt they were contributing, but in fact
nobody had the time (or focus) to extract value out of their efforts.

What Labs needs in fact depends a lot on the project -- some need
feedback on a product concept; some need user testing; some need
architectural review/critique; some need design feedback; some need
performance analysis; some need regulatory input! For each of these
kinds of contribution types, it turns out, we need to build explicit,
carefully designed, contribution models, each with its own pipeline,
communication mechanisms, selection criteria, etc. I'll be the first to
admit that we're very, very early in that process. And it's also clear
that some of the modes of contribution map more or less well a) to our
past practices, and b) to the utopian default of "anyone's input is
equally valued".

As an example, I had an idea recently for how we could make it easier
for websites to safely build webapps for kids. While I could start a
wide open thread about that, and it would likely gather hundreds of
messages, and at some point we will, the odds of getting the maximally
useful feedback from that thread is low. Because the problem here isn't
"having ideas" but "figuring out whether the idea is compatible with US
and European laws-in-the-making", that would be a waste of my time _and
the contributors'_ time. Instead, I should find contributors who are
experts in the field - legal scholars, kids-website-makers, carefully
chosen kids & parents, politicians even. Once I understand the
regulatory model better, if the idea has any hope, then we'd broaden the
ways of participating in that proto-project, in particular to see how
much we can extend the concept to other jurisdictions, for example.

The point is not to be opaque (it'll all be on public wikis etc.), but
that for any project to succeed one should be thoughtful about what kind
of contribution you _need_, what contributions you _want_, and what
percentage of your time you can afford to spend managing contributions
as opposed to doing.

In many, many areas, we should not shy from saying "you must be this
tall" to participate. That "height" should be intentional though:
thoughtful, and explicitly avoid biasing for things that aren't
relevant, like employment status, and hopefully geography, timezone,
age, etc.

To be clear: I'm a _huge_ believer in the statement that Mozilla needs
to figure out how to massively increase the number of people that
contribute meaningfully to our success. I also think that we've learned
a lot over the years (both within Mozilla and in other participatory
efforts from open source to elections and other environments) about the
need to _architect_ participation models (cue Tim O'Reilly). I'm
personally hoping to spend a good chunk of Q2 thinking about that, and
getting people to help me do that for some of the Labs "architecture of
participation" in particular.

The point that I was trying to make was in (positive) response to
David's suggestion that there could be "product management office hours"
-- I think that in general all leaders (not just PMs/drivers) need to
have explicit, easy to understand engagement models -- those need to be
"reasonable" and "efficient" -- we don't want people who have a _lot_ of
work to _do_ to spend all their time hearing "constituent complaints".
And for the record, I think that the vast majority of Mozilla leaders
already spend a huge amount of time hearing and listening -- but we're
maybe not good enough about being clear a) how/where to "speak" so that
you'll be heard, b) that we're indeed hearing the input. We also need
to be clear that our jobs involve making decisions and moving things
forward, and that while we must hear the feedback, we need not agree,
not even with the majority.

--david

[Majken Connor]

That's true, no one has time for everything. But you have people like me
for example. I don't have the skills to follow through on my on on many of
my ideas. I do a great job, though of helping other people go to the right
places, finding the right people to talk to, right documents to read, etc.
I would have time to read, which is what I do a lot of the time so that I
know where to send people.

There is definitely a fine line in your thoughts about when to be open. I
think we have to be more careful when employees are concerned because they
have the power to effectively lock out contributors from any meaningful
part of the process (not saying they do). There is a balance though. We
shouldn't be deciding how people's time should be spent. If people want to
"waste" their time on a discussion who's to say it's really a waste? The
keys are making sure people who want to get things done aren't spending too
much time in the discussion, and like it was suggested, maybe check back in
a few days or a week, rather than checking every reply as it comes. Also
the place. Hopefully it works out well to say "hey I'm going to work on
something like this, ping me if you want to help" especially if it's an
"official" team project.

I totally agree that people need to be contributing to the right places and
there need to be requirements for some things, but we should be able to
help people meet those requirements who want to, and we should make sure
there are roles for everyone where we can. The Reps program definitely
helps with this. If someone comes along and wants to help with something,
but they don't know how, we're starting to have a layer of community that
can mentor them to it.

I also very much agree with you about not needing to agree. I think this is
why some people shy away from open discussions or think it's wasting their
time because it's a lot of energy to get everyone to agree. I think what
matters more is making sure the decisions and the reasoning are clearly
communicated. If someone sincerely wants to discuss it because they're
trying to understand or contribute it would be great if there is someone
that can engage them (reps/stewards eg) but it doesn't have to be the
leader per se.

[Justin Dolske]

On 4/12/12 9:18 AM, Mitchell Baker wrote:
> I wonder -- humans need generally need a way to vent. We know that
> venting in bugzilla sucks energy.
>
> Any chance we can find some accepted ways of venting that are less
> destructive? Or develop a culture that identifies something as "venting"
> without pushing the person identified as venting into rage? So we could
> acknowledge some human traits but keep the workspace peole come back to
> regularly less draining?

I think it's helpful to think about such venting as coming in different
flavors...

One is venting (or, really, any inappropriate behavior) from a new
Bugzilla user. I don't see any way to completely stop that. We could
probably do a bit better in making new users aware of etiquette, but
some are going to ignore it.

For users in that bucket, I think the onus is on _us_ to deal with it.
Maybe that means ignoring it. Or privately sending them a polite
form-letter about how to participate more effectively. Or having some
way to hide/edit/mark as the mistakes of innocents.

The other kind of venting comes from users who are no longer new, and/or
have demonstrated a pattern of abusive comments (and have ignored
repeated warnings).

Those users should know better, and more stern measures are fair. A
different form-letter that's more blunt about _them_ needing to change
their ways. We could add a "troll" bit to that others can ignore them.
Disabling their account as a final measure.

Bugzilla already labels new users differently (iirc, for accounts less
than X days old or having made less than X changes?), so that part is
essentially free. :)

Justin

[Josh Matthews]

On 12-04-12 2:23 PM, Zack Weinberg wrote:
> Having said that, I definitely support adding a "hide this comment by
> default" feature to bugzilla. I think it should work on top of the
> existing collapse-comment mechanism, so that the hidden comments are
> easily accessible to anyone who wants to make sure we're not squelching
> legitimate criticism, and I think it should be possible to label each
> collapsed comment with a one- or two-word explanation of why it is not
> useful ("spam", "off-topic", "venting", like that).

Another idea occurred to me while filling out a survey for a project
about automatic bug summarizing: we could go the opposite route and
specifically mark certain comments as being important. If a bug contains
such comments, a new link appears on the side that collapses comments
that have been marked as such.

Cheers,
Josh

[Majken Connor]

On Sat, Apr 14, 2012 at 9:35 AM, Josh Matthews <jo...@joshmatthews.net>wrote:

> On 12-04-12 2:23 PM, Zack Weinberg wrote:
>

>> Having said that, I definitely support adding a "hide this comment by
>> default" feature to bugzilla. I think it should work on top of the
>> existing collapse-comment mechanism, so that the hidden comments are
>> easily accessible to anyone who wants to make sure we're not squelching
>> legitimate criticism, and I think it should be possible to label each
>> collapsed comment with a one- or two-word explanation of why it is not
>> useful ("spam", "off-topic", "venting", like that).
>>
>

> Another idea occurred to me while filling out a survey for a project about
> automatic bug summarizing: we could go the opposite route and specifically
> mark certain comments as being important. If a bug contains such comments,
> a new link appears on the side that collapses comments that have been
> marked as such.
>
> Cheers,
> Josh
>

> ______________________________**_________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/governance<https://lists.mozilla.org/listinfo/governance>
>

HI all,

Today I finally figured out how I would categorize bugzilla comments so
that we could filter them: "update" and "discussion"

I think that makes it pretty clear the difference between the two. An
update has new information, a patch, STR etc. Discussion is questions or
comments or telling someone how to get STR etc. By default we could show
updates only.