Changes between Version 8 and Version 9 of UserStories/FreifunkMap

Timestamp:

22.12.2012 19:25:41 (12 years ago)

Author:

MK

Comment:

--

UserStories/FreifunkMap

@@ -4 +4 @@
 
 Hier gibt es auch schon eine Menge Infos von Aaron zum dem Thema:
-
-https://github.com/FFM/FFM/tree/master/doc
-https://github.com/FFM/FFM/blob/master/doc/cwnos.txt
-https://github.com/FFM/FFM/blob/master/doc/cwnos-architecture-overivew.pdf
+ * https://github.com/FFM/FFM/tree/master/doc
+ * https://github.com/FFM/FFM/blob/master/doc/cwnos.txt
+ * https://github.com/FFM/FFM/blob/master/doc/cwnos-architecture-overivew.pdf
 
 === User ===
@@ -15 +14 @@
   * Das sollte Server-Seitig für die Domain FF-Karte einstellbar sein (Wer kann neue user anlegen? {{{admin||user}}})
  * User hat einen Nickname, über dem man ihm interne Nachrichten schicken kann.
- * User kann einstellen, welche seiner Daten welcher Community angezegt werden sollen.
+ * User kann einstellen, welche seiner Daten welcher Community angezeigt werden sollen.
  * Das System kann User per Mail über neue Nachrichten informieren. 
- * User soll eine neue Community erstellen können. Community kann sehr lokal (Strassenzug) und sehr global (Berlin, D, A, CH) sein. Properties der 
 
-=== Community ===
-  * Name
-  * Anzahl Mitglieder (rechnen!)
-  * ggf. regelmäßige Treffen (Location, Anschrift, Uhrzeit, Periode)
-  * Community kann nur gelöscht werden, wenn leer = keine Mitglieder
- * User soll vorhandener Community beitreten können. (beliebig vielen)
- * User soll neuen Accesspoint erstellen können. Properties zum Accesspoint:
-  * Standort (Geo, Höhe)
-  * Kanal
-  * Meshprotokoll
-  * ...
+=== Datenmodell ===
+ * User, Node, Community
+   * Node gehört-zu Community?
+   * User gehört-zu Community
+   * Community wird-administriert-von User
+   * Node wird-administriert-von User
+ * User: Name, E-Mail, Wikitext als Beschreibung
+   * Leute können User per Webmail kontaktieren.
+ * Node: Name, Position, Kanal, Protokoll...
+   * User soll neuen Accesspoint erstellen können.
+ * Community: Name, Ort, Wikitext als Beschreibung, Treffenstermin/-ort/-periode
+   * Beschreibungstext sollte insbesondere auch Links zu zugeordneten Foren und Wiki-Seiten enthalten (per Template motivieren)
+   * User soll eine neue Community erstellen bzw. beliebig vielen Communitys beitreten können.
+   * Community kann nur gelöscht werden, wenn leer = keine Mitglieder
+   * Ort kann sehr lokal (Strassenzug) und sehr global (Berlin, D, A, CH) sein.
+   * Termin wäre für einen Service wie "upcoming meetings" interessant, aber wohl kaum wirklich aktuell zu halten. Deaktivieren, falls Meetings nicht nach Nachfrage-Mail bestätigt?
 
-=== NodeMap ===
+=== !NodeMap ===
 
  * Was sind im Moment die größten Probleme?
    0. verschiedene Datenformate.
    0. nicht replizierbar.
-   0. läuft nicht auf Smartphones/Tablets.
-   0. map skaliert nicht weltweit.
-   0. code unmaintained oder unmaintainable.
-
- * In einer GeoMap sollen alle Accesspoints sichtbar sein (Standort). 
+   0. läuft nicht auf !Smartphones/Tablets.
+   0. Map skaliert nicht weltweit.
+   0. Code unmaintained oder unmaintainable.
+ * In einer !GeoMap sollen alle Accesspoints sichtbar sein (Standort). 
  * Sofern diese meshen (mindestens OLSR, besser auch batman), soll die Linkverbindung und Linkqualität angezeigt werden.  
  * Schneller Überblick, wie groß ist FF?
@@ -53 +55 @@
  * feste ewig gültige kurze schöne URLs für alles, was sich im System findet
  * einfaches REST-Interface
+
+=== Vorgehen ===
+ * !Bau/Zusammenstellen einer möglichst simplen Komponente, die Node-Daten zusammensammelt und in einfachem vereinheitlichtem Format per REST zur Verfügung stellt
+   * z.B. PHP/SQLite-Skript, das erstmal einfach alle Nodes als Komplett-Dump als CSV per REST ausliefert
+ * Datenmodell in DM bauen
+ * Importer für o.g. Daten in DM schreiben (Synchronisierung...)
+ * ...