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


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.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to