Ich würde gerne diskutieren, wie wir ein nachvollziehbares Verfahren etablieren, Wünsche und zukünfitge Features für Portal und Visualisierung zu erfassen. GitHub ist vielleicht nicht das Vehikel.
Wenn es das alles schon gibt,würde ich mich über einen Hinweis freuen, wo ich das finde und wie man das bedeint 
Hallo Klaus, ich denke das ist etwas, was man besser im Forum diskutiert - Vielleicht kannst du ja mal in einem Thread den Aufschlag machen, indem du beschreibst, was für Funktionen du dir im Issuetracker oder Prozess fürs Issue Tracking deiner Wahl wünscht und was davon bei Github fehlt? Auf der Basis könnte man anfangen zu diskutieren was für ein Werkzeug man auswählt.
Github wird von vielen tausend Entwicklern und auch Firmen für solche Prozesse genutzt, ich würde mich sehr wundern, wenn sich das dort nicht abbilden ließe.
edit: ich habs natürlich trotzdem mal auf die Agenda gesetzt, denke aber wirklich dass das ein Detailthema ist, das von Diskussion in Textform mit viel Zeit zum Nachdenken zwischen Beiträgen im Forum profitieren kann.
Lass uns das demnächst mal auf dem Spielplatz diskutieren
Ich hab mir grad schon ein paar gedanken gemacht, was es aus meiner sicht braucht:
Bei Open Source Entwicklung ist eine der wichtigsten Ressourcen (wie üblich bei Ehrenämtern) die Motivation der Arbeitenden.
Ich verenge das hier mal auf die Portal/Visualisierung, obwohl das Thema eigentlich auch die Hardware- und OBS-Softwareentwicklung betrifft.
Im „Ruhezustand“ wird man als Open Source Entwickler die Probleme angehen, die einem selbst am dringlichsten erscheinen und die gleichzeitig mit der endlichen Zeit löstbar sind. In der Community gibt es jetzt natürlich zahlreiche Ideen, was man alles brauchen könnte, um die Visualisierung besser zu machen - Manche erschließen sich nicht allen beteiligten, andere sind für einzelne Initiativen wichtig. Im Darmstädter Modell mit der anonymen Komplettspende z.B. ist Datenschutz kein großes Thema, umgekehrt sind andere Initiativen vielleicht gar nicht an einer öffentlich sichtbaren Echtzeitauswertung interessiert und würden eher in PostGis Presseauswertungen produzieren.
Wenn man selbst den Weg scheut, sich da reinzufuchsen und zu implementieren, (was ich immer schade finde) und auf andere angewiesen ist, damit diese einem die Ideen umsetzen ist die Frage: Wie motiviert man diese Menschen, etwas umzusetzen, das diese lokal vielleicht gar nicht selbst brauchen.
Was oft leider passiert ist, dass das auf eine Liste geschrieben wird „Wir von Initiative X brauchen das und das“ oder „Warum kann X noch nicht jenes“ und dann erwartet wird, dass das irgendwann umgesetzt wird und zunehmend unhöflich danach gefragt wird. Das ist motivatrionstechnisch superkontraproduktiv. Die Idee ist oft der kleinste Teil zur Umsetzung und meistens ist die Antwort auf die Frage „Warum gibt es das noch nicht“ einfach „Weil noch niemand der das brauchte sich die Mühe gemacht hat das selbst zu implementieren und die, die es nicht brauchten lieber das implementiert haben, was sie selbst brauchten“.
Ich denke um Feature requests am besten sortieren zu können muss man vor allem die Motivation herausstellen warum man ein Feature braucht. Oft wird gesagt „hier ich bräuchte X“, aber was oft fehlt ist, dass dabei steht, was der mehrwert wäre den andere daraus ziehen könnten. Wenn ich als Entwickler verstehe, warum ein Feature für die Durchsetzung unserer gemeinsamen radpolitischen Ziele besonders hilfreich ist, fällt es mir leichter, zeit da rein zu stecken, weil man dabei das Gefühl hat, was sinnvolles zu tun, und wenn die Frage freundlich formuliert wurde noch leichter, weil ich dann weiß, dass meine Zeit auch wertgeschätzt wird.
Am Ende ist es aber dauerhaft so: Es wird viel mehr featurewünsche geben als umgesetzt werden können, einfach weil für die Entwicklung offenbar nur wenige Freiwillige zur Verfügung stehen. Um in dieser Situation die Motivation nicht zu killen ist es sehr wichtig, nicht pampig zu werden. Denn wenn man große Teile seiner Freizeit in ein Projekt steckt und dann trotzdem alle paar Tage zu hören bekommt „Ist doch alles scheiße ich hab schon vor 8 Wochen nach Feature X gefragt und es funktioniert noch nicht“, ist die Motivation schnell dahin. Das beste was wir erreichen können ist eine sinnvolle Priorisierung von Featurewünschen, und es werden immer viele unumgesetzt bleiben, solange nicht ein plötzlicher Entwicklerrregen einsetzt.
Eine Arbeit, die hier von einem Nichtentwickler übernommen werden könnte, wäre die Aufbereitung der Featurewunschliste samt Motivation für die Features.
An der Stelle ist es im Interesse jedes Featurewünschenden, sein Feature freundlich zu präsentieren, aber immer im Kopf zu behalten, dass es mit anderen Features um die Zeit weniger Freiwilliger konkurriert.
1 „Gefällt mir“
Wünsche und zukünfitge Features für Portal und Visualisierung zu erfassen. GitHub ist vielleicht nicht das Vehikel.
Ich verstehe diese Annahme nicht, kannst du das etwas ausführen, @Klaus? So wie ich das sehe ist eine Liste von Feature Request (aka „Issues“) nachvollziehbar und transparent, und viel einfacher als das geht es ja auch nicht, oder? Also ich bin mit Github äußerst zufrieden, und zwar in beide Richtungen, als jemand der Features requested und auch umsetzt.
Interessanter wäre die Spezifizierung und Priorisierung, nicht die Erfassung. Besonders an der Spezifizierung hakt es oft. Ein „ich hätte gern X“ ist halt oft nicht zu Ende gedacht und braucht dann input von denen, die es umsetzen würden, und das „bigger picture“ haben. Daraus ergibt sich dann in der Regel Bedarf für Diskussion oder kleine Experimente, bis klar ist, was genau das Ziel ist, und wie das am besten erreicht werden kann, egal ob „X“ der richtige Lösungsansatz war oder nicht.
Wo diese Diskussion stattfindet ist mir im Endeffekt egal. Ich finde, dass sich Github gut dafür eignet, da es projektbezogen ist (getrennte Repos) und nachvollziehbar bleibt, was noch offen ist. Die Integration mit den Entwicklertools ist auch großartig. Aber das Forum wäre auch okay.
Priorisierung ist wieder ein anderes Thema, das @gluap ja ganz gut beschrieben hat. Ich stimme zu, dass Motivation da viel mit reinspielt. Kleine Wünsche sind halt in der Regel spaßiger umzusetzen (sofern die Umsetzung so klein ist wie sie anhand des Wunsches erscheint, das geht auch manchmal erheblich auseinander), große Features sind anstrengend. Wenn ich am eben abends noch schnell was machen will und nur so 20-30 Minuten investieren kann/will, dann mach ich halt was kleines. Die Integration der Datenpipeline in die API des Portals hat mich meine ganzen Herbstferien gekostet, und das war mir vorher auch klar, darum hab ich dieses Riesenthema da dann gemacht. Wem was wie wichtig ist spielt bei dieser Zeitplanung gar keine Rolle 
Da wird sich auch ohne andere Anreize oder mehr Peoplepower nichts dran ändern, denke ich.
2 „Gefällt mir“
Schließe mich @opatut an: Ich finde GitHub ist genau der richtige Ort dafür. Vielleicht kann man mit guten Issue Templates dafür sorgen, dass die Qualität der Issues besser wird und die angesprochene Motivation in einem Issue hervorgehoben wird.
1 „Gefällt mir“
Hey, Github hat ein neues Feature für Projects, um
- repoübergreifend in der Organisation
- in übersichtlicher Tabellenform
- mit beliebigen Zusatzfeldern (z. B. Priorisierung oder Komplexität)
… Tickets zu verwalten. Ich hab mal ein solches Projekt angelegt für Datenverarbeitung und -visualisierung im Portal:
https://github.com/orgs/openbikesensor/projects/2/views/1
Vielleicht können wir uns damit ja etwas Übersicht verschaffen.
2 „Gefällt mir“