Diskussionsstand Mai 2011 nach Relaunch: Unterschied zwischen den Versionen

Aktuelle Version vom 22. Juli 2011, 11:43 Uhr

Bitte auffüllen! Danke.

1 Professionalisierung/Projektcharakter

1.1 klar definierter Zielrahmen

mh... v1.0 / v1.1 ?

1.2 MitarbeiterInnen

Wie groß ist der geschätzte gesamte Arbeitsumfang und wie teilt er sich nach notwendigen Fähigkeiten auf? --> Sinnvolle Projektteamgröße? Aufgabenverteilung (zeitlich/inhaltlich): Leitung Programmierung Lassen sich einzelne Aufgabenbereiche sinnvoll voneinander trennen, um Verantwortlichkeiten klar abzugrenzen? Hilfskräfte

Wie und wo können die notwendigen Menschen gefunden, begeistert und entlohnt werden? (Uni Heidelberg (IWR, C-Linguistik, Mathe, Physik), Uni Mannheim (Informatik), weitere Hochschulen?, IT-Unternehmen, wie SAP und Oracle?)

1.3 Zeitrahmen

Start im Sommer, vorl. Zeitplan bis Ende 2011 </br> Das Semester Endet am 23.7.2011. Da wir MitarbeiterInnen am ehesten im Umfeld der Universitäten/Hochschulen finden werden ist es sinnvoll schon jetzt mit der Suche zu beginnen. Es ist aber unrealistisch, eine Finanzierung für das Projekt innerhalb der nächsten 6-8 Wochen organisieren zu können. Eine Möglichkeit wäre, jetzt weitere Menschen zu suchen und so viele Vorarbeiten wie möglich schon zu erledigen und mit der konkreten Projekt-/ Programmierarbeit erst im Herbst (September/Oktober) zu beginnen. Um zunächst den Zielrahmen des Projektes zu erreichen sollten 4-6 Monate Laufzeit ausreichen.

1.4 Open Source

Da unser Projekt zur Transparenz von Entscheidungsprozessen beitragen soll, muss diese Transparenz logischerweise auch in unserer Software gewährleistet sein. Deshalb soll unser Projekt ein freies Software-Projekt werden und ausschließlich auf freien Komponenten aufbauen. Außerdem soll unsere Software auf möglichst vielen Plattformen lauffähig sein. Es wird teilweise auf schon bestehenden offenen Quellcode zurückgegriffen und dieser (hoffentlich) weiter entwickelt.

1.5 Finanzierung

Es ist angedacht für das Projekt möglichst von vornherein eine Vollfinanzierung zu organisieren. Dazu soll ein Antrag bzw. zunächst eine 2-3 seitige Projektskizze erstellt werden, mit der bei entsprechend engagierten Stiftungen oder Fördervereinen um die Finanzierung ersucht wird.

1.5.1 Stiftungen und Mittelbedarf

Zu den möglicherweise geeigneten Stiftungen und dem vorläufig grob abgeschätzten Mittelbedarf gibt es ein paar Details in den letzten Protokollen. Noch nicht berücksichtigt sind bisher die technischen (Hardware) Voraussetzungen (z.B. Serverinfrastruktur) für die praktische Arbeit.

1.5.2 Antrag / Projektskizze

Vorbemerkung: Für den Antrag ist es sehr wichtig klar zu trennen zwischen einerseits dem allgemeinen vielleicht sogar theoretischen Ansatz/Einsatz von LD und unserem spezielle Projekt in Form der angestrebten Softwarelösung!

Einleitung: Eine Demokratie lebt von Ideen und der Initiative der Menschen aus der Gesellschaft. Von Bürgerinnen und Bürgern wird in der letzten Zeit immer öfter mehr Mitbestimmung gefordert. In den vergangen Jahren hat sich das Internet zum dominierenden Informations und Kommunikationsmedium entwickelt. Fast alle Menschen in Deutschland haben Zugriff und nutzen es täglich. Sie vernetzen sich, informieren sich, leiten Nachrichten weiter, diskutieren und kommentieren. Das Internet bietet der Demokratie und den Menschen neue Möglichkeiten, es fehlt jedoch an einem System, das dies in strukturierte Bahnen lenkt. Mit einer neuen Plattform soll es möglich werden Demokratie auf neue Art zu praktizieren und zu leben.

Die Zielvorstellung ist ein internetbasiertes System, das es ermöglicht eigene politische Ideen und Meinungen und Vorschläge zu veröffentlichen, gemeinsam weiter zu entwickeln und darüber abzustimmen. Es soll ein Open Source Projekt werden, also mit einem offenen Programmcode, den alle weiter entwickeln können. Das Programm soll vor allem eine intuitive Oberfläche für eine einfache Handhabung bieten und zum mitmachen anregen. Diskussionen und komplexe politische Vorschläge sollen für alle transparent und gut strukturiert dargestellt werden, damit man sich einfach einen Überblick verschaffen und sich gut beteiligen kann. Der Anwendungsbereich eines solchen Angebots erstreckt sich von allgemeinen öffentlichen Diskussionen, über Partei- oder Gruppeninterne Abstimmungen bis hin zu Unternehmensinternen Verbesserungsvorschlägen.

Status quo: Es gibt Initiativen, die ähnliche Ansätze versuchen, sie beschränken sich im Moment jedoch hauptsächlich auf die Abstimmungskomponente. Aufgrund der Darstellung der Inhalte, der schwierigen Übersichtlichkeit und der teils unintuitiven Bedienung konnten sich diese Projekte bisher nicht durchsetzen. Weitere Probleme sind unübliche Programmiersprachen und eine dünne Personaldecke. Die Heidelberger Gruppe setzt sich mit dem Thema seit über einem Jahr auseinander und hat aus einem ersten Versuch viele Erkenntnisse mitgenommen. Es gibt kein System, dass die „Evolution oder Entwicklung von Ideen“ ermöglicht und eine hohe Bedienfreundlichkeit aufweist.

Umsetzung: Das Projekt soll von projekterfahrenen Studierenden geleitet und vorangetrieben werden. Bei der Umsetzung assistieren erfahrene Entwickler, es sollen jedoch vor allem auch engagierte Studierende programmieren. Um sehr gute und kontinuierliche Arbeit machen zu können, bedarf es teilweise externer Experten und einer Aufwandsentschädigung für die Beteiligten.

2 Vorhandene Systeme / praktische Beispiele

2.1 Verwendete Programmiersprachen (Vor-/Nachteile)

2.1.1 PHP, PostGreSQL, Lua

Warum PostgreSQL? PostgreSQL ist ein freies, objektrelationales Datenbankmanagementsystem, das wir dazu verwenden, um die Daten des Systems zu speichern. Es ist lauffähig auf vielen Unix-Plattformen (darunter auch Linux), auf Mac OS X und Windows und bietet Schnittstellen zu vielen Programmiersprachen, darunter auch PHP. Im Gegensatz zu MySQL unterstützt PostgreSQL auch Constraints vollständig, um die referenzielle Integrität der Daten sicherzustellen. Unsere Wahl fiel auf PostgreSQL, da wir für unser Projekt ein professionelles, freies Datenbankmanagementsystem verwenden möchten. Nicht zuletzt basiert der Kern von Liquid Feedback, den wir für unser Projekt verwenden möchten auf PostgreSQL.

Warum PHP? PHP ist eine freie objektorientierte Skriptsprache, die hauptsächlich zur Erstellung dynamischer Webseiten oder Webanwendungen verwendet wird. Es ist lauffähig auf vielen Unix-Plattformen (darunter auch Linux), auf Mac OS X und Windows und bietet eine breite Datenbankunterstützung, darunter auch PostgreSQL. Die aktuelle Version von PHP verwendet als Zeichensatz ausschließlich Unicode, wodurch die Software problemlos auf Sprachen mit nichtlateinischer Schrift angepasst werden kann. (hm, PHP 6 ist anscheinend noch nicht fertig). Außerdem stehen aufgrund der weiten Verbreitung von PHP zahlreiche Funktionsbibliotheken zur Verfügung.

2.2 Entscheidungsmethoden

2.2.1 Condorcet (Schulze)

Condorcet-Methode: -> Wahlmethoden, bei dem der Wähler Kandidaten nach dem Rang ordnet -> Es wird ein Sieger ermittelt, indem immer 1 gegen 1 gespielt wird, der der alles gewinnt ist Sieger -> Methoden unterscheiden sich, wenn es keinen Sieger gibt

Schultze Methode: Die momentan am meisten genutze Condorcet Methode. Kandidaten können auf den gleichen Rang gesetzt werden. Auswertung über einen Graphen.

2.3 Technische Ansätze

2.4 Kern-Plugin-Struktur, um die Flexibilität für die Anwendungsszenarien zu erhalten

3 Anwendungsszenarien

3.1 Allgemein

• Ein neuer Weg in „Moderation von Entscheidungsprozessen und Ergebnisfindungsprozessen“
• „Gruppe von Menschen die versucht eine Entscheidung zu treffen"
• Was für Situationen gibt es, wo man sowas braucht?
• Was will ich entscheiden – gibt es Dinge, die ich ausschließen will

Anwendungsfälle: - Hochschule - Betrieb - In kleinen Gruppen, in riesigen Gruppen

- Ideenfindung - Ideenentwicklung - Diskussion - Abstimmung

3.2 Klein(Arbeits-)gruppen

3.3 Uni Heidelberg/StuRa

3.4 Große Organisationen (Unternehmen, Parteien)

4 Fähigkeiten von LD

4.1 geklärtes

• es müssen laufend „Abstimmungen“ möglich sein --> diese Interaktivität ist durch das bewerten von Argumenten und Vorschlägen gegeben
• In der Entwicklungsphase darf das System noch nicht starr sein, man muss Stimmen/votes hin oder her ziehen können wie man will
• Modulare Software + Trennung von Kern & Frontend & Tools (Funktionalitätserweiterung/anpassung an Anwendungsfeld) "eine Box mit verschiedenen Tools aus der man sich bedienen kann"--> soll so gemacht werden
• Es soll Diskussion strukturiert darstellen können
• Die Einstiegsmöglichkeit soll leicht sein, man muss die Hauptentscheidungslinien gut erkennen können

4.2 teilweise geklärtes

• Transparenz der Entscheidung → graphische Aufarbeitung --> durch Vorschlagsbaum im Prozess, aber wie ist es hinterher mit Ergebnissen und wie lange sollen Ergebnisse sichtbar bleiben?
  • man soll den ganzen Delegationsweg sehen --> nicht nur hinterher, sondern immer (d.h. man kann bei Personen immer alle delegationen sehen) --> stimmen werden nie gesplittet!
  • sollen Gruppen auch delegieren können?
    • ja, an Einzelpersonen? - ja!--> man sieht ja die delegationsketten, wenn eine gruppe an eine anonyme Person delegiert, dann soll sie halt.
    • an Gruppen? - ja!
  • alle die delegationen haben müssen vor einer best. Frist abstimmen
  • man muss auch einstellen können, dass man keiene delegationen bekommen kann.
    • kann ich einstellen, dass ich nur delegationen zu bestimmten themen annehme? --> weil dann müsste eine gewisse Auswahl an Themen vorgegeben sein!!! - aber nicht nur das, wir laufen mit den Themen auch in Delegationskonflikte, weil ich nach Themen delegieren kann und so darf eine Angelegenheit theoretisch nur einem Thema zugeordnet sein, was bei vielen komplexen Angelegenheiten jedoch zu Verzerrungen führen kann.
• Problem der auswahl an Themen (welche gibt es überhaupt, was sind Unterpunkte und was sind überpunkte?) und überschneidung von Themen. Selbst wenn eine Themenauswahl beim Aufsetzen vorgegeben wird, so werden im Laufe der Benutzung neue Themen hinzukommen (-> Neue Delegationskriterien?) Eine Angelegenheit braucht ein (mindestens und höchstens?) Thema, aber evtl. wollen die user dies ändern, weil die Kategorisierung strittig ist und durch die Themendelegation in einem "reiferen" LD durch Gruppen und viele Delegationen die Auswahl des Themas eine Richtung (Machtgewichte) vorgeben kann.
• • delegationsringe vermeiden: system meldet delegationsringe, man soll immer erfahren wie die delegationskette aussieht. Prinzipiell erscheinen uns Ringe aber nicht besonders problematisch. Christian hatte aber mal was zu Pfadabhängigkeiten und ähnlichem erzählt, wo es schwierig wird das letztendlich in Software zu gießen. Außerdem hatte er erwähnt, dass es bei Ringen auch Stimmsplittungen geben könnte. Das konnten wir aktuell nicht mehr nachvollziehen, stehen aber jetzt auf dem Standpunkt, dass es das Ziel sein muss bei Stimmen nur in Ganzen zu rechnen, um die Vergleichbarkeit zwischen den usern zu gewährleisten.
  • als einfacher Teilnehmer/Nutzer kann ich meine History angucken & Benachrichtigung über Entscheidung. Wenn ich delegiert habe und die Person anders abstimmt, dann hat man halt pech gehabt.
  • man will auch schauen wie jemand abgestimmt hat, an den man eine Stimme delegiert, deshalb History ja. History auch ja, weil ich immer Informationen über andere bekomme: z.B. ich erfahre dass durch eine delegationskette die Person xY für AB gestimmt hat...
  • wie kann Manipulation verhindert werden? --> alle sollen "Stimmen von Hand nachzählen können" - Inwiefern ist das mit Personendaten verknüpft --> nur die Synonyme, sonst nix (ohne persönliche Daten). Nur so kann eine Transparenz hergestellt werden.
    • anonymisierungsdiskussion: je aktiver ein Nutzer ist, desto weniger anonym wird er.
    • Manipulation und Administration: --> dazu gibt es was gutes im Piraten-Wiki
    • alle abstimmen? dann ist Manupulation in Form von zusätzlicher Stimmgenerierung bzw. Stimmnegierung nicht mehr möglich.
    • alle die nicht abstimmen werden im Ergebnis berücksichtigt - z.B. als Enthaltung - damit würden auch "Nichtwähler" berücksichtigt
• gruppen haben andere Deadlines bei der Abstimmung: Diese ist z.B. 3 Tage vor der Generalabstimmung und wird dann allen mitgeteilt die eine Stimme an dei Gruppe delegiert haben.
  • Gruppen können z.B. auch die Entscheidung, die in ihrem Liquid zum thema A gefällt wird, auf die Leute übertragen die ihre Stimme an die Gruppe delegiert haben. (Gesamtentscheidung zum thema A).
  • Gruppen können die internen Regelungen wie sie die Delegation machen selbst entscheiden. Es kann die oben beschriebene "Mirror-Möglichkeit" geben, es kann die "einer entscheidet" möglichkeit geben, es kann Mehrheitsentscheidungen geben, Konsens geben...
  • Gruppenmitgliedschaften können ebenfalls von den Gruppen selbst definiert werden: Aufnahme nach bestätigung, direktaufnahme
  • man soll auf jeden Fall alle Gruppen sehen können und in allen gruppen alles lesen können, auch ohne Mitgliedschaft. --> Transparenz"! Hinterzimmer werden nicht implementiert =).
• „Evolution der Idee“ (22.3.) Minimalkonsens? Varianten zusammen führen... → Scheinalternativen --> muss noch verbessert werden
• „Startseite“ mit Anderungsmeldungen + Beobachten (→ untersch. Formen des Interesses)
• wenig Moderation / selbstregulierend
• Listen (von Themen, Vorschlägen etc.) ordnen über versch. Attribute (Beliebtheit, Neuigkeit) --> ist durch die pull down Menüs gegeben, welche Attribute?
• Problemerörterungsphase (infos sammeln vor Entscheidungen) erst denken, dann handeln --> 3 Phaseneinteilung, was sind die Kriterien zum Übergang?
• Phasen, die eine unterschiedliche bearbeitung eines problems ermögilchen: wenn wir sehen, dass neue aspekte rein kommen, dann geh ich nochmal ein paar schritte zurück
• Wissensdatenbank (Referenzen, Erläuterungen, auf die z.B. bei Argumentationen verwiesen werden kann) --> ist jedem Vorschlag angefügt - Gesamtwissensdatenbank?
• Vorschläge in Gruppen (im LD) geschlossen diskutieren, bevor sie „raus“ gehen. (in die LD Öffentlichkeit)
• Interesse haben, Interesse abonierern können?
  • Leute die irgendwo mitgearbeitet haben werden informiert, wenn da was bearbeitet wird
  • Ich möchte über alle Einzelheiten, oder über neue Versionen etc informiert werden.

4.2.1 am 19.7. Besprochene Themen (noch offen)

• themen
  • zuordnung über tags (ermöglicht mehrdeutige zuordnung)
    • problem: wenn man zu gewissen Themen delegiert, wie wirkt sich das dann aus
    • dilemma: thematische differenzierung oder überschneidung vs. klare delegationen
      • wenn z.B. ein user eine delegation an xy für umwelt hat und ein thema umwelt und energie hat, dann muss der user rückgefragt werden.
      • nicht mehr als drei tags, sonst machen die delegationen keinen sinn mehr
  • wie werden die Tags in Themenfelder o.ä. integriert / darstellung?
  • tags abonnieren?

• wie verhindert man dummy- accounts
  • beim zugang: account über email verifizieren
  • mehrere accounts pro person:
  • bei geschlossenen systemen oder kleinen gruppen hat man eine gesamtzahl

• • Anwendungsbeispiele
    • Admin läd ein: man schließt die mögilchkeit dass accounts selber angelegt werden aus
    • bsp unternehmen: über eine gewisse domain (filter)(emailstruktur) - oder uni - nur über stud.uni-hd
    • parteien: invites oder verifikationscode --> piratenwiki beschreibung
    • völlig frei --> Konsequenzen für qualität der ergebnisse !!!

• scheinalternativen: (beseitigen)
  • system semantik beibringen (das liegt noch in der Zukunft)
  • oder über user bzw. über bewertungen und crowdsourcing (Effektivität ist abhängig vom Nutzungsgrad)

• wie macht das system 'Spaß'?
  • bilder und grafiken zur besseren übersichtlichkeit
  • textvergleiche und kommentarfunktionen
  • "twitter"-funktionen
  • "circles"-funktion (google+) ???

4.3 ungeklärtes

• wie bekommt man einen account - sodass es keine dummy-accounts gibt?
• soll man bei einem Vorschlag eine zusätzliche Kategorie haben wie "Rahmenbedingungen" wo z.B. gesetzliche Bestimmungen zum Thema oder der finanzielle Rahmen o.ä. aufgelistet sind?
• Möglichkeit von Umfragen - oder wird das schon über die Vorschlagsmöglichkeit abgedeckt?
• Einbindung von „realen“ Diskussionen
• Diskussion & Abstimmungen in Gruppen / AG / Treffen (offline-Ergebnisse müssen zurück gespiegelt werden)
• Transparenz / Übersichtlichkeit des Systems aus Sicht des Benutzers
• Anmeldung versch. Interessenebenen
• (autom.) Strukturierung bei Argumentationen
• Bei Vorschlägen: alte Versionen / Neue Versionen → Verhaltnis / Neutralitat wahren (vgl. LF Problem des frühen Interesses)
• Textentwicklung vs. Ideenentwicklung vs. Verteilte Entscheidungsprozesse (untersch. Juristischer Härte)
• gruppeninterne (von außen nicht sichtbare) Diskussionsmoglichkeit (limitierte eigene LD-Instanz fur Gruppe)
• Visualisierung von Vorschlagsbaumen
• Pseudonymisierung (vgl. Transparenz) vs. Verifikation des Nutzers
• Strukturierung von Diskussionen (gerade bei vielen Nutzern müssten sich die möglichen Strukturen automatisch verengen)
• Ideenentwicklungstool (Ideenfindung) vs. Beschlussvorlagen und Textentwicklungstool --> muss alles können
• Ist es für viele Nutzern konzipiert, dann stärker vereinfacht, damit es benutzbar bleibt oder sollen nur wenige mitmachen können und „tiefer“ in Texte einsteigen? --> sollte beides können
• Probleme unterschiedlicher Komplexität, wie flexibel kann ein System sein und auf einfache und schwierige Dinge eingehen

Varianten

• Möglichkeit von Varianten
• Manche Entscheidungen zerlegen, Zwischenschritte
• Minimalkonsens sichern, weiter diskutieren
• Verschiedene Entscheidungen zusammenführen (Versionen verbinden?)
• Teilaspekte gegeneinander abwägen
• Möglichkeit von Methafragen: Verschiedene Schemata?, Vorschlag von Verfahren/Vorgehen soll möglich sein
• wie fasse ich 20 Vorschläge die sich nur minimal unterscheiden zusammen (Scheinalternativen)?

4.4 Fragen

„Was kann man tun, das man nicht erschlagen wird (von viel Text)“ „Was kann man tun, dass spätere Alternativen gegenüber etablierten nicht benachteiligt werden“ „Wie kann Meinungsbildung stattfinden, bevor (undurchdachte)Alternativen eingestellt werden?“ „Man sollte Vorschläge Stück für Stück diskutieren können.“ - Mehere Phasen? Zuerst grob, dann feiner? „Wie kann ich verhindern, dass es eine Flut von Vorschlägen gibt?“ 1. Entwicklungsphase nicht so starr, der und der Punkt ist strittig – daran kann man seperat weiter machen – einen eigenen Vorschlag dazu machen? „Datails von Grundsatzentscheidungen – wie trennt man das?“

5 Grundsätzliche Limitierungen

5.1 Entscheidungskonsequenz

Wie juristisch hart ist eine LD-Entscheidung?

• Inwiefern sind Vorschläge im Gesamtkontext (un)widersprüchlich?

=> es gibt keine objektive Gesetzgebung, also sind Widersprüche nur logisch Wie können sujektiv bedingte Widersprüche in LD berücksichtigt werden?

• Nehmen Institutionen die Ergebnisse an?

5.2 Anonymität vs. Nachvollziehbarkeit

5.3 Moderationsnotwendigkeit, begrenztes semantisches Verständnis der Technik

• System übernimmt Moderation? (gleichwertige Behandlung von Ideen)
• Allgemein: Spannungsfeld zwischen Moderation und keiner Moderation (wenn man ein hoch skalierendes Modell annimmt, darf die Moderation keine große Aufgabe sein...)
• wie ist die Berechtigung menschlicher Intervention (Moderation), wie werden ModeratorInnen ausgewählt? Was ist ihr Legitimation?
• Taktische Spielchen, „ich mache absichtlich einen schlechten Vorschlag“
• Trolle, Spamer, Beleidigungen, Rassismus, Sexismus...
• Regulationsmechanismus: User bewerten ob es an Fragestellung vorbei geht. „unsachlich“ (Spam) oder „Thema verfehlt“ => allgemein: „Relevanz für die Entscheidung“
• wie wird die Moderation legitimiert, muss aufgefordert werden, um in Aktion zu treten

5.4 Ansprüche an Verständlichkeit (Transparenz)

5.4.1 Limitierung der Ausdrucksmöglichkeiten (flexibel nach Anwendung und Phasen)

6 Grundsätzliche Gedanken

Schwarmintelligenz nutzen ... interessanter Link in dem auch zu einer Studie weiterverlinkt wird: http://www.spiegel.de/wissenschaft/mensch/0,1518,762837,00.html Diese Studie gibt Antwort auf die Frage, ob während einer Abstimmung Zwischenergebnisse geliefert werden sollten (--> nein!).

Es wäre auch gut Funktionen ins System einzubauen wie "jemandem anderen etwas zeigen" oder Kommentare und Vorschläge zu "posten" ... um damit den gleichen Effekt wie bei Twitter zu erzielen: wichtige Sachen verbreiten sich schneller

6.1 Anreize (die LD bietet, damit es genutzt wird)

• Mitbestimmung
• Gleichberechtigung
• „Kummer-Kasten“, Problem-Threat, Konfliktprävention
• Betroffenheit
• Erfolg
• Hohe Akzeptanz für das System/die Entscheidung, weil ich weiß, dass es gerecht ist
• Präsenz in der Öffentlichkeit
• (soziale Interaktion)
• EMPOWERMENT!

In einem Unternehmen: Konfliktvermeidung, gute Einbindung von Mitarbeitern, Transparenz für Entscheidungen anderer – Nutzen von Querdenken über Arbeitsgruppen hinaus, besserer Überblick, höhere Motivation, Vorschläge von anderen Abteilungen/ Abteilungsübergreifend, Reduzierung von Reibungsverlusten durch Vernetzung und frühzeituges informieren

6.2 Welche Probleme löst LD?

Einstiegshürde politische beteiligung herabsetzen? ein grundsätzliches Problem der aktuellen Demokratie? einbindung der Bevölkerung? Gap zwischen den Ansprüchen der Bevölkerung und der Umsetzung der politik verkleinern? Akzeptanz der Politik erhöhen? mehr direkte Demokratie? Bürgerbeteiligung besser umsetzen Bürgern, die sich mehr einbringen wollen, eine Plattform geben

ergänzend:

• Welche Probleme löst LD nicht?
• Welche Probleme werden durch LD neu geschaffen? (Stw. Hürden/Inklusion)
• Wie unterscheidet sich unsere angestrebte Variante von bereits vorhandenen Lösungen/Ansätzen? (was machen wir anders/besser? Warum sollte unser spezielles Projekt gefördert werden (im Rahmen des gesamte LD)? (wichtig für Antrag!, Stakeholderanalyse)

7 Visualisierung

7.1 Skizzen

8 Aktuell offen Fragen und nächste Arbeitsaufträge