Autofixture: Apa selanjutnya untuk AutoFixture?

@Kralizek , terima kasih telah bertanya.

Saya hanya bisa berbicara sendiri, sebenarnya (masih) seperti yang saya tulis di https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457:

Baik oleh saya, jika saya memiliki pengetahuan yang diperlukan untuk meninjau PR. Biasanya, saya (dengan senang hati) meninjau bagian dari basis kode tempat saya sebelumnya bekerja, membuat, atau berkontribusi.

Jika saya melewatkan permintaan tarik atau masalah di mana saya disebutkan secara eksplisit, beri tahu saya. Sudah lama sejak seseorang menambahkan saya sebagai pengulas, atau secara eksplisit menyebut saya tentang masalah...

Terima kasih, @moodmosaic , telah menunjuk kembali ke #703. Posisi saya masih sama seperti dulu: Saya keluar dari proyek AutoFixture, meskipun saya senang membantu dengan saran jika diminta secara eksplisit.

Saya pikir masuk akal untuk membuka masalah ini jika sepertinya tidak ada yang terjadi. Mungkin pengelola saat ini telah pindah juga. Mari kita lihat apakah kita mendapat tanggapan dari salah satu dari mereka. Jika tidak, tolong ping saya lagi, haruskah kita katakan, sekitar seminggu?

Saya masih dapat membantu meninjau PR sesekali di area yang pernah saya alami, tetapi saya kira area itu mungkin sedikit dan jauh di antara hari-hari ini.

Jika segala sesuatunya tidak bergerak, mari kita lihat apakah kita dapat mengetahui alasannya, dan kemudian melihat apakah kita dapat membantu menemukan lebih banyak orang untuk membantu jika perlu.

Saya tidak bermaksud untuk mengambil kembali kendali proyek, tetapi sejauh yang saya tahu, saya masih memiliki akses tulis ke repositori. Jika ada orang lain yang secara sukarela memimpin proyek, saya akan dengan senang hati membantu mewujudkannya.

Hai kawan!

Ada juga umpan balik saya yang hilang di sini. Tidak secara resmi, tetapi mungkin ada harapan bahwa saya adalah pengelola paling aktif/pimpinan untuk proyek ini untuk saat ini.

Awalnya saya sangat bersemangat tentang pemeliharaan dan memiliki sedikit ide apa yang dapat ditingkatkan lebih lanjut. Bahkan hari ini saya melihat hal-hal yang masuk akal untuk dilakukan, setidaknya dari perspektif pemeliharaan (mis. drop .NET Standard 1.x support).

Baru-baru ini saya mundur dari mendukung proyek sama sekali dan saya mengidentifikasi beberapa alasan untuk ini.

DISCLAIMER : Tujuannya bukan untuk menyalahkan siapa-siapa, jadi jangan tersinggung. Sebaliknya, saya hanya ingin berbagi pengalaman saya sendiri sehingga kami dapat melihat apakah ada yang dapat kami lakukan tentang itu dan apakah itu sepadan.

Sulit untuk mengubah proyek.

Sangat sulit untuk mengubah proyek ini, karena saya memiliki perasaan yang kuat bahwa semua orang mencoba untuk melestarikan warisan yang ditinggalkan Mark. Tidak ada kebebasan untuk mencoba hal lain, kecuali apa yang akan dilakukan Mark. Mark dikutip di hampir setiap PR di mana dia tidak berpartisipasi secara langsung :)

Pada titik tertentu saya mulai merasa bahwa saya menjadi terlalu sulit untuk memodifikasi apa pun di sini. Dan itu membunuh gairah yang saya miliki tentang proyek tersebut.

Meski Mark pergi, saya pribadi tetap merasa bahwa kepemilikan proyek tetap miliknya. Saya merasakan banyak tekanan internal/eksternal saat membuat keputusan, karena ada peluang untuk menghancurkan sesuatu yang dibuat dengan sangat apik oleh Mark dengan kejam dan biadab. Beberapa persepsi ini dibuat hanya oleh saya, tetapi ada bagian ketika pengelola lain berkontribusi untuk membuat kesan seperti itu.

Mungkin hanya bedanya dengan harapan dan kenyataan saya. Saya berpikir bahwa saya akan dapat mengekspresikan dan mencoba ide-ide saya dengan proyek ini, bahwa proyek ini akan gesit, segar dan penuh dengan fitur-fitur baru. Tetapi pada kenyataannya itu terasa seperti proyek warisan di mana Anda tidak diizinkan untuk banyak berubah, karena semuanya berjalan dengan baik.

Saya akui bahwa beberapa proposal saya mungkin tidak ideal dan, tentu saja, saya tidak berpengalaman seperti Mark yang terhormat. Tapi kita bisa lebih bebas dalam mengambil keputusan, sehingga proyek lebih hidup.

Ini sedikit kesepian

Ketika saya bergabung dengan proyek ini, antara lain saya diharapkan untuk berpartisipasi dalam diskusi yang lincah, menjadi bagian dari tim, bersosialisasi dengan orang lain. Sayangnya, karena keberuntungan waktu dan/atau faktor lain, pengelola lain tidak terlalu banyak berpartisipasi dalam diskusi dan akhirnya saya mulai merasa bahwa saya sendirian di sini. Saya merasa bahwa pengelola lain tidak memiliki terlalu banyak waktu/gairah tentang proyek ini saat ini, jadi akhirnya saya mulai berbagi hal yang sama.

Saya tidak bekerja secara aktif dengan AutoFixture sekarang

Saat ini saya tidak menulis banyak kode back-end, jadi jangan terlalu banyak menggunakan AutoFixture. Saya masih sangat senang dengan proyek ini dan percaya bahwa perpustakaan ini harus dimiliki. Tetapi karena saya tidak menulis terlalu banyak tes, saya pribadi tidak menuntut perubahan apa pun.

Melangkah lebih jauh, saya tidak keberatan untuk berpartisipasi dalam kehidupan proyek dan membagikan pengetahuan saya apakah berlaku. Jika ada kebutuhan, saya bisa membantu dengan kode/pemeliharaan juga. Tapi saat ini, sayangnya, saya tidak memiliki semangat dan energi yang cukup untuk menjadi seorang lead maintainer. Jika kita memiliki calon yang kita percaya dan yang penuh semangat, kita pasti harus mengundangnya dan menjadikan salah satu pengelolanya.

Pertama, saya ingin meminta maaf kepada @AutoFixture/tim inti karena tidak menghubungi Anda kembali dalam diskusi #703. Ya, itu adalah waktu yang sibuk bagi saya (dan masih) tetapi saya tidak begitu sibuk sehingga saya tidak dapat menjawab. Saya benar-benar tidak mendapatkan pemberitahuan apa pun untuk penyebutan saya dan saya tidak berpikir untuk memeriksa kembali diskusi tersebut. Saya benar-benar baru mengetahuinya sekarang ketika saya mengunjungi kembali #703. Sekali lagi, saya minta maaf. 😞.

Posisi saya di masa depan AutoFixture sama dengan yang saya ungkapkan di tahun 2016 lalu . Saya percaya AutoFixture cukup stabil dan sudah bertahun-tahun sekarang. Jika seseorang ingin membawanya ke arah yang berbeda, saya pikir mereka akan lebih baik memulai dari awal yang bersih. Konsep pembuatan data pengujian otomatis sangat bagus dan AutoFixture tentunya bukan _hanya_ cara yang dapat dilakukan pada platform .NET.

Itu tidak berarti bahwa AutoFixture bebas bug. Apa yang saya katakan adalah bahwa volume dan cakupan pemeliharaan cukup kecil sehingga dapat tetap menjadi tanggung jawab tim @AutoFixture/inti.

Apakah kita membutuhkan pengembang utama? Sejarah open source tampaknya menunjukkan bahwa sebuah proyek tanpa pemimpin individu pada akhirnya akan ditinggalkan. Tapi bagaimana dengan sekelompok lead?

Saya katakan kami mencoba untuk bergerak maju dengan model saat ini dikurangi petunjuk yang ditunjuk dan melihat bagaimana kelanjutannya.

AutoFixture adalah proyek yang bagus, akan sangat menyedihkan melihatnya perlahan memudar.

Karena @zvirja adalah pengelola proyek/lead paling aktif. Saya percaya masuk akal baginya untuk memimpin bagaimana proyek ini akan berkembang. Mempertahankan proyek open source membutuhkan banyak usaha dan waktu. Secara pribadi saya tidak keberatan menyumbang untuk membuat proyek ini berjalan. Dan terima kasih @zvirja

Seseorang harus menunjukkan gajah di ruangan itu, jadi mungkin saya juga.

Utas ini sangat mirip pemakaman (atau penyesalan)

Saya percaya kita (komunitas) harus lebih fokus untuk menemukan jalan keluar dari situasi yang kita alami daripada melemparkan permintaan maaf.
Sejauh ini utas ini sangat bagus dalam menunjukkan masalahnya (jangan ragu untuk menyelesaikan):

1. Pengelola saat ini tidak punya waktu/tidak tertarik dengan proyek
2. Proyek ini sulit untuk dipertahankan
3. Peninjauan kode terlalu ketat

Sekarang bisakah kita membuat daftar tindakan yang bisa kita ambil?

Jika ada yang peduli, inilah pendapat saya tentang ini:

1. Terima anggota baru ke dalam komunitas. @Kralizek telah ada untuk sementara waktu, dia mungkin kandidat yang baik. Mungkin ada tim lain bersama @AutoFixture/core?
2. Buat tumpukan masalah, prioritaskan, minta bantuan komunitas
3. Longgarkan tinjauan kode. Seseorang tidak dapat mengambil alih kepemilikan sebuah proyek jika dia terus-menerus ditampar oleh pemilik sebelumnya.
   Izinkan percobaan, mungkin buat paket tambahan AutoFixture.Experimental , untuk hal-hal tersebut, yang belum dikonfirmasi untuk mendapatkan versi inti perpustakaan (seperti Boost untuk perpustakaan C++ standar).

Saya setuju dengan @zvirja , proyek ini sangat mengintimidasi. Saya telah menemukan AutoFixture sekitar dua tahun yang lalu dan baru-baru ini mendapat keberanian untuk mengajukan PR.
Saya percaya ada orang lain yang merasakan hal yang sama. Orang yang menggunakan alat ini dan ingin melihatnya berkembang.

Terima kasih @aivascu telah menunjuk gajah di dalam ruangan.

Saya setuju dengan analisis Anda, tetapi saya juga memiliki opsi keempat (walaupun saya akan membencinya): garpu baru untuk memberikan kebebasan kepada pengelolanya untuk bergerak dan dipusingkan.

Juga, terima kasih telah memasukkan nama saya ke dalam daftar tetapi sayangnya saya tidak begitu berpengalaman dengan internal perpustakaan dan saya benar-benar tidak bisa bergerak sendiri di sekitarnya.

Saya dengan senang hati dapat campur tangan dalam hal pengalaman pengguna...

Bagaimana dengan program sponsor/pendukung untuk membangkitkan antusiasme untuk mempertahankan proyek?
Bagaimanapun, ini adalah repo yang populer.

Dua sen saya menggunakan AutoFixture selama tiga tahun terakhir:

Saya pikir nama merek untuk AutoFixture sangat bagus. Itu nama yang keren.

Ini populer di Stack Overflow. [autofixture] memiliki 506 pertanyaan, sedangkan [xunit.net] memiliki 801. Menjadi hampir sepopuler kerangka pengujian kuasi-resmi .NET Core agak luar biasa, dan sebagian karena dedikasi tanpa henti dari Mark untuk mengajar (dan menjadi guru yang hebat). Dan blog Mark seperti sumber pengetahuan pengujian gratis.

Menurut saya API AutoFixture agak sulit dipelajari.

Bagian dari AutoFixture yang saya suka:

• Kemampuan untuk menggunakan pola desain Wadah Mengejek Otomatis (mungkin konsep pengujian paling kuat yang pernah saya perkenalkan sebagai seorang insinyur).
• Fixture.Freeze luar biasa
• Ekstensi AutoMoq untuk memungkinkan pembuatan perlengkapan dengan cepat untuk hal-hal yang memerlukan tiruan
• Kemampuan untuk secara otomatis menghasilkan grafik objek entitas dan menguji pola Repositori generik saya dan menjamin cakupan kode pengujian integrasi ujung ke ujung untuk repositori Entity Framework saya.

Bagian dari AutoFixture yang tidak pernah saya gunakan secara langsung:

• Fixture.Inject

Bagian dari AutoFixture yang ingin saya tingkatkan/perpanjang

• Lihat masalah saya yang dibuat kemarin: #1179
• Kemampuan untuk menukar perilaku default Guid untuk string dengan sesuatu yang lebih bagus, seperti Waffle Text Generator. Saya menyadari Anda dapat melakukan ini hari ini, tetapi jika #1179 telah dikerjakan, maka kita dapat menghubungkan Pemilih Elemen Sewenang-wenang dengan penyedia data khusus.
• AutoFixture lambat, dan tidak menggunakan trik modern untuk mempercepat kompilasi ekspresi, seperti yang dilakukan proyek DryIoC Maksim Volkau dengan FastExpressionCompiler Maksim https://github.com/dadhi/FastExpressionCompiler

Bagian dari AutoFixture yang tidak saya sukai (kebanyakan minor):

• Perlengkapan. Sesuaikanselalu bekerja secara tidak benar dengan Visual Studio intellisense.
• Menulis kustomisasi, dan mengapa metode Kustomisasi tidak memungkinkan Anda menyuntikkan kustomisasi. Hal-hal semacam itu barok dan menjengkelkan dan menciptakan kurva belajar yang besar.
• Kustomisasi dan pembuat spesimen dan hal-hal ada di mana-mana. Ini tidak terorganisir.
• Kosakata aneh untuk beberapa hal
• Seluruh pola desain Do..Without agak sulit untuk digunakan. Ini berfungsi, tetapi bertele-tele dan tidak membantu Anda dengan entitas rekursif. Untuk itu, Anda memerlukan Perilaku khusus untuk memberi tahu AutoFixture untuk membuat tabel hash dari objek yang sudah dibuat.
• Tidak ada sintaks yang disederhanakan untuk tugas umum
• Desain monolitik yang membutuhkan pemahaman mendalam tentang internal hanya untuk memecahkan masalah. Anda tidak bisa hanya menggunakan sepotong-sepotong. Anda harus cukup banyak menonton kursus Mark's PluralSight hanya untuk melewati kurva pembelajaran awal, atau bekerja dengan pengembang yang ahli dalam AutoFixture, untuk menghargai mengapa AutoFixture begitu mengagumkan.
• Pendirian Mark bahwa AutoFixture seharusnya hanya menghasilkan "nilai anonim." Ini menciptakan banyak penulisan kode pihak ketiga untuk menyelesaikan pekerjaan. Contohnya termasuk posting StackOverflow berikut:
  
  
  
  • Autofixture, buat daftar kamusdengan kunci bergantian
  
  
  • Bagaimana cara menetapkan properti hanya pada subrangkaian item dalam daftar?
  
  
  • Bagaimana cara membuat daftar kelas yang selalu memiliki nilai standar yang ditetapkan di AutoFixture?
  
  

Bagian yang saya lihat kemungkinan untuk inovasi:

• Ketika C# menjadi lebih dan lebih fungsional (pencocokan pola, jenis catatan, dll), AutoFixture idealnya akan bekerja lebih dan lebih seperti FsCheck dan Hedgehog di F#.
• Alangkah baiknya jika AutoFixture mampu reify beberapa konsep concolic testing dari FsCheck, seperti fitur Arb.
• Gunakan inovasi seperti yang dibahas di RLCheck untuk memungkinkan para insinyur membuat input pengujian yang sangat kuat dan beragam (Panduan karena string adalah peretasan!) https://www.carolemieux.com/rlcheck_preprint.pdf

Saya pikir beberapa masalah yang saya uraikan di sini adalah mengapa Microsoft tidak menggunakan AutoFixture dalam pengujiannya untuk .NET Core.

Kedengarannya seperti garpu eksperimental bisa menjadi cara untuk pergi. AutoFixture adalah salah satu dari sedikit proyek open source yang saya tahu yang digunakan secara luas sehari-hari oleh pengembang, pasti dapat memperoleh manfaat dari kemampuan tambahan dan peningkatan kemudahan penggunaan, dan memiliki basis kode berkualitas tinggi di belakangnya. Saya tidak dapat membayangkan minat akan rendah jika kekhawatiran tentang kontribusi dan perubahan arah dikurangi, itulah yang akan dilakukan oleh fork aktif.

Kedengarannya seperti garpu eksperimental bisa menjadi cara untuk pergi.

Mengapa Anda ingin melakukan itu? Anda harus menjaga garpu itu. Jika Anda bersedia melakukannya, mengapa tidak melangkah sebagai pengelola repositori ini saja?

Daripada garpu eksperimental, saya akan mempertimbangkan untuk membuat repo baru (atau terus membangun yang ini) untuk memperkenalkan peningkatan kualitas hidup yang dibahas di atas.

AutoFixture memiliki API yang kuat yang dapat mencapai banyak hal tetapi dapat menakuti banyak orang. Kebanyakan hal dapat diperkenalkan sebagai gula sintaksis sederhana.

untuk memperkenalkan peningkatan kualitas hidup

Renato ( @Kralizek ), apa kepanjangan dari QoL? Kualitas hidup?

Ya.

Jika Anda bersedia melakukannya, mengapa tidak melangkah sebagai pengelola repositori ini saja?

@ploeh bagaimana satu langkah sebagai pengelola untuk repositori? Apakah ada persyaratan?
Sejujurnya melihat daftar pengelola saat ini, ada beberapa sepatu besar yang harus diisi.
Saya ingin berkontribusi pada AutoFixture, bahkan mungkin sebagai pengelola (suatu hari nanti) dan saya yakin ada orang lain, tetapi saya membayangkan tidak ada orang yang akan diterima untuk memelihara repositori sepopuler ini.

Mengapa Anda ingin melakukan itu? Anda harus menjaga garpu itu.

Saya setuju dengan kutipan itu. Ketika saya awalnya mengusulkan paket eksperimental, di utas ini, saya memikirkan cara untuk mengurangi masalah yang dimiliki @zvirja , sambil mempertahankan repositori. Paket tersebut akan berisi fitur yang dibangun di atas inti AutoFixture, bukan garpu yang diubah. Sesuatu seperti yang dijelaskan @Kralizek .
Tentu saja, idealnya, paket seperti ini tidak diperlukan. Apa yang saya pikir harus kita selesaikan adalah masalah manusia daripada masalah teknologi.

Apa yang saya pikir harus kita selesaikan adalah masalah manusia daripada masalah teknologi.

Saya tidak tahu apa artinya. Beritahu kami lebih lanjut.

Apa yang saya pikir harus kita selesaikan adalah masalah manusia daripada masalah teknologi.

Saya tidak tahu apa artinya. Beritahu kami lebih lanjut.

Menurut saya yang dia maksud adalah AutoFixture membutuhkan pengelola berkomitmen yang merasa bebas untuk berinovasi tanpa takut merusak karya seni yang indah, seperti yang dikatakan @zvirja dalam komentarnya .

Sulit untuk merasa berkomitmen pada sesuatu di mana Anda merasa tangan Anda terikat oleh bayangan yang dibuat oleh keputusan dan kepemimpinan sebelumnya.

Beberapa ide menarik ditolak karena bertentangan dengan "Cara Lama". Ini akan membunuh motivasi siapa pun. Dari sudut pandang itu, garpu akan membebaskan banyak bagasi ini.

Oke, saya pria sederhana, saya hanya ingin hal-hal seperti https://github.com/AutoFixture/AutoFixture/pull/928 digabungkan. Seperti yang saya sebutkan di atas, AutoFixture tidak memiliki cara yang baik untuk mendukung menghasilkan nilai unik. Generator kongruensial linier perkalian tampaknya merupakan dasar yang baik untuk fitur semacam itu. Kami baru-baru ini menulis sendiri dan tidak secerdas seseorang yang tahu tentang trik ini, dan saya hanya menemukan PR nanti.

Saya seperti, "Ya, ayo lakukan lebih banyak hal keren ini."

bagaimana cara seseorang naik sebagai pengelola untuk repositori?

Anda pada dasarnya menyatakan bahwa Anda bersedia untuk mengambil tanggung jawab itu. Sejauh yang saya tahu, saya masih memiliki hak admin ke repositori, dan meskipun tidak ada pengelola saat ini yang secara eksplisit menyatakan ini, saya mendapat kesan bahwa tidak ada dari mereka yang akan meneruskan ini.

Apakah ada persyaratan? Sejujurnya melihat daftar pengelola saat ini, ada beberapa sepatu besar yang harus diisi.

Jangan khawatir tentang masa lalu. Saat ini, jika saya membaca situasinya dengan benar, AutoFixture sudah mati di dalam air. Kecuali seseorang mengambil tugas untuk meneruskannya, tidak ada yang akan berubah.

Dengan demikian, Anda dapat membuat semua kesalahan di dunia, dan Anda tidak akan memperburuk keadaan.

@ploeh jika Anda mengatakannya seperti ini maka saya akan dengan senang hati melangkah sebagai pengelola dan saya berharap yang lain akan melangkah juga.

@aivascu Terima kasih, itu bagus.

Saya akan memberikan waktu kepada pengelola dan pengguna saat ini @zvirja , @moodmosaic , @adamchester , @ecampidoglio sekitar 24 jam untuk mengomentari ini, dan jika saya tidak melihat protes, saya akan memberi Anda hak pengelola.

@ploeh Tidak ada keberatan dari pihak saya.
@aivascu Selamat datang. Semoga proyek ini akan memberi Anda kesenangan yang Anda cari 😊

@aivascu Saya bukan pengelola tapi saya suka perpustakaan ini. Ping saja saya jika Anda membutuhkan seseorang untuk memantulkan pikiran Anda.

@ploeh , @aivascu , baiklah oleh saya :+1: :rocket:

Saya senang mendiskusikan tentang bagian dari basis kode tempat saya bekerja, membuat, atau berkontribusi. Jika saya melewatkan permintaan tarik (atau masalah) di mana saya disebutkan, beri tahu saya.

@aivascu Doa terbaikku untukmu. Satu-satunya saran saya adalah dibutuhkan waktu sekitar 6 bulan untuk setiap 20.000 baris kode dalam basis kode, terutama jika tidak ada "catatan keputusan arsitektur" yang jelas di satu tempat. Untuk alasan ini, pada proyek yang saya pertahankan, saya mulai menulisnya sehingga orang memahami "gaya" kodenya. Mark telah menulis ini, tetapi sebagian besar di blognya dan/atau StackOverflow. @moodmosaic telah melakukan hal yang sama. Saya akan mengatakan, ke depan, buat folder adr di root repo yang mendokumentasikan alasan desain apa pun. Anda dapat menggunakan file .md untuk itu. Untuk tabel yang kompleks, gunakan tabel html daripada tabel penurunan harga.

Terima kasih semua atas sambutan hangatnya.
Saya pikir untuk awalnya, saya akan mengikuti saran dari @jzabroski dan akan mulai mengisi kekosongan dalam dokumentasi untuk mempermudah masuknya pengelola dan kontributor baru.
Secara paralel mungkin saya bisa mulai membakar backlog yang ada.
Semoga akan ada lebih banyak anggota komunitas yang melangkah maju, alat yang luar biasa ini.

Selamat @aivascu.

Saya merasa Anda adalah pengembang utama sekarang. Saya mengatakan ini, karena saya merasa bahwa segala sesuatunya akan kembali ke keadaan 'mati' seperti sekarang, segera setelah Anda berhenti - jadi saya melihat Anda sekarang :)

Saya berharap tim Autofixture 'memburu' anggota tim baru, untuk mengurangi risiko masalah perjalanan kesepian yang disebutkan sebelumnya. Saya senang berkontribusi saja, jika seseorang dapat melihat ini https://github.com/AutoFixture/AutoFixture/pull/1164.

@aivascu Saya telah mengirimkan undangan kepada Anda untuk bergabung dengan tim inti AutoFixture, tetapi undangan tersebut masih dalam proses.

@ploeh saya baru saja menerima undangan. Terima kasih!

@aivascu 👍 Selamat datang di tim.

Jika ada lagi yang bisa saya lakukan untuk membantu Anda, saya akan dengan senang hati melakukannya. Namun, saya telah tidak aktif dalam proyek ini selama bertahun-tahun, jadi saya tidak lagi tahu cara kerja hal-hal praktis. Saya harap @zvirja dapat mengisi Anda dengan detail tersebut.

Terima kasih!

Selamat datang @aivascu

@aivascu Saya akan dengan senang hati mengajak Anda ke proyek. Jika Anda tidak keberatan, saya akan sangat senang untuk berbicara dengan Anda, sehingga saya dapat menunjukkan semuanya dan menjawab pertanyaan. Jika Anda siap untuk itu, silakan tulis saya email (Anda dapat menemukan alamat di komit) sehingga kami dapat menyetujui detailnya.

Dan selamat datang lagi.

@zvirja itu akan sangat bagus. Saya akan mengirimkan Anda email.

Selamat datang @aivascu :+1:

Selamat datang, @aivascu! 🙂.

@aivascu Mengingat bahwa Anda melangkah sebagai pengelola baru yang penuh semangat dan energi untuk mengerjakan ini, haruskah kita menutup & melepas sematan masalah ini? Agak mengatakan bahwa untuk saat ini masa depan kita ditentukan? 😄.

@zvirja Saya agak berharap orang lain mungkin meminta untuk mengisi jajaran pengelola. 😄.

Jika ada yang merasa bahwa dia mungkin menikmati menjadi pengelola repositori ini, buka masalah atau kirim pesan kepada kami.
Saya akan menutup masalah ini sekarang.