Partkeepr: Meta: Zu viele offene Fragen

im Grunde erstellen wir also einen de-facto "Backlog"...
@Drachenkaetzchen Bist du offen dafür, ein paar von uns in das Projekt aufzunehmen, damit wir etwas Ordnung in die Probleme bringen können?

im Grunde erstellen wir also einen de-facto "Backlog"...

Irgendwie. Aber ja, das ist die Grundidee.

@Drachenkaetzchen Bist du offen dafür, ein paar von uns in das Projekt aufzunehmen, damit wir etwas Ordnung in die Probleme bringen können?

Auf Wunsch helfe ich hier gerne weiter.

Hey Leute, das ist eine sehr gute Idee und wurde auch von uns im IRC diskutiert.

Ich habe vor kurzem Zugang zum Github bekommen und werde mir ansehen, wie man weitere Leute hinzufügt, die bei der organisatorischen Seite helfen, die Probleme zu lösen, und ich freue mich über Ihr Angebot, dabei zu helfen.
(Wenn ich es aus Zeitgründen vergesse, scheuen Sie sich nicht, mich anzustecken)

Ok @christianlupus Ich habe dich als Triage-Mitglied zu diesem Repository hinzugefügt.
@baradhili bist du auch daran interessiert, dabei zu helfen?

Hier werden die Fähigkeiten dafür beschrieben: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Irgendwann werden wir natürlich auch noch einige Leute mit Code-Zugang hinzufügen. Lassen Sie uns zunächst versuchen, sich auf die Organisation der Probleme zu konzentrieren.

@dromer ja bitte

@dromer Danke für die Ergänzung.

Ein erster Vorschlag ist, ein Label needs-triage hinzuzufügen und eine Regel aufzustellen, um jede neue Ausgabe und PR in dieses Label einzufügen.
Grund: Der Reporter sieht, dass eine Triage erforderlich ist/durchgeführt werden soll. Außerdem können wir (später) nach solchen Problemen sortieren. Vielleicht sollten wir in Erwägung ziehen, jedes Thema unter dieses Label zu stellen, um zu sehen, was bereits getan wurde und was Aufmerksamkeit erfordert.

Und zusätzlich: Ich schlage auch folgende Labels vor:

• meta : Wird für Probleme verwendet, die sich nicht auf den Code selbst beziehen, sondern auf das Repo, das Wiki, die Programmierstandards und dergleichen
• help-requested : Wird verwendet, um anzuzeigen, dass ein Problem während der Einrichtung, Verwendung usw. nach Hilfe sucht. Dies könnte besser in ein Forum gedrängt werden, als hier auf github als Problem aufbewahrt zu werden.

Klingt gut.. obwohl ich vorschlage, dass wir nicht alles unter needs-triage weil wir einfach dort landen, wo wir jetzt sind :).. Ich würde auch vorschlagen backlog , next-release und roadmap sobald wir die Dinge überprüfen

Als ich jetzt anfing, einige Themen zu kategorisieren, fiel es mir schwer, sie zu beschriften, wenn diese nicht klar definiert sind (zumindest für einen Teil davon).

@christianlupus wie willst du die

@christianlupus Es sieht so aus, als ob wir ein weiteres Tag "move-to-wiki" brauchen könnten

@christianlupus wie willst du die

@baradhili Ich bin in UTC+1 (Berlin).
Ich habe ein paar Ausgaben einige Labels und einen Meilenstein gegeben, falls zutreffend. Aber jetzt wird es Zeit für mich, mich an die Arbeit zu machen. Also pausiere ich erstmal.

Haben Sie gute Vorschläge zur Koordination? Eine Person morgens eine Person abends, um Kollisionen zu vermeiden? Was ist Ihre bevorzugte Zeit, um daran zu arbeiten?

Da ich nicht weiß, in welcher Stadt du wohnst, habe ich zufällig eine aus der genannten Zeitzone genommen: Hier kannst du dir einen schnellen Überblick über die Zeitverschiebung verschaffen. Vielleicht möchten Sie Ihre Stadt adoptieren.

@christianlupus Es sieht so aus, als ob wir ein weiteres Tag "move-to-wiki" brauchen könnten

Ja, das scheint so zu sein.

@christianlupus Ich arbeite gerade alte Probleme mit bug Tags durch. bin in Perth - wir wollen wahrscheinlich komplexe Probleme mit einem Tag versehen, damit die anderen einen Blick darauf werfen und eine Meinung abgeben können.

@dromer Wenn wir Ihnen eine Liste mit neuen Tags geben, können Sie diese hinzufügen?

Oh, ist das etwas, was ich tun muss?

Lassen Sie es mich wissen und ich werde versuchen, weitere hinzuzufügen.

@christianlupus Ich arbeite gerade alte Probleme mit bug Tags durch. bin in Perth -

Okay, das liegt ganz bei Ihnen. Vielen Dank, dass Sie hier helfen. Ich arbeite im Moment an den unbeschrifteten Problemen, damit wir nicht kollidieren.

Wir möchten wahrscheinlich komplexe Probleme mit einer Art Tag markieren, damit die anderen einen Blick darauf werfen und eine Meinung dazu abgeben können.

Ja, ich denke, das ist eine gute Idee. Wie wäre es mit complex-triage ?

Oh, ist das etwas, was ich tun muss?

Lassen Sie es mich wissen und ich werde versuchen, weitere hinzuzufügen.

Wir können den Issues nur Labels und Meilensteine ​​anbringen. Aber wir können der Liste der gültigen Labels keine neuen Labels hinzufügen. Also, ja, wir bitten Sie, die entsprechenden Labels hinzuzufügen.

@baradhili Also für nicht haben wir diese Liste mit neuen Labels (bitte korrigiert mich):

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

Über die aktuellen Labels ( backlog , roadmap , next-release ) Ich denke, das wird besser von Meilensteinen erfasst, findest du nicht? Auch dies muss mit jedem koordiniert werden, der dem Repository Code zur Verfügung stellt.

Ich werde diesen Kommentar aktualisieren, sobald Bedarf an neuen Labels besteht. Okay damit? Wenn ja, fragen Sie Dromer danach.

@dromer
Könnten wir die folgenden Etiketten einrichten?

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

Danke

@baradhili Ich habe versucht, die Etiketten ein wenig in einer MD-Datei zu organisieren. Ich habe Sie als Mitbearbeiter hinzugefügt, damit Sie die Datei bearbeiten können.

Sind die Definitionen, soweit ich sie geschrieben habe, in Ordnung?

Alles gut!Dokumentation!

Am Dienstag, 14. Januar 2020 um 19:36 Uhr schrieb Christian [email protected] :

@baradhili https://github.com/baradhili Ich habe versucht die Labels zu organisieren
in einer MD-Datei
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
bisschen. Ich habe Sie als Mitbearbeiter hinzugefügt, damit Sie die Datei bearbeiten können.

Sind die Definitionen, soweit ich sie geschrieben habe, in Ordnung?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW61
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
Bret Watson
Direktor
IT Interim Management Pty Ltd T/A TICM
Mob: +61 (0)41 33 03 840
E-Mail:[email protected]
„Der Inhalt dieser E-Mail-Übermittlung ist ausschließlich für die genannten
Empfänger können vertraulich sein und können privilegiert oder anderweitig sein
vor Offenlegung im öffentlichen Interesse geschützt. Die Verwendung, Vervielfältigung,
Offenlegung oder Verbreitung des Inhalts dieser E-Mail-Übermittlung durch
jede andere Person als der/die genannte(n) Empfänger(n) ist untersagt. Wenn Sie es nicht sind
einen namentlich genannten Empfänger benachrichtigen Sie bitte umgehend den Absender."

build system eindeutig mit der ci/cd zu tun (siehe meine 2 PRs), also würde ich es behalten.

Ich werde deine Liste @baradhili hinzufügen und hoffentlich kannst du wenigstens vorankommen.
Im Moment denke ich, dass es in Ordnung ist, „zu viele“ Labels zu haben, als „zu wenige“. Wir können bestimmte Labels jederzeit entfernen/ignorieren.

Irgendwelche bestimmten Farben, die Sie damit verbinden möchten? :)

Ok, zu spät, ich habe mich jetzt für die Standardfarben entschieden :D

@dromer Könnten wir einen Meilenstein für 1.5.0 haben?

@christianlupus Ich werde 1 - Ready für Dinge verwenden, von denen behauptet wird, dass sie behoben sind, aber getestet werden müssen

@dromer im Nachhinein.. Mir wurde klar, dass ich mit Must Have mit Dingen umgehen kann, die so aussehen, als müssten sie "bald" erledigt werden
@christianlupus beendet Bug .. arbeitet jetzt an alten Problemen ohne Meilenstein

Ich entferne die Labels wie Will be closed soon! und Feedback Needed , sobald ein Problem geschlossen werden kann. Ist das für unseren gemeinsamen Workflow in Ordnung?

@dromer könnte ich ein zusätzliches Tag haben.. low-hanging ? Ich sehe von Zeit zu Zeit Probleme, die einfach zu beheben sein sollten

@christianlupus ja.. und ich sollte noch einmal durchgehen und überprüfen, ob ich das getan habe

Anscheinend bietet github einige automatisierte "Hooks", wenn Sie stattdessen das Tag good first issue verwenden:

Label-Probleme und Pull-Requests für neue Mitwirkende

Jetzt hilft GitHub potenziellen erstmaligen Mitwirkenden dabei, Probleme zu entdecken, die mit good first issue

Soll ich es stattdessen so nennen?
Probleme mit diesem Tag werden in einigen anderen Übersichten auftauchen, die Leute ermutigen sollen, sich zu engagieren.

Like auf https://github.com/partkeepr/PartKeepr/contribute

funktioniert bei mir! :)

@baradhili Ich habe mich gerade durch die ungetaggten Probleme gearbeitet. Um ehrlich zu sein, werde ich für heute nicht weitermachen, das war genug. Trotzdem wollte ich mit Ihnen die nächsten Schritte abstimmen. Ich freue mich auf Ihre Antwort.

@christianlupus ja.. Ich habe festgestellt, dass ich etwa 20/25 Probleme pro Tag Danach ist mein Gehirn gebraten ...
Ich werde es heute morgen mal ausprobieren..

@dromer Als nächste Schritte müssten wir uns wahrscheinlich mit der Priorisierung befassen.. und vor allem.. den Entwicklern zuweisen.. haben wir irgendwelche Entwickler?

@baradhili Ich habe dir gerade eine E-Mail an deine ticm-Domain geschickt. Können Sie bitte Ihr Konto überprüfen?

haben wir irgendwelche devs?
Äh ... wenn wir es täten, hätten wir diesen Rückstand nicht :)

Ich denke, ihr bewegt euch etwas schneller, als es das Projekt derzeit zulässt, was eine gute Sache ist, da die Organisation des Rückstands die Dinge verstopfte, so dass die Priorisierung hoffentlich dazu beiträgt, den Fokus für diejenigen zu lenken, die bereit sind, einen Beitrag zu leisten. (Sie zu finden oder uns finden zu lassen, ist natürlich eine andere Herausforderung)

ok Leute.. wir haben jetzt eine Issue-Liste mit allen Issues, die einem Meilenstein zugeordnet sind und ziemlich viel abgeschlossen
Ich denke, unser Fokus liegt jetzt darauf, jemanden zu entwickeln :) Leider habe ich NFI um ExtJS und Symfony herum, also kann ich nicht helfen ...

Optionen

1. wir bekommen einen Sponsor und setzen Freelancer auf guru.com oder stackexchange ein
2. wir versuchen selbst welche zu finden
3. ?

Darüber hinaus sollten Sie darauf achten, niemandem in die Zähne zu treten, indem Sie ihm die harte Arbeit abnehmen, ohne ihn zu kontaktieren. Dies geschah mit meiner Druckfunktion und seitdem habe ich nur noch von der Seitenlinie beobachtet, was hier passiert. Ich bin auch bei einer Software geblieben, die in neueren Versionen nutzlos ist, da keine solche Funktion wieder hinzugefügt wurde.

Es sollte eine klare Struktur geben, wie man mit solchen Dingen umgeht und auch mit architektonischen Entscheidungen oder was eine gute Praxis ist, etwas zu tun. Das Projekt selbst ist klar strukturiert und auch Personen, die kein PHP-Experte (sondern Programmierexperte in anderen Sprachen) sind, können mit Hilfe der verwendeten Frameworks und Strukturen einfach Dinge umsetzen.

@Boldie Hallo Sven, Entschuldigung , wenn Ihre Arbeit ohne vorherige Ankündigung entfernt .. Dinge haben viel in das Projekt in der letzten Zeit geändert , und wir sind sehr daran interessiert , das Vertrauen der Gemeinschaft zu bauen - _ vor allem die Entwickler _

Übrigens - ich gehe davon aus, dass Ihre Druckfunktion Massendrucke unterstützt? was wäre nötig, damit es wieder funktioniert?

Es sollte eine klare Struktur geben, wie man mit solchen Dingen umgeht und auch mit architektonischen Entscheidungen oder was eine gute Praxis ist, etwas zu tun.

Dies ist meistens richtig, aber weil das Projekt meistens in einem Ein-Personen-Projekt verwaltet wurde. Es war nicht erforderlich, Regeln für die Interaktion mit der Community zu definieren. Wenn wir beginnen, das Gewicht des Projekts auf mehrere Personen zu verteilen, kann es von Vorteil sein, Regeln für das weitere Vorgehen festzulegen.

Das Projekt selbst ist klar strukturiert und auch Personen, die kein PHP-Experte (sondern Programmierexperte in anderen Sprachen) sind, können mit Hilfe der verwendeten Frameworks und Strukturen einfach Dinge umsetzen.

Ich gehe davon aus, dass Sie selbst Programmierer sind, um eine solche Aussage mit Autorität treffen zu können. Ich möchte niemanden beleidigen, aber in der Zwischenzeit denke ich, dass es schwieriger ist, beim Entwickeln des Codes nasse Füße zu bekommen.

Ich habe es versucht, aber es war schwer. Die Bibliotheken sind höllisch veraltet und Dokumentationen zu diesen alten Codes sind mittlerweile rar. Außerdem ist die Dokumentation des Projekts (zB #635) nicht vollständig.
Ich schikaniere hier nicht, aber ich möchte auf einige kritische Probleme der aktuellen Software hinweisen. Da der ursprüngliche Entwickler zu diesem Zeitpunkt meistens nicht erreichbar ist, brauchen wir Leute, die zumindest einen Teil des Codes kennen, um die Dinge wieder auf den richtigen Weg zu bringen. Ich hoffe, dass "alte Mitwirkende" hier helfen können. Es gibt ein paar Fehler zu beseitigen, aber das Hauptproblem besteht darin, dass die Software nicht mehr in Bezug auf Abhängigkeiten gewartet und wartbar ist. Wir müssen die Hauptprobleme lösen, sonst WIRD das Projekt scheitern.

Daher frage ich Sie: Haben Sie am Code mitgearbeitet und haben Sie Erfahrung mit den damit verbundenen Abhängigkeiten?

Übrigens - ich gehe davon aus, dass Ihre Druckfunktion Massendrucke unterstützt? was wäre nötig, damit es wieder funktioniert?

@Boldie , ich schlage vor, dass Sie ein neues Problem öffnen, um die fehlende Funktionalität zu verfolgen. Irgendwann wird diese Ausgabe hier archiviert. Infolgedessen wird Ihre Anfrage, die Druckfunktion wieder zum Laufen zu bringen, von den meisten Menschen vergessen.

Übrigens - ich gehe davon aus, dass Ihre Druckfunktion Massendrucke unterstützt? was wäre nötig, damit es wieder funktioniert?
Es besteht aus 2 Teilen:

• Der Massendruck von StorageLocations / Parts als PDF
• Drucken eines einzelnen Teils (für Etiketten)

Der erste war hochintegriert, fügt aber auch einige problematische Abhängigkeiten hinzu. Der zweite ist vielleicht heute noch besser mit der REST-API implementiert. Es wird immer noch in einer dieser 200 offenen Ausgaben verfolgt :)

Ich habe mir gerade den Code angeschaut: Ich habe einige Probleme damit, wie dieses Zeug wirklich funktioniert. Das Framework scheint eine Art lose Kopplung zu verwenden, die schwer zu verfolgen ist. Vielleicht sagt ein Experte, der dieses Framework verwendet, etwas anderes (meistens habe ich Kontakt mit C++ und manchmal Python mit Django). Ich habe mich nur daran erinnert, dass dies auch schwierig war, herauszufinden, wie man einige Dinge hinzufügt, als ich meine erste Implementierung machte. Das Problem, wie ich sehe, besteht darin, dieses Projekt von einer mehr oder weniger Ein-Mann-Show zu einem Community-getriebenen Projekt zu führen. Leider bin ich der falsche Ansprechpartner für das Abhängigkeitsproblem, aber ich stimme zu, dies muss als erstes gelöst werden, um die technische Abteilung zu reduzieren.

Um die Entwicklung zu erleichtern, würde ich vorschlagen, eine Art Umgebung einzurichten, mit der man leicht mit der Entwicklung beginnen kann, ohne zweimal Arbeit zu machen. In meinem Unternehmen haben wir einen Docker-Container mit dem Zeug eingerichtet und auch ein Skript zum Ausführen von Tests / Hinzufügen von Demodaten, ... um den Entwicklungsstart zu erleichtern.

Gibt es eine Möglichkeit die Community zu kontaktieren? Ich denke, den meisten Usern ist nicht bewusst, dass wir hier Hilfe brauchen, sonst wird das Projekt immer veralteter und irgendwann nicht mehr nutzbar. Ist es möglich ein Statement auf die Homepage zu setzen? Da es die meisten Downloads gibt, sind sich die Leute mit den entsprechenden Kenntnissen der Situation und dieses Repositorys hier nicht bewusst.

@ Boldie Gute Idee! @dromer @Drachenkaetzchen hat jemand Zugriff auf die Hauptseite?

@christianlupus Gibt es hier oder in der Meilensteinansicht eine Liste welche Arbeiten als nächstes erledigt werden müssen? Ich denke, eines der ersten Dinge ist ein Upgrade auf Symhony4 #1083?

@Boldie ja, es wurde an Prioritätenproblemen gearbeitet. siehe diese Liste:

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

Das Upgrade von Symfony und anderen Abhängigkeiten ist derzeit die größte und wichtigste.
(obwohl ich denke, dass das Tag "gute erste Ausgabe" für Neulinge gedacht ist, nicht für die Bezeichnung "zuerst erledigt").

Gibt es eine Möglichkeit die Community zu kontaktieren?
Wir sind mit einer Reihe von Benutzern im IRC-Kanal #partkeepr auf irc.freenode.net
Es gibt auch die Google-Gruppen (eine öffentliche und eine private), aber ich denke, der Issue Tracker + IRC sind derzeit die beste Wahl, um mit Leuten über PartKeepr zu sprechen (in Bezug auf die Aktivität).

Darüber hinaus sollten Sie darauf achten, niemandem in die Zähne zu treten, indem Sie ihm die harte Arbeit abnehmen, ohne ihn zu kontaktieren. Dies geschah mit meiner Druckfunktion und seitdem habe ich nur noch von der Seitenlinie beobachtet, was hier passiert. Ich bin auch bei einer Software geblieben, die in neueren Versionen nutzlos ist, da keine solche Funktion wieder hinzugefügt wurde.

Der Grund, warum ich die Funktionalität entfernen musste, ist hier dokumentiert: https://github.com/partkeepr/PartKeepr/issues/622

Wenn Sie sich in die Zähne getreten fühlen tut es mir leid, aber so war das damals.

Außerdem verbringe ich die meiste Zeit meines Tages damit, diese Software zu schreiben. Bitte haben Sie Verständnis dafür, dass wenn ich Code entfernen muss, um eine neuere Version zu erstellen, dann sei es verdammt nochmal so. Sie hätten einen anderen PR erstellen können, um ihn mit der neuen Version kompatibel zu machen

Ja, ich bin gerade verdammt wütend. Ich habe so viele Jahre damit verbracht, den Code kostenlos zu schreiben, den Großteil der Arbeit gemacht, viel Support-Arbeit geleistet, versucht, ein Geschäft aufzubauen, und alles, was ich für die Hunderte, wenn nicht Tausende Stunden unbezahlter Arbeit bekomme, ist das.

wenn es nicht mein Verantwortungsbewusstsein gewesen wäre, hätte ich die Website und alles andere vor 2 Jahren geschlossen.

ich habe in diesen zeiten kaum geld um einen monat zu überstehen, habe mehrere krankheiten, von denen ich mich nicht so schnell erholen werde und versuche dieses projekt irgendwie am leben zu erhalten, auch wenn es mir kaum gelingt.

Außerdem verbringe ich die meiste Zeit meines Tages damit, diese Software zu schreiben. Bitte haben Sie Verständnis dafür, dass wenn ich Code entfernen muss, um eine neuere Version zu erstellen, dann sei es verdammt nochmal so. Sie hätten einen anderen PR erstellen können, um ihn mit der neuen Version kompatibel zu machen

Ja, ich bin gerade verdammt wütend. Ich habe so viele Jahre damit verbracht, den Code kostenlos zu schreiben, den Großteil der Arbeit gemacht, viel Support-Arbeit geleistet, versucht, ein Geschäft aufzubauen, und alles, was ich für die Hunderte, wenn nicht Tausende Stunden unbezahlter Arbeit bekomme, ist das.

wenn es nicht mein Verantwortungsbewusstsein gewesen wäre, hätte ich die Website und alles andere vor 2 Jahren geschlossen.

ich habe in diesen zeiten kaum geld um einen monat zu überstehen, habe mehrere krankheiten, von denen ich mich nicht so schnell erholen werde und versuche dieses projekt irgendwie am leben zu erhalten, auch wenn es mir kaum gelingt.

Ich weiß, dass Sie sich in einer ernsten Situation befinden und dieses Projekt einschließlich der Community trägt zu Ihrer Situation bei. Ich respektiere auch Ihre Arbeit und denke auch, dass dieses Projekt (insbesondere im Vergleich zu anderen) eine gut gemachte Struktur hat, sonst würde ich nicht versuchen, mir auszudenken, was ich tun kann, um dieses Projekt wiederzubeleben und wie man ein Entwicklungsteam darauf vorbereitet notwendige Arbeit.
Ich möchte die Vergangenheit jetzt nicht aufwärmen, es wird uns nicht helfen, mit Partkeepr weiterzumachen.

Aus meiner täglichen Arbeit weiß ich, dass es manchmal schwierig ist, mit Code von anderen Personen umzugehen, insbesondere wenn die Person nicht erreichbar ist (für die Zukunft und wenn es notwendig ist, kann mich jeder über die E-Mail-Adresse aus den git-Commits oder über die Domain kontaktieren und kontaktieren Sie mich über meine Homepage). Jeder hat seine eigene Handschrift beim Schreiben von Codierungen. Meiner Meinung nach ist es eine Art Handwerkskunst, Code zu schreiben. Ich habe auch viel Erfahrung mit Komplexität und wie schwierig es ist, dies zu bewältigen, wenn man ein Upgrade einer Bibliothek oder einer Reihe von Abhängigkeiten durchführt. Ich habe dies mit einem Team monatelang in meiner bezahlten Arbeit gemacht.
Jetzt haben wir also wieder diese Herausforderung hier und müssen uns einen Weg überlegen, dies mit einer Community zu tun. Es ist viel anspruchsvoller als in einem bezahlten Umfeld, in dem man sagen wird: Wir machen das.

Ich habe mir den Code angesehen und seit ich das letzte Mal etwas gemacht habe, hat es sich VIEL verändert (jemand investiert hier viel Arbeit!! :)). Also musste ich mich wieder in den Code einarbeiten und anfangen zu arbeiten. Aber dafür brauchen wir eine enge Kommunikation und einen Fahrplan, was als nächstes zu tun ist. Ich denke, die Wiederherstellung der Druckfunktionalität hat im Vergleich zu den anderen Dingen eine sehr geringe Priorität und ich oder jemand anderes kann dies später tun. Für mich ist es eher lohnenswert meine Daten beim nächsten OS Upgrade in Zukunft nicht zu verlieren, da dies auch viel Arbeit bedeuten wird auf etwas anderes zu migrieren (ich weiß nicht was das sein kann), es hat lange gedauert in meiner Freizeit, um die Datenbank zu füllen.

Danke @Boldie

@christianlupus @dromer Ich denke, wir können das jetzt schließen, da sich die Dinge wieder bewegen...!

Noch ein Punkt zur Diskussion: Aufgrund der Änderungen in #1091 werden alle neuen Ausgaben mit einigen Tags versehen. Wollen wir einen Indikator dafür haben, dass hier keine menschliche Überprüfung stattgefunden hat?

Abgesehen davon bin ich damit einverstanden, dieses Thema jetzt zu schließen.

Inwiefern unterscheidet sich das, was wir gemacht haben, von einer menschlichen Überprüfung? :)

@baradhili genau das haben wir kürzlich gemacht. Ich meine folgendes: Da der genannte PR akzeptiert wurde, haben alle neuen Issues je nach Art des ausgewählten Issues entweder Bug, Feature Request oder Help-waned Voreinstellung als Label.
Das bedeutet, dass neue Probleme (die die manuelle Triage, die wir in letzter Zeit durchgeführt haben, nicht bestanden haben) nicht so erscheinen, als ob sie keine Labels hätten. Es gibt also keinen einfachen Filter in GitHub, um die Probleme auszuwählen, die noch nicht menschlich geprüft wurden.

Also kurz: wollen wir ein need-triage oder ähnliches anzeigen.

können wir das Label needs-triage automatisch unter dem Vorlagensystem von github hinzufügen?

Ja, Sie müssen das Etikett hinzufügen und eine Zeile in der Vorlagendatei ändern. Das sollte reichen.

Ich habe gerade #1097 zum Thema Vorlagensystem geöffnet. Wenn das Label needs-triage nicht erwünscht ist, schlage ich vor, das einzelne Commit zu entfernen.

schließe das jetzt