diss
1.0.0
Nachdem ich ein Projekt an [email protected] veröffentlicht hatte, ist mir auf mich aufmerksam, dass diejenigen in der FOSS-Community Bedenken hinsichtlich der Verwendung eines proprietären Devleopment-Systems wie Github haben.
Ich werde dies als Archiv für die Bemühungen unserer ersten Woche für alte Zwecke verlassen.
Zukünftige Updates finden Sie im neuen Projekthaus in Gitlab und dem neuen Projekt Wiki auf Gitlab.
Ich danke Ihnen allen für Ihr Interesse an diesem Projekt und begrüße Sie, uns auf Gitlab zu folgen. Ich werde daran arbeiten, unseren IRC -Bot im Entwicklungskanal zu aktualisieren, um Webhook -Benachrichtigungen über das neue System zu unterstützen. Ich werde diese Projektseite nicht weiter aktualisieren.
Projekt mit dem ehrgeizigen Ziel, alle Support-Ressourcen von Debian synergistisch zu integrieren und eine einfache und intuitive Schnittstelle für gut getestete diagnostische Verfahren anzubieten.
Dies ist keineswegs dazu gedacht, alle unsere vorhandenen Ressourcen zu ersetzen und in der Tat sehr stark abhängig. Das Begründung hier ist, dass unser System exponentiell wächst und wir "das universelle Betriebssystem" sind und dass wir nur begrenzte Unterstützungsressourcen haben und nicht jeder weiß, wie und in welcher Reihenfolge sie alle ordnungsgemäß verwenden, was zu vielen bekannten und leicht beobachtbaren Problemen führt.
Support -Team Burnout durch wiederholte Handhabung, die bekannten Probleme, die wir bereits gelöst haben, unsere Verfahren und Richtlinien erläutern und Informationen (manchmal herausfinden) Informationen sammeln, die für das vorliegende Problem relevant sind, usw.
Benutzern Sie die Entfremdung durch mangelnder Verständnis der Systeme und unproduktive Interaktion mit Anhängern und dergleichen. Es war eine gut dokumentierte Denkweise bei einigen unserer besten Unterstützer, ich selbst eingeschlossen, dass wir diese Art von Nutzern, die unerfahren sind, nicht wirklich wollen, weil sie nur unsere Ressourcen einziehen werden, ohne zu unserem Projekt beizutragen. Es ist auch eine leicht beobachtbare Tatsache, dass die Entwickler und erfahreneren Benutzer oft die letzten Personen sind, die Fehler und Probleme finden, da sie nicht nur weniger abenteuerlustig sind, wenn sie eine andere Software ausprobieren, weil sie bereits wissen, was sie mögen und verwenden, und sie so verwenden, wie es verwendet werden sollte. Es braucht jemanden, der unerfahren ist, um alle möglichen Optionen auszuprobieren und Dinge auf eine Weise zu verwenden, die obskure Fehler aufdeckt. Dies ist eine wertvolle Ware, um eine Menge unerfahrener Benutzer über unsere ständig wachsende Softwarebasis durchsuchen und Probleme aufdecken, die wir sonst vermissen würden. Wir müssen jedoch sicherstellen, dass das Feedback, das wir aus dieser wertvollen Ressource erhalten, aussagekräftig ist und am richtigen Ort endet, ohne dass das oben erwähnte Problem auftritt. Daher benötigen wir eine Art Filter, die sowohl ihren Bedürfnissen als auch unseren Bedürfnissen gerecht werden.
Wir müssen auch sicherstellen, dass alle Anstrengungen gegen diese beiden Probleme verwendet werden. Das heißt, wir können nicht weitermachen, wenn Benutzer mit Eigeninteresse an der Lösung eines Problems zu uns kommen, und dass diese Anstrengungen nicht ausreichend ausgelastet wurden, da es nicht ordnungsgemäß dokumentiert wurde. Einige Benutzer kommen zurück und teilen Lösungen für Probleme. Manchmal erstellen wir ein Faktoid darüber, manchmal gibt es eine Wiki -Seite, einen Fehlerbericht usw., aber die meiste Zeit ist dies nicht der Fall. Darüber hinaus wissen wir nicht immer, dass dies getan wurde, wenn das Problem wieder auftaucht. Unser aktuelles System stützt sich auf unsere Unterstützer, die sich an diese Dinge erinnern, und wenn die Leute, die sich daran erinnern, nicht zu der Zeit eingeschaut, können wir wieder in Ausgabe 2 zurückfallen und unsere Benutzer entfremden oder das Problem überhaupt nicht effektiv dokumentiert oder gelöst werden.
Client/Frontend (Readline, Flüche, GTK, QT), Diagnostik (signierte Diagnosebaumdateien), Bot (IRC), Server (Problemverfolger)
Der Kunde ist ein Assistenten im Berichtsbug -Stil, mit dem ein Benutzer ein Programm auswählen kann (auf niedrigeren Skill -Levels, generische Namen wie "Filemanager" und automatisch den tatsächlichen Programmnamen oder die Verwendung einer Grabfuktion, bei der der Benutzer auf ein Fenster klicken und den Befehl eingeben kann) und die Beschreibung seiner Ausgabe eingeben kann. Mit einer Ausgabe -ID und einer E -Mail, die an den Benutzer zurückgegriffen hat, um Privatsphäre zu erhalten, kann der Benutzer den weiteren CC abmelden, indem sie den Tracker per E -Mail an die ID senden, die ihm anfält, zu stoppen).
Die erste Stufe verwendet dann Diagnostik, um einfache Tests durchzuführen und weitere Quetionen zu fragen, Informationen zu sammeln und einen Bericht/Anmelden zu diesem Problem zu kompilieren.
Die Protokolle sollten höchstwahrscheinlich analysiert/serialisiert/sterilisiert werden, um personenbezogene Daten wie IPS, MAC -IDs, Benutzernamen, möglicherweise sogar Pfad/Dateinamen zu entfernen oder zu ersetzen und sie durch generische wie 1.2.3.4 oder 12: 34: 56: 78: 90 oder so zu ersetzen.
Wenn das Problem dann nicht durch automatische diagnostische Prozesse gelöst werden kann, die das Problem basierend auf bekannten, abgenutzten und kattgetesteten einfachen Lösungen identifizieren, tut der Kunde in der zweiten Stufe genau so, wie Reportbug und Suchbugsberichte (und/oder Forum/Wiki-Beiträge) und an den Benutzer aus vorhandenen Wissensdatenbäumen angezeigt werden.
Wenn das Problem ungelöst bleibt, wird es in der dritten Stufe die Weiterleitung des Problems an den Ausgaber Tracker erleichtern und ihm eine ID -Nummer angeben, und dann an unsere Support -Tools (IRC/Mailing -Listen) weiterleiten, die wir bereits aus dem Kunden selbst haben. Der Benutzer erhalten keine Lösung oder beschließt zu gehen, das Problem kann dann geöffnet bleiben und/oder an Mailinglisten weitergeleitet werden. Sie können nachverfolgen, indem sie die Tracker -Website mit ihrer ID -Nummer besuchen oder E -Mail -Benachrichtigungen über das Problem vom Tracker ergeben.
Wenn das Problem immer noch nicht gelöst ist, kann es an die 4. Stufe weitergeleitet werden, die Dinge wie die BTS (die Einreichung des Berichts über die BTS einreichen, da es von den Anhängern als Softwareproblem eingestuft wird) oder möglicherweise vorgelöst.
Die Diagnostik -Baumdateien können möglicherweise eine Art XML oder dergleichen sein und müssen unterschrieben und verifiziert werden. Der Kerndiagnosebaum ist ähnlich wie Reportbug, er sammelt nur einige vorläufige Informationen über das System und vergewissern sich, dass es debian debian ist, welche Version, Arch, und welche Quellen vorhanden sind. Wie einen Tontest durchführen und den Benutzer fragen, ob er den Sound gehört hat, überprüfen Sie den Mixer, bitten Sie ihn, seine Verbindungen usw. zu überprüfen.
Diese diagnostischen Baumdateien ermöglichen auch weitere Informationen, die das Sammeln von Befehlen ausführen, die mehr Informationen für die Art des fraglichen Problems sammeln. Diese Befehle müssen vom Benutzer angezeigt und erklärt und verifiziert werden sowie die Berichte/Protokolle/Ausgabe angezeigt und (optional) analysiert/serialisiert/sterlisiert, um alle persönlichen Daten zu entfernen. Diese Diagnostik muss unterschrieben und bewertet werden, und der Problem Tracker ermöglicht dies auf die gleiche Weise, dass ein gutes Forum -System nur mit GPG -Signaturen verwendet wird, und die Bewertung einer Lösung führt nicht nur dazu, dass der Klient das diagnostische Erhöhung seines Vertrauens erhöht, sondern auch das Vertrauen der Anhänger erhöht, die zu diesen Teilen des Diagnostiks zu diesen Teilen der Diagnose führen.
Wann immer möglich, sollten alle Sicherheitsmechanismen, die von Dingen wie Chroots bis hin zu Kernel-basierten Sicherheitsmechanismen zur Verfügung stehen, eingesetzt werden, um die Dinge zu sperren, die Diagnostika tun, und sie sollten so einfach und ungehindert wie möglich sein. Wir möchten kein empfindungsfähiges Diagnose -Tool erstellen, nur ein paar einfache Überprüfungen für bekannte Konfigurationsprobleme, einfache Tests und kompilierte Daten zur weiteren Unterstützung.
Der IRC -Bot sollte nicht nur ein Kanäle/Proxy für den Benutzer der IRC -Supportkanäle sein (auf viel Debatte). solch. Dies kann verschiedene Arten erfolgen, und IRC-Client-Skripte können geschrieben werden oder Clientfunktionen, mit denen diese IDs wie ein normaler Nick erledigt werden können, oder möglicherweise kann ein Unterstützer den Bot an ein Problem anstellen, sodass das Gespräch mit dem Bot Informationen an den Benutzer zurücksendet, für den Sie sich angemeldet haben.
Der Bot erleichtert auch den Zugriff auf den kompilierten Bericht mit Informationen, die vom Diagnose gesammelt und vom Benutzer eingereicht wurden, wodurch das gesamte Geschwätz über die Ausführung von sehr verbreiteten Befehlen und die Verwendung von Pastebins und dergleichen entsteht. Darüber hinaus könnte sich der Bot möglicherweise als Client -Schnittstelle für die Eröffnung eines neuen Problems im Tracker (möglicherweise auch bei notwendig erachtet, nur von einem bekannten und registrierten Unterstützer) durch jemanden in einem normalen eigenständigen IRC -Kunden verhalten.
Kurz gesagt, der Bot ist der Klebstoff, der Diss an die IRC -Unterstützungskanäle bindet, und es sollte darauf geachtet werden, dass die Info im richtigen Kanal abhängig von der bevorzugten Sprache des Benutzers, dem Zweig von Debian, und vielleicht sogar über das Paket oder die Ausgabe von Hässern, die sie haben, da wir spezifische Kanäle für Differenzierung haben.
Der Tracker enthält Metadaten bezüglich des Problems, generiert eine Ausgabekennung, verfolgt eine CC -Adresse, die der Benutzer angegeben hat, und wo die Berichte (paste.debian.net höchstwahrscheinlich) und der Status des Problems sowie eines beliebigen Forums, Versandlisten, BTS oder anderen Dingen, die die Clients oder Anhänger dazu veranlassen, zu diesem Problem verbunden zu sein. Es sollte kein neues Wiki oder Forum an sich sein, nur ein Frontend, das alles mit Metadaten über das Problem verbindet und klebt. Es sollte eine Weboberfläche haben, die der BTS ähnelt.
Probleme und Fehler sind unterschiedlich; Fehler sind tatsächliche Probleme in der Software, bei denen Probleme am häufigsten nur Pebcak oder dergleichen sind. Aus diesem Grund ist es notwendig, einen neuen Tracker zu erstellen, da dieser nur für kurzfristige Track das Problem dient und sicherstellt, dass er an den richtigen endgültigen Ruhestätte kommt. Der Tracker stellt dem Bot und dem Kunden die Informationen zur Verfügung, die erforderlich sind, um in unseren vorhandenen Info -Bots einen Faktoid zu erstellen, einen Fehlerbericht einzureichen oder eine E -Mail an Mailinglisten auszugeben und als Ort zu dienen, an dem eine interessierte Partei herausfinden kann, welche dieser Dinge stattgefunden haben und wo sie finden können. Es ist kein Ersatz für alle unsere vorhandenen Systeme. Es ist der Kleber, der alle Komponenten des Diss bindet, einschließlich aller, die wir bereits haben.
Es wurde oft vermutet, dass wir einfach vorhandene Systeme verbessern, und das ist ein Teil davon, aber es ist nicht anstelle dessen. Das hätte immer noch das Problem der Ausgabe Nr. 2, die Benutzer entfremdet, da sie wissen und wie man diese Dinge benutzt. Dies wäre eine Software im Betriebssystem selbst, die all das auf intuitive Weise integriert und erleichtert, was kein Jahr oder mehr Lernpolitik und -praxis erfordert.
In Bezug auf die Verbesserung bestehender Systeme werden dieses Projekt und seine Mitwirkenden versuchen, die Registrierung in allen Debian -Support -Systemen zu vereinen, die Registrierung erfordern, und mit den aktuellen Teams dieser Systeme zusammenzuarbeiten, um sie auf synergistische Weise zusammen zu integrieren.
Darüber hinaus können vorhandene Systeme bei der Beschreibung der aktuellen Entwickler verwendet/angepasst werden, beispielsweise die BTS und der Tracker können ein und dasselbe sein, und diese "Probleme" können nur eine viel niedrigere Klasse von Fehler sein, mit denen der Betreuer nicht gestört wird, und der Bericht kann nur erweitert werden, um diese anderen Merkmale zu erfüllen. Die erforderlichen Funktionen, und es kann sich um die benötigten Funktionen handeln, und es kann sich um die benötigten Funktionen handeln, und es kann sich um die benötigten Funktionen handeln, und es kann sich um die benötigten Funktionen handeln, und es kann sich um die benötigten Funktionen handeln, und es kann sich um die benötigten Funktionen handeln, und es kann sich um die benötigten Funktionen handeln, und es können sich um die benötigten Funktionen und die erforderlichen Funktionen hinzufügen, um die benötigten Funktionen zu erweitern, und das IRC -Bot, das die benötigten Funktionen erfolgt, und addieren, um die erforderlichen Merkmale zu erfüllen, kann die erforderlichen Funktionen erweitert werden. Dies ist nicht nur ein Projekt, das darauf abzielt, eine einzige neue Software zu erstellen, sondern alles, was wir jetzt haben, um uns in Zukunft besser zu dienen.
Wir brauchen Programmierer. Diejenigen, die mit Python geschickt wurden, da es für diese Aufgaben gut geeignet zu sein scheint, leicht zu codieren und leistungsstark und flexibel genug, um die Dinge zu entwickeln, die wir mit weniger Abhängigkeiten außerhalb des Basissystems benötigen. Diejenigen, die mit vertrauensbasierten Systemen und Diensten, GPG -Signaturen usw. geschickt wurden, diejenigen mit GUI/Frontend -Programmierungserfahrung. Diejenigen, die mit dem Debian -Entwicklungsprozess und allen Bedenken von Benutzern und Entwicklern gleichermaßen vertraut sind. Diejenigen, die Client/Server -Netzwerkstapel mit Sockets, HTTP, E -Mail -Protokollen usw. programmieren können, usw. Diejenigen, die eine robuste API für Debian -Support -Systeme entwickeln können, um effektiv zu kommunizieren, die Kenntnisse über die Integration von Anwendungen im und außerhalb des Webs erfordern.
Wir benötigen Input und Planung in Bezug auf unsere vorhandenen Systeme, die Anstrengungen der vorhandenen Teams und helfen ihnen, ein einheitliches Debian -Login -Anmeldeinformationssystem aufzunehmen, das auf allen Debian -Websites und -diensten funktioniert.
Wir brauchen Personen, die an der Dokumentation und Vernetzung mit der Webpräsenz dieses Projekts arbeiten, um die Statusinformationen und -projekte (n) und so klar definiert zu halten.
Dieses Projekt begann gerade in den frühen Morgenstunden des Freitags, dem 13. Oktober 2017, gegen 2 Uhr morgens/EST. Zum jetzigen Zeitpunkt sind wir nicht einmal 24 Stunden und haben bereits ein halbes Dutzend Menschen im Kanal und Antworten in verschiedenen Foren. Wir alle sind zu diesem Zeitpunkt nur nudeln, werfen Ideen herum und versuchen, vorläufige Entscheidungen zu treffen, die das Projekt und sein Design beeinflussen.
Das erste Ziel hier ist es, eine feste Webpräsenz mit einem Wiki zu etablieren und die Anatomie dieses integrierten Systems und den Fortschritt zu erstellen, damit die Menschen verstehen können, woher wir kommen, wohin wir gehen und wie weit wir sind.
Das zweite Ziel hier ist es, eine API zu erfassen, die die Funktionen und die Kommunikation dieses Systems definiert, und ich bin kein sehr erfahrener Programmierer, aber ich habe es seit Jahrzehnten gesehen, dass Sie manchmal etwas (ein Werkzeug) machen müssen, um etwas anderes zu machen, und in diesem Fall denke ich, dass die Arbeit an der Kundenschnittstelle anfängt, insbesondere die GU -Frontend, die die API aus der API ausgeht. Und zunächst ohne einen Problemverfolger, Probleme werden nicht beständig sein, es wird einfach ein Kunde sein, der mit einem rudimentären Bot spricht, der wahrscheinlich in unserem Entwicklungskanal lebt.
Es sollte betont werden, dass dies nicht etwas ist, das wir schnell herausschieben und einsetzen möchten. Wir möchten einen Arbeitsrahmen erhalten und umfangreiche Alpha-Tests außerhalb normaler Kanäle durchführen, zunächst ohne Änderung vorhandenen Diensten, um die Integration zu erleichtern, da die API noch nicht vorhanden ist. Sobald wir Arbeitskomponenten und Interesse an einem Betreuer und denjenigen im Debian Developer Circle haben, möchten wir eine Beta-Testing-Phase nur für Nichtproduktionstests/instabile Systeme starten. Sobald es Vertrauen in die Implementierung sicherer Vertrauensmechanismen für die Diagnostik gibt, kann das System tatsächlich für SID verpackt und hoffentlich in eine zukünftige stabile Debian -Veröffentlichung verwandelt werden. Die Diagnostikdateien werden höchstwahrscheinlich eine Art Repository verwenden, mit dem sie im Laufe der Zeit entwickelt und in den Client implementiert werden können, ohne auf einen neuen Debian -Release -Zyklus zu warten, der auf einem separaten starren Test- und Signier-/Überprüfungsprozess basiert.
Langfristig möchten wir sehen, dass Debian Installer eine robustere Fähigkeitsbestimmung als erster Schritt hat, mit mehr als nur einem normalen/Experten -Installationsmodus, und dieser Support -Client wird automatisch standardmäßig auf Systemen installiert, die keine fortgeschrittenen oder Expertenniveaus auswählen. Wir möchten, dass alle unsere Unterstützer nicht nur an der Freilandunterstützung teilnehmen, sondern sich auch in ein vertrauenswürdiges System registrieren und GPG-Signaturen verwenden, damit unsere Wissensbasis qualitativ hochwertiger und vertrauenswürdiger sein kann.
Diss wiki
Reddit -Thread
Debian -Foren treten
Debian-Project Mailing List-Thread
Debian-Devel Mailing List-Thread
Debian-User Mailing List-Thread
Verwandte Beitrag von der Debian-Project Mailingliste im März 2017
