Information: Tinjau periode kode PR

Saya juga mendapat kesan bahwa proses itu ditulis dengan mempertimbangkan repo yang berpusat pada komunitas, yaitu PR yang lebih dekat dengan perubahan organisasi.

Setuju, kode dapat dilihat sebagai aturan penerapan yang mengubah cara kerja organisasi, tetapi pembatasan keras tentang cara kita membuat kode tidak akan bisa dilakukan. Ini akan menghentikan pengembangan hingga berhenti praktis.

Mungkin membuat prosesnya lebih jelas tentang ini, sehingga tidak diterapkan pada kode PR?

Secepat mungkin? Jadi, Anda idealnya akan langsung bergabung setelah membuka permintaan atau masalah tarik? Apakah kita membutuhkan jendela untuk berdialog?

Saya berpendapat secara instan melampaui apa yang mungkin. :-) Kami perlu mengizinkan pengulas untuk membuat ulasan yang terinformasi, tetapi karena mereka sudah membutuhkan waktu untuk melakukan itu, dan tidak ada penggabungan yang terjadi sebelum mereka melakukannya, "secara instan" hanyalah hipotetis.

Jadi, saya tidak sepenuhnya setuju dengan @megoth , bahwa kami tidak dapat membuat proses tersebut berlaku untuk kode, karena ada perubahan kode yang kontroversial.

Namun, perlu juga dicatat bahwa inti dari penggunaan sistem revisi adalah bahwa perubahan kode tidak dapat diubah. Baru sebelum perubahan kode mencapai rilis penuh, pengembalian benar-benar menjadi masalah besar, dan itu membutuhkan waktu lebih lama.

Saya pikir intinya di sini adalah bahwa benar-benar tidak mungkin ada aturan keras dan cepat untuk berapa lama setiap PR (baik untuk kode atau lainnya) harus dipegang sebelum digabungkan.

Banyak perubahan kode, dan banyak perubahan dokumentasi yang dihadapi manusia, tidak akan kontroversial, dan tidak ada alasan untuk memaksakan penundaan 14 hari atau 3 hari atau bahkan 3 jam antara pengiriman PR dan penggabungan pada sesuatu seperti "kesalahan ketik tetap , hyperlink ke hyperlink" ...

PR umumnya harus ditinjau oleh seseorang yang akrab dengan hal yang diubah -- apakah itu kode atau bukan. Tampaknya masuk akal untuk mengatakan sesuatu seperti "w OR ((x dan/atau y) AND z) akan meninjau semua PR untuk repo/file/apa pun" -- kerangka waktu ulasan mungkin berbeda dengan beban kerja pengulas saat ini serta target PR!

Perubahan yang berpotensi menimbulkan perdebatan -- dalam bentuk apa pun -- harus diperhatikan oleh pengulas tersebut, yang harus dipercaya untuk kemudian meminta tinjauan yang lebih luas, yang berpotensi mencakup "petinggi" dalam bentuk apa pun.

Alasan mengapa saya memilih periode tetap adalah karena ada percakapan tentang 1) masalah dan permintaan tarik tidak ditangani dengan cukup cepat 2) masalah dan permintaan tarik tidak dipublikasikan cukup untuk memberikan kesempatan untuk memberikan masukan dan legitimasi saran yang dipertanyakan sebagai hasilnya. Tidak menuliskannya secara eksplisit berarti bahwa orang-orang yang bekerja di Solid untuk waktu yang lama memiliki keunggulan dibandingkan pendatang baru yang harus menebak aturan keterlibatan yang tak terucapkan sehingga bergabung dengan komunitas bukanlah lingkungan terbuka yang transparan.

Sebagai solusinya, haruskah kita mengatakan bahwa ada periode 3 hari untuk semua permintaan tarik dan masalah yang harus ditangani setelah diterbitkan?

Saya masih memiliki masalah dengan itu sebagai solusi "satu ukuran cocok untuk semua". Saya pikir itu akan memiliki beberapa efek merugikan pada kualitas kode dan kemajuan proyek.

Pertama-tama, tidak ada aturan keterlibatan yang tidak diucapkan yang belum ada setidaknya selama lima tahun , dan ini adalah praktik yang sangat standar di ribuan dan ribuan proyek. Jadi, memang, jika Anda benar-benar baru dalam pengembangan secara keseluruhan, Anda akan dirugikan, tetapi itu bukan karena sesuatu yang khusus dengan Solid, selalu ada kurva pembelajaran yang terlibat ketika memasuki bidang usaha baru. Seperti yang telah saya katakan, bagi saya penting bahwa Solid memiliki ambang batas yang sangat rendah untuk masuk, tetapi saya tidak yakin pengembangan server adalah tempat orang harus mulai mengembangkan keterampilan mereka, lingkungan di mana mereka tidak perlu bekerja sama secara erat dengan yang lain. pengembang pada basis kode yang sama mungkin lebih cocok untuk mereka.

Banyak, jika tidak sebagian besar, PR secara alami akan memiliki periode peninjauan lebih dari tiga hari, dibatasi oleh ketersediaan pengulas. Namun, kami juga secara alami berjuang untuk PR yang relatif kecil yang mudah ditinjau. Ini adalah praktik yang baik untuk melakukan itu, sehingga Anda mendapatkan umpan balik awal dan tidak terlalu sulit bagi pengulas. Namun, itu sering berarti bahwa menyelesaikan tugas yang lebih besar akan melibatkan beberapa PR inkremental. Jika setiap PR membutuhkan periode peninjauan tiga hari, itu akan memperlambat perkembangan secara signifikan. Kalau memang begitu kebijakannya, maka saya curiga kita sebagai developer pada akhirnya tidak akan menulis PR kecil-kecilan, melainkan mengerjakan satu PR besar sehingga tidak perlu menunggu periode review tiga hari untuk masing-masing.

Itu akan menghasilkan PR yang lebih besar yang lebih sulit untuk ditinjau, penyimpangan dari pengembangan yang gesit, dan kesalahan risiko yang lebih besar akan menyelinap melalui proses peninjauan.

Saya akan sangat tertarik untuk mendengar apa yang dilakukan proyek-proyek besar lainnya dalam hal ini, tetapi bagi saya, pendekatan satu ukuran untuk semua tidak diinginkan atau tidak dapat dicapai.

Sulit bagi saya untuk mengatakannya, karena saya adalah manajer rilis, tetapi saya pikir @TallTed akan mendukungnya, prosesnya sebagian besar harus atas kebijaksanaan manajer rilis. Manajer rilis harus memastikan bahwa pengulas yang paling cocok diminta, jumlah pengulas yang sesuai diminta tergantung pada masalahnya, dan penggabungan tidak terjadi sebelum jumlah pengulas yang tepat merespons dengan persetujuan, penggabungan tidak ' tidak terjadi jika ada perubahan yang diminta, bahwa cabang yang tepat dikunci untuk menegakkan proses peninjauan, bahwa PR yang berpotensi kontroversial dibawa ke misalnya perhatian Pemimpin Komunitas melalui beberapa cara pemberitahuan, dan memang, peninjau lain tentu saja dipersilakan untuk melakukan itu demikian juga.

Hanya ingin memasukkan catatan dari percakapan pertemuan dukungan komunitas. Poin-poin ini dibuat oleh orang yang berbeda dalam Solid Team:

• Periode peninjauan 3 hari dapat memperlambat kerja yang solid.
• Apa manfaat praktis dari jangka waktu? Manfaat praktisnya adalah menciptakan lingkungan inklusif yang lebih terbuka dengan proses pengambilan keputusan yang transparan yang dapat dipahami dan dirujuk kembali.
• apa masalah yang kita coba selesaikan? Apakah ada cara lain untuk menyelesaikannya? Apa yang sebenarnya kami coba selesaikan adalah bahwa ada kendala ketika perubahan dilakukan dan mereka tidak memiliki kesempatan untuk memberikan perspektif mereka. Batas waktu adalah cara untuk memberi kesempatan. Pendekatan lain untuk mengundang inklusivitas adalah memastikan bahwa saran diposting di lingkungan yang dapat diperiksa orang, misalnya solid/saran.
  – Diskriminasi merupakan efek samping daripada akarnya.
• Di mana batas antara inklusivitas dan efisiensi? Do-ocracy Anda perlu membiarkan orang yang melakukan sesuatu memutuskan. Memiliki sedikit otonomi adalah ekstrem lain yang tidak boleh kita tuju. Metirokrasi – do-okrasi. Implementasi cita-cita ini bisa menjadi racun bagi minoritas.

• Mari berusaha menjadi yang terdepan. Apa yang bisa kita pelajari dari kesalahan. Mari kita tidak melakukan segala sesuatu seperti yang telah dilakukan sebelumnya, mari kita renungkan mengapa kita melakukan apa yang kita lakukan. Bekerja untuk menerjemahkan spesifikasi ke dalam bahasa alami. Terutama ketika spesifikasinya berkembang, sulit untuk selalu memperbaruinya. Itu bisa sangat panjang, dan lebih mudah dibaca orang, mungkin terlalu banyak untuk dikunyah. Mengusulkan mencoba menemukan topik dalam spesifikasi. Temukan cara untuk mendistribusikan cara melihat spesifikasi. Tulis lebih banyak tutorial, untuk memecahkan berbagai masalah. Ada juga ruang untuk posting blog yang menjelaskan elemen spesifikasi. Buatlah menjadi titbits kunyah.

• Kami dapat menghapus komit, mereka dapat dibalik, namun, apakah pembalikan praktis? Mengembalikan komunitas dilakukan dengan lambat, jadi akan membutuhkan waktu lebih lama untuk membalikkannya. Lebih sulit untuk dikembalikan di server karena item dibangun di atas keputusan sebelumnya.

• Kami tidak melakukan sesuatu yang berbeda dari proyek lain. Meskipun pengaturan periode waktu berbeda dari praktik sebelumnya, apa yang kami coba lakukan adalah membangun model yang berbeda, dan model sebelumnya telah didominasi oleh kelompok yang homogen, jadi apakah kami ingin menggunakan praktik masa lalu atau berusaha untuk menjadi yang terdepan? pemikiran? Bisakah kita belajar dari contoh sebelumnya bagaimana tidak jatuh ke dalam perangkap yang sama dan menganalisis apa yang berhasil? Kami berjanji untuk menjadi berbeda – apa yang berhasil di masa lalu tidak berhasil.

• Bisakah kita membedakan antara repo? Jika demikian, bagaimana?

• Apakah kodenya berbeda dari aturan? Server solid node berdampak pada masyarakat seperti halnya repo komunitas dan spesifikasi Solid. Jadi bagaimana membedakannya? Sulit untuk menilai apa yang akan berdampak sosial, terutama ketika para profesional dalam membuat penilaian tersebut tidak dapat mengakses informasi karena tidak dalam bahasa yang dapat mereka tafsirkan.
• Server padat adalah perangkat lunak normatif yang memiliki dampak besar pada masyarakat, sehingga keputusan kode memiliki dampak besar.
• Permintaan tarik individu adalah sedikit perubahan, yang tidak memiliki properti itu. Mereka hanya ada untuk membuat perubahan bertahap untuk membungkus pikiran kita di sekitarnya. Tidak sama dengan perubahan masyarakat karena secara kualitatif dan kuantitatif tidak sama.
• Tiga repo spesifikasi dan repo komunitas harus memiliki proses yang lebih ketat misalnya dengan periode tinjauan minimum yang ditentukan dan peninjau yang dialokasikan. Spek memiliki efek normatif yang besar. Cara yang baik untuk membedakan repo dengan efek normatif yang dapat mereka miliki secara luas. Repo komunitas dan spesifikasi solid termasuk dalam kategori itu. Jadi akan lebih baik untuk memiliki penggabungan yang transparan.

• Dapat memiliki aturan hybrid yang ditetapkan untuk node-solid-server yang mengatakan jika perubahan menyimpang dari spesifikasi, perlu waktu peninjauan yang lebih lama. Kasus di mana kita mengimplementasikan spesifikasi dalam kode yang menyimpang dari spesifikasi juga penting untuk diproses.

• Alur kerja dan langkah-langkah tidak didokumentasikan.

• Insinyur lebih percaya pada pipa daripada non-insinyur. Mungkin kita mempercayai ini. Mungkin ada benarnya. Demografi budaya pengembang, mungkin karena menurut kami memang seperti itu seharusnya.
• Keputusan kunci disamarkan sebagai teknis padahal sebenarnya mereka memiliki implikasi besar di luar teknis.
• Kode dapat memiliki dampak yang luar biasa pada masyarakat sehingga penting untuk memahami dampaknya dan memungkinkan orang untuk ikut serta.
• Bahasa alami – spesifikasi dapat menggunakan beberapa penyegaran dalam hal apa pun. Dalam melakukan itu ada cara yang lebih baik untuk menjelaskan sesuatu. Tidak akan sejauh menulis ulang elemen teknis sebagai non-teknis. Ada peluang untuk meningkatkan keterbacaan spesifikasi untuk memastikan bahwa Itu benar. Akan mendapat banyak tekanan balik yang mengatakan bahwa teknisnya akan dihilangkan.
  
  
  
  • Kita perlu membangun hal-hal yang dapat diterima dan oleh karena itu perlu dipahami oleh semua orang.
  
  

@TallTed apakah Anda memiliki pemikiran tentang notulen rapat di komentar sebelumnya?

Sebagai jalan ke depan saya mengusulkan sebagai berikut:

Permintaan tarik dan masalah yang terkait dengan repo berikut harus dibuka selama minimal tiga hari:
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

Permintaan tarik dan masalah yang terkait dengan semua repo lain dapat segera ditutup dan tidak memiliki waktu minimum untuk dibiarkan terbuka kecuali jika menyimpang dari spesifikasi dalam hal ini harus dibuka selama minimal tiga hari.

Ada keberatan?

Bekerja untuk saya. Ini juga merupakan kemungkinan untuk menambahkan teks ke deskripsi peran Manajer Rilis, menjelaskan apa yang harus mereka lakukan dengan repo yang tersisa.

Saya suka solusi ini juga :smile_cat: Mari kita tuliskan alasannya di suatu tempat juga, sehingga orang memahami pemikiran kita di baliknya

@kjetilk Ya, saya akan menambahkan catatan ke https://github.com/solid/community/pull/44

@megoth ok akan menyertakan deskripsi singkat di repo komunitas readme

https://github.com/solid/community/blob/master/README.md