Apa retort kanonik untuk "itu open source, kirim tambalan"? [Tutup]

215

Bahaya dari pernah menyarankan beberapa fitur pada suatu produk, terutama open source, adalah bahwa Anda akan mendapatkan respons, "mengapa Anda tidak melakukannya?".

Itu valid, dan itu keren bahwa Anda dapat melakukan perubahan sendiri. Tetapi kita tahu secara praktis bahwa produk sering kali meningkat ketika programmer mendengarkan suara pengguna - bahkan jika pengguna tersebut adalah programmer lain. Dan, cara yang efisien untuk melakukan perubahan itu dapat mencakup seseorang yang sudah bekerja pada proyek yang mengambil ide dan mengimplementasikannya.

Ada beberapa istilah umum yang digunakan untuk merujuk pada masalah pengembangan perangkat lunak. misalnya Bikeshedding . Apakah ada istilah umum yang digunakan yang pada dasarnya menjawab, "Ya, saya tahu bahwa saya dapat mengubah apa saja di dunia - bahkan sumber tertutup. Saya bisa dipekerjakan, dan menulis kode itu. Tetapi dalam kasus ini saya hanya membuat sebuah pengamatan yang mungkin sebenarnya berguna untuk pembuat kode lain yang sudah cocok untuk dengan mudah melakukan perubahan itu - atau hanya mendiskusikan kemungkinan secara umum. "

[ps (beberapa hari kemudian) - Seharusnya saya menunjukkan bahwa "kirimkan tambalan" sering dikatakan dengan humor masam, dan saya mencari respons jenaka yang tepat.]

Vincent Scheib
sumber
16
Saya berharap saya dapat memperbaiki ini lebih dari sekali! (Dan itu datang dari seseorang yang telah mengirimkan tambalan ke beberapa proyek yang berbeda dan membuatnya diterima. Sikap yang Anda gambarkan itu benar-benar menjengkelkan!)
Mason Wheeler
62
Saya kira, "Seperti apa rupa saya, monyet kode pengangguran? Saya punya kehidupan!" bukan retort yang dapat diterima ;-)
Steven A. Lowe
12
Dalam pengalaman saya, jawaban "kirim tambalan" biasanya muncul setelah pengembang menjelaskan mengapa menambahkan fitur tidak praktis.
user16764
7
@ Seven, tergantung pada Anda hanya ingin puncak penghinaan, atau benar-benar membuat mereka melakukan apa yang Anda butuhkan. Saya percaya ini bukan strategi yang optimal jika Anda menginginkan yang terakhir.
12
@orokusaki: Atau D) Mereka menganggap fitur tersebut kurang berharga daripada fitur lain yang bisa mereka kerjakan, dan mereka memiliki sumber daya yang terbatas.
David Thornley

Jawaban:

115

Ini poin yang sulit: karena pengguna tidak secara langsung atau tidak langsung membayar suatu produk, ia tidak dapat meminta fitur untuk diimplementasikan. Bukannya Anda pemegang saham atau pelanggan langsung yang memesan produk, dan bahkan bukan pengguna akhir produk komersial.

Makhluk ini berkata, "kirimkan tambalan" bukan jawaban yang valid. Itu tidak sopan. Itu tidak benar. Bahkan untuk produk sumber terbuka. "Kirim tambalan" adalah versi singkat dari:

"Kami tidak peduli apakah Anda menyukai produk kami atau tidak. Pergi dan modifikasi jika Anda mau, tapi jangan ganggu kami dengan permintaan pelanggan Anda."

Bagaimana dengan mengirim tambalan?

Yah, itu tidak mudah. Untuk melakukannya:

  • Anda harus tahu bahasa yang digunakan dalam proyek sumber terbuka.

  • Anda harus dapat memuat kode sumber dari kontrol versi untuk dapat memodifikasinya.

  • Anda harus memiliki semua versi yang benar dari dependensi build apa pun yang diinstal (termasuk pustaka runtime dan tools build).

  • Anda harus dapat mengkompilasi kode sumber ini , yang dalam beberapa kasus tidak begitu jelas. Terutama, ketika sebuah proyek besar membutuhkan beberapa jam untuk mengkompilasi dan menampilkan 482 kesalahan dan ribuan peringatan, Anda mungkin berani untuk pergi dan mencari sumber kesalahan tersebut.

  • Anda harus memahami dengan baik bagaimana proyek dilakukan , apa gaya pengkodean yang digunakan, jika ada, cara menjalankan tes unit, dll. Jika proyek tidak memiliki dokumentasi yang layak (yang sering terjadi pada proyek sumber terbuka ), mungkin sangat sulit.

  • Anda harus menyesuaikan diri dengan proyek dan dengan kebiasaan pengembang yang berpartisipasi aktif dalam proyek. Misalnya, jika Anda menggunakan .NET Framework 4 setiap hari, tetapi proyek tersebut menggunakan .NET Framework 2.0, Anda tidak bisa menggunakan LINQ, atau Kontrak Kode, atau ribuan fitur baru lainnya dari versi terbaru kerangka kerja.

  • Tambalan Anda harus diterima (kecuali jika Anda melakukan perubahan hanya untuk diri sendiri, tanpa bermaksud membaginya dengan komunitas).

Jika niat Anda adalah untuk berpartisipasi aktif dalam proyek, maka Anda dapat melakukan semua hal itu dan menginvestasikan waktu Anda untuk itu. Jika, di sisi lain, hanya ada bug minor yang mengganggu atau fitur sederhana yang hilang, menghabiskan berhari-hari, berminggu-minggu atau berbulan-bulan mempelajari proyek, maka melakukan pekerjaan itu sendiri dalam beberapa menit tidak masuk akal, kecuali Anda menyukainya.

Jadi apakah ada retort kanonik untuk "itu open source, kirim tambalan"? Saya kira tidak. Entah Anda menjelaskan kepada orang itu bahwa dia tidak sopan, atau Anda hanya berhenti berbicara dengannya.

MainMa
sumber
9
Kedengarannya seperti ini ditulis oleh seseorang yang tidak memiliki pengalaman memelihara proyek open source.
Rein Henrichs
46
@Rein: Mempertahankan proyek sumber terbuka tidak berbeda dengan mempertahankan proyek lain mana pun. Anda memiliki pelanggan. Jika Anda mengabaikan pelanggan itu, mereka akan berhenti memberi Anda umpan balik yang berharga, dan mereka akan pergi ke tempat lain untuk solusi mereka. Mungkin itu baik-baik saja dengan orang-orang open source, tetapi saya ingin tahu apakah saya akan benar-benar bertanggung jawab untuk membuat perbaikan bug pada perangkat lunak open source, karena itu akan membuat saya berpikir dua kali untuk menggunakannya.
Robert Harvey
17
@Rein: Sejauh ini saya sudah mendengar Anda mengatakan dua kali bahwa kita tidak tahu apa yang sedang kita bicarakan. Mungkin Anda bisa mencerahkan kami, eh?
Robert Harvey
8
@Rein Henrichs: Dua komentar pertama Anda adalah serangan '' ad hominem ''. Jika ada perbedaan di antara keduanya, katakan apa adanya, daripada mengatakan bahwa orang lain tidak tahu apa-apa.
Andrew Grimm
13
Saya menduga maksudnya adalah "Mempertahankan proyek open source tidak berbeda dengan mempertahankan proyek lain dalam hal mendengarkan umpan balik pelanggan dan menjaga itikad baik mereka." Jika demikian, saya sepenuhnya bersedia untuk membatalkannya tetapi, sebagai seseorang yang telah memelihara beberapa proyek FOSS dengan mulai dari segelintir hingga ratusan kontributor, saya menemukan pernyataan selimut asli "salah".
Rein Henrichs
79

Retort kanonik adalah untuk mengirimkan tambalan.

tanya
sumber
47
Atau lebih baik lagi, untuk mengatakan, "Saya sudah melakukannya enam bulan yang lalu. Kapan kalian akan meninjau dan melakukan itu?"
Bob Murphy
14
Saya biasanya tidak menyukai jawaban pendek, tetapi ini adalah satu-satunya cara untuk merespons yang dijamin akan mengakhiri hasil yang Anda cari. Mereka dengan jelas menyatakan cara terbaik untuk mencapai tujuan Anda. Mengapa bercinta dengan solusi yang lebih rendah?
19
-1 jawaban brengsek open source. Tidak berguna. (Maaf.) Tidak ada "retort" kanonik. Respons terbaik (dengan asumsi OP tidak bisa hanya mengirimkan tambalan, yang menurut saya merupakan asumsi yang masuk akal dalam kasus ini) adalah salah satu dari (1) "Saya tidak memiliki kemampuan atau sumber daya untuk menghasilkan tambalan [dan mungkin termasuk tautan ke pertanyaan ini] ", (2) eyeroll, tidak ada respons, penggunaan alat dalam kondisi saat ini, atau (3) mencari alat yang lebih baik.
JohnL4
1
Itu tidak harus menjadi tambalan. Memberikan umpan balik yang terperinci dan halus juga bernilai. Semua ini mengatakan, jangan berharap saya menginvestasikan waktu saya untuk memenuhi kebutuhan spesifik Anda jika Anda tidak memiliki apa-apa untuk ditawarkan sebagai imbalan.
Evan Plaice
67

Ini adalah jawaban standar ketika pengembang tidak berpikir mereka akan melakukan sesuatu dalam jangka waktu yang masuk akal, tetapi sudah berulang kali muncul.

Ini paling tidak adil ketika sudah berulang kali dibesarkan, tetapi orang yang baru-baru ini disebutkan tidak tahu itu, dan hanya mendapat "kami sedang mengambil tambalan untuk itu" segera. Dalam hal ini pengelola sudah muak dengan diskusi tetapi pengguna menganggap itu topik baru. Bagaimanapun, kemungkinan besar jika Anda mendapatkan "mengambil tambalan" segera, Anda tidak boleh mengambilnya secara pribadi tetapi mungkin ingin membaca arsip dan pelacak bug untuk rincian lebih lanjut tentang masalah ini.

Jika Anda berulang kali mengajukan permintaan sendiri, "mengambil tambalan" berpotensi dimaksudkan untuk menjadi relatif tidak sopan, vs. beberapa alternatif yang kurang sopan ...

Dan tentu saja ada pengelola kasar yang akan mengatakan "mengambil tambalan" tanpa penjelasan kepada siapa pun, tapi saya akan mengatakan itu minoritas.

Jika Anda pernah memelihara proyek open source dengan banyak pengguna, Anda akan tahu bahwa ada 100x lebih banyak permintaan daripada yang bisa didapat oleh pengelola, dan banyak dari permintaan itu penting bagi pemohon tetapi akan sangat sulit, atau akan mengganggu banyak pengguna lain, atau memiliki cacat lain yang hanya terlihat dengan pemahaman global tentang proyek dan basis kode. Atau kadang-kadang hanya ada panggilan penilaian, dan butuh terlalu banyak waktu untuk berdebat setiap orang berulang kali.

Sebagian besar perusahaan non-open-source tidak akan memberi Anda akses ke pengembang sama sekali, dan Anda hanya akan mendapatkan perlakuan diam atau cerita yang sopan tapi palsu dari dukungan pelanggan. Jadi, dalam open source setidaknya Anda memiliki beberapa opsi (membayar seseorang untuk mengkodekan fitur, dll.) Dan sementara pengembang mungkin kasar, setidaknya mereka memberikan jawaban langsung. Saya lebih suka "tidak" daripada biasanya "itu ada di peta jalan kita ... [2 tahun kemudian] ... itu masih ada di peta jalan kita" semacam hal yang saya dapatkan dari sejumlah vendor ...

Jadi saya tidak berpikir ada jawaban. Mungkin pengelola open source sangat sibuk, mungkin mereka brengsek, tapi bagaimanapun, mereka mungkin memiliki pekerjaan yang sulit dan masuk ke dalam debat yang memiliki kata terakhir tidak terjadi di mana-mana. Yang terbaik yang dapat Anda lakukan adalah berkontribusi dalam beberapa cara dan berusaha bersikap konstruktif.

Mungkin ini bukan kode, tapi mungkin ada banyak analisis dan dokumentasi skenario pengguna yang bisa Anda lakukan. Ketika saya memelihara window manager GNOME, sering kali akan sangat membantu jika orang menganalisis masalah secara global dengan mempertimbangkan semua pengguna, dan benar-benar menuliskan masalah dan pro dan kontra dan apa yang harus terjadi dari perspektif global.

(Sebaliknya, hal yang biasa adalah mulai menyala seolah-olah mereka adalah satu-satunya pengguna yang penting dan tidak ada pengorbanan. Dan sementara itu hebat, dan merupakan titik data, dan seringkali saya berhasil tetap sopan atau bahkan menyelesaikan masalah mereka pada akhirnya .. "Menyala tidak membuat sesuatu terjadi lebih cepat. Itu hanya membingungkan emosi ke dalam masalah dan membuang waktu semua orang."

Havoc P
sumber
4
@Aronaught Saya sudah ada di sekitar ratusan proyek sumber terbuka dan belum melihat DIY sebagai respons default. Ini merupakan respons terhadap rasa permintaan tertentu.
Havoc P
2
Yang saya katakan adalah, saya pikir lebih sering daripada tidak, ada beberapa alasan seorang pengelola setidaknya sedikit muak dengan suatu topik (atau orang) sebelum mereka mengatakan "mengambil tambalan," dan mungkin ada baiknya mencari tahu mengapa Anda mendapat jawaban itu. Ini pengalaman saya, fwiw. Jika pertanyaannya di sini adalah tentang kasus-kasus di mana tidak ada alasan untuk muak dengan topik atau orang tersebut, maka tentu saja, "mengambil tambalan" mungkin bukan hal yang hebat untuk dikatakan oleh pengelola. Orang-orang membuat kesalahan. Saya masih mengatakan, saya ragu jawaban (atau meta-diskusi seperti ini) akan membantu, tetapi melibatkan secara konstruktif kadang-kadang mungkin.
Havoc P
5
Selain itu, walaupun dapat diutarakan lebih atau kurang dengan sopan, jika seorang pengelola memiliki tumpukan pekerjaan dalam pikiran mereka, mereka mungkin memiliki 1 hal yang dapat mereka peroleh sendiri, untuk setiap 100 hal yang akan mereka tempuh karena mereka menginginkan fitur; dan kemudian ada kategori perubahan lain yang akan mereka tolak bahkan jika orang lain melakukan pekerjaan itu. Jadi harus ada cara untuk berkomunikasi, "Saya akan mengambil perubahan itu, tetapi tidak punya rencana untuk melakukannya sendiri." Beberapa orang di sini tampaknya merasa bahwa "Tentu, segera datang" adalah satu-satunya jawaban yang dapat diterima. Tapi "mengambil tambalan itu" adalah kategori nyata.
Havoc P
2
@Aonaona memang terdengar seperti ungkapan yang bagus. Saya pikir sering kali tidak ada pelanggaran / kekasaran yang dimaksudkan oleh "kami akan mengambil tambalan untuk itu," tetapi programmer tidak biasanya tipe yang paling sensitif secara emosional, mungkin bergegas melalui email, dan nada tidak menyampaikan melalui teks dengan sangat baik, jadi mudah untuk menemukan secara singkat.
Havoc P
2
Sebenarnya, "kami akan mengambil tambalan untuk itu" berbeda dalam dua cara halus namun penting: (1) tidak menempatkan tanggung jawab langsung pada pengguna , dan (2) ia mengakui bahwa permintaan telah dipertimbangkan secara serius meskipun tidak ada diimplementasikan. Meskipun hasil bersih pada dasarnya sama, itu adalah jawaban yang jauh lebih manusiawi. (Tetap saja, tidak ada salahnya untuk menambahkan secara tersirat ... tapi kami tidak memiliki sumber daya untuk menyelesaikannya sendiri saat ini. )
Aaronaught
43

Alasan Anda mendapatkan respon ini bukan bahwa pengelola tersentak, itu bahwa Anda belum cukup meyakinkan mereka dari proposisi nilai mereka bekerja pada Anda fitur untuk Anda .

Respons terbaik adalah memulai dialog tentang nilai fitur Anda kepada komunitas mereka secara keseluruhan , untuk melihat apakah Anda dapat meyakinkan mereka untuk mengubah pikiran mereka. Mungkin mereka benar dan mereka tahu lebih banyak tentang kebutuhan komunitas mereka sendiri daripada Anda - tetapi, sekali lagi, mungkin tidak.

Jika fitur ini hanya berharga bagi Anda dan sedikit atau tidak ada nilainya bagi komunitas, saya menemukan bahwa uang adalah motivator yang sangat baik, sementara mengeluh tentang sikap mereka tidak.

Rein Henrichs
sumber
15
Tentu saja, mungkin mereka brengsek. Tanggapan ini saja bukan indikator yang sangat akurat, karena juga digunakan oleh non-sentakan ketika penanya adalah brengsek.
Rein Henrichs
4
Saya juga ingin menambahkan bahwa dengan tidak adanya uang, Anda sering dapat berdagang dalam bentuk barang untuk beberapa pekerjaan: membantu menentukan masalah antrian yang sibuk, bergaul di saluran IRC dan memberikan dukungan, patch pengujian, atau menulis dokumentasi. Proyek sumber terbuka memiliki sumber daya yang terbatas dan perlu memanfaatkan yang terbaik dari mereka. Menambahkan fitur layak jika penting bagi cukup banyak orang, atau penting bagi orang yang cukup / memberi. Jika kasing Anda bukan yang pertama, buat yang terakhir.
HedgeMage
2
Jujur, cara terbaik untuk meyakinkan pengembang adalah dengan menunjukkan kepadanya seberapa banyak basis penggunanya yang menginginkan fitur tersebut. Bugtracker dengan voting, utas forum, dll. Semuanya sangat bagus untuk ini, dan digunakan dalam banyak proyek open source.
ProdigySim
4
Demikian pula, ketika orang mendapatkan RTFM atau DAFS sebagai jawaban, atau -1 pada SE, itu karena si penanya belum memadai yakin penjawab dari proposisi nilai menjawab mereka pertanyaan untuk mereka . Saya yakin banyak dari Anda yang bisa merasakan perasaan ini.
Rein Henrichs
1
@Walter Yep, itulah sebabnya saya menyarankan meyakinkan orang "nilai fitur Anda kepada komunitas mereka secara keseluruhan".
Rein Henrichs
31

Apa retort kanonik untuk "itu open source, kirim tambalan"?

Tidak ada jawaban yang masuk akal yang kemungkinan akan membuat perbedaan. Mencoba membujuk sukarelawan untuk melakukan sesuatu yang mereka tidak berniat lakukan adalah buang-buang waktu ... atau lebih buruk.

Pilihan Anda adalah:

  • Lakukan apa yang disarankan oleh respons; yaitu mengimplementasikan fitur dan mengirimkannya sebagai tambalan. Ini disebut "memberikan sesuatu kembali".

  • Temukan seseorang yang bersedia menerapkan fitur untuk Anda dengan uang sungguhan. Bisa jadi proyek itu sendiri (misalnya dengan imbalan sponsor), seseorang yang terkait dengan proyek, atau "pembuat kode acak" yang disewa.

  • Temukan produk alternatif.


Jika Anda menerima respons ini ketika Anda membuat saran "membantu", pertimbangkan bagaimana Anda mungkin merespons jika Anda siap. Misalnya, bagaimana tanggapan ANDA jika Anda berpikir bahwa saran tersebut tidak bermanfaat / dipikirkan dengan baik / dimengerti / dll, tetapi tidak memiliki waktu atau kesabaran untuk terlibat dalam debat yang berlarut-larut?


Saya telah terlibat dalam proyek OS open source yang sudah berjalan lama, dan salah satu hal yang paling menyebalkan adalah orang-orang yang duduk di "galeri kacang" dan memberi Anda saran tentang melakukan hal-hal "lebih baik" yang:

  • tidak lengkap, tidak dapat dimengerti atau benar-benar tidak masuk akal,
  • adalah ide yang belum dicoba dengan peluang keberhasilan yang rendah,
  • akan membutuhkan sejumlah besar upaya untuk mengimplementasikan, dan / atau
  • bertentangan dengan tujuan proyek yang dinyatakan.

Seringkali respons terbaik adalah dengan menantang orang tersebut untuk terlibat dalam proyek ... dan berharap mereka mengambil petunjuk ... untuk "tutup mulut atau tutup mulut". Sayangnya, yang paling menyebalkan bahkan tidak memberi petunjuk.

Tentu saja, respons lain terhadap orang-orang semacam itu adalah tidak merespons sama sekali, atau mengabaikan mereka sama sekali.

Stephen C
sumber
7
"Bagaimana tanggapan ANDA jika Anda berpikir bahwa saran itu tidak bermanfaat / dipikirkan dengan baik / dimengerti / dll" - persis bagaimana setiap profesional lain merespons. "Bisakah kamu menjelaskan / memberikan beberapa contoh dari apa yang kamu minta?" atau "Bisakah Anda memberi saya alasan mengapa Anda memerlukan fitur ini?" atau "Bagaimana jika kita melakukan hal lain ini, apakah itu akan berhasil untuk Anda?" atau bagaimana dengan "Terima kasih atas saran Anda, kami akan mempertimbangkannya untuk rilis mendatang." Ini adalah keterampilan dasar interpersonal, bukan ilmu roket.
Aaronaught
12
@Aaronaught - Maaf, tapi Anda tidak mengerti. Pengembang open source yang khas tidak memiliki waktu untuk terlibat dalam diskusi yang sopan tetapi pada akhirnya tidak ada gunanya yang bertujuan mengelus ego "pelanggan" -nya; yaitu berpura-pura peduli, ketika orang yang setengah cerdas dapat mengetahui bahwa itu semua adalah fasad. Dan jujur ​​saja, saya menemukan ego semacam itu membelai kesopanan untuk menjadi pelindung ... dan LEBIH menyinggung daripada diberitahu terus terang bahwa tidak ada kesempatan mereka akan menerapkan XYZ.
Stephen C
6
@ Kurige - sebenarnya, jika orang yang bersangkutan DID mengirimkan tambalan, mereka PASTI akan dipertimbangkan. Masalahnya adalah bahwa orang-orang yang dimaksud adalah "semua mulut"; yaitu tidak tertarik untuk melakukan usaha apa pun.
Stephen C
10
Karena pengembang open source pada umumnya sudah memiliki pekerjaan, dan mereka melakukan pengembangan open source untuk bersenang-senang. Melakukan apa yang orang lain ingin Anda lakukan adalah bekerja. Melakukan apa yang ingin Anda lakukan itu menyenangkan.
ProdigySim
8
@Aaronaught: Apakah perlu memperlakukan banyak brengsek dengan hormat? Diberikan layanan publik, akan ada orang yang membuat tuntutan yang tidak masuk akal, seringkali dalam bentuk penghinaan. Berurusan dengan orang-orang bodoh yang tidak sopan bisa jadi sangat menyakitkan. Persyaratan untuk menghormati mereka akan membuat banyak orang keluar dari bisnis F / OS, dan itu akan menjadi kerugian bagi semua orang.
David Thornley
20

Jawabannya akan masuk akal jika Anda dan programmer yang dimaksud adalah sama, dan tahu hampir sama tentang basis kode dan bahasa dan semua hal lain yang relevan dengan hal khusus yang Anda tunjukkan.

Anda tidak setara (atau Anda mungkin hanya akan melakukannya) jadi saya akan menyarankan retort yang tepat menjadi:

"Tidak mungkin aku bisa melakukannya secepat dan sebaik yang kamu bisa, itulah sebabnya aku memintamu untuk membantuku sejak awal. Tolong!"

Saya percaya bahwa bertentangan dengan sifat dasar manusia untuk mengatakan "oh, ya, hal ini telah lama saya habiskan dan sangat bagus, sangat sederhana sehingga siapa pun dapat masuk dari jalan dan melakukan pekerjaan sebaik Saya bisa ".

user1249
sumber
Tapi bukan itu yang mereka katakan. Mereka mengatakan "hal yang Anda inginkan bukanlah sesuatu yang diinginkan komunitas, jadi kami tidak benar-benar tertarik untuk mengerjakannya. Kami mungkin menerima tambalan jika Anda ingin mengerjakannya." Tersirat adalah "kita mungkin juga berubah pikiran jika komunitas menginginkannya." Ingat bahwa "Saya ingin Anda membantu saya " bertentangan dengan sifat dasar dari proyek-proyek open source , di mana (untuk membawa kekuatan penuh Star Trek saya untuk menanggungnya), kebaikan banyak orang selalu melebihi kebaikan beberapa orang.
Rein Henrichs
Ya, kecuali beberapa dari mereka punya banyak uang, secara historis.
Rein Henrichs
2
@Rein, tidak, apa yang mereka katakan adalah MEREKA tidak ingin melakukannya. Semua ini "komunitas inginkan" hanyalah manusia jerami. Intinya adalah bahwa satu dari MASYARAKAT memintanya.
1
"Sangat tidak sopan untuk menyarankan menulis tambalan jika Anda tidak tahu sebelumnya bahwa - jika itu datang - Anda akan mempertimbangkannya untuk produk Anda." Sepakat. Seperti yang saya katakan, inilah mengapa saya tidak menggunakan respons ini. Saya bisa bersimpati dengannya. "Jika Anda dengan tulus mengatakan bahwa" mengirim tambalan "dimaksudkan untuk membuat orang tutup mulut daripada mendelegasikan pekerjaan, maka Anda setuju bahwa ini diminta oleh anggota komunitas dan bukan pengembang." Saya tidak begitu yakin apa yang Anda katakan di sini, maaf.
Rein Henrichs
1
@ Thorbjørn Ah ya. Sebenarnya, pengelola open source yang saya kenal tentu tidak berpikir seperti itu. Faktanya, kami berusaha keras untuk menyediakan panduan dan dokumentasi pengembang untuk membantu orang mempelajari proyek dan konvensi untuk berkontribusi secara tepat karena kami menyadari kesenjangan keterampilan. Misalnya, rubini.us/doc/en/contributing
Rein Henrichs
16

Retort kanonik adalah untuk memotong proyek.

pengguna16764
sumber
8
atau kirim tambalan
Kamil Szot
2
Apa gunanya forking membawamu?
1
@ Torbjorn: Semua orang bisa menggunakan garpu yang baik sekarang dan lagi. Bahkan garpu kasihan.
user18014
15

Jawaban kanonik untuk "kirim tambalan" adalah:

"Aku tidak memiliki keterampilan, pengalaman, atau waktu yang diperlukan, bisakah tolong katakan padaku di mana aku harus mengirimkan bir kepada orang yang bisa melakukannya untukku?"

gbjbaanb
sumber
13

Kirim kasus uji komprehensif .

alecco
sumber
1
Saya suka yang ini, meskipun demikian, seringkali membutuhkan waktu lebih lama daripada mengirimkan tambalan itu sendiri! Konstanta di sini adalah waktu untuk membiasakan diri dengan basis kode dan kemungkinan bagian terbesar dari membuat tes atau menulis tambalan secara langsung!
Newtopian
1
Saya suka jawaban ini untuk bug. Bahkan jika Anda tidak memahami kerangka kerja yang cukup untuk mengirim perbaikan, ini menghemat banyak waktu bagi seseorang yang melakukannya. Tidak ada yang kurang mungkin membuat saya memperbaiki masalah selain "bug" yang tidak jelas dan tidak dapat diproduksi yang mungkin hanya merupakan sistem yang tidak terkonfigurasi. Tidak ada yang membuat saya melompat pada masalah lebih cepat daripada testcase sederhana sehingga saya dapat dengan cepat mencoba berbagai perbaikan.
BobMcGee
11

"Jika kamu melakukannya, aku akan memasukkannya" jauh lebih baik daripada "tidak."

Jika Anda tidak dapat melakukan pekerjaan karena satu dan lain alasan, jelaskan situasinya kepada pengelola proyek secara pribadi.

Jika Anda tidak mau berkontribusi dalam beberapa cara ke proyek open-source yang ingin Anda gunakan, maka Anda harus mencari dukungan komersial atau produk komersial lainnya.

yfeldblum
sumber
5
Jadi hanya mereka yang berkontribusi secara langsung memiliki hak untuk mengeluh tentang bug atau fitur yang hilang? Baik, saya kira, tetapi itu juga berarti bahwa baik kontributor maupun pengguna tidak memiliki hak untuk mengeluh tentang kurangnya adopsi.
Aaronaught
@Aaronaught Tidak, mereka memiliki hak untuk mengeluh, tetapi ada batasan jumlah waktu yang tidak dibayar yang dapat diinvestasikan pengembang dalam suatu proyek dan penting bagi pengguna untuk mengenali hal ini. Dalam pekerjaan saya sendiri, saya mencadangkan "Saya akan menyambut permintaan tambalan / tarik" untuk fitur-fitur yang memiliki proposisi nilai upaya / komunitas yang buruk. Atau di mana pengguna bersikeras mereka mendapatkan fitur SEKARANG JUGA dan tidak menghormati waktu orang lain atau komitmen proyek lainnya.
BobMcGee
10

"Terima kasih atas tanggapannya."

Karena:

  • Dengan harga nol, permintaan (permintaan fitur) melebihi pasokan (coders yang tersedia untuk mengimplementasikan fitur tersebut).
  • Menyeret apa pun yang disediakan gratis tidak memiliki IMHO kelas.
  • Inilah inti dari FOSS: orang-orang membawa sayuran dan daging mereka sendiri untuk menambah nutrisi pada sup batu. Jika saya tidak dapat menyumbangkan sesuatu, maka saya harus bersyukur bahwa saya dapat makan sama sekali, dan tidak mengeluh bahwa saya tidak makan lebih baik.
John
sumber
9

Anda tidak perlu mengatakan apa-apa. Fakta bahwa pengembang telah merespon adalah indikasi yang cukup bahwa mereka sudah tahu masalah itu ada dan itu menyebabkan rasa sakit bagi (setidaknya beberapa) pengguna.

Pada akhirnya, tidak ada yang Anda katakan akan meyakinkan pengembang untuk bekerja untuk Anda jika mereka tidak mau.

Dean Harding
sumber
9

Proyek open source yang bagus akan memiliki sistem permintaan bug / fitur di mana pengguna dapat mengirimkan bug / fitur dan orang lain dapat memilih mereka sehingga pengelola dapat mengidentifikasi apa yang penting bagi komunitas secara keseluruhan. Namun cara tercepat untuk mendapatkan fitur Anda adalah dengan mengirimkan tambalan untuk itu. Periode ... tidak ada jalan lain.

Michael Brown
sumber
8

Secara pribadi, saya lebih suka mendapat jawaban dari "Ini adalah masalah yang diketahui, tetapi sayangnya ini bukan masalah yang akan segera dibahas. Pengembang sedang mengerjakan masalah lain. Tidak ada ETA saat ini."

Respons "kirim tambalan" sangat kasar, karena mengasumsikan beberapa hal:

  1. Semua pengguna program adalah pemrogram atau semua pelapor bug adalah pemrogram.
  2. Semua programmer tahu bahasa programnya.
  3. Semua programmer tahu tentang setiap jenis masalah yang mungkin dimiliki oleh program apa pun.
  4. Semua programmer memiliki waktu luang untuk mengerjakan proyek open source.

Bahkan jika kita menganggap pembuat respons "kirim tambalan" mengetahui semua hal di atas, itu hanya membuat pernyataan itu terdengar seperti "X jam waktu saya bernilai lebih dari perintah besarnya lebih banyak dari jam waktu Anda Anda akan bangun untuk mempercepat dan memperbaiki masalah ".

Secara umum, ketika saya mendapat respons kasar dari pengembang ketika saya bertanya tentang masalah saya memiliki atau mengirimkan bug, saya berhenti menggunakan program itu. Saya tidak lagi menggunakan uTorrent (bukan open source, tetapi intinya tetap) misalnya, karena tanggapan yang saya dapatkan di forum "dukungan" mereka sangat kasar. Saya mengirimkan masalah yang saya miliki di forum Laporan Bug. Utas segera dikunci dengan tautan ke utas lain tentang masalah yang serupa, tetapi berbeda di utas (yang juga dikunci, tentu saja). Sementara itu, saya membuka utas di forum Diskusi Umum yang menanyakan apakah ada yang menemukan solusi untuk masalah ini. Pada waktu yang diperlukan untuk menyimpan utas itu dan kembali dan melihat bahwa utas pertama saya telah dikunci, utas saya pada umumnya terkunci dan akun forum saya diblokir karena perilaku yang mengganggu. Saya mencopot uTorrent dan belum kembali sejak itu.

Bacon Bits
sumber
Apakah maksud Anda "Saya lebih suka mendapat jawaban" sebagai lawan dari "Saya lebih suka tidak mendapat"?
Andrew Grimm
Terima kasih untuk paragraf pertama khususnya. Sungguh menakjubkan bagaimana bentuk dasar kesopanan profesional dapat menjadi asing bagi begitu banyak orang. Apakah Anda dibayar atau tidak, respons yang sesuai adalah mengakui masalah dan menjelaskan statusnya (bahkan jika statusnya "ditangguhkan").
Aaronaught
8

Membalas "kirim tambalan" adalah IMO kasar, tetapi tetap saja ... jika Anda menggunakan perangkat lunak open source untuk hal yang serius, Anda harus siap untuk mengurusnya jika perlu.

Berikut ini berdasarkan pada posting oleh Jeremias Maerki (dari Apache FOP fame):

Jika sesuatu tidak berhasil untuk Anda, Anda memiliki beberapa opsi:

  • Ini adalah sumber terbuka: Anda dapat memperbaikinya sendiri.
  • Jika Anda tidak dapat memperbaikinya sendiri, Anda dapat menunggu sampai seseorang memiliki waktu luang dan menganggapnya menyenangkan untuk diterapkan.
  • Jika itu tidak terjadi, Anda dapat menemukan atau menyewa seseorang untuk melakukannya untuk Anda.

Saya pikir ini adalah versi lengkap yang sangat valid dari jawaban "kirim tambalan".

Bertrand Delacretaz
sumber
6

Setiap kali saya melihat ini, saya segera mulai mencari produk alternatif. Bagi saya ini adalah tanda berbahaya bahwa pengelola tidak peduli dengan pengguna mereka (buruk jika proyek Anda digunakan di mana-mana) atau telah kehilangan minat pada proyek. Keduanya biasanya berarti bahwa proyek akan segera mati atau akan terganggu oleh stagnasi karena pengembang menolak untuk memajukan proyek.

(Perhatikan bahwa saya tidak mengatakan bahwa laporan bug pertama yang Anda lihat dengan respons yang Anda jalankan. Anda harus melihat tren umum. Jika sebagian besar laporan bug diakhiri dengan respons semacam ini, maka ikuti saran ini. Jika itu hanya beberapa, maka itu kemungkinan besar adalah permintaan fitur yang tidak sesuai dengan tujuan proyek atau sangat spesifik digunakan)

Seperti yang dikatakan @MainMa, mulai berkontribusi pada proyek baru sangat sulit. Sebagian besar pengembang tidak memahami ini karena mereka telah mengerjakan proyek selama berbulan-bulan / tahun dan itu masuk akal bagi mereka. Ini terkadang bisa menjadi kesalahan yang jujur.

TheLQ
sumber
3

Saya sesekali bercanda bahwa perangkat lunak bebas bisa gratis seperti dalam bir, gratis seperti dalam pidato atau gratis seperti pada Anda mendapatkan apa yang Anda bayar.

Sementara saya mengatakan itu dengan bercanda (saya bekerja untuk perusahaan yang menggunakan banyak OSS) tapi saya pikir ada kebenaran di sana - jika Anda ingin dukungan tingkat komersial maka Anda perlu menggunakan perangkat lunak komersial dengan kesepakatan dukungan yang sesuai, atau menemukan solusi perangkat lunak open source yang memungkinkan Anda mendapatkan tingkat dukungan (biasanya melalui seseorang yang dibayar untuk memberikannya tetapi berpotensi melalui organisasi Anda yang menggunakan atau menugaskan sumber daya pengembangan untuk mengerjakannya).

"Kirim tambalan" itu menyebalkan tetapi menyoroti sesuatu tentang OSS dan mungkin itu harus menjadi pengingat bahwa OSS tidak tepat untuk semua orang dalam setiap situasi, setidaknya tidak tanpa memastikan Anda memiliki kerangka dukungan yang solid untuk itu (baik in-house, dibayar untuk atau melalui komunitas).

Kita sering berpikir tentang perangkat lunak yang bebas seperti bir tetapi tidak seperti dalam ucapan (yaitu freeware non-terbuka). Mungkin ini adalah kasus di mana kita harus berpikir tentang perangkat lunak sebebas dalam berbicara tetapi tidak seperti dalam bir.

Jon Hopkins
sumber
2

Beralih ke alternatif yang dirawat dengan baik.

Dari pengalaman saya dengan proyek open-source yang dikelola dengan baik adalah, bahwa jika Anda membuat laporan bug atau permintaan fitur yang terdefinisi dengan baik, maka peluang penerapannya sangat tinggi.

vartec
sumber
2
Laporan bug dan permintaan fitur sering tidak didefinisikan dengan baik. Pengalaman saya adalah bahwa kompetensi dan rasa hormat bekerja dengan baik. Selain itu, permintaan fitur yang terdefinisi dengan baik akan dipertimbangkan. Ini mungkin dianggap prioritas rendah, atau mungkin sesuatu yang secara eksplisit tidak ingin dilakukan oleh grup proyek (ada contoh bagus di FAQ Putty, dan daftar permintaan fitur yang bagus yang dikelompokkan berdasarkan kategori).
David Thornley
1

"Saya hanya bisa mengerjakan satu hal pada satu waktu, tetapi saya bisa mengeluh tentang banyak hal sekaligus. Saya pikir kedua fungsi itu berguna." - akkartik di ycombinator .

Vincent Scheib
sumber
1

Saya menganggap bahwa ketika seseorang mengerjakan sebuah proyek, memberikan rilis dan dukungan, kontrak dukungan yang tidak terucapkan, tersirat, antara dev dan pengguna muncul. Dev telah mengambil tanggung jawab tersirat dalam mendukung basis kode untuk penggunanya, termasuk menambahkan fitur atas permintaan.

"Kirim tambalan" pada dasarnya memberikan jari kepada pengguna, menurut saya. Ini kontekstual - kadang-kadang terlalu banyak upaya untuk diterapkan, kadang-kadang akan merusak proyek yang ada atau menimbulkan kreaturitis tipuan, atau salah satu dari sejumlah alasan lain. Tetapi, pada akhirnya, dikatakan, "sekrup Anda, tidak melakukannya". Yang, dalam pikiran saya, pada tingkat tertentu, merupakan pelanggaran kontrak yang tak terucapkan itu.

Paul Nathan
sumber
Itu bukan kontrak kecuali kedua belah pihak menerima sesuatu. Apa yang biasanya diinginkan oleh proyek adalah laporan bug yang dilakukan dengan baik dan permintaan fitur yang sering dilakukan dengan baik, dan tidak semua yang datang langsung sampai akhir kontrak implisit.
David Thornley
1
@Aaronaught: Mereka menyediakan pengujian gratis hanya jika mereka melaporkan laporan bug yang cukup rinci untuk bekerja dengannya. Saya telah melihat bagian laporan bug buruk saya. Mereka mungkin atau mungkin tidak menyediakan iklan yang bagus. Sebagian besar orang yang menggunakan F / OSS tidak memberikan apa pun yang berguna, yang baik-baik saja, tetapi tentu saja tidak satu sisi kontrak.
David Thornley
1
@ David: Apakah Anda berhenti berusaha membatasi percakapan hanya untuk pengguna yang paling sulit / tidak produktif? Jika kita akan menggeneralisasi maka generalisasi itu harus untuk seluruh basis pengguna dan kontributor sebagai kolektif; merilis ke publik membuat Anda semua orang ini. Sebagai imbalan untuk kebaikan yang Anda dapatkan dari banyak dari mereka, Anda mendapatkan beberapa masalah dari banyak orang lain. Itulah hidup.
Aaronaught
1
@Aaronaught: Jika kita akan menggeneralisasi, kita perlu memastikan bahwa kita menggeneralisasi dengan tepat. Saya tidak mencoba membatasi percakapan dengan pengguna terburuk, hanya menunjukkan bahwa mereka ada di sana. Sebagian besar percakapan tampaknya berasumsi bahwa semua pengguna adalah kontributor, dan itu tidak benar. Jika kita akan berbicara hanya tentang pengguna yang berguna untuk proyek, sepertinya adil untuk berbicara tentang hanya anggota tim proyek yang umumnya sopan.
David Thornley
2
@ David: Jelas ada beberapa pengguna dan kontributor luar yang membantu, dan juga beberapa yang menyebabkan masalah. Jelas ada beberapa pengembang yang sopan dan profesional sejauh akal sehat dan keterampilan manajemen waktu yang baik memungkinkan, dan ada juga beberapa pengembang yang kasar dan tidak profesional karena kebiasaan. Ini adalah pertanyaan tentang bagaimana menangani kelompok pengembang yang terakhir. Keberadaan "pengguna masalah" tidak dalam sengketa, tetapi merupakan herring merah yang tidak memiliki tujuan lain selain menggagalkan diskusi dengan menciptakan situasi permusuhan - jadi mari kita biarkan saja.
Aaronaught
1

Ada beberapa cara yang harus dilakukan.

  • Mengusulkan proposal dan memberikan suara. tapi ini butuh waktu.

  • Dipekerjakan oleh perusahaan yang membutuhkannya untuk membuat tambalan. Jelas ini adalah solusi terbaik, tetapi bersiaplah untuk berkolaborasi dengan pria yang membuat perangkat lunak sumber terbuka yang ingin Anda tingkatkan.

  • Mencari tahu mengapa fitur ini tidak diimplementasikan di tempat pertama juga penting. Seringkali fitur tersebut tidak sesuai dengan proyek perangkat lunak: tim tidak menginginkan fitur ini, tidak merasa perlu atau mereka hanya berpikir itu bukan cara yang baik untuk melakukan sesuatu. Dalam hal ini Anda hanya harus membayar proyek dan membuatnya sendiri.

  • Gunakan perangkat lunak berpemilik yang melakukan apa yang Anda inginkan.

  • Ingatlah bahwa perangkat lunak OOP sering memudahkan proses pengintegrasian fitur.

  • Merengek di milis, di irc atau di forum hanya akan mengecewakan programmer, dan akan memberikan amunisi kepada pendukung OSS.

jokoon
sumber
0

Tidak ada yang bisa Anda katakan yang akan membuatnya melakukannya. Lagi pula, mengapa dia harus melakukannya? Karena keinginan satu pengguna? Tidak cukup alasan.

Tetapi , jika Anda dapat mengumpulkan jumlah pengguna yang masuk akal dan memberikan alasan rasional ("Saya menginginkannya" bukan alasan rasional.) Mengapa fitur itu dapat berguna, secara umum dan untuk Anda dan sejumlah orang lain, ia mungkin akan berubah pikiran. .

Meski, ada juga kasus khusus yang harus diperhatikan. Itu dev. bosan mengembangkan aplikasi, perlahan-lahan ingin meninggalkannya (ada hal-hal lain yang harus dilakukan), dan dia perlahan-lahan menolak permintaan fitur. Selain mencoba meyakinkannya untuk merilis kode, dalam hal ini praktis tidak ada yang dapat Anda lakukan, bahkan sehubungan dengan di atas.

Benteng
sumber
Atau, pengembang memiliki permintaan fitur yang cukup untuk membuatnya tetap sibuk sepanjang sisa abad ini, ingin memasukkan Anda, tetapi tidak melihat itu akan terjadi dalam waktu dekat.
David Thornley
@ David Thornley - Itu juga.
Benteng
0

Proyek sumber terbuka khususnya ramah terhadap karunia atau pendanaan pengembangan fitur tertentu, bahkan jika fitur baru itu tidak sampai ke rilis resmi.

Plus, ya, salah satu ide di balik penerbitan open source adalah agar siapa saja dan semua orang memiliki hak dan tanggung jawab untuk memberikan kontribusi mereka sendiri.

Dengan sumber tertutup, sumber daya terbaik Anda adalah mengumpulkan kelompok yang penting secara statistik dari basis pengguna yang menginginkan solusi seperti yang Anda inginkan.

Apalala
sumber
2
The tepat untuk berkontribusi, ya, tapi terakhir kali saya membaca GPL itu tidak menyebutkan apa-apa tentang tanggung jawab bagi pengguna akhir untuk membuat kontribusi mereka sendiri. Itu agak dibuat-buat, bukan begitu?
Aaronaught
0

Dalam pengalaman saya, respons ini biasanya diberikan jika permintaan pengguna tidak sesuai dengan tujuan proyek. Itu terjadi ketika orang berpikir bahwa Anda akan menerapkan semua yang mereka usulkan kepada Anda, dan sedikit lebih - gratis, open source dan masa depan yang hebat dan bahagia.

'Kirim tambalan' adalah respons yang relatif kasar (dan harus dihindari, tentu saja. Terutama dalam bentuk yang ringkas dan tajam ini. Ada banyak cara untuk mengekspresikan pesan yang kira-kira sama - misalnya 'mengundang' pengguna untuk membantu karena Anda tidak punya waktu untuk mengimplementasikannya sendiri). Tapi seperti apa adanya, itu adalah indikator 'berhenti membuang-buang waktu' yang jelas. Dengan demikian, tidak banyak yang dapat Anda lakukan tentang hal itu, juga tidak ada respons 'kanonik'.

Respons terbaik yang dapat saya pikirkan adalah benar-benar memberikan tambalan . Dengan asumsi tambalan Anda berfungsi, Anda setidaknya telah membuktikan bahwa idenya tidak sepenuhnya tidak realistis. Biasanya, ini berarti bahwa orang yang bertanggung jawab atas proyek akan mempertimbangkan kembali proposal tersebut.

Alexander Gessler
sumber
1
Saya tidak berpikir pengembang mana pun harus menjawab "kirim tambalan" mengenai permintaan yang tidak sesuai dengan tujuan proyek. Itu lebih tidak jujur ​​daripada kasar. Entah perangkat lunaknya membengkak dan pengembang membencimu, atau dia tidak menerima tambalan dan secara efektif membuang waktu Anda. Yang terakhir lebih mungkin. Pengembang benar-benar harus dengan jujur ​​mengatakan "Kami tidak ingin mengubah ini karena ____" dan selesai dengan itu.
Rei Miyasaka
@Rei Miyasaka: Secara pribadi, saya akan sangat marah jika saya menerima "kirim tambalan", melakukan pekerjaan untuk membuat tambalan yang berkualitas baik, dan kemudian diberitahu bahwa mereka tidak menginginkan fitur tersebut.
David Thornley
@ David Ya, kan? Saya akan melempar satu atau dua kursi.
Rei Miyasaka
0

"kirimkan tambalan" adalah sapuan sah untuk gagasan yang tidak sesuai dengan tujuan proyek. Dalam jangka panjang mungkin lebih baik untuk hanya memberitahu Anda ide itu menyebalkan atau Anda sedang mencoba menggunakan proyek untuk sesuatu yang jauh di luar ruang lingkup yang dimaksudkan, tetapi "hei, jika Anda berpikir apa yang Anda tanyakan itu sangat sepele, mengapa tidak t Anda mencoba memasukkannya ke dalam basis kode yang ada "kadang-kadang sesuai.

Jika minor dan benar-benar bermanfaat bagi pengguna proyek yang dituju, maka cukup kirimkan laporan bug, jelaskan masalahnya, berikan langkah-langkah untuk mereproduksi, tunjukkan bahwa Anda menggunakan bangunan malam hari ini, dan biarkan saja.

Apa yang tampak seperti perubahan kecil sederhana yang akan membantu banyak pengguna mungkin sebenarnya sangat menyebalkan karena tidak ada yang akan menggunakan selain Anda. Itu kasus terbaik untuk "kirim tambalan".

Mungkin juga Anda mengalami kasus seperti pengelola glibc terkenal yang tampaknya memiliki pikiran satu jalur bahwa sistemnya adalah alam semesta, interpretasinya tentang spesifikasi adalah kata dewa, dan hanya itu yang ada di sana, terlepas dari berapa banyak orang lebih suka sebaliknya.

Kevin Peterson
sumber
Saya tidak berpikir siapa pun akan memilih untuk mengajukan pertanyaan ini jika mereka tahu bahwa perubahan itu akan sangat menyakitkan di pantat hanya digunakan oleh satu orang. Jadi alih-alih "mengirim tambalan", mengapa tidak dengan sopan dan singkat menjelaskan mengapa itu merupakan masalah besar dan tidak dapat dilakukan dengan segera.
Tn. Shickadance
2
"Kirim tambalan" membuat sapuan yang sangat buruk, karena ada kemungkinan seseorang akan mengirimkan tambalan. Ini harus disediakan untuk prioritas rendah yang disukai.
David Thornley
0

Saya akan menyarankan membuat proyek untuk mengimplementasikan fitur di situs-situs seperti RentACoder / ELance / etc, dan mempostingnya di forum proyek open source asli. Salah satu programmer di proyek open source, termasuk penulis, sekarang memiliki insentif keuangan untuk mempertimbangkan permintaan Anda.

Renji Panicker
sumber
-1

Saya sebenarnya mendaftar hanya untuk menjawab pertanyaan ini.

Apakah perlu retort? respons ini biasanya digunakan ketika pengembang tahu tentang masalah ini tetapi tidak menganggapnya penting.

Saya akan memberi Anda contoh langsung. ubuntu menjatuhkan dukungan systray (tetapi dapat dikerjakan dengan mendaftar putih aplikasi) dan menambahkan indikator aplikasi baru. beberapa aplikasi seperti jupiter mengandalkan dukungan systray sehingga pengembang memberi tahu tentang workaournd alih-alih menambahkan dukungan indikator-aplikasi jadi saya meminta pengembang untuk menambahkan suplai indikator-aplikasi jawabannya adalah "Kirimi kami tambalan." menanyakan alasan mereka memilih untuk tidak mengimplementasikan ini. ada ini

Saya tidak tertarik menghabiskan waktu saya membangun dukungan untuk libra1ry yang saya tidak akan pernah gunakan hanya karena seseorang dengan banyak uang menuntutnya dengan membuat daftar hitam kemampuan aplikasi saya untuk berfungsi dengan baik pada distribusi Linux-nya hanya karena dia bisa.

Jika itu adalah masalah teknis yang nyata, saya mungkin akan mengambil tindakan tetapi ini murni manuver politik, jadi tidak, saya tidak berpikir begitu.

Tidak, saya akan daftar putih saja

Cukup adil. pengembang memiliki alasan untuk tidak mengimplementasikan fitur tetapi bersedia menerima tambalan. ini tidak benar-benar kasar dan ofensif sehingga tidak perlu balas.

Intinya: retort kanonik adalah untuk mengirimkan tambalan tetapi jika Anda tidak bisa tidak perlu retort

Lincity
sumber
-1

Mulai hadiah untuk fitur yang Anda inginkan.

Atau keluar dan beli produk yang mengklaim melakukan persis apa yang Anda inginkan dan menyalahgunakan personel pendukung mereka ketika Anda menemukan bahwa pemasaran tidak sesuai dengan harapan Anda.

CyberFonic
sumber
-2

Yang terbaik yang bisa saya pikirkan adalah "Anda payah".

Maaf ini jelas tidak terlalu membantu, tapi saya pikir ini hanya salah satu situasi yang tidak menguntungkan di mana pengguna benar-benar kacau. Seruan yang sangat jujur ​​terhadap hati nurani pengembang adalah upaya terakhir.

Anda dapat mencoba menawarkan ( batuk ) "sumbangan" untuk mengatasi masalah Anda, tetapi saya khawatir praktik seperti itu jika dilakukan bersama akan menyebabkan hilangnya integritas yang sangat buruk di industri, karena perbaikan bug tidak boleh membuat keuntungan, baik untuk "Gratis" atau perangkat lunak komersial.

Rei Miyasaka
sumber