Partkeepr: Meta: Terlalu banyak masalah terbuka

Dibuat pada 13 Jan 2020  ·  55Komentar  ·  Sumber: partkeepr/PartKeepr

Seperti yang disebutkan @baradhili dalam komentar ini, kami memiliki cukup banyak masalah terbuka saat ini.

Meskipun saya mengkonfirmasi bahwa ini adalah situasi yang tidak menyenangkan yang memberikan (terlalu) banyak tekanan pada pengembang dan orang-orang yang mungkin tertarik, saya pikir ini juga merupakan sumber informasi yang berguna tentang apa yang tidak berfungsi dan hilang di PartKeepr. Tidak semua masalah ini adalah prioritas tinggi dan beberapa mungkin tidak valid, harus saya akui.

Pertama, saya ingin membuat satu utas untuk membahas ini alih-alih membajak masalah lain di sini.

Untuk menyiasati seluruh situasi ini, saya sarankan untuk tidak menutup masalah yang menggantung.
Sebagai gantinya, saya mengusulkan untuk menggunakan fitur internal github untuk manajemen orang untuk mengkategorikan dan mengatur masalah. Berikut adalah beberapa ide, tetapi ini harus didiskusikan:

  • Menambahkan label ke masalah memungkinkan untuk memisahkan antara bug, peningkatan, mencari dukungan, dan topik lainnya.
  • Menambahkan tonggak (termasuk yang disebut "masa depan" atau sejenisnya) memungkinkan untuk mengatur secara kronologis
  • Penggunaan fitur proyek untuk mengatur masalah
  • Kemungkinan beberapa proyek (satu untuk bug, satu untuk peningkatan)

Jika proyek mulai kembali bekerja secara aktif di basis kode, kita bisa memikirkan semacam bot basi. Tapi menurut saya ini tidak boleh dilakukan selama kita "offline".
Mungkin ada beberapa masalah terbuka, yang benar-benar harus ditutup. Di sini, mungkin berguna untuk memperingatkan pengguna sekali jika masalahnya masih menarik dan hanya tutup yang

  • tidak ada yang menjawab dan
  • tampaknya terkait dengan masalah individu (hal-hal seperti "Saya tidak dapat memperbarui dari x.xx ke y,yy) untuk menghindari kehilangan informasi yang relevan.
meta

Komentar yang paling membantu

bekerja untuk saya! :)

Semua 55 komentar

jadi pada dasarnya kami membuat "backlog" de-facto...
@Drachenkaetzchen apakah Anda terbuka untuk menambahkan beberapa dari kami ke proyek sehingga kami dapat menyelesaikan masalah?

jadi pada dasarnya kami membuat "backlog" de-facto...

semacam. Tapi, ya, ini adalah ide dasarnya.

@Drachenkaetzchen apakah Anda terbuka untuk menambahkan beberapa dari kami ke proyek sehingga kami dapat menyelesaikan masalah?

Saya akan bersedia membantu di sini, jika diinginkan.

Hai teman-teman, ini adalah ide yang sangat bagus dan telah didiskusikan oleh kami di IRC juga.

Saya baru-baru ini mendapat akses ke github dan saya akan melihat menambahkan beberapa orang untuk membantu dengan sisi organisasi untuk mengelola masalah dan menghargai tawaran Anda untuk membantu dengan ini.
(kalau karena keterbatasan waktu saya lupa jangan malu-malu untuk mencoleknya)

Ok @christianlupus Saya telah menambahkan Anda sebagai anggota Triage ke repositori ini.
@baradhili apakah Anda tertarik juga untuk membantu dengan ini?

Di sini dijelaskan kemampuan untuk ini: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Akhirnya tentu saja kami akan menambahkan lebih banyak orang dengan akses kode juga. Untuk saat ini mari kita coba dan fokus pada pengorganisasian masalah.

@dromer ya tolong

@dromer Terima kasih atas tambahannya.

Saran pertama adalah menambahkan label needs-triage dan membuat aturan untuk menempatkan setiap terbitan baru dan PR ke dalam label ini.
Alasan: Reporter melihat bahwa triase perlu/akan dilakukan. Selanjutnya kita dapat mengurutkan (nanti) untuk masalah tersebut. Mungkin kita harus mempertimbangkan untuk meletakkan setiap masalah di bawah label ini untuk melihat apa yang sudah dilakukan dan apa yang perlu diperhatikan.

Dan tambahan: Saya juga menyarankan label berikut:

  • meta : Digunakan untuk masalah yang tidak terkait dengan kode itu sendiri tetapi repo, wiki, standar pemrograman dan sejenisnya
  • help-requested : Digunakan untuk menunjukkan bahwa masalah sedang mencari bantuan selama penyiapan, penggunaan, dll. Ini mungkin lebih baik didorong ke forum daripada disimpan sebagai masalah di sini di github.

Kedengarannya bagus.. meskipun saya sarankan kita tidak memasukkan semuanya di bawah needs-triage karena kita hanya akan berakhir di tempat kita sekarang :).. Saya juga menyarankan backlog , next-release dan roadmap setelah kami meninjau semuanya

Ketika saya mulai mengkategorikan beberapa masalah sekarang, saya merasa sulit untuk memberi label pada mereka kecuali jika ini didefinisikan dengan jelas (setidaknya untuk sebagian dari mereka).

@christianlupus bagaimana Anda ingin mengkoordinasikan triase? Saya di UTC+8

@christianlupus Sepertinya kita perlu tag lain "pindah ke wiki"

@christianlupus bagaimana Anda ingin mengkoordinasikan triase? Saya di UTC+8

@baradhili saya di UTC+1 (Berlin).
Saya memberikan beberapa masalah beberapa label dan tonggak sejarah bila berlaku. Namun ada waktu bagi saya untuk mulai bekerja sekarang. Jadi saya akan berhenti sejenak.

Apakah Anda punya saran bagus tentang koordinasi? Satu orang di pagi hari satu orang di malam hari untuk menghindari tabrakan? Apa waktu pilihan Anda untuk mengerjakannya?

Karena saya tidak tahu di kota mana Anda tinggal, saya mengambil satu secara acak dari zona waktu yang disebutkan: Di sini Anda bisa mendapatkan gambaran singkat untuk mengatur shift waktu. Anda mungkin ingin mengadopsi ke kota Anda.

@christianlupus Sepertinya kita perlu tag lain "pindah ke wiki"

Yup, sepertinya memang begitu.

@christianlupus Saya sedang mengatasi masalah lama dengan tag bug saat ini.. Saya pikir saya dapat menghabiskan waktu sekitar jam 8 atau 9 pagi...Saya menggunakan versi bahasa Inggris dari situs yang sama - saya saya di Perth - kami mungkin ingin menandai masalah yang kompleks dengan beberapa tag sehingga yang lain dapat melihat dan memberikan pendapat..

@dromer jika kami memberi Anda daftar tag baru, dapatkah Anda menambahkannya?

Oh, apakah ini sesuatu yang harus saya lakukan?

Beri tahu saya dan saya akan mencoba menambahkan lebih banyak lagi.

@christianlupus Saya sedang mengatasi masalah lama dengan tag bug saat ini.. Saya pikir saya dapat menghabiskan waktu sekitar jam 8 atau 9 pagi...Saya menggunakan versi bahasa Inggris dari situs yang sama - saya sedang di Perth -

Oke, ini sepenuhnya terserah Anda. Terima kasih telah membantu di sini. Saya sedang mengerjakan masalah yang tidak berlabel untuk saat ini, jadi kami tidak bertabrakan.

kami mungkin ingin menandai masalah yang rumit dengan beberapa tag sehingga yang lain dapat melihat dan memberikan pendapat..

Ya, saya pikir ini adalah ide yang bagus. Bagaimana dengan complex-triage ?

Oh, apakah ini sesuatu yang harus saya lakukan?

Beri tahu saya dan saya akan mencoba menambahkan lebih banyak lagi.

Kami hanya dapat melampirkan label dan pencapaian untuk masalah tersebut. Tetapi kami tidak dapat menambahkan label baru ke daftar label yang valid. Jadi, ya, kami akan meminta Anda untuk menambahkan label yang relevan.

@baradhili Jadi untuk tidak, kami memiliki daftar label baru ini (mohon perbaiki saya):

  • meta
  • help-requested
  • move-to-wiki
  • complex-triage

Tentang label tepat waktu ( backlog , roadmap , next-release ) Saya pikir ini lebih baik ditangkap oleh tonggak sejarah, bukan begitu? Juga ini harus dikoordinasikan dengan siapa pun yang memberikan kode ke repo.

Saya akan memperbarui komentar ini segera setelah kebutuhan untuk label baru bermunculan. Oke dengan itu? Jika ya, jangan ragu untuk bertanya kepada dromer tentang hal itu.

@dromer
Bisakah kita memiliki pengaturan label berikut?

  • meta
  • help-requested
  • move-to-wiki
  • complex-triage
  • security-issue

Terima kasih

@baradhili Saya mencoba mengatur label dalam file MD sedikit. Saya menambahkan Anda sebagai kolaborator sehingga Anda dapat mengedit file.

Apakah Anda setuju dengan definisi sejauh yang saya tulis?

Semuanya bagus!dokumentasi!

Pada Selasa, 14 Januari 2020 pukul 19:36, Christian [email protected] menulis:

@baradhili https://github.com/baradhili Saya mencoba mengatur label
dalam file MD
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
sedikit. Saya menambahkan Anda sebagai kolaborator sehingga Anda dapat mengedit file.

Apakah Anda setuju dengan definisi sejauh yang saya tulis?


Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWZ434com74VMVBZW63LNMVXH
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
Bret Watson
Direktur
Manajemen Interim TI Pty Ltd T/A TICM
Massa: +61 (0)41 33 03 840
Email:[email protected]
"Isi dari transmisi email ini ditujukan hanya untuk yang bernama
penerima (s), mungkin rahasia, dan mungkin istimewa atau sebaliknya
dilindungi dari pengungkapan untuk kepentingan publik. Penggunaan, reproduksi,
pengungkapan atau distribusi isi transmisi email ini oleh
siapa pun selain penerima yang disebutkan namanya dilarang. Jika kamu tidak
penerima yang disebutkan, harap beri tahu pengirim segera."

build system jelas ada hubungannya dengan ci/cd (lihat 2 PR saya) jadi saya akan menyimpannya.

Saya akan menambahkan daftar Anda @baradhili dan semoga kalian setidaknya bisa maju.
Untuk saat ini saya pikir lebih baik memiliki label 'terlalu banyak' daripada memiliki 'terlalu sedikit'. Kami selalu dapat menghapus/mengabaikan label tertentu.

Adakah warna tertentu yang ingin Anda kaitkan dengannya? :)

Ok terlambat, saya menggunakan warna default untuk saat ini :D

@dromer Bisakah kita memiliki tonggak sejarah untuk 1.5.0?

@christianlupus Saya akan menggunakan 1 - Ready untuk hal-hal yang muncul/diklaim diperbaiki, tetapi perlu pengujian

@dromer dalam retrospeksi.. Saya menyadari bahwa saya dapat menangani hal-hal yang tampaknya perlu dilakukan "Segera" dengan Must Have
@christianlupus selesai Bug .. sekarang mengerjakan masalah lama tanpa pencapaian

Saya menghapus label seperti Will be closed soon! dan Feedback Needed segera setelah masalah selesai. Apakah ini baik untuk alur kerja kita bersama?

@dromer bisakah saya memiliki satu tag tambahan.. low-hanging ? Saya melihat masalah dari waktu ke waktu yang seharusnya mudah diperbaiki

@christianlupus ya .. dan saya harus kembali dan memeriksa apakah saya sudah melakukannya

Rupanya github menyediakan beberapa 'kait' otomatis jika Anda menggunakan tag good first issue sebagai gantinya:

Beri label masalah dan tarik permintaan untuk kontributor baru

Sekarang, GitHub akan membantu calon kontributor pertama kali menemukan masalah yang diberi label good first issue

Jadi, haruskah saya menyebutnya begitu?
Masalah dengan tag ini akan muncul di beberapa ikhtisar lain yang seharusnya mendorong orang untuk terlibat.

Seperti di https://github.com/partkeepr/PartKeepr/contribute

bekerja untuk saya! :)

@baradhili Saya baru saja menyelesaikan masalah yang tidak ditandai. Sejujurnya, saya tidak akan melanjutkan untuk hari ini, ini sudah cukup. Namun demikian, saya ingin mengatur dengan Anda langkah selanjutnya. Looking forward untuk balasan Anda.

@christianlupus ya.. Saya menemukan saya dapat mempertahankan sekitar 20/25 masalah per hari.. setelah itu otak saya digoreng ...
aku akan lari pagi ini..

@dromer langkah selanjutnya kita mungkin harus mulai melihat prioritas.. dan yang paling penting.. menugaskan ke devs.. apakah kita punya devs?

@baradhili Saya baru saja mengirimi Anda email ke domain ticm Anda. Bisakah Anda memeriksa akun Anda?

apakah kita punya dev?
Er ... jika kami melakukannya, kami tidak akan memiliki backlog ini :)

Saya pikir kalian bergerak sedikit lebih cepat daripada proyek yang saat ini 'diizinkan', yang merupakan hal yang baik karena mengatur backlog menyumbat segalanya, jadi semoga prioritas akan membantu memberi fokus bagi mereka yang mau berkontribusi. (menemukan mereka, atau meminta mereka menemukan kita, tentu saja merupakan tantangan yang berbeda)

ok teman-teman .. kami sekarang memiliki daftar masalah dengan semua masalah yang ditetapkan ke tonggak sejarah dan cukup banyak yang ditutup
Saya pikir fokus kami sekarang adalah membuat seseorang berkembang :) sayangnya saya memiliki NFI di sekitar ExtJS dan Symfony jadi tidak dapat membantu ...

pilihan

  1. kami mendapatkan sponsor dan menggunakan freelancer di guru.com atau stackexchange
  2. kami mencoba dan menemukan sendiri
  3. ?

Selain itu, Anda harus memastikan untuk tidak menendang gigi seseorang dengan melepaskan kerja kerasnya tanpa menyentuhnya. Ini terjadi pada fungsi pencetakan saya dan sejak itu saya hanya melihat dari garis samping apa yang terjadi di sini. Saya juga terjebak dengan perangkat lunak yang tidak berguna di versi yang lebih baru, karena tidak ada fungsi seperti itu yang ditambahkan lagi.

Harus ada struktur yang jelas bagaimana menangani hal-hal seperti itu dan juga dengan keputusan arsitektur atau apa praktik yang baik untuk melakukan sesuatu. Proyek itu sendiri terstruktur dengan jelas dan juga orang yang bukan ahli php (tetapi ahli pemrograman dalam bahasa lain) dapat mengimplementasikan berbagai hal dengan mudah dengan bantuan kerangka kerja dan struktur yang digunakan.

@Boldie Hai Sven, mohon maaf jika pekerjaan Anda dihapus tanpa pemberitahuan.. banyak hal telah berubah dalam proyek belakangan ini dan kami sangat ingin membangun kepercayaan dari komunitas - _ terutama para pengembang _

BTW - Saya berasumsi fungsi pencetakan Anda melakukan pencetakan massal? apa yang diperlukan untuk membuatnya berfungsi lagi?

Harus ada struktur yang jelas bagaimana menangani hal-hal seperti itu dan juga dengan keputusan arsitektur atau apa praktik yang baik untuk melakukan sesuatu.

Ini sebagian besar benar tetapi karena proyek tersebut sebagian besar dikelola dalam proyek satu orang. Tidak perlu mendefinisikan aturan untuk berinteraksi dengan komunitas . Saat kami mulai membagi bobot proyek ke beberapa orang, mungkin bermanfaat untuk menentukan aturan tentang cara melanjutkan.

Proyek itu sendiri terstruktur dengan jelas dan juga orang yang bukan ahli php (tetapi ahli pemrograman dalam bahasa lain) dapat mengimplementasikan berbagai hal dengan mudah dengan bantuan kerangka kerja dan struktur yang digunakan.

Saya berasumsi Anda sendiri adalah seorang programmer untuk dapat membuat pernyataan seperti itu dengan otoritas. Saya tidak bermaksud menyinggung siapa pun tetapi sementara itu, saya pikir lebih sulit untuk membuat kaki Anda basah mengembangkan kode.

Saya mencobanya tetapi sulit. Perpustakaan sudah ketinggalan zaman dan dokumentasi tentang kode-kode lama ini jarang terjadi. Selanjutnya dokumentasi proyek (misalnya #635) tidak lengkap.
Saya tidak mengintimidasi di sini tetapi saya ingin menunjukkan beberapa masalah kritis dari perangkat lunak saat ini. Karena pengembang asli sebagian besar tidak dapat dijangkau pada saat itu, kami membutuhkan orang yang mengetahui setidaknya sebagian dari kode untuk mengembalikan semuanya ke jalurnya. Saya harap "kontributor lama" dapat membantu di sini. Ada beberapa bug yang harus dihapus tetapi masalah utamanya adalah perangkat lunak tidak lagi dipelihara dan dapat dipelihara terkait dependensi. Kita perlu menyelesaikan masalah utama, jika tidak, proyek AKAN gagal.

Jadi saya bertanya kepada Anda: Apakah Anda mengerjakan kode dan apakah Anda memiliki pengalaman dengan dependensi terkait?

BTW - Saya berasumsi fungsi pencetakan Anda melakukan pencetakan massal? apa yang diperlukan untuk membuatnya berfungsi lagi?

@Boldie , saya sarankan Anda membuka masalah baru untuk melacak fungsionalitas yang hilang. Pada titik tertentu, masalah ini di sini akan diarsipkan. Akibatnya, permintaan Anda untuk mengembalikan fungsi pencetakan akan dilupakan oleh kebanyakan orang.

BTW - Saya berasumsi fungsi pencetakan Anda melakukan pencetakan massal? apa yang diperlukan untuk membuatnya berfungsi lagi?
Terdiri dari 2 bagian :

  • Pencetakan massal StorageLocations / Parts ke pdf
  • Mencetak satu bagian (untuk label)

Yang pertama sangat terintegrasi, tetapi juga menambahkan beberapa dependensi yang bermasalah. Yang kedua mungkin diimplementasikan lagi dengan lebih baik menggunakan REST API hari ini. Itu masih dilacak di salah satu dari 200 masalah terbuka ini :)

Saya baru saja melihat kodenya: Saya memiliki beberapa masalah tentang bagaimana hal ini benar-benar berfungsi. Kerangka tampaknya menggunakan semacam kopling longgar yang sulit untuk diikuti. Mungkin seorang ahli yang menggunakan kerangka kerja ini akan mengatakan sesuatu yang berbeda (sebagian besar hari, saya memiliki kontak dengan C++ dan terkadang python dengan Django). Saya baru ingat ini juga sulit untuk mengetahui cara menambahkan beberapa hal saat saya membuat implementasi pertama saya. Masalahnya seperti yang saya lihat adalah untuk memimpin proyek ini dari kurang lebih one-man-show ke proyek berbasis komunitas. Sayangnya, saya orang yang salah untuk membantu masalah ketergantungan, tetapi saya setuju, ini harus menjadi hal pertama yang harus diselesaikan untuk mengurangi departemen teknis.

Untuk memudahkan pengembangan, saya akan menyarankan untuk menyiapkan semacam lingkungan yang dapat dengan mudah mulai dikembangkan tanpa melakukan pekerjaan dua kali. Di perusahaan saya, kami telah menyiapkan wadah buruh pelabuhan dengan barang-barang dan juga skrip untuk menjalankan tes/menambahkan data demo, ... untuk membuat pengembangan dimulai dengan mudah.

Apakah ada cara untuk menghubungi komunitas? Saya pikir sebagian besar pengguna tidak menyadari bahwa kami memerlukan bantuan di sini, jika tidak, proyek akan semakin usang dan pada suatu waktu tidak dapat digunakan lagi. Apakah mungkin untuk menempatkan pernyataan ke beranda? Karena ada sebagian besar unduhan, orang-orang dengan pengetahuan yang tepat tidak mengetahui situasi dan repositori ini di sini.

@Boldie Ide bagus! @dromer @Drachenkaetzchen apakah seseorang memiliki akses ke halaman web utama?

@christianlupus Apakah ada daftar di sini atau di tampilan tonggak pekerjaan mana yang perlu dilakukan selanjutnya? Saya pikir salah satu hal pertama adalah meningkatkan ke Symhony4 #1083 ?

@Boldie ya, ada pekerjaan yang dilakukan untuk masalah prioritas. lihat daftar ini:

https://github.com/partkeepr/PartKeepr/issues?q=is%3Aopen+is%3Aissue+label%3A%22Harus+Memiliki%22

Memutakhirkan symfony, dan dependensi lainnya, adalah yang terbesar dan terpenting saat ini.
(walaupun saya pikir tag 'masalah pertama yang baik' dimaksudkan untuk pendatang baru, bukan untuk penunjukan 'perlu dilakukan terlebih dahulu')

Apakah ada cara untuk menghubungi komunitas?
Kami bersama sejumlah pengguna di saluran #partkeepr irc di irc.freenode.net
Ada juga grup google (publik dan pribadi), tetapi saya pikir pelacak masalah + IRC adalah cara terbaik Anda untuk berbicara dengan orang-orang tentang PartKeepr saat ini (dalam hal aktivitas).

Selain itu, Anda harus memastikan untuk tidak menendang gigi seseorang dengan melepaskan kerja kerasnya tanpa menyentuhnya. Ini terjadi pada fungsi pencetakan saya dan sejak itu saya hanya melihat dari garis samping apa yang terjadi di sini. Saya juga terjebak dengan perangkat lunak yang tidak berguna di versi yang lebih baru, karena tidak ada fungsi seperti itu yang ditambahkan lagi.

Alasan saya harus menghapus fungsionalitas didokumentasikan di sini: https://github.com/partkeepr/PartKeepr/issues/622

Jika Anda merasa telah ditendang di gigi, saya minta maaf, tapi begitulah dulu.

Juga, saya menghabiskan sebagian besar waktu harian saya menulis perangkat lunak ini. tolong mengerti bahwa jika saya harus menghapus kode untuk membuat versi yang lebih baru, maka biarlah. Anda bisa membuat PR lain agar kompatibel dengan versi baru

ya, aku benar-benar marah sekarang. Saya menghabiskan bertahun-tahun menulis kode secara gratis, melakukan sebagian besar pekerjaan, melakukan banyak pekerjaan pendukung, mencoba membuat bisnis dan semua yang saya dapatkan untuk ratusan bahkan ribuan jam kerja yang tidak dibayar adalah itu.

jika bukan rasa tanggung jawab saya, saya akan menutup situs web dan yang lainnya 2 tahun yang lalu.

saya hampir tidak punya cukup uang kali ini untuk bertahan hidup sebulan, memiliki beberapa penyakit yang tidak mungkin saya sembuhkan segera dan saya masih mencoba untuk menjaga proyek ini entah bagaimana hidup, meskipun saya hampir tidak mampu melakukannya.

Juga, saya menghabiskan sebagian besar waktu harian saya menulis perangkat lunak ini. tolong mengerti bahwa jika saya harus menghapus kode untuk membuat versi yang lebih baru, maka biarlah. Anda bisa membuat PR lain agar kompatibel dengan versi baru

ya, aku benar-benar marah sekarang. Saya menghabiskan bertahun-tahun menulis kode secara gratis, melakukan sebagian besar pekerjaan, melakukan banyak pekerjaan pendukung, mencoba membuat bisnis dan semua yang saya dapatkan untuk ratusan bahkan ribuan jam kerja yang tidak dibayar adalah itu.

jika bukan rasa tanggung jawab saya, saya akan menutup situs web dan yang lainnya 2 tahun yang lalu.

saya hampir tidak punya cukup uang kali ini untuk bertahan hidup sebulan, memiliki beberapa penyakit yang tidak mungkin saya sembuhkan segera dan saya masih mencoba untuk menjaga proyek ini entah bagaimana hidup, meskipun saya hampir tidak mampu melakukannya.

Saya tahu Anda berada dalam situasi yang serius dan proyek ini termasuk komunitas memiliki kontribusi untuk situasi Anda. Saya juga menghormati pekerjaan Anda dan saya juga menganggap proyek ini (terutama dibandingkan dengan yang lain) memiliki struktur yang dikerjakan dengan baik, jika tidak, saya tidak akan mencoba memikirkan apa yang dapat saya lakukan untuk merevitalisasi proyek ini dan bagaimana menyiapkan tim pengembangan untuk melakukan pekerjaan yang diperlukan.
Saya tidak ingin menghangatkan masa lalu sekarang, Itu tidak akan membantu kita untuk melangkah lebih jauh dengan Partkeepr.

Dari pekerjaan sehari-hari saya, saya tahu terkadang sulit untuk menangani kode dari orang lain terutama jika orang tersebut tidak dapat dijangkau (untuk masa depan dan jika perlu, semua orang dapat menghubungi saya melalui alamat email dari git commits atau menggunakan domain dan hubungi saya menggunakan beranda saya). Setiap orang memiliki tulisan tangannya sendiri saat menulis coding. Menurut pendapat saya ini semacam keahlian untuk menulis kode. Saya juga memiliki banyak pengalaman dengan kompleksitas dan betapa sulitnya untuk melewati ini, jika seseorang akan melakukan pemutakhiran perpustakaan atau banyak dependensi. Saya melakukan ini dengan tim selama berbulan-bulan dalam pekerjaan saya yang dibayar.
Jadi sekarang kami menghadapi tantangan ini lagi dan kami harus memikirkan cara untuk melakukannya dengan komunitas. Ini jauh lebih menantang karena dalam lingkungan berbayar di mana orang akan berkata: Kami akan melakukannya.

Saya telah melihat kode dan karena saya melakukan sesuatu terakhir kali itu berubah BANYAK (seseorang menginvestasikan banyak pekerjaan di sini!! :). Jadi saya harus menggali kode lagi dan mulai bekerja. Tapi untuk ini kita perlu komunikasi yang erat dan roadmap apa yang harus dilakukan selanjutnya. Saya pikir mengembalikan fungsi pencetakan adalah prioritas yang sangat rendah dibandingkan dengan hal-hal lain dan saya atau orang lain dapat melakukannya nanti. Bagi saya itu lebih layak untuk tidak kehilangan data saya dengan Upgrade OS berikutnya di masa depan, karena ini berarti juga BANYAK pekerjaan untuk bermigrasi ke sesuatu yang lain (saya tidak tahu apa ini bisa), butuh kerja lama di waktu luang saya untuk mengisi database.

Terima kasih @Boldie

@christianlupus @dromer Saya pikir kita bisa menutup yang ini sekarang karena semuanya bergerak lagi...!

Satu hal lagi untuk didiskusikan: Karena perubahan pada #1091, semua masalah baru akan memiliki beberapa tag yang dilampirkan. Apakah kita ingin memiliki indikator bahwa tidak ada tinjauan manusia yang dilakukan di sini?

Terlepas dari ini, saya setuju dengan menutup masalah ini sekarang.

apa yang telah kami lakukan berbeda dengan tinjauan manusia? :)

@baradhili inilah yang kami lakukan baru-baru ini. Maksud saya sebagai berikut: sejak PR bernama diterima, masalah baru apa pun akan memiliki Bug, Permintaan Fitur, atau preset bantuan yang diinginkan sebagai label tergantung pada jenis masalah yang dipilih.
Itu berarti bahwa masalah baru (yang belum lulus triase manual yang kami lakukan baru-baru ini) tidak akan muncul dengan sendirinya tanpa label yang dilampirkan. Jadi, tidak ada filter sederhana di GitHub untuk memilih masalah yang belum diprioritaskan secara manusiawi.

Jadi singkatnya: apakah kita menginginkan need-triage atau serupa untuk ditunjukkan.

dapatkah kita menambahkan label needs-triage bawah sistem template github?

Ya, ini soal menambahkan label dan mengubah satu baris di file template. Itu sudah cukup.

Saya baru saja membuka #1097 tentang masalah sistem templating. Jika label needs-triage tidak diinginkan, saya sarankan untuk menghapus komit tunggal.

tutup ini sekarang

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

WickedAx picture WickedAx  ·  11Komentar

gfarcas picture gfarcas  ·  20Komentar

Drachenkaetzchen picture Drachenkaetzchen  ·  11Komentar

baradhili picture baradhili  ·  17Komentar

dani2bunny picture dani2bunny  ·  24Komentar