Wir haben früher schon mal begonnen, Geschichten zu schreiben. Sie sind nicht mehr aktuell und die Diskussionen verwirren möglicherweise.
Finde ich super wichtig. Florian und ich hatten schon in der Diskussion über den Timeless Way kurz mal wieder einen Use Case angesprochen und das hat mir wieder sehr geholfen.
Ist es hier eigentlich möglich, Beiträge zu labeln bzw. eine neue Kategorie aufzumachen?
Das ist eine Frage an @almereyda.
In Discourse können Kategorien maximal eine Ebene Unterkategorien enthalten. Das wäre wohl im späteren Verlauf möglich. Wir wollen nicht den Fehler machen die Diskussion zu stark vorzustrukturieren, ohne dass sich die Unterstrukturen dann leicht mit Inhalten füllen ließen.
Ich habe nun auch das Tagging-Plugin repariert, sodass sich mit Hilfe des Bearbeitungsbuttons/Bleistiftes 
neben den Überschriften eines Artikels nun Tags setzen lassen, als auch beim Erstellen von Artikeln.
Probiert’s mal aus!
Läuft, vielen Dank dafür!
Ein Beitrag wurde in ein neues Thema verschoben: openLCA: Life Cycle and Sustainability Modeling Suite
Neben der Ausformulierung der erwünschten User Experience in Form von User Stories und User Journeys, später angereichert mit Mockups und Style Guide, ließe sich auch die Erwartung formulieren eine angemessene Developer Experience zu des Systems erzielen, sodass bestehende IT-Systeme kompatibel gemacht werden können.
Es wurde von @fkleedorfer bereits die Vorstellung geäußert, dass es die Anwendung gegenwärtig wohl eher Entwicklerïnnen als Anwenderïnnen anspräche. Diese würden zunächst benötigt, um das Ökosystem des Web of Needs Protokolls mit Beispielen auszugestalten.
Daher kann auch eine Darstellung der sozialen und technischen Partizipationsmöglichkeiten an diesem Prozess mögliche praktikable Nutzungsszenarien anbieten.
Spannend fände ich auch anzudenken, inwiefern sich diese Szenarien eigentlich von guten Mustern unterscheiden würden?
Der Gedanke der Developer Experience gefällt mir. Dabei denke ich zuerst an eine angemessene Zerlegung des Systems in überschaubare Teile. Neben der üblichen Zerlegung in Frontend, Backend, Übersetzung etc. geht das auch in einer zweiten Dimension wie in diesem Ticket beschrieben:
https://git.fairkom.net/transcomm/transcomm-concept/issues/36
Ich stelle mir vor, dass das überschaubare und interessante Aufgaben ergibt:
- Verstehe diese und jene Schnittstelle/ Protokoll
- Implementiere sie in Sprache xyz
- Daten bekommst da und dort her
In unserer Welt: Everything is a pattern. (Wenn es kein Mittel ist) 
Hierfür empfehle ich auch die Lektüre des Artikels
(ich übertrag hier meinen Beitrag aus mattermost)
Ein Nachtrag zum gestrigen Gespräch, ad 3 - nächste Schritte: Ich habe das ein wenig sacken lassen und ich hätte einen Vorschlag für das Projekt des Konsumentenschutzes (@raffael), der genau in dieselbe Kerbe schlägt, wie die Vorschläge, Domain Driven Design zu praktizieren:
Ich glaub es wäre wichtig, sich drauf zu konzentrieren, was die Leute, die man ansprechen will, am ehesten nützlich finden würden. Wenn ich recht verstanden habe: im Menschen in einem lokalen Kontext (zb. Dorf/Kleinstadt/kleiner Kanton), und da eher die, die sich nicht sowieso alles kaufen können, was sie so brauchen. Darüber mal ein paar Hypothesen aufstellen und dann mit VertreterInnen der Zielgruppe reden, daraufhin die hypothesen überarbeiten, usw - solange bis man überzeugt ist, dass man gute use cases hat. Dann kann man sich an ein UX-design für genau diese use cases machen - und man kann sich überlegen, wie man das mit der Mustertheorie in Übereinstimmung bringt.
Zum Beispiel könnte es sein, dass dabei herauskommt, es gäbe viel Kooperationspotenzial beim Thema Kinderbetreuung. Wenn man das Umsetzen will, läuft man garantiert in ein Trust-Problem: die Leute wollen ihre Kinder nur jeweils ein paar handverlesenen Leuten geben. Das hieße, man muss da auch social-networking Funktionen einbauen - wovon ich bisher in Marcus’ Texten noch nichts gelesen habe. Ginge man nur von der Theorie aus, würde man solche Anforderungen tendenziell übersehen - und andere Use Cases haben wieder ihre eigenen Anforderungen, es hängt also von der Auswahl der Use Cases ab, was man technisch bieten muss.
Die Auswahl der Use Cases sollte man, glaube ich, davon abhängig machen, dass sie Netzwerkeffekte in der Zielgruppe haben. Grob gesagt: dass es für einen user eine intrinsische Motivation gibt, die software einer Handvoll anderer Leute zu empfehlen, und dass es für jemanden, der’s empfohlen bekommt, eine intrinsische Motivation gibt, sie mal auszuprobieren.
Es würde mich nicht wundern, wenn diese use cases, sehr simple Muster wären, und eher sozial komplex sind (also auf sozialen Beziehungen, eventuell transitiven (“ich vertraue wem du vertraust”) explizit oder implizit vorhandenen Gruppen (Familie, Nachbarschaft, …) , etc. beruhen)
Ich finde das ein sehr spannender Ansatz, um an gute Use Cases zu kommen und entsprechende User Storys machen zu können.
Verstehe ich es richtig: Das würde man vor allem anderen machen, also vor Design, richtig? Man könnte dann die zwei, drei wichtigsten Wünsche der Zielgruppen in die erste Version reinnehmen, schauen, dass möglichst schnell ein Netzwerkeffekt im Kleinen auftritt und die App dann nach und nach mit anderen Use Cases erweitern und hätte dadurch schon eine Userbasis für die schrittweise Expansion.
Das würde dann aber auch heissen, dass wir uns komplett nach den Wünschen der Zielgruppe ausrichten, was heisst, dass wir den eigentlichen Zweck der Software potenziell erst in Jahren implementieren werden, richtig?
Was denkst du @fkleedorfer und all ihr anderen?
Ja, so in etwa hätte ich das gedacht.
In dem von dir beschriebenen Spannungsfeld ist das Projekt notwendigerweise, glaube ich. Wenn man was baut, dass am Ende keiner verwendet, kommt dieser Zweck auch nicht wirklich zum Tragen, umgekehrt, wenn man am Ende etwas gebaut hat, das viele Leute nutzen, aber die ursprüngliche Idee ist darin vergessen worden, ist es zwar besser, aber auch unbefriedigend. Idealerweise findet man was, das beide Kriterien erfüllt, also die Leute brauchen und wollen es, und, der ‘Zweck’ ist auch dabei.
Allerdings wüsste ich auch gern: Was wäre denn dieser ‘eigentliche Zweck der Software’, dieses Zentrale, das nicht vergessen werden darf?
Ich finde die Idee wirklich gut. Im Prinzip ist es auch das, was wir mit den verschiedenen Oberflächen (UX-Designs?) so angedacht haben, nur eben, wenn ich es richtig verstanden habe, noch mit eigenen Funktionen erweitert. Ist meiner Meinung nach der richtige Ansatz.
Das stimmt, bisher gibt es noch nichts dazu und im Timeless Way verweist auch nichts in die Richtung. Gerade bei der Arbeit am vierten Teil der Reihe (Erstfassung ist übrigens fast fertig!) hat sich mir die Vertrauensfrage auch sehr aufgedrängt - in einem anderen Kontext zwar, aber darauf übertragbar. Was ich mich gerade frage ist, ob sich Vertrauen sozusagen quantisieren lässt - also sich auch von einer Person auf andere zu übertragen und bei Regelbrüchen auch für diese einzustehen. Bei mir hat sich die Frage durch eben mögliche Manipulationen der Software ergeben: Was ist, wenn Leute mehrere Accounts erstellen, um sich selbst mehr Bedürfnisse befriedigen zu lassen? Oder was ist, wenn jemand angibt, ein Bedürfnis durch das private Mittel eines anderen befriedigen zu wollen, das private Mittel dann von dieser Person ordnungsgemäß abholt, aber einfach damit abhaut? Eine unschöne Lösung ist die Verifikation durch Personalausweis o.ä., aber da kann ich den breiten (und teils gerechtfertigten) Widerspruch schon hören - und ob ich da als Anwender selbst darauf Lust hätte, wenn ich die Software zum Beispiel nur ausprobieren will, ist mehr als fraglich.
Worauf ich hinauswill: Vielleicht lassen sich durch solche Use-Cases wie Kinderbetreuung Möglichkeiten von allgemeiner Gültigkeit herausstellen. Aber das finde ich wesentlich: Das Prinzip, wie hier vertraut wird, soll auch in allen anderen Sphären prinzipiell funktionieren. Wenn die UX-Designs auch verschieden sind und verschiedene Funktionen vielleicht hervorgehoben werden, soll die Funktionsweise doch gleich sein. Und Muster die dort erstellt werden, sollen in der “Hauptsoftware” genauso angewendet werden. Die einzelnen kleinere, speziell zugeschnittenen Apps füttern damit die Große.
Ist es das, was du damit auch gemeint hast, @raffael?
Das mit dem Zweck versteh ich nicht. Der “Zweck” als solcher muss ja im Kleinen wie im Großen gleichermaßen gegeben sein.
Der Zweck ist es Bedürfnisse direkt (nicht geldvermittelt) durch Prozesse der Selbstzuordnung befriedigen zu können. Und Mittel mit dem Zweck der Bedürfnisbefriedigung zu beschreiben, d.h. sie außerhalb des privaten Eigentums organisieren und ihre Anwendung auf Augenhöhe diskutieren zu können.
In einem zentralisierten System kann man das noch halbwegs beschränken (aber das Beispiel Facebook zeigt, dass schon das echt schwierig ist). In einem dezentralen System ist das natürlich noch schwieriger. Es gibt aber schon Möglichkeiten, sich an Identitäts-Infrastrukturen, wie zB die österreichische Bürgerkarte anzubinden - das ist dann schon relativ belastbar. In der WoN-Webapp kannst du übrigens so viele ‘Personas’ anlegen wie du willst - ist eher ein Privacy-Feature, damit du, sagen wir, für die Kooperation in der Familie eine andere Persona verwenden kannst als für dein berufliches Netzwerk oder deine Einkäufe. Wir haben auch mit verschiedenen Varianten von Reputationssystemen experimentiert - so etwas kann natürlich schon Trust vermitteln - ist aber auch nicht ohne Probleme.
Die von dir genannten Probleme existieren bei einem System ab eine kritischen Größe sicherlich, aber ich glaube, wir sollten uns davon nicht zu sehr beeindrucken lassen.
Vielleicht wäre gut, sich voll auf die positiven Aspekte zu konzentrieren: was ermöglicht mir die Software, was nimmt sie mir ab, was erleichtert sie mir, und wieviel (wie wenig) Aufwand bringt es mit sich, sie zu nutzen. Wenn das System dann von Trittbrettfahrern ausgenutzt wird, ist das ja schon ein deutliches Zeichen für Erfolg - so weit muss man erstmal kommen!