First page Back Continue Last page Overview Text

Notes:


Means for working together (very rare physical encounters)
<put a gimped picture of Branden as a club-holding troll>
Branden Robinson is a huge one-eyed club-holding cave giant (evil)
You don't know people personally, so it's difficult to interpretate non-strictly-technical contents or the way they use to make comments and to criticize.
Never, ever discuss about critical things in a public mailing list (you will start a Godwin flame war)
example: How do we discuss a new NM queue via mail without starting a Godwin flamewar?
It's hard to have critical discussions, because they will involve a lot of people, their emotions, their will to contribute and their will for their opinions to be taken into account
If you want feedback, create faulty projects (To have good feedback, you need to create interesting and faulty projects)
If you make a bad proposal, and people don't like it, you get criticized.
If you make a good proposal, and people like it, they won't answer to you, to avoid stupidly quoting your message to only add "nice".
With the result that good proposals tend to end up ignored.
It's very hard to do non-verbal communication in e-mail, but it would help a lot (lack of interested looks, nodding, smiles, thumbs up...)
To have people help you, don't write good code
Working alone: if you do things well, things will just work, people will be happy and won't send you ideas, bug reports and other feedback. With the result that everybody's happy, but you can't know it.
If you want to gather people around your project, don't do it perfectly
If you do it perfectly, people will think that you don't need a hand
If you do it perfectly, you'll be alone
(if you work with people in person, this won't happen because the other people will see how much you work on that project and can decide to have a look at what you are doing, ask questions and eventually give you a hand)
If you have a great idea, have the DPL take credit for it
If you don't know who's making a proposal, it's hard to determine if it's serious, what are his goals, what his commitment, what his skills
Any idea that needs more than one person to realize, is not a serious idea
One way to understand if a project is serious, is to try and evaluate a prototype; this means that it you haven't the resources so make a prototype, it's hard to get people to evaluate your idea (in normal life you tend to be introduced to people, and with a quick chat you can understand if the other is a serious and knowledgeable guy with good ideas and good plans or if he's a delirious nut)
Never get italians and germans in the same IRC channel (especially if the french are around)
People are from different places and cultures and have different social habits. Their code of behaviour is different from the one (unofficially) adopted in the lists.
What is the code of behaviour officially adopted in the list?
We work mainly using Computer Mediated Communication
Lack of empathy
Lack of non-verbal communication
Lack of shared significations<TODO: check with Mantovani>
Lack of common cultural, social, linguistical, educational background
Lack of common habits and code of behaviour (actually, geekiness might turn out to be a social glue for Debian, and this might be the reason for non-geek people having difficulties getting in)
Suggest book: "New Communication Environments: From Everyday to Virtual" by Giuseppe Mantovani Publisher: Taylor & Francis; (February 1996) ISBN: 0748403965
In lists you usually don't say "If I understood you well, you want to do <resumé of proposal>, isn't it?", because you would look like you're creating useless noise. In reality, however, it's a common behaviour.
FIXME: Make a list of communication noise which is useful in live
communication but isn't done in CMC