Bagaimana cara saya menangani pemrogram yang sulit bergabung dengan proyek sumber terbuka?

Saya memiliki skrip open source untuk situs tertentu (saya mencoba untuk tidak memanggil apa pun dengan nama di sini) yang baru-baru ini saya dan beberapa pengembang lain pindah ke GitHub. Kami mendapatkan beberapa pengembang baru sejak kami pindah ke sistem baru, termasuk satu yang sangat aktif pada khususnya. Namun, yang aktif ini sudah mulai mengubah banyak proyek.

Pertama-tama, dia menghapus sistem versi kami (tidak seperti Git, tapi seperti itu - kami menyebutnya versi v4.1.16) dan mengatakan akan lebih baik untuk hanya mendorong kode ke situs ketika kami pikir sudah siap. Sekarang tidak ada tempat terpusat untuk menaruh catatan rilis, yang sudah menjengkelkan.

Hal yang membuat saya hampir siap untuk mengepak tas saya dan pergi adalah naskah push. Pengembang lain di proyek ini menulis skrip push sederhana berbasis Python. Karena kami membuat banyak versi skrip online di berbagai tempat, saya mulai mengkode program Java yang lebih besar dengan antarmuka grafis yang akan menggantikan skrip Python. Saya menggunakan IRC untuk memberi tahu semua orang tentang hal itu, dan saya mendapat respons yang sangat menjengkelkan dari programmer yang mengatakan bahwa skrip berbasis Python lama dapat melakukan semua yang dapat saya lakukan dan jauh lebih ringan (dia juga berkomentar tentang fakta yang dia pikir Python lebih baik dari Java dan sebagainya). Saya melihat kode untuk naskah push lama dan melihat bahwa tidak ada fitur yang katanya ada di sana.

Jadi sekarang saya ingin tahu apa yang harus dilakukan. Saya telah menghabiskan banyak waktu untuk proyek ini, jadi saya tidak ingin bangun dan pergi, tetapi saya merasa sulit untuk bekerja dengan pengembang baru ini. Di sisi lain, dia sekarang menjadi committer # 1 di proyek ini, dengan komitmen lebih dari pengembang utama. Saya tidak begitu yakin apa yang harus saya lakukan tentang ini. Adakah orang lain yang mengalami masalah ini? Jika demikian, apa yang Anda lakukan?

PEMBARUAN 1 : Saya telah menonaktifkan akses komit semua orang dan saya meminta orang-orang melalui permintaan tarik. Saya juga mengusulkan beberapa langkah untuk memperbaiki masalah lainnya. Semua orang belum menunjukkan dukungan untuk itu. Dev yang bermasalah hanya mengatakan bahwa orang yang tidak mengikuti "melakukan tindakan" dengan cermat dapat berpikir bahwa proyek itu berantakan ketika sebenarnya tidak. Saya jelas tidak setuju dengan ini, jadi saya serius mempertimbangkan untuk mengundurkan diri dari proyek.

UPDATE 2 : Pengembang utama mulai mengomel tentang fakta bahwa salah satu komit saya seharusnya menghapus tiga baris baru dalam kode (komit revert muncul tepat setelah saya memposting diskusi, dan bahkan tidak merujuk "komit" saya), lalu mereka berdua mulai mendiskusikan apakah akan mencabut akses komit saya. Jadi, saya sudah melakukan hal yang logis dan meninggalkan proyek. Terima kasih atas bantuan Anda dengan semuanya ini!

1. Anda bisa berhenti. Bukan hal yang paling konstruktif untuk dilakukan, tetapi kadang-kadang itu satu-satunya pilihan. Jika ya, jangan duduk dan mengeluh tentang bagaimana Anda harus melepaskannya, ambil energi itu dan letakkan langsung ke sesuatu yang lain - 'lanjutkan' dengan kata lain.

2. Anda bisa membayarnya. Tidak ada alasan mengapa Anda harus bekerja dengan siapa pun. Fork, perbaiki kode dan biarkan yang lain terus memiliki ego-fest mereka sendiri. Proyek baru Anda hanya akan bersaing dengan yang lama dan terserah Anda apakah Anda berhasil, atau yang lama mengalahkan Anda dalam hal pengguna dan fitur.

3. Anda dapat terlibat dengan tim pengembangan lainnya di proyek untuk menyuarakan keprihatinan Anda. Jangan membuatnya pribadi, tetapi pastikan bahwa Anda tidak senang dengan kode churn, atau kurangnya proses kualitas yang mapan, atau tidak senang bahwa keputusan baru hanya didorong keluar tanpa persetujuan dari semua orang. Anda akan diberitahu bahwa tidak ada yang salah untuk berubah, atau Anda akan mendapatkan beberapa orang lain yang setuju dengan Anda bahwa tim perlu memperbaiki keadaan. Itu mungkin berakhir dengan pria yang mengganggu kehilangan akses komitnya. Mungkin Anda semua akan setuju bahwa beberapa perubahan bukanlah perbaikan dan proyek perlu dikembalikan. (Opsi terakhir ini adalah hasil yang paling mungkin, kecuali jika itu berubah menjadi argumen besar pendapat yang mengakar.)

Mungkin sulit ketika seseorang datang dan mengubah rutinitas yang aman dan nyaman yang sudah biasa Anda lakukan, tetapi dapat dikatakan bahwa seseorang datang dan mengguncang praktik lama yang nyaman adalah hal yang baik dalam diri mereka.

Anda membuatnya sedikit tidak jelas apa peran Anda di sini. Jawabannya tergantung pada bagaimana Anda cocok.

Jika Anda memimpin proyek dan mengontrol repositori git

Ambil kembali kendali. Jika orang ini membuat komitmen yang tidak Anda sukai tanpa berkonsultasi dengan Anda, hapus akses komit langsungnya. Dia dapat melakukan fork proyek dan membuat permintaan tarik untuk menggabungkan komitmennya. Itulah cara kerja open source sampai pengguna membangun kepercayaan. Anda tidak perlu, dan tidak boleh, memberikan akses penuh segera.

Jika orang lain mengendalikan repo

Sampaikan kekhawatiran Anda kepada orang yang melakukannya, dan dorong proses yang lebih disiplin untuk merencanakan dan menyetujui perubahan. Jika kepemimpinan tidak dapat menerima proses, maka Anda dapat memilih untuk menerima status quo dan terus berkontribusi, Anda dapat membayar proyek dan mengerjakan versi Anda sendiri (membawa serta siapa saja yang setuju dengan Anda), atau Anda dapat memilih untuk meninggalkan dan mengerjakan hal-hal lain. Bagaimanapun Anda tidak diharuskan untuk terus berurusan dengan ini.

Maafkan keterusterangan saya, tetapi posting Anda dibaca seperti kata-kata kasar.

Anda mengatakan itu adalah orang lain yang menginginkan perubahan tanpa pikiran, tetapi kemudian Anda bertentangan dengan diri Anda ketika berbicara tentang program Java baru Anda yang mengkilap.

Istirahat; ini bukan jalan satu arah, silakan coba mencari kompromi (jika Anda ingin terus bekerja pada proyek - forking adalah keputusan termudah tetapi itu tidak akan membawa Anda ke tempat yang berguna, meskipun itu mungkin membuat Anda egois).

Tolong juga pikirkan dengan seksama tentang pembagian kerja dalam proyek ini - perang wilayah tidak terhindarkan jika Anda tidak memiliki batas yang jelas untuk memberi tahu Anda siapa yang kompeten dalam hal apa . Ya, terkadang Anda harus memercayai penilaian orang lain.

Telah disebutkan dalam beberapa jawaban bahwa pembagian kerja adalah salah satu cara untuk mengurangi konflik. Berikut ini beberapa contoh nyata:

1. Seimbangkan produktivitas vs stabilitas. Untuk meminjam analogi dari permainan strategi, sebuah tim harus terdiri dari campuran Boom, Turtle dan Rush , dan rekan satu tim harus siap untuk mengubah peran dalam menanggapi situasi.
   • Ketika seseorang berada dalam kegemaran produktivitas, orang lain dapat mengerjakan:
   • Fitur lainnya
   • Memperbaiki bug
   • Spesifikasi (mengelola permintaan fitur baru, dan memverifikasi bahwa perangkat lunak memenuhi kriteria yang disepakati)
   • Kualitas asuransi
     • Pengujian manual (eksplorasi)
     • Pengujian otomatis
   • Dokumentasi
   • Refactoring dan pembersihan kode
   • Melakukan studi pengguna untuk mengumpulkan ide untuk perbaikan
   • dll.
2. Suatu proyek dapat dimodulasi (seperti dalam arsitektur perangkat lunak), atau bahkan dikelompokkan (seperti dalam manajemen proyek) sehingga setiap modul dapat dikerjakan secara mandiri.
   • Secara umum, sebagian besar perangkat lunak yang mengandung front-end dan back-end harus dimodulasi, karena mereka memiliki kecepatan pengembangan yang berbeda.
   • Perangkat lunak kaya UX mungkin sulit untuk modularisasi karena mereka banyak menggunakan routing acara lintas-modul.
   • Pemelihara proyek mungkin ingin menjaga proyek tetap sederhana dengan menghindari modularisasi.
3. Cabang fitur . Setiap pengembang dapat melakukan fork proyek, mengerjakan fitur kesayangan favoritnya, dan meminta penggabungan saat implementasi selesai. Pengembang utama dapat memiliki keputusan akhir apakah akan menerima penggabungan.

Selain dari aspek penghindaran konflik, jelas bahwa proyek tersebut mungkin memiliki tata kelola yang tidak memadai .

Mengapa tata kelola itu penting? Bayangkan suatu hari mantan rekan tim mengambil perangkat lunak, dan menuntut tim atas pelanggaran. Atau tim yang digugat oleh troll paten. Atau tidak ada yang tahu siapa yang memutuskan untuk mengirim pemberitahuan DMCA ke situs hosting proyek dan meminta kode sumber proyek dihapus.

Minimal:

• Lisensi untuk digunakan oleh semua kode sumber yang dikontribusikan
• Lisensi di mana kode sumber proyek dapat dipublikasikan
  • Dalam kasus lisensi publik baru dicari, cara mendapatkan persetujuan dari setiap kontributor
• Siapa yang dapat memiliki akses administratif ke proyek
• Siapa yang akan ditunjuk untuk menanggapi permintaan hukum (seperti pemberitahuan DMCA atau troll paten)
• Siapa yang akan mengelola keuangan untuk proyek (membayar biaya server dan pembukuan pendapatan iklan atau donasi)
• Siapa yang akan memiliki hak suara untuk memasukkan anggota baru dan mengeluarkan anggota.
• dll.

Sebagian besar situs proyek sumber terbuka dapat menyediakan piagam tata kelola proyek siap pakai.

Saya telah melihat masalah sebelumnya. Tetapi setelah beberapa tahun Anda benar-benar bosan dengan proyek, jadi solusi saya adalah meninggalkan proyek . Ini mungkin tidak cocok untuk Anda, tetapi masalahnya pada dasarnya orang yang berbeda berpikir dengan cara yang berbeda. Fitur yang menurut Anda sangat penting sama sekali tidak penting bagi orang lain.

Rencana yang baik adalah membagi tugas orang yang berbeda. Jika Anda dapat setuju dengan orang-orang bagian mana dari proyek yang menjadi tanggung jawab setiap orang, maka hanya satu orang yang mengambil keputusan pada bagian tertentu dari proyek tersebut. Namun kerja tim selalu sulit. Anda masih tidak akan menyukai keputusan yang dibuat oleh programmer lain. Solusi terbaik adalah tidak pernah melihat apa yang diputuskan programmer lain. Cukup percaya mereka untuk melakukan hal yang benar sudah cukup.

Tujuan bersama akan memfokuskan upaya Anda pada hal-hal penting. Semua orang yang bekerja ke arah yang sama sulit untuk mendapatkan, dan konflik akan tetap terjadi. Memutuskan tujuan bersama memerlukan mengetahui status proyek saat ini, dan kemudian memutuskan di mana harus setelah beberapa waktu.

Berikut ini contoh hal yang harus dihindari: Misalnya, sejumlah besar programmer c ++ berpikir kode yang tidak menggunakan pustaka STL rusak. Pemrogram lain berpikir bahwa setiap ketergantungan ke perpustakaan eksternal rusak, termasuk STL. Konflik semacam itu tidak dapat diselesaikan dengan baik - kedua situasi tidak dapat dipenuhi secara bersamaan - dan orang-orang yang paling bermasalah akan mendorong pendapat mereka tidak peduli oposisi apa pun yang akan mereka hadapi.

Empat pilihan, kurasa.

1. Jatuhkan dia. Kamu (diduga) masih cowok utama di proyek ini; mencabut hak dorongnya dan menyebutnya sehari. Hasil yang paling mungkin adalah dia mengerjakan proyek, membagi komunitasnya, dan kemudian perang pecah, dan ketika debu mengendap, salah satu garpu akan menjadi yang populer.
2. Garpu dan lanjutkan di tempat lain. Kurang agresif dari 1., tetapi konsekuensinya sama. Anda harus aktif di komunitas untuk menarik orang ke sisi Anda.
3. Biarkan saja: biarkan dia melakukan apa yang dia lakukan, tenang, dan berharap yang terbaik.
4. Diskusikan dengan komunitas, kompromi sesuai kebutuhan, dan selesaikan situasinya.

Secara pribadi, saya lebih suka opsi 4.

Google telah melakukan beberapa pembicaraan teknologi tentang hal ini beberapa tahun yang lalu. Perhatikan mereka:1 ,2 . Pendeknya:

1. Memahami : Memahami motivasi komunitas Anda untuk bekerja pada proyek Anda vs semua biaya kesempatan lain, dan melestarikan alasan tersebut.
2. Fortify : Membangun komunitas yang sehat dengan norma sosial kesopanan, rasa hormat, kepercayaan, dan kerendahan hati.
3. Identifikasi : Cari tanda-tanda orang beracun (terlalu banyak untuk disebutkan, tetapi jika Anda mengajukan pertanyaan ini, Anda mungkin sudah tahu banyak dari mereka).
4. Disinfektan : Bersikap tenang dan tahan, tetap tidak reaktif terhadap penghinaan, penghinaan, tantangan, rasa tidak hormat, dll., Dan gigihlah dalam memperkuat norma-norma komunitas Anda.

Sebuah garis besar tertulis yang komprehensif tersedia juga jika Anda lebih memilih untuk membaca bukannya menonton.

Anda tidak bisa berhenti begitu saja tanpa berusaha mengungkapkan kekhawatiran dan kesulitan Anda. Saya tahu ini bisa sulit. Jika faktanya jika Anda dan anggota tim Anda cukup muda untuk tidak mengalami langsung banyak masalah sosial yang terjadi di tim pengembangan mana pun, itu bisa sangat sulit.

Karena itu, saya sangat percaya Anda harus mengungkapkan kekhawatiran Anda. Anda dapat menuliskannya di email dan menunjukkannya kepada teman tepercaya Anda yang bukan bagian dari tim dan tidak memiliki atau sedikit minat pada apa yang Anda lakukan. Dalam hal ini Anda mungkin mendapatkan umpan balik yang baik sehingga kata-kata dari email Anda tidak terlalu keras. Tetap berpegang pada fakta. Jangan menuduh atau menyalahkan. Hanya fakta bahwa sulit melakukan sesuatu untukmu karena 'bla' hilang. Mengapa 'bla' hilang harus jelas bagi setiap anggota tim, yaitu "programmer baru" yang dihapus atau tidak mencapai sesuatu.

Sekali lagi, mengirim email ini sulit tetapi dengan sendirinya merupakan pengalaman hebat yang mungkin sangat berguna bagi Anda untuk maju. Pelajaran yang bagus untuk dipelajari.

PS: Saya tidak bermaksud terdengar terlalu orangtua. Namun itu memang sesuatu yang akan saya katakan kepada siapa pun termasuk anak-anak saya.