Issues über VS-Studio bearbeiten #17
Labels
No labels
CI
Duplikat
FAU
Fehler / Bug
GU
gutes erstes Issue
Hilfe gesucht
invalid
oer.community
Offene Frage
technik
Verbesserung
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Comenius-Institut/FOERBICO#17
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ich finde es ausgesprochen umständlich und nervig, Issues in Codeberg anzulegen. Ich muss mich dazu jedesmal im Web anmelden, obwohl ich das Repositorium auf meinem Desktop z.B. im Visualstudio Code habe. Weiß jemand ein Erweiterung oder eine App, mit der ich Issues direkt in VS-Code anlegen oder beantworten kann?
Oder gibt es Alternativ eine geeignete Desktop App, die das ermöglicht?
Wie das mit VS Code geht, weiß ich nicht, aber vielleicht geht es mit der Desktop App? https://webcatalog.io/de/apps/codeberg/ => habe es selbst nicht ausprobiert!
Webcatalog stellt für jede Url einen Standalone "Browser" als eigenes Fenster zur Verfügung. Also ähnlich wie eine Url-Verknüpfung auf deinem Desktop.
Ich habe auch recherchiert und bin auf das hier gestoßen: https://code.visualstudio.com/docs/sourcecontrol/overview
Da scheinen die GIT-Möglichkeiten umfangreich dokumentiert zu sein.
Ob die "Github Pull Requests and Issues extension" neben Github auch für die Gits auf Codeberg funktioniert kann ich noch nicht beurteilen.
Für Android habe ich jetzt nur die App GitNex Pro for Forgejo / Gitea gefunden, die das mti den Issues auf Codeberg (Forgejo) laut Beschreibung können sollte.
Ich investere mal die 4,89€ und teste das
Die GitNex App ist super intuitiv und lohnt sich, aber danach hattest du ja nicht gefragt.
Die API beinhalten zahlreiche Anschlussmöglichkeiten im Blick auf die Issues: https://codeberg.org/api/swagger#/issue
Kannst du damit was anfangen, @johappel ?
@joerglohrer die Forgejo API ermöglicht theoretisch auch ein solches VS-Code Addon zu entwickeln. Ich habe in google und co nichts dazu gefunden. Die Frage ist, ab wann sich die Entwicklung und Pflege eines solchen Addons lohnt. Das ist ein eigenes Projekt. Die Voraussetzung dass so etwas wirklich passiert, schätze ich so ein, dass sich mindestens eine Software-Firma finden müsste, die großes Interesse an der Entwicklung über Forgejo hat und ihr SoftwareProjekt Management auch darüber organisieren will und entsprechende Addons (hoffentlich dann auch für VS-Code) entwicklet und pflegt. Dabei könnte auch ein userfreundliches Dasboard für Codeberg entstehen.
@johappel https://gist.github.com/basiszwo/5403341 ich habe alle Apps mal durchgeklickt und nur die wenigsten funktionieren noch oder sind erreichbar. Ich schließe daraus, dass selbst auf Github und für Github solch eine Entwicklung sehr spezifisch wäre und offensichtlich wenig genutzt.
Ich kopiere gerne @johappel s Kommentar hierher, damit uns das im Blick bleibt:
Mir erschließt sich noch nicht der spezielle Anwendungsfall für VS-Studio und den Issues.
Wenn ich das richtig sehe, wurden in keinem Repositorium von rpi-virtuell in den vergangenen Jahren auf github Issues mit VS-Studio erstellt. Und im wekan-Kanban von rpi-virtuell wurden die Issues ausschließlich über die Weboberfläche erstellt und es gibt nach wie vor keine App dazu.
Wozu bräuchte es jetzt eine Entwicklung für den Quelltexteditor VS-Code von Microsoft?
Wir verwenden bei rpi-virtuell keine Issues, weil sie weder in unseren Workflow passen noch von unseren Nutzerinnen genutzt wurden und wir nutzen auch nicht das Projektmanagement von Github, was ebenfalls zu umständlich zu bedienen ist immerhin einfacher als das von forgejo. Dein Anliegen ist ja, dass auch wir unser Projektmanagement über forgejo betreiben, weshalb ich nach Optionen gefragt habe, wie sich das integrieren lässt.
Im Sinne von Transparenz und Beteiligung halte ich im Kontext von fOERbico ein offeneres Projektmanagement für erforderlich, als das rpi-virtuell bislang praktiziert hat.
"Umständlich" und "nicht in den Workflow passen" sind Argumente, die klarer konturiert werden müssten.
Eventuell kannst du ja mal bei Gelegenheit skizzieren, wie du das Projektmanagement bislang organisiert hast und was es bräuchte um eine anschlussfähige git-basierte Organisation davon umzusetzen.
Das Issue konzentriert sich auf die Verbesserung der Ergonomie. rpi-virtuell und das Comenius-Institut nutzen Wekan für Kanban. Die Frage der Transparenz in fOERbico ist ein separates Thema. Öffentlich zugängliche Kanbanboards bieten nicht automatisch Transparenz; dafür sind Communitymanager* und Öffentlichkeitsarbeiter* zuständig. Deine Erfahrung als ehemaliger rpi-virtuell Communitymanager könnte in einem eigenen Issue behandelt werden. Wenn keine weiteren Lösungen gefunden werden, können wir das Issue schließen.
Also ich bin hier zwar mitlesend. Aber euren Diskursen kann ich kaum folgen. Insgesamt halte ich es wichtig in rpi-virtuell eine Openes Strategie zu etablieren. Und wir sollten strukturell weiterdenken. Das Projektmanagement von rpi-virtuell der letzten Jahre würde mich auch interessieren. Ich denke Communitymanagement und Öffentlichkeitsarbeit sollten auch mit dem Projektmanagement zusammengedacht werden.
Sorry, wenn es vorher unverständlich war:
Kanban ist eine sehr verbreitete und einfach zu nutzende Methode des Projektmanagements. Mithilfe dieser Methode funktioniert auch das Projektmanagement in rpi-virtuell (zumindest im Bereich der Infrastruktur und der technischen Entwicklung). Das Community-Management und die Redaktion haben sich in der Vergangenheit zumindest im Team von rpi-virtuell etwas schwer getan. Eine andere agile Methode ist SCRUM, wie sie etwa bei der Entwicklung von religlobal angewendet wird. Beide Methoden nutzen Kanban Boards, um Projekte zu managen und Aufgaben zu organisieren. Einige Teams im Comenius-Institut nutzen beide Methoden je nach Projekt. Um diese Methoden digital zu unterstützen, verwenden wir den Open-Source Trello-Klon Wekan. Die Bedienung ist sehr einfach. Die Boards lassen sich öffentlich machen, was bei den Boards von rpi-virtuell der Fall ist, sodass jeder sehen kann, woran wir arbeiten, wie der Fortschritt ist und was von uns zurückgestellt wurde. Allerdings können nur Mitglieder des Teams Aufgaben am Board erstellen und zuweisen. Ein Ticketsystem, in dem auch Besucher Anliegen eintragen können, gibt es, wird aber wenig genutzt. In der Regel kommen Anfragen direkt über die Kanäle in der Matrix, relilab, Telefon usw. Zumindest die Technikleute haben sich bemüht, alles, was an Anfragen über irgendwelche Kanäle hereinkam, hier zu sammeln und im Board anzupinnen, um den Fortschritt dort zu dokumentieren. Und da wirklich sehr viele Kärtchen in den verschiedenen Projekten geschrieben werden, ist eine effiziente Software wichtig.
Für dieses Projektmanagement, wie wir es bisher betrieben haben, brauchte es keine Issues (früher hatten wir die bei Github tatsächlich mal genutzt, aber letztlich kamen die meisten Anfragen über andere Kanäle rein, was die Nutzung von Issues komplizierter machte, vor allem wenn es sich um Issues handelt, die gar nicht genau einem Projekt zuzuordnen sind).
Issues kommen, wie das Wort schon sagt, vor allem zur Lösung von (Software-) Problemen vor. Dafür gibt es in der Regel eigene Ticketsysteme. Issues gehören als Teil der Fehlerbehebung zur Softwareentwicklung und machen da auch viel Sinn, gehören aber nicht zwangsläufig zu einem Repository oder zu einem Projekt. Im Falle von Github und anderen Entwicklerportalen hat man Issues in die Entwicklungsplattform für versionskontrollierte Softwareentwicklung (GIT, SVN etc.) integriert, um einen Mehrwert gegenüber der Bereitstellung einer simplen GIT-Software zu erreichen und hat den Nutzern viele Tools bis hin zum Messenger drumherum gebaut. In Forgejo wurde einiges davon abgeschaut. Die Umsetzung ist aber wenig überzeugend und ergonomisch eine Katastrophe. Gina und Jörg haben nach Möglichkeiten gesucht, wie man dieses Problem vielleicht umschiffen kann, etwa über die API und eigene Software-Addons zu implementieren. Aber hier hat sich gezeigt, dass die API ausgerechnet das für das Projektmanagement zentrale Werkzeug (Kanban Board) nicht unterstützt. Was für mich ein K.O.-Argument ist und damit Forgejo für das Projektmanagement überwiegend ungeeignet macht.
Neben Wekan gibt es viele Open-Source-Lösungen, die die Kanban-Methode unterstützen. Forgejo tut dies technisch und ergonomisch gesehen in einer umständlichen und wenig durchdachten Weise.
Vielleicht ist meine Argumentation jetzt besser verständlich.
Vielen Dank für die ausführliche Erläuterung. Wir haben ja hier ein Kanbaanboard in rpi. Und durch das Teammeeting werden die Punkte die auf dem Tisch liegen genannt und abgearbeitet. Durch den Issue bekomme ich eine Übersicht was erledigt/geschafft wurde. Das Mittagsmeeting ermöglicht ja an weiteren Dingen dran zu bleiben.
Der von dir beschriebene Workflow über Issues könnte in einer sequentiellen Projektmanagementlogik mit aufeinanderfolgenden Phasen funktionieren. Für rpi-virtuell eher nicht, weil wir gleichzeitig in vielen Projekten, Aufgaben und Abteilungen involviert sind. Du musst ständig neu bewerten, was du vorziehen und was du zurückstellen musst. Das kannst du in einem Issueverlauf nicht einfach visualisieren, da steht dann einfach nur "offen". Du müsstest irgendwo im Text oder über ein Label auszeichnen, dass dieses Issue gerade zurückgestellt ist. Auch Deadlines sind im Issue schlechter zu visualisieren. Eine Gesamtübersicht der gerade aktiven Issues wird mit jedem neu angelegten Issue unübersichtlicher. Es gibt auch keine Begrenzung der maximal aktiven Issues. Deshalb hatte man die Kanban Methode erfunden. Sie dient vor allem der Transparenz und der Visualisierung. In rpi-virtuell nutzen wir dazu keine Issues, sondern Kärtchen, wie man das analog auch machen würde. Natürlich helfen Dailys und der wöchentliche Jour fixe dem Team, diese agilen Dynamiken besser nachzuvollziehen. Aber alle, die in diesen Treffen nicht anwesend sind, wie etwa die Institutsleitung, haben keinen Überblick. Deshalb ist das Kanban-Board das Herzstück agilen Projektmanagements. Und ich würde zumindest in den Projekten von rpi-virtuell ungern darauf verzichten. Vielleicht eröffnet sich ja mit Foerbico eine neue Erkenntnis, die die bisherigen Methoden des Projektmanagements erweitert.
Allerdings haben ja Daniel und Bernd es nicht ausgeschlossen mit diesem Tool zu arbeiten. Und wenn ich es richtig verstehe arbeiten wir dann zukünftig mit zwei verschiedenen Projektmethoden?
Gibt es zwei Methoden des Projektmanagements? Forebico hat sich offensichtlich für Forgejo entschieden. Dass sich Forebico auch für eine bestimmte Methode des Projektmanagements entschieden hat, habe ich leider nicht mitbekommen. Kann man das irgendwo nachlesen?
Gibt es zwei Projektmanagementsysteme? Ja, es gibt verschiedene Projektmanagementsysteme im Comenius-Institut, es sei denn, es gelingt dem Forebico-Team, alle Mitarbeitenden zu Forgejo zu überreden. Ansonsten werden wir in rpi-virtuell mit unterschiedlichen Systemen in verschiedenen Teams und Kontexten arbeiten müssen. Das Forebico-Team hat es da natürlich einfacher, weil sie nur ihr eigenes Projekt managen müssen.
Dieser Issue hier geht ja um VS-Studio und hat sich nun zu einem Gespräch zu Projektmanagementsystemen entwickelt.
Das würde ich gerne an anderer Stelle verorten, damit wir nicht durcheinanderkommen.
Gerne können wir diesen Issue zu VS-Studio hier schließen und in einem neuen Issue (lässt sich vermutlich hier auch referenzieren) der Sache auf den Grund gehen, was die Ergonomie und Nutzbarkeit angeht.
Wir hatten ja auch den Topic zur Zukunft des Kanbanbords als Issue in den letzen beiden Montagsmeetings im alten wekan und werden sicherlich am kommenden Montag dann wie vereinbart hier im im Kanban weiter daran arbeiten.