diss
1.0.0
Setelah memposting proyek ke [email protected] telah menjadi perhatian saya bahwa mereka yang berada di komunitas Foss mungkin memiliki kekhawatiran tentang penggunaan sistem devleopment berpemilik seperti GitHub.
Saya akan meninggalkan ini untuk tujuan warisan sebagai arsip upaya minggu pertama kami.
Pembaruan di masa depan akan ada di rumah proyek baru di Gitlab dan proyek baru Wiki di Gitlab.
Saya berterima kasih atas minat Anda pada proyek ini dan menyambut Anda untuk mengikuti kami di Gitlab. Saya akan berupaya memperbarui bot IRC kami di saluran pengembangan untuk mendukung pemberitahuan webhook dari sistem baru. Saya tidak akan memperbarui halaman proyek ini lebih lanjut.
Proyek dengan tujuan ambisius untuk secara sinergis mengintegrasikan semua sumber daya dukungan semua Debian dan menawarkan antarmuka yang sederhana dan intuitif untuk prosedur diagnostik yang telah teruji dengan baik.
Ini sama sekali tidak dimaksudkan untuk diganti, dan pada kenyataannya sangat tergantung pada, semua sumber daya kita yang ada. Alasan di sini adalah bahwa sistem kami tumbuh secara eksponensial dan kami adalah "OS universal", dan bahwa kami memiliki sumber daya dukungan yang terbatas dan tidak semua orang tahu bagaimana dan dalam urutan apa untuk menggunakan semuanya dengan benar yang menghasilkan banyak masalah yang terkenal dan mudah diamati.
Dukungan Tim Burnout Melalui Penanganan Berulang, masalah yang diketahui yang telah kami selesaikan, harus menjelaskan prosedur dan kebijakan kami, dan mengumpulkan (kadang -kadang mencabut) informasi yang relevan dengan masalah yang dihadapi, dll
Keterasingan pengguna melalui kurangnya pemahaman tentang sistem, dan interaksi yang tidak produktif dengan pendukung dan semacamnya. Ini adalah pola pikir yang terdokumentasi dengan baik di antara beberapa pendukung terbaik kami, saya sendiri termasuk bahwa kami tidak benar -benar menginginkan pengguna seperti itu yang tidak berpengalaman karena mereka hanya akan menjadi daya tarik sumber daya kami tanpa berkontribusi pada proyek kami. Ini juga merupakan fakta yang mudah diamati bahwa pengembang dan pengguna yang lebih berpengalaman sering kali adalah orang terakhir yang menemukan bug dan masalah karena mereka tidak hanya cenderung kurang suka bertualang dalam mencoba perangkat lunak yang berbeda karena mereka sudah tahu apa yang mereka sukai dan gunakan, dan mereka menggunakannya dengan cara yang dimaksudkan untuk digunakan. Dibutuhkan seseorang yang tidak berpengalaman untuk mencoba segala macam opsi dan menggunakan hal -hal dengan cara yang akan mengungkap kesalahan yang tidak jelas. Ini adalah komoditas yang berharga untuk memiliki banyak pengguna yang tidak berpengalaman menjelajahi basis perangkat lunak kami yang terus berkembang, mengungkap masalah yang seharusnya kami lewatkan. Namun kita perlu memastikan bahwa umpan balik yang kita dapatkan dari sumber daya yang berharga ini bermakna dan berakhir di tempat yang tepat tanpa masalah yang disebutkan di atas, sehingga kita membutuhkan jenis filter yang melayani kebutuhan mereka dan juga milik kita.
Kita juga perlu memastikan bahwa semua upaya menuju kedua masalah itu digunakan. Itulah kami tidak dapat terus membuat pengguna datang kepada kami dengan kepentingan diri sendiri dalam memecahkan masalah, dan upaya itu kurang dimanfaatkan karena tidak didokumentasikan dengan benar. Beberapa pengguna kembali dan berbagi solusi untuk masalah, kadang -kadang kita akhirnya membuat factoid tentang hal itu, kadang -kadang akhirnya ada halaman wiki, laporan bug, dll. Tetapi sebagian besar waktu yang tidak terjadi. Selain itu, kami tidak selalu tahu ini telah dilakukan ketika masalah muncul lagi. Sistem kami saat ini bergantung pada pendukung kami untuk mengingat hal -hal ini, dan ketika orang -orang yang mengingatnya tidak melihat pada saat itu, kami dapat akhirnya jatuh kembali ke masalah #2 dan mengasingkan pengguna kami, atau tidak mendapatkan masalah yang didokumentasikan atau diselesaikan sama sekali, bahkan secara tidak efektif.
Klien/Frontend (Readline, Kutukan, GTK, QT), Diagnostik (File Pohon Diagnostik yang Ditandatangani), Bot (IRC), Server (Pelacak Masalah)
The client will be a reportbug style wizard that will allow a user to select a program (on lower skill levels, use generic names like "filemanager" and have it automatically detect the actual program name or use a grab fuction where the user can click on a window and get the command) and enter a description of their issue and should have various classes of issues (Network, Sound, Crashes, Build errors, Package system problems, etc.) and optionally a CC address (email can be masked by the tracker with ID masalah dan email bangkit kembali ke pengguna untuk privasi, dengan kemampuan bagi pengguna untuk kemudian memilih keluar dari CC lebih lanjut dengan mengirim email kepada pelacak dengan ID yang mengatakannya untuk berhenti).
Tingkat pertama kemudian akan menggunakan diagnostik untuk melakukan tes sederhana dan meminta pertanyaan lebih lanjut, dan mengumpulkan informasi dan menyusun laporan/log tentang masalah ini.
Log kemungkinan besar harus diuraikan/diserialisasi/disterilkan untuk menghapus atau mengganti data pribadi seperti IP, ID Mac, nama pengguna, bahkan mungkin jalur/nama file dan menggantinya dengan yang generik seperti 1.2.3.4 atau 12: 34: 56: 78: 90 atau semacamnya.
Maka jika masalahnya tidak dapat diselesaikan melalui proses diagnostik otomatis yang mengidentifikasi masalah berdasarkan solusi sederhana yang terkenal, usang, dan teruji pertempuran, klien akan melakukan persis seperti yang dilakukan ReportBug dan mencari laporan bug (dan/atau posting forum/wiki) dan menampilkannya kepada pengguna dari database pengetahuan yang sudah ada.
Jika masalah ini tetap belum terpecahkan, maka dalam tingkat ke -3 memfasilitasi penerusan masalah ini ke pelacak masalah dan memberikannya nomor ID, kemudian meneruskannya ke alat pendukung kami (IRC/mailing list) yang sudah kami miliki, dari dalam klien itu sendiri, dan jika IRC digunakan dalam piano. Tidak menerima solusi atau memutuskan untuk pergi, masalah ini kemudian dapat tetap terbuka dan/atau diteruskan ke milis dan mereka dapat menindaklanjuti dengan mengunjungi situs web pelacak dengan nomor ID mereka atau dengan menerima pemberitahuan email tentang masalah dari pelacak.
Jika masalah ini masih belum diselesaikan, itu dapat diteruskan ke tingkat ke -4 yang akan menjadi hal seperti BTS (mengajukan laporan tentang BTS, karena ditentukan untuk menjadi masalah perangkat lunak oleh para pendukung), atau mungkin di hulu.
File -file pohon diagnostik mungkin dapat berupa semacam XML atau semacamnya, dan perlu ditandatangani dan diverifikasi, pohon diagnostik inti akan sangat mirip dengan apa yang dilakukan oleh ReportBug, itu hanya akan mengumpulkan beberapa informasi awal tentang sistem dan memverifikasi bahwa itu adalah hal yang sama, dan apa yang disebabkan oleh pembagian pohon, dll. Yang lain yang akan dikembangkan dan dikelola dengan spesifik dari waktu ke waktu, dan sumber yang lebih baik, dll. Yang lain yang akan dikembangkan dan dipelihara dengan spesifik dari waktu ke waktu, dan sumber yang lebih baik, dll. Yang lain yang akan dikembangkan dan dipelihara dengan spesifik dari waktu ke waktu, dan sumber yang tepat, Uji suara dan tanyakan kepada pengguna apakah mereka mendengar suara, periksa mixer mereka, minta mereka untuk memeriksa koneksi mereka, dll.
File -file pohon diagnostik ini juga akan memfasilitasi pengumpulan informasi lebih lanjut dengan menjalankan perintah yang mengumpulkan lebih banyak informasi khusus untuk jenis masalah yang dimaksud. Perintah -perintah ini perlu ditampilkan dan dijelaskan kepada, dan diverifikasi oleh pengguna, serta laporan/log/output ditampilkan dan (secara opsional) diuraikan/diserialisasi/disterlized untuk menghapus informasi pribadi apa pun. Diagnostik ini perlu ditandatangani dan dinilai, dan pelacak masalah akan memfasilitasi melakukannya dengan cara yang sama seperti sistem peringkat forum yang baik, hanya menggunakan tanda tangan GPG, dan menilai solusi tidak hanya akan menyebabkan klien menandatangani bahwa diagnostik kepercayaannya, tetapi juga meningkatkan kepercayaan para pendukung yang berkontribusi pada porsi diagnostik tersebut.
Kapan pun memungkinkan, semua mekanisme keamanan yang tersedia dari hal-hal seperti chroots hingga mekanisme keamanan berbasis kernel harus digunakan untuk mengunci hal-hal yang diagnostik, dan mereka harus sederhana dan tidak mengganggu mungkin. Kami tidak ingin membuat alat diagnostik yang hidup, hanya beberapa pemeriksaan sederhana untuk masalah konfigurasi yang diketahui, tes sederhana, dan mengkompilasi data untuk dukungan lebih lanjut.
The IRC bot should be not only a conduit/proxy for the user to the IRC support channels (up for much debate) perhaps speaking on the user's behalf in the channel with a generated user ID or issue number, which will not only allow us to ensure the user only sees stuff related to their issue, but that the issue tracker knows what support responses belong to the issue for later documentation of the issue and solution back to our existing tools like the wiki, forums, mailinglists and seperti. Ini dapat dilakukan dengan berbagai cara, dan skrip klien IRC dapat ditulis atau fitur klien yang digunakan untuk melengkapi ID ini seperti nick normal, atau mungkin pendukung dapat mengirim pesan kepada bot untuk "masuk" ke masalah sehingga berbicara dengan bot mengirimkan info kembali ke pengguna yang Anda tandatangani.
Bot juga akan memfasilitasi akses ke laporan yang dikompilasi dengan informasi yang dikumpulkan oleh diagnostik dan diserahkan oleh pengguna, elminating semua obrolan tentang menjalankan perintah yang sangat umum dan menggunakan pastebin dan semacamnya. Selain itu bot mungkin bisa berperilaku sebagai antarmuka klien untuk membuka masalah baru di pelacak (mungkin bahkan jika dianggap perlu, hanya oleh pendukung yang diketahui dan terdaftar) oleh seseorang dalam klien IRC mandiri yang normal.
Singkatnya bot adalah lem yang mengikat diss ke saluran dukungan IRC, dan perawatan harus diambil untuk memastikan bahwa info berakhir di saluran yang tepat tergantung pada bahasa pilihan pengguna, cabang Debian, dan mungkin bahkan paket atau masalah apa yang mereka miliki, karena kami memiliki saluran tertentu untuk hal -hal yang menghubungkannya (dengan demikian menghilangkan kebutuhan mereka untuk merujuk pada orang lain.
Pelacak akan berisi metadata mengenai masalah ini, itu akan menghasilkan pengidentifikasi masalah, melacak alamat CC yang disediakan pengguna, dan di mana laporan tersebut (pasta.debian.net kemungkinan besar), dan status masalah, serta forum, milis, BTS, atau hal lain yang disebabkan oleh klien atau pendukung yang dihubungkan dengan masalah ini. Seharusnya tidak menjadi semacam wiki atau forum baru di dalam dan dari dirinya sendiri, hanya frontend yang menghubungkan dan menempelkan semuanya bersama dengan metadata tentang masalah ini. Seharusnya memiliki antarmuka web yang mirip dengan BTS.
Masalah dan bug berbeda; Bug adalah masalah aktual dalam perangkat lunak, di mana masalah paling sering hanya Pebcak atau semacamnya. Inilah sebabnya mengapa perlu untuk membuat pelacak baru, karena yang satu ini hanya berfungsi untuk melacak masalah jangka pendek dan memastikan itu sampai ke tempat peristirahatan terakhir yang tepat. Pelacak akan memberikan bot dan klien informasi yang diperlukan untuk membuat factoid di bot info kami yang ada, mengajukan laporan bug, atau mengeluarkan email ke milis, dan berfungsi sebagai tempat di mana setiap pihak yang berkepentingan dapat mengetahui hal -hal mana yang telah terjadi dan di mana menemukannya. Ini bukan pengganti, tetapi pembungkus, semua sistem kita yang ada. Ini adalah lem yang mengikat semua komponen dari diss, termasuk semua yang sudah kita miliki.
Telah disarankan berkali -kali bahwa kami hanya meningkatkan sistem yang ada, dan itu adalah bagian dari ini, tetapi bukan bukannya ini. Itu masih akan memiliki masalah pengguna #2 yang mengasingkan pengguna karena mereka perlu tahu tentang dan bagaimana menggunakan hal -hal itu. Ini akan menjadi perangkat lunak dalam OS itu sendiri yang mengintegrasikan dan memfasilitasi menggunakan semua itu dengan cara yang intuitif yang tidak memerlukan satu tahun atau lebih kebijakan dan praktik pembelajaran.
Sehubungan dengan peningkatan sistem yang ada, proyek ini dan kontributornya akan berusaha untuk menyatukan pendaftaran di setiap dan semua sistem pendukung Debian yang membutuhkan pendaftaran, dan bekerja dengan tim saat ini dari sistem tersebut untuk mengintegrasikannya bersama secara sinergis.
Selain itu, sistem yang ada dapat digunakan/diadaptasi pada saat descretion pengembang saat ini yang bekerja di area lain, misalnya BTS dan pelacak dapat menjadi satu dan sama, dan "masalah" ini hanya dapat menjadi kelas yang jauh lebih rendah yang tidak perlu dikerjakan oleh pelapor dan pelaporan yang tidak perlu dikenakan, dan alas yang ada di bawah, dan alas yang ada di for -for yang ada untuk menjadi for -forcing yang ada untuk menjadi for -forcing yang dapat dikenakan oleh IRC yang dapat dikerjakan dengan alas yang dapat dipasang oleh IRC. Ini bukan hanya proyek yang bertujuan untuk membuat satu perangkat lunak baru, tetapi untuk mengadaptasi semua yang kita miliki sekarang untuk melayani kita dengan lebih baik ke depan.
Kami membutuhkan programmer. Mereka yang terampil dengan Python karena tampaknya cocok untuk tugas -tugas ini, mudah untuk kode dan cukup kuat dan fleksibel untuk mengembangkan hal -hal yang kita butuhkan dengan lebih sedikit ketergantungan di luar sistem dasar. Mereka yang terampil dengan sistem dan layanan berbasis kepercayaan, tanda tangan GPG, dll. Mereka yang memiliki pengalaman pemrograman GUI/Frontend. Mereka yang akrab dengan proses pengembangan Debian dan semua kekhawatiran pengguna dan pengembang. Mereka yang dapat memprogram tumpukan jaringan klien/server menggunakan soket, http, protokol email, dll. Mereka yang dapat mengembangkan API yang kuat untuk sistem pendukung Debian untuk berkomunikasi secara efektif, yang akan membutuhkan pengetahuan tentang mengintegrasikan aplikasi di dalam dan di luar web.
Kami membutuhkan input dan perencanaan di sekitar sistem kami yang ada, upaya oleh tim yang ada dan membantu mereka untuk memasukkan sistem kredensial login Debian yang seragam yang akan bekerja di semua situs dan layanan Debian.
Kami membutuhkan orang -orang yang akan bekerja pada dokumentasi dan berinteraksi dengan kehadiran web proyek ini, menjaga informasi status dan tujuan proyek dan didefinisikan dengan jelas.
Proyek ini baru saja dimulai pada dini hari Jumat 13 Oktober 2017, sekitar pukul 02:00 waktu US/EST. Sampai tulisan ini kita bahkan tidak 24 jam, dan kita sudah memiliki setengah lusin orang yang nongkrong di saluran, dan tanggapan di berbagai forum. Kita semua hanya noodling pada saat ini, melemparkan ide -ide dan mencoba dengan cermat membuat keputusan awal yang akan membentuk proyek dan desainnya.
Tujuan pertama di sini adalah untuk membangun kehadiran web yang kuat dengan wiki dan sedemikian rupa sehingga akan membuat anatomi sistem terintegrasi ini dan kemajuannya, sehingga orang dapat memahami dari mana kita berasal, ke mana kita pergi, dan seberapa jauh kita berada.
Tujuan kedua di sini adalah untuk menyempurnakan API yang akan menentukan fitur dan komunikasi dari sistem ini, dan saya bukan programmer yang sangat berpengalaman tetapi saya telah melihatnya dilakukan selama beberapa dekade, bahwa kadang -kadang Anda harus membuat sesuatu (alat) untuk membuat sesuatu yang lain, dan dalam hal ini saya pikir mulai bekerja pada antarmuka klien, khususnya frontend GUI akan secara inheren dikeluarkan API. Dan pada awalnya tanpa pelacak masalah, masalah tidak akan gigih, itu hanya akan menjadi klien yang berbicara dengan bot yang belum sempurna yang kemungkinan tinggal di saluran pengembangan kami.
Harus ditekankan bahwa ini bukan sesuatu yang ingin kami dorong dan sebarkan dengan cepat, kami ingin mendapatkan beberapa kerangka kerja dan melakukan pengujian alfa yang luas di luar saluran normal, pada awalnya tanpa modifikasi pada layanan yang ada untuk membantu memfasilitasi integrasi, karena API belum ada. Setelah kami memiliki komponen kerja dan minat pemelihara dan mereka yang sudah berada di dalam lingkaran pengembang Debian, kami ingin memulai fase pengujian beta hanya untuk digunakan pada pengujian non-produksi/sistem yang tidak stabil. Setelah ada kepercayaan pada implementasi mekanisme kepercayaan yang aman untuk diagnostik, sistem ini dapat benar -benar dikemas untuk SID dan mudah -mudahan digulung ke dalam rilis stabil Debian di masa depan. File diagnostik kemungkinan besar akan menggunakan semacam repositori yang dapat memungkinkan mereka untuk dikembangkan dari waktu ke waktu dan diimplementasikan ke dalam klien tanpa menunggu siklus rilis Debian baru, berdasarkan pada proses pengujian dan penandatanganan/verifikasi yang terpisah.
Jangka panjang, kami ingin melihat Debian Installer memiliki tekad keterampilan yang lebih kuat sebagai langkah pertama, dengan lebih dari sekadar mode instalasi normal/ahli, dan klien dukungan ini secara otomatis diinstal secara default pada sistem yang tidak memilih tingkat lanjutan atau ahli. Kami ingin melihat semua pendukung kami berpartisipasi tidak hanya dalam dukungan jarak bebas, tetapi mendaftar ke sistem berbasis kepercayaan dan menggunakan tanda tangan GPG, sehingga basis pengetahuan kami dapat lebih berkualitas dan lebih tepercaya.
Diss Wiki
Utas reddit
Forum Debian Tapak
Utas milis debian-proyek
Utas milis debian-devel
Utas milis debian-user
Posting Terkait dari Mailing Debian Project pada Maret 2017
