I'd like to add to Bertrand's list:
4) Users logging a Jira bug to ask a technical question.
It looks like a variant of #2 ('The "wrong list" syndrome') but has the
added annoyance that activity is sent to the project dev list, to which
the issue submitter may not be subscribed. Indeed the issue submitter
might not even be on the project user list.
Are other projects encountering this? Is there a way to modify
project-specific Jira pages to add a notice "To ask a technical
question, please post to ${project}-user@ "? (Maybe I need to be reading
a jira faq -- *ouch*).
-jean
Bertrand Delacretaz wrote:
Le 7 août 05, à 16:16, Noel J. Bergman a écrit :
... - Is there an issue?
I don't think there is a general issue, but I see three points which
might help:
1) Talking on lists that one doesn't know well is hard
For me I feel much more comfortable on dev@cocoon.apache.org than on
other lists because I consider that one "my home" at the ASF. I know
many of the people who talk there, several of them I have met IRL, and
we're used to talk together on the list, we know each other's tone,
who's harsher and what it really means, who is sometimes betrayed by
their limited english, etc.
We read between the lines a lot when talking with people that we know well.
OTOH, when I try to participate in a conversation with people whom I
know less, I'm often surprised by the tone of some messages, or I
discover pre-existing tensions between people which bend their way of
talking, etc. It's just a more foreign environment which makes me feel
less comfortable.
Suggestion: people should make a conscious switch when they leave their
"home lists" to talk on other lists, and be extra careful when not at
home, mostly about their tone and how they react to the tone of others
(who might be "at home" on that list). It's basic netiquette anyway, but
maybe we forget about this because the other list is also at the ASF and
we think it's home as well.
2) The "wrong list" syndrome
The typical scenario is when a message is copied on the board@ list,
then people start talking there even if the discussion does not belong
there.
Then, some people stay away from the discussion because they know it's
off-topic there, and this most probably causes valuable opinions to be
missing, or the discussion to thin out without any real action.
Suggestion: define a simple "protocol" for moving discussions to another
list when this happen.
Suggested protocol:
Reply with [MOVE] in the subject when one feels the discussion should
move, and as soon as there are 3 or 5 +1s to this the discussion has to
move, starting on the new list with a summary of what was said so far
(without breaking privacy of course).
3) Lack of whiteboard
It's well known that the most efficient discussion is an open one around
a whiteboard. We have the openness with our lists, but very often we're
missing the whiteboard: it's hard to jump in a discussion because one
doesn't have a clear picture of the current state, what was said, what
was already agreed upon, etc.
This often causes a lot of friction, misunderstandings, irritation and
generally lowers the already poor efficiency of the lists as a way of
negociating important issues.
Suggestion: use more [SUMMARY] messages when discussions go on for a
long time and/or for many messages. Or post a progress report on a wiki,
without breaking privacy of course. Do that in a "3P" state of mind;
Progress, Problems, Perspectives.
- o -
Apart from that, I think it's up to each PMC to take care of the tone of
their lists. Talking about Cocoon again, because it's the only project
where I'm regularly active, we take great care of not letting flamewars
go on.
I'm not saying that the Cocoon team is a perfect one, but there have
been several instances of people calming down discussions, often saying
"we don't talk like that here" and asking people to get back to factual
claims instead of personal stuff.
It works, the downside is that we tend to be too politically correct
sometimes, but in the long term it seems much better than flaming at
will. But I don't think any rules will help here, it's just each group
that has to take care of themselves.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
