Mindstorm: Rework of mailing list rules
Catalog of possible mailing list etiquette rules
1.1. The mailing list language is English.
1.1.1. If you have problems expressing yourself in English, a small note in your message saying so is enough.
1.1.2. Don’t apologize if your English is bad.
1.1.3. Listing which languages you speak better will also help. Maybe another speaker of that language can help clarifying the obscure parts of your posting.
1.2.Post to the right mailing list:
1.2.1. User problems, techniques, hardware advice, requests for comments about images, GIMP usage to [gimp-user].
1.2.2. Questions on coding, patches, bugs and other GIMP’s guts things to [gimp-developer]. Similar, GEGL- related stuff to [gegl-developer]
1.3. Do not post the same message to various mailing lists.
1.4. What goes to the mailing list?
1.4.2. Enhancement requests before filing them in the Bugzilla bug tracker. Be ready to put some efforts into that topic to let the enhancement become real.
1.4.3. Answers to your questions; also if you found them by yourself.
1.5. What must not go to the mailing list?
1.5.2. Criminal stuff or requests for it. We’re developers, not bad guys and girls.
1.5.3. Job offers, excepting you want to hire somebody for GIMP related stuff, like fixing a bug or implementing a feature.
1.5.4. Ways to make money fast
1.5.6. Invitations to send birthday wishes to a friend
1.5.7. Invitations from social networks, like “Foo has tagged you” or flash mob invitations.
1.5.8. Subscribe/Unsubscribe messages. To unsubscribe follow the instructions in the ‘Welcome to the mailing list’ mail or at the mailing list links on the GIMP website.
1.5.9. Test messages
1.5.12.Reactions on all of the aforementioned
1.6.Investigate the topic before writing:
1.6.1. Especially for problematic topics
Known to be flame-critical topics, like the best tool, the best image editing software or whatever of your things is better than others.
The name GIMP, save vs. export behavior …
Philosophical, off-topic discussions about definitions etc.
Long running discussions.
1.6.2. Don't claim to have found a bug without investigating it before.
1.6.3. Where to investigate:
in the mailing list archives and forums,
in the documentation,
in the FAQs,
your own experiments and observations.
Ask a skilled friend and let him try first on another computer.
As programmer: read the source code, API documentation etc.
On user interface related issues see the GUI specs: http://gui.gimp.org/index.php/Specifications
1.6.4. Check your facts, even before reporting.
1.6.5. Check that you use a current GIMP version.
1.6.6. Show, that you first investigated the topic and what you've learned thereby.
1.6.7. Careless and sloppy questions get careless and sloppy answers, if at all.
1.7.Stick to the point.
1.7.1. If the topic starts to change, choose a new subject and append '(Was: <previous topic>)'.
1.7.2. Discuss new questions in a new thread.
1.8.Use a meaningful subject.
1.8.1. Without HELP or GIMP. We know that you're writing about GIMP and probably need help.
1.8.2. 'Object - Problem' style, like “JPEG files from SupaDupaCam ABC123 - EXIF data get lost”
1.8.3. Put the word “[RESOLVED]” in front of subject of postings with a solution.
1.8.4. Don't try to attract attention, like “HELP”,“URGENT” or “!!!”.
1.9.Shortly describe the content of URLs, especially those from URL shorteners like Bitly etc.
1.10.On problems provide as much necessary information as possible:
1.10.1.Clear and careful description of symptoms in chronological order.
1.10.2.If you have own assumptions, try them out instead of posting them. You can post them if you found out that they work. That would be a bigger help.
1.10.3.CPU name or family
1.10.4. Operating system, version, 32/64 bit. On Linux:distribution,
1.10.5. From which download source, your Linux distribution or compiled by yourself.
1.10.6. GIMP version number
1.10.7. On hardware problems: exact product name of device, for instance Wacom Bamboo Fun Pen & Touch graphics tablet
1.10.8. Own investigations and diagnose steps and results
1.10.9. Possibly relevant configuration changes of computer or software
1.10.10.How to reproduce
1.10.11.What answer do you expect? A solution hint, a patch or integration of your own patch? On questions for tutorials, first tell, which effect exactly you're trying to achieve.
1.11.Only tell facts, represent them clearly and properly and check them before posting
1.12.Dispense with useless questions like “Can anybody help me?“. The answer would probably be a single ‘Yes’ or ‘No’.
1.13.If a solution was helpful, post it and thank those, who helped you
1.14.Go without visual effects, like ASCII-art, banners and tons of smileys.
1.15.Use brief signatures with your name and e-mail address, but without fancy bells and whistles like in web forums
1.16.Quality prior to quantity.
1.17.Do not assume we all know the same software like you. Believe it or not: most of the readers here don’t have Photoshop. So if you refer to some other software, describe clearly, what you mean or add a link to a relevant screenshot.
2.1.1. Delete irrelevant text
2.1.2. Be clear and precise
2.2.1. Insert white spaces, punctuation, paragraphs
2.2.2. Go without unnecessary punctuation
2.2.3. Use upper and lower cases.
2.2.4. Between paragraphs and after quotes insert blank lines.
2.3.Write in complete words and sentences
2.3.1. Don’t use slang or short message style.
2.3.2. Use proper grammar
2.3.3. Use spelling correction.
2.4. Chip in, if you've something to tell, but don't cackle to every topic and dominate the discussion.
2.5. Ask ongoing questions to the mailing list, not solely to the one who used to help you one time. So other experts can also help you and the answer will help all.
2.6. Be factual
2.7. Don't be emotional:
2.7.1. Let anger fly by.
2.7.2. Don’t grovel
2.7.3. Don't feel personally attacked, even if a post sounds harsh.
2.8. How to handle offenses:
2.8.1. Chill out, calm down, exhale.
2.8.2. Read the text again, without ruffle or excitement.
2.8.3. If it's untenable, unbelievable lies: ignore it
2.8.4. If it’s a real offense: send a mail to the senders postmaster and report the abuse.
2.8.5. If it contains subject-specific arguments, that are worth responding:
reply calmly and factual
explain, in which points the offender is wrong
2.8.6. EXCEPTIONAL: flame back but keep in mind: it's hard to write a good flame. We’re a mailing list, not a kindergarten.
2.9. Don't force your opinions to others.
2.10.Be honest in what you're telling about yourself or any facts
2.11.It's helpful to tell others something about your own relevant knowledge or experience background, but don't be a smartass.
2.12.Be friendly and open:
2.12.1.Respect the others here like they are.
2.12.3.Use irony sparingly; if you can't resign on it, mark irony.
2.12.4.Don't use sarcasm or cynicism
2.12.5.Don't be a know-all.
2.12.6.No personal attacks!
2.12.7.Be politely if you disagree with somebody others opinion.
2.12.8.Your readers are humans, not morons or slaves.
2.12.9.Don't criticize others if their English is bad
2.12.10.Assume best intentions.
2.12.11.Respect the others' work or postings, even if you think it's idiotic
2.12.12.Don't stalk the others.
2.12.13.Avoid offending statements about other philosophies of life.
2.13.Separate private affairs from the mailing list:
2.13.1.Never forward private mails to the mailing list, except you have the written permission from its sender.
2.13.2.Don't answer to the list and the intended recipient, except you're sure, that he/she needs the answer quickly
2.13.3.Send private mails only to the intended recipient
2.14.If you have to say nothing new, keep quite.
2.15.Send pure agreement/disagreement in private mails.
2.16.Use > signs to mark cites. Your email application usually puts them in automatically.
2.17.Don't quote to deep (‘> > > > > a cite is a cite is a cite.’)
2.18.Don't put your answer before the question, but after or between the lines you answer to.
2.19.On quoting: only cite that part of the text you're referring to:
2.19.1.Cut unnecessary header parts
2.19.2.Cut disclaimers, even from private mails
2.20.Use citation signs properly; do not put words into sb. others mouth
2.21.If you have doubts about the rules, read the archives and follow those before you.
3. Technical stuff
3.1. Use plain text, not HTML nor RTF.
3.2. Check your own computers time zone and time to avoid answers virtually appearing before the questions
3.3. Use standard compliant mail client software, like Thunderbird etc.
3.4. You're responsible on your own to protect against abuse of your mail address and malware.
3.5. Wrap lines after 70 characters, but don't wrap data dumps.
3.6. Use 7-bit-ASCII-Code
3.7. Don’t send autoreply messages to the mailing list, like ‘I’m out of office.’
3.8. No e-mail attachments. If you MUST attach them:
3.8.1. only send useful attachments to what you’re discussing. For code attachments this means to send only the relevant code, that is a example with minimal code.
3.8.2. Don’t post them in proprietary file formats, like Word, Excel, Powerpoint or Flash.
3.8.3. Attach only small attachments. Use compressors, like gzip, and for images .xcf.gz, .xcf.bz2, png or jpg. If they are bigger than 10 KB, upload them somewhere and post the URL instead.
3.9. No MIME Quoted Printable Encoding (that one with numbers like %20 between words). This will make your posting almost unreadable.
3.10.Filter mails do avoid getting flooded with uninteresting postings.
4.1. Postings defying these rules will be answered with a warning.
4.2. On defying these rules repeatedly the sender will be barred from the mailing list. Don’t think we’re stupid: this also applies to messages from different senders, but with the same content.