While good messages are important, ensuring that the project keeps being a productive and fun place to be requires some care towards relationships with other people. This mainly boils down to being smart, honest and polite.
Most of the following suggestions are likely to be trivial for everyone, but they are worth collecting anyway so that we avoid forgetting some of them.
Read messages smartly.
Most of the fun with working with others depends on how you read and interpret their messages and contributions:
Exercise your will.
It is finally up to you to decide how a message is important and how it influences the way you do things.
A message is ultimately important if it meets your needs and motivations: other aspects of it, such as if it is the last message in a thread or if it is full of convincing rhetoric or catchy phrases, have no relevance in a technical discussion.
Interact with human beings instead of single messages.
When you see a message you don't like, try to remember your general opinion of the person who wrote it. Try not to make a case about a single episode.
If you see a message you don't like written by a person you don't know, wait to see some more posts before making assumptions about the person.
If people do something that seriously undermines your trust or opinion of them, try writing them privately to tell about your disappointment and ask about their reasons.
Also, try to remember who is normally doing good work and who is normally being a troll.
Be forgiving.
Try to be tolerant towards others; when you are unsure about the intentions of a message, assume good intentions.
Be tolerant of personal differences.
Remember that you might be discussing with someone who normally looks, thinks or behaves very differently than you do.
Debian is a large project which involves people from different cultures and with different beliefs. Some of these beliefs are understood to be in open conflict, but people still manage to have a fruitful technical cooperation.
It is normal to dislike someone's beliefs but still to appreciate their technical work. It would be a loss if a good technical work is not appreciated because of the beliefs of its contributor.
Be positive before being negative
Try to put positive phrases before negative phrases: the result is more rewarding and pleasant to read.
This can make a difference between a bug report that looks like an insult and a bug report that motivates developers to carry on their work.
It is an interesting and at times difficult challenge to do it: you can look at how these guidelines are written to see examples.
One reason this is hard to do is because most of the work with software is about problems. For example, most of the conversations in the Bug Tracking System start with telling that something does not work, or does not work as expected.
This naturally leads us to mainly talk about problems, forgetting to tell us when things work, or when we appreciate the work of someone.
Give credit where credit is due.
Always acknowledge useful feedback or patches in changelogs, documentation or other publicly visible places.
Even if you personally do not care about attribution of work you've done, this may be very different for the other person you're communicating with.
Debian is an effort most people pursue in their free time, and getting an acknowledgement is often a nice reward, or an encouragement for people to get more involved.
Be respectful and polite.
If you write in an unpleasant manner, people won't feel motivated to work with you.
Help the public knowledge evolve.
Reply to the list.
If you can help, do it in public: this will allow more people to benefit from the help, and to build on top of your help. For example they can add extra information to it, or use parts of your message to build an FAQ.
Encourage people to share the help they receive.
Solving a problem creates knowledge, and it is important to share it. A useful IRC or email conversation can become a blog entry, a wiki page, a short tutorial or HOWTO.
When answering a question, you can ask the person to take notes about what it takes to actually completely solve the problem, and share them.
Sustaining a discussion towards solving a problem is sometimes more important than solving the problem.
The most important thing in a technical discussion is that it keeps going towards a solution.
Sometimes we see a discussion and we can foresee a solution, but we do not have the time to sort out the details.
In such a case, there is a tendency to postpone answering until when one has the time to create a proper answer with the optimal solution in it.
The risk is that the time never comes, or we get carried away by other things, and everything we had in mind gets lost.
When there is this risk, keeping the discussion going towards solving the problem is more important than working silently towards the solution.
Judge the work and not the people.
Judging work is easier than judging people, and in a technical community it is also more appropriated.
Also, remember that human nature can be strange:
If I get told "your program does not work", I am encouraged to fix it.
If I get told "you suck", I am encouraged to go and work somewhere else.
If I get told "your program is great", I am encouraged to write more.
If I get told "you are great", I don't need to work anymore to be cool.