Fig 1. Thread nyasar
| Arsip mwmag | [Files] [Up] | © 2002 PT Masterweb Media |
Figures
Email adalah sarana berkomunikasi yang telah ada berpuluh tahun silam, bahkan lama sebelum ARPANET/Internet popular. Sebuah medium komunikasi akan menumbuhkan cara, aturan, dan kebiasaan-kebiasaan tersendiri. Email pun tanpa terkecuali. Pengguna email yang relatif baru pun mungkin sudah tahu beberapa netiket dasar. Antara lain, jangan menulis dengan huruf kapital. Atau jangan melakukan spam (sudah barang tentu!). Atau bubuhkan smiley/emotikon seperlunya, untuk memperjelas maksud Anda.
Selain netiket yang sudah umum ada juga aturan-aturan tak kentara atau kebiasaan tak tertulis lainnya yang, jika dilanggar, kadang juga bisa membuat kita tampil seperti newbie atau orang tak tahu aturan di komunitas tertentu. Kadang sifatnya tidak seketat netiket umum, sehingga tak apalah sekali-kali dilanggar. Mungkin juga ini karena tidak semua anggota komunitas yang lain mengetahui kebiasaan tersebut. Tapi bagi para veteran yang tahu, bisa saja pelanggaran tersebut amat menjengkelkan melebihi pelanggaran terhadap netiket-netiket umum.
Mari kita lihat pelanggaran-pelanggaran apa saja yang bisa membuat jengkel itu.
Top posting adalah model mereply dengan email sebelumnya dikutip di bagian bawah dan tulisan jawaban kita di atas, seperti ini:
The JMX RI is free for any commercial use.
JMX (JSR 3) does not cover the remotability (now covered by JSR 160)
and SNMP. So it does not provide any code relative to SNMP but the
package that you have mentioned that is not providing an SNMP
implementation.
chris/
Sergey Armishev wrote:
> Hi all,
> simple question. How can I use javax.management.snmp API's definitions to
> develop my own implementation and use it in commercial products without
> violating any licensing rules?
>
> Thanks,
> -Sergey
Top posting sering sekali dilakukan oleh pengguna Outlook/Outlook Express, dikarenakan setting default kedua program tersebut. Kutipan email yang dihasilkan Outlook juga sering ditandai dengan indentasi, bukan dengan “>”, seperti di bawah ini:
Aku juga yah ...
newbie2
-----Original Message-----
From: newbie linux [mailto:newbie@kota.com]
Sent: Monday, September 16, 2002 2:59 PM
To: milis@linux.id
Subject: Minta tolong..
Kalau ada yang punya RPM-nya Gerambil, minta dong.. japri aja..
Bandingkan dengan cara mereply email secara “normal” yaitu kutipan di atas dan jawaban di bawah, seperti berikut:
Hi,
> what going on, Yesterday my interclient can communication with
> FireBird. But Today i get an error message like this :
>
> java.lang.VerifyError: (class: interbase/interclient/ErrorKey,
> method: _$372 signature: (Ljava/lang/String;Ljava/lang/String;I)V)
> Expecting to find unitialized object on stack
Are you using another JDK?
I believe this error occured when using the original (JDK 1.1)
compiled interclient with JDK 1.2 or higher.
Sebagian orang sebal dengan top posting karena selain alur pembacaan email jadi terbalik (mis: si pembaca jadi melihat jawaban dulu, baru pertanyaan) juga sering menjadi ciri bahwa si pengirim email kurang memperhatikan postingnya. Biasanya, begitu tekan Reply, langsung ketik (karena kursor ditaruh di awal teks oleh program email), lalu Send. Tidak pernah memotong kutipan, bahkan jarang membaca dulu teks email apa yang sebetulnya dibalas.
Saya pribadi cenderung tidak anti terhadap top posting. Toh tidak memotong kutipan pun bisa dilakukan oleh seseorang yang bukan “top poster”. Malah, keuntungan top posting adalah, jika membrowse pesan-pesan (misalnya arsip milis) dalam window yang tidak terlalu panjang, jawaban di tiap-tiap posting bisa langsung dilihat secara sekilas karena letaknya di bagian atas.
Namun mungkin kalau sifat jawaban sebuah email bersifat percakapan, misalnya:
> Di mana beli CD Gerambil?
Di Mangga Dua juga ada.
> Berapa harganya?
Kalau di M2, antara 15-25 ribu.
> Di Pecenongan ada gak ya?
Kayaknya ada.
sebaiknya tidak memakai gaya top posting, melainkan mereply dengan menyelip-nyelipkan jawaban yang sesuai tepat di bawah baris pertanyaan, seperti di atas. Dengan top posting, antara pertanyaan dan jawaban mungkin lebih sulit diikuti. Namun dengan model kutipan ala Outlook yang pakai indentasi, sulit memang pakai model selip-selipan, karena dengan pelipatan kata atau perataan paragraf, jawaban Anda bisa tampil bercampur aduk dengan pertanyaannya.
Di program email grafis seperti Eudora atau Outlook, kalau kita ingin mengirim email baru kepada sebuah milis (atau kepada seseorang), kadang kita mencari dulu email terakhir yang dikirimkan ke milis (atau dikirimkan oleh si orang tersebut). Lalu kita menekan Reply di email tersebut agar alamat email milis/si orang tersebut muncul di header To email baru kita. Lalu kita menghapus subjek dan isi email agar reply ini tampak sebagai email kosong.
Cara ini praktis tapi berefek samping, yaitu menghasilkan header In-Reply-To—yang biasanya tidak dapat Anda lihat. Header In-Reply-To dipakai oleh program email atau pengarsip mailbox untuk membuat tampilan threading. Akibatnya, email yang kita maksudkan sebagai thread baru akan muncul sebagai cabang dari thread sebelumnya. Lihat tampilan Mozilla Mail di Gambar 1 untuk jelasnya dan lihat header posting oleh “Aulia” berjudul “exchange standard & enterprise”. Milis delphindo@yahoogroups.com misalnya, adalah sebuah milis di mana para anggotanya gemar sekali melakukan abuse tombol Reply ini.
Sebagian orang kesal dengan kebiasaan yang kadang disebut juga dengan istilah ‘thread hijacking’ ini (thread baru yang ‘numpang’ ke thread lain). Bahkan ada moderator milis yang secara eksplisit memberi instruksi larangan terhadap hal ini. Mengapa? Para pembaca email yang sering menggunakan tampilan thread bisa jadi lolos tidak membaca thread-thread baru yang nyasar ke cabang thread lain ini.
Jika Anda ingin memulai thread baru, biasakanlah memilih menu New Mail, lalu mengetik field To secara manual (atau mengkopi paste atau memasukkan alamat milis ke Address Book). Jangan biasakan menggunakan tombol Reply sebab akan berakibat email Anda menjadi reply dari email sebelumnya.
Seharusnya netiket yang satu ini cukup jelas. Tapi ternyata masih saja banyak yang—karena ingin praktis—mengirim file besar-besar kepada rekan sekerja. Biasanya pelakunya adalah mereka-mereka yang berada di lingkungan intranet yang memiliki server SMTP lokal. Mengirim file besar terasa amat cepat, karena email dikirim dulu ke server lokal. Barulah si server lokal ini yang—kadang harus mati-matian—mengirimkannya ke dunia luar.
Email sebetulnya bukanlah sarana transfer file yang efisien, apalagi jika ke Internet. Pertama, email akan sampai di mailbox penerima dalam ukuran yang lebih besar dari ukuran file. Meskipun daemon SMTP rata-rata sudah 8-bit, namun banyak email akan disimpan di mailbox mbox yang masih mewajibkan 7-bit. Sehingga file biner harus diencode dengan base64 misalnya, dan memperbesar ukuran penyimpanan. Artinya email Anda akan berukuran lebih besar saat berjalan-jalan di Internet. Kedua, protokol SMTP tidak mendukung resume. Artinya, kalau kalau Anda mengirim ke server SMTP dan emailnya terputus di tengah-tengah, transfer harus diulang dari awal. Ketiga, email tidaklah bersifat real time dan kadang harus dioper-oper dari host ke host sebelum mencapai tujuan. Artinya, waktu sampai bervariasi dan teman Anda mungkin harus menunggu file tersebut dari bermenit-menit hingga berhari-hari. Keempat, kalau terjadi bounce, maka biasanya seluruh email Anda yang besar itu akan kembali dibungkus kepada Anda, memboroskan lagi bandwidth. Kelima, rata-rata program email tidak memiliki fasilitas resume download email yang besar.
Berkirim file besar via email sebaiknya hanya dilakukan di jaringan intranet, dan jangan ke Internet. Juga, tidak pernah boleh ke milis. Ada anggota milis yang mungkin kapasitas mailboxnya hanya 500KB, dan email Anda akan membuat mailboxnya mampet. Untuk mengirim file besar atau ke orang banyak, sebaiknya upload dulu ke situs web atau FTP, lalu cantumkan URL-nya di email Anda. Rekan-rekan Anda akan dapat memakai protokol HTTP dan FTP, yang mana adalah lebih baik dalam hal transfer file.
Sekilas ini nampak remeh, namun saya kenal ada orang yang sangat benci pada hal yang satu ini. Memang kalau sedang asyik reply-replyan, obrolan bisa ngalor-ngidul dari Jakarta ke Bogor. Pada saat-saat yang tepat, tahanlah diri untuk tidak segera mereply. Melainkan, luangkan sedikit waktu mengubah subjek. Atau kalau perlu jangan reply sama sekali dan buatlah thread baru kalau memang topik sudah berubah sama sekali. Biasanya aturan pengubahan subjek adalah:
Re: Ini sudah sampai Bogorkah?
Sudah (was Re: Ini sudah sampai Bogorkah?)
Atau sekalian memperpendek subjek sebelumnya:
Re: Ini sudah sampai Bogor atau masih di Jakarta sih?
Di Bogor (was Re: ini sudah sampai Bogor...)
Kebiasaan Anda mengganti subjek agar lebih sesuai akan berguna bagi mereka yang membaca arsip diskusi.
Ada sebagian pemakai veteran yang mencibir kalau seseorang memasang autoresponder/autoreply/vacation message. Memasang autoresponse langsung berarti tidak cool. Memang, umumnya email pribadi tidak perlu dipasangi autoresponse karena diragukan fungsinya. Ditambah lagi selalu saja ada orang yang mencoba memasang atau bahkan membuat sendiri skrip autoresponse yang terlalu naif. Sehingga mengakibatkan insiden-insiden memalukan seperti looping atau pesan berkali-kali ke milis. Seperti yang baru-baru ini terjadi di milis firebird-devel@lists.sourceforge.net, di mana 3000-lebih pesan autoresponse terkirim ke milis oleh sebuah skrip yang looping. Kalikan dengan sekian ratus jumlah anggota milis, dan hitung sendiri berapa bandwidth dan waktu yang terboroskan.
Lho, pikir Anda. Membuat autoresponse kan semudah menulis skrip yang mengambil header Reply-To si pengirim lalu mengirimkan email berisi “Terima kasih, maaf saya sedang tidak ada”; lalu menaruh skrip ini di .qmail atau .forward bukan? Salah. Ada beberapa aturan yang perlu diperhatikan autoresponse yang baik. Pertama, jangan mereply ke milis karena ini biasanya dianggap tidak sopan. Posting dari milis biasanya dapat dibedakan karena memiliki header Precedence: bulk. Kedua, tidak perlu mereply ke orang yang sama lebih dari satu kali. Cukup sekali sehari atau sekali seminggu misalnya. Berarti skrip autoresponse Anda perlu mengingat daftar pengirim dengan menaruhnya ke file/database misalnya. Ketiga, skrip harus menghindari looping. Artinya, pesan autoresponse yang dikirimkan skrip perlu diberi tanda—misalnya header X-Been-There—sehingga jika ternyata terkirim kembali ke kita maka skrip bisa tahu dan tidak mengirim ulang autoresponse. Jika tidak, maka akan menyebabkan looping, reaksi berantai, dan akhirnya ledakan jumlah email.
Selain tidak disengaja atau karena jam komputer memang rusak, ada sebagian orang sengaja mengubah tanggal yang tercantum di email. Alasannya? Pertama, ingin terlihat seperti pengirim dari luar negeri dengan mengubah zona waktu dari WIB ke EST misalnya. Sayangnya, kadang-kadang konsepnya salah. Misalnya, kalau sekarang tanggal 17 Sep 2002, 01:30 WIB (GMT+7) dan Anda ingin zona waktu Anda menjadi EST (GMT–5), maka seharusnya setelah mengubah waktu zona ke EST Anda juga memundurkan waktu 12 jam ke belakang menjadi 16 Sep 2002, 12:30. Karena memang di Amerika dan Kanada pada waktu tersebut jamnya masih sebegitu. Jika tidak, jam Anda akan tampil 12 jam terlalu cepat.
Kedua, dan ini merupakan salah satu bentuk abuse yang tidak sopan, karena si pengubah waktu ingin memanipulasi urutan penampilan pesannya di mailbox penerima. Misalnya, memajukan tanggal tepat 24 jam kemudian agar selalu tampil di paling atas. Atau bahkan tepat 20 tahun ke belakang agar tampil paling bawah tapi yang pertama dilihat. Modifikasi tanggal tampilan banyak dilakukan oleh spam.
Mengapa ini menjengkelkan? Karena beberapa program pengarsip akan jadi salah mengelompokkan pesan email ybs ke bulan bahkan tahun lain. Bagi penerima email pun menjengkelkan, karena ini merusak tampilan pengurutan di programnya. Beberapa orang malah terpaksa memodifikasi dulu email-email seperti ini lewat filter yang memanipulasi header Date di setiap email yang masuk.
Ini juga seharusnya sudah jelas, tapi ternyata banyak juga orang yang dengan sadar dan sengaja terus-menerus melakukan hal ini demi kepentingan dan kenyamanan diri pribadi. Dan agar tidak terlalu menjengkelkan, menempelkan pesan “Maaf bung admin, cross posting” atau “Numpang lewat, sori kalau cross posting” di awal email dengan harapan bisa terus-menerus dimaafkan. Ini sesuatu yang manipulatif dan juga kebiasaan buruk.
Lucunya lagi, kadang-kadang si cross poster sedikit rajin dengan membuat email terpisah untuk setiap pesannya. Misalnya, ia sebetulnya ingin cross posting ke milis-masterweb@yahoogroups.com dan toekangweb@yahoogroups.com. Tapi daripada harus menulis satu email, mencantumkan dua To, lalu mengembel-embeli pesannya dengan meminta maaf karena cross posting; dia membuat dua email yang persis sama. Berkat teknologi modern copy paste, hal ini tidak terlalu makan waktu.
Biasanya pesan yang dicross post adalah pertanyaan. Karena ingin cepat dapat jawaban, atau biar jawaban yang diterima lebih lengkap/bervariasi, maka ditempuhlah jalan tersebut.
Cross posting terutama membuat kesal orang-orang yang mengikuti dua atau lebih milis yang kebetulan dicross post, sehingga ia menerima email dobel-dobel. Dan bukan itu saja, kadang-kadang setting filter program email dapat salah memasukkan semua cross post ke folder satu milis saja dan milis lain jadi tidak “kebagian”.
Kadang-kadang dosa cross posting dilanjutkan dengan membuat balasan demi balasan yang cross posting pula, seolah satu cross post itu tidak cukup. Ini biasanya bikin gregetan sebagian orang di newsgroup.
Tindakan yang sopan adalah menghindari cross post sebisa mungkin. Cukup posting ke satu milis; jika tidak ada tanggapan baru teruskan pertanyaan Anda ke milis berikutnya. Jika posting Anda berupa pengumuman, juga pilihlah hanya satu milis yang paling relevan/mewakili. Jika memang pengumuman Anda penting, akan ada orang lain yang memforwardkannya ke milis lain. Setidaknya, kalau nanti penghuni milis lain tidak suka, si orang itu yang kena marah. Bukan Anda.
Kebiasaan ini berhubungan dengan nomor 7, dan biasanya dilakukan oleh orang-orang yang telah menganggap sebuah milis sebagai “tempat bertanya/support gratis.” Bahkan saking tidak tahu dirinya, sudah milis gratis dituntut cepat pula. Kalau tidak ada yang merespon posting mereka ke milis, maka mereka pun mengirimkannya kembali sehari kemudian, dua hari kemudian, dsb. Kadang-kadang disertai alasan gadungan “maaf, mungkin ada yang tidak baca” atau “maaf, mungkin tidak terkirim.” Padahal, milis umum adalah sarana komunikasi dan bertukar pendapat yang sifatnya suka rela. Siapapun tidak ada yang punya kewajiban untuk menjawab posting seseorang.
Di luar konteks milis pun, pengiriman ulang ini bisa membuat jengkel si penerima. Misalnya, jika dalam satu dua hari tidak ada balasan, si pengirim mengirim ulang sambil menyertakan alasan “takut Anda tidak terima.” Atau, jika si penerima punya dua alamat email, si pengirim selalu mengirimkan email ke kedua alamat dengan alasan “biar lebih yakin.” Perlu dicatat bahwa pada umumnya daemon email (MTA) sudah cukup andal. Jika pesan Anda sudah terkirim dan Anda tidak menerima bounce-nya, maka kemungkinan besar pesan tersebut sudah sampai ke tujuan atau sedang terus diusahakan oleh MTA untuk dikirim. Biasanya tunggulah hingga seminggu atau lebih sebelum mencoba mengirim ulang, karena memang itulah waktu rata-rata percobaan ulang sebelum MTA benar-benar menyerah. Juga, jika penerima punya lebih dari satu alamat email, tindakan yang lebih sopan adalah bertanya dulu ke alamat email yang mana sebaiknya email Anda tersebut dikirimkan. Membombardir semua alamat email yang ada tak ubahnya seperti melakukan spamming.
Kebiasaan yang satu ini masih berkaitan dengan milis. Kadang-kadang, jika sebuah milis yang relatif ramai tiba-tiba selama 1–2 hari sepi, maka ada seseorang yang merasa perlu melakukan pengiriman pesan tes ke milis. Dengan alasan “takutnya milis ini ngaco” atau “takutnya email saya error”. Ada beberapa alasan mengapa posting seperti ini lame.
Pertama, kalau email Anda error (tidak bisa menerima email) maka sebaiknya Anda pertama-tama melakukan tes pengiriman ke diri sendiri. Kenapa harus ke milis? Kedua, kalau Anda takut email Anda tiba-tiba ter-unsubscribe maka Anda sebaiknya mengecek subscription dengan mengirimkan kembali email subscription atau mengecek ke interface web milis (Yahoo! Groups atau milis-milis yang dimanage oleh Mailman sudah pasti memiliki interface web). Tidak perlu mengirim posting ke milis. Catat juga bahwa pada umumnya kalau email Anda memang bounce terus maka dibutuhkan waktu dua minggu hingga lebih dari sebulan sebelum program milis benar-benar mengeluarkan alamat Anda dari keanggotaan. Ketiga, kalau Anda hanya takut ada posting 1–2 hari yang terlewat atau belum sampai ke mailbox Anda, maka Anda sebaiknya mengecek dulu ke arsip web. Jangan langsung memposting ke milis dan bertes-tis ria.
Juga salah satu netiket yang seharusnya sudah jelas. Milis atau penerima tertentu kadang jelas-jelas tidak suka email HTML. Jadi Anda sebaiknya bisa menyesuaikan diri atau, lebih baik lagi, membiasakan mengirimkan format email teks polos saja sebisa mungkin.
Mengapa masih ada saja orang yang benci email HTML, padahal email tersebut “indah” dan mendukung berbagai macam format “warna-warni”? Pertama, email HTML biasanya lebih dua tiga kali besar (apalagi kalau mengandung gambar, entah itu background, kop surat, dsb). Padahal isi pesannya sama saja dan sering sekali pemformatan HTML itu tidak benar-benar perlu. Kedua, email HTML tidak bisa dibaca di semua program pembaca email. Ketiga, email HTML memaksakan penampilan tertentu pada sebuah email, seperti jenis font atau warna; padahal seringkali orang ingin membaca email dengan warna, jenis, ukuran font kesukaannya. Keempat, email HTML berbau spam, sebab banyak sekali spam yang berbasiskan HTML.
Kebiasaan ini menunjukkan pada orang bahwa si pengirimnya seolah hanya tahu tekan Reply (karena rata-rata milis mengeset Reply-To kembali ke milis) dan tidak tahu bagaimana harus mengemail orang/moderator secara pribadi dengan mengambil alamat email dari header email secara manual.
Beberapa contoh yang umum: 1) Mengalami kesulitan unsubscribe/set digest sehingga posting ke milis dan memelas/marah-marah “bagaimana caranya unsubsribe[sic]?” (Apakah tidak membaca pesan bantuan saat diterima sebagai anggota milis? Tentu tidak.) 2) Begitu terjadi looping autoresponse, ada yang mengebom, menyepam, atau melakukan pelanggaran aturan milis, langsung posting balik ke milis dan bertanya “Bagaimana nih, Bung Admin?” (Seharusnya setidaknya mengirim email kepada moderator dulu). 3) Ngobrol di milis dengan seorang peserta lain (Seharusnya, begitu topik diskusi tidak lagi relevan dengan milis, bawalah diskusi Anda ke jalur pribadi).
Ini juga salah satu fitur yang sering membuat orang jengkel. Setiap ingin menutup program email, atau bahkan setiap ingin menutup window email si pengirim, si penerima akan mendapat kotak dialog peringatan bahwa “si pengirim minta diberitahu Anda sudah baca email ini.” Selain kotak-kotak dialog ini mengesalkan, return receipt juga dirasakan oleh sebagian penerima mengganggu privasi. Salah satu ciri khas email dibandingkan IM atau chat adalah sifatnya yang tidak real time dan terasa seperti surat-menyurat. Kita bebas kapan saja ingin membaca (kalau memang ingin membacanya) maupun membalas (kalau memang ingin membalasnya). Pihak pengirim tidak perlu tahu apakah kita sudah membacanya atau belum.
Jika Anda memang merasa butuh sekali meminta return receipt, setidaknya set-lah hanya kepada orang tertentu. Jangan secara default meminta return receipt kepada semua orang.
Kadang-kadang orang meminta return receipt secara “manual.” Setiap mengirim email, ia menuliskan “Reply ya kalau sudah terima.” Kalau untuk pacar mungkin oke-oke saja. Tapi bagi sebagian orang ini ternyata bisa cukup mengesalkan. “Ya kalau saya ingin jawab ya bakal saya jawab, kalau tidak ya tidak,” begitu mungkin di benak si penerima.
Juga sebuah netiket yang seharusnya jelas, tapi karena banyak sekali orang yang tidak tahu cara menulis subjek dengan baik, rasanya perlu dijelaskan kembali di sini.
Pemilihan subjek amat sangat penting dalam sebuah email. Subjek yang baik haruslah spesifik mencerminkan isi email. Dengan selalu menulis subjek yang spesifik, Anda telah membantu satu atau bahkan ratusan orang menghemat beberapa detik waktu mereka. Setiap email yang bersubjek terlalu umum seperti “Tanya nih” atau “Minta informasi” akan memboroskan beberapa detik waktu setiap pembaca email tersebut.
Salah satu patokan saya dalam memilih subjek yaitu dengan berusaha menuliskan seluruh inti pesan saya ke dalam subjek. Jika memang pesannya sudah bisa terwakili semua di subjek, ya sudah, bodi saya biarkan kosong. Jika tidak barulah bodi bicara. Contoh, subjek “jangan lupa meeting jam 15.00” sudah bisa mewakili seluruh pesan jadi bodi saya kosongkan. Demikian pula “Tadi ke mana?” atau “Saya sudah beli RAM-nya.” Anggap saja Anda sedang menulis SMS. Kalau 10-20% email Anda sudah bisa ditulis hanya dengan subjek saja, maka itu menurut saya sesuatu yang bagus. Tentu saja, pesan ke milis biasanya harus lebih spesifik dan mendetail. Tapi tetap jangan lupakan subjek yang spesifik. Pikirkan mereka-mereka yang akan membaca arsip milis.
Rata-rata program email biasanya mengerti header X-Priority. Sayang sekali, tidak ada konsensus pesan-pesan seperti apa saja yang perlu dikategorikan high priority atau bahkan highest. Apa yang menurut Anda gawat atau penting belum tentu demikian di mata penerima email. Apalagi jika Anda sering-sering memberi atribut prioritas tinggi kepada email Anda, maka itu akan semakin menjengkelkan penerima dan bahkan membuat si penerima berkesimpulan pesan-pesan Anda tidak ada yang penting.
Wah, ternyata ada begitu banyak aturan tak tertulis. Kok saya tidak pernah baca? Kok tidak ada yang memberi tahu saya sebelumnya? Begitu mungkin Anda berkata. Memang, yang namanya aturan tidak tertulis ya biasanya tidak tertulis. Dan perlu diperhatikan pula bahwa lain lubuk lain belalang. Mungkin saja ada aturan tak tertulis lain di sebuah milis atau komunitas yang mana Anda dituntut untuk mematuhinya. Bagi saya pribadi, selain semua kebiasaan-kebiasaan di atas, ada satu lagi yang entah mengapa bagi saya menjengkelkan: “Menulis ‘minta pencerahannya dong!’ di akhir email.” Tentu saja, untuk yang satu ini Anda tidak dituntut mematuhinya. (sh)
mw
[Last-Modified: Fri Nov 29 14:46:08 2002]
| Arsip mwmag | [Files] [Up] | www.master.web.id/mwmag |