Hubs4Change (drupal) für die SoLaWi Netzwerk Seite


#1

ich hatte @tantebootsy mal so verstanden, dass er eher weg von typo3 möchte.

wir bauen für ein paar netzwerke seid märz eine freie drupal distribution die u.a. alle funktionen aus dem dokument in der cloud abdeckt und relativ nah an einer beta version ist. dadurch das mehrere netzwerke dahinterstehen und wir bisher nur positive resonanz bekommen, rechnen wir damit, dass sich das ganz gut trägt. wir entwickeln es grundsätzlich ehrenamtlich, ein optionales hosting soll so gestaltet werden, dass wartung&support kostendeckend sind.

netzwerke bisher sind wandel.jetzt, transition zürich, global ecovillage network suisse, bonn im wandel und stadtwandler freiburg. von den fünfen sind auch je leute aktiv an der entwicklung beteiligt, daher ist klar, dass sie es nutzen, weitere werden wir erst wirklich ansprechen, wenn wir fertig sind, daher gibt es auch noch keine internetpräsenz. bisher sind ein paar urbane netzwerke und zb 1-x regional wert ag’s die davon mitbekommen haben sehr interessiert.

und genau, wir stellen es auch schon bald einem netzwerk freier refugee radios in bawü zur verfügung, dadurch wird es neben deutsch-englisch und perspektivisch französisch, auch in arabisch und farsi übersetzt werden und eine umfassende mediathek bekommen.

mitgliederverwaltung wird integriert sein, inkl. optionaler collmex api oder csv export für sepa&co.

rest & andere schnittstellen, um organisationen, termine artikel mit anderen plattformen teilen zu können. gerade organisationen sollen mit karte von morgen, imwandel usw open data mäßig geteilt werden können, ein entsprechender peer2peer austauschstandard ist eine parallele baustelle.

wenn wir im herbst eine beta haben, kann ich das in ein solawi demo gitlab legen und eine instanz einrichten und es kann als potentielles lösung evaluiert werden.

der newsletter wird so sein, dass wir pro kampagne statistiken erheben und nicht pro user. bisher gibt es da ja wenig systeme, die statistiken machen ohne gleich alles zu tracken. egal in welchem system, finde ich das wichtig, dass man über matomo o.ä. newsletter auswerten kann, aber nur pro newsletter, nicht pro user. ich finde das gerade bei kleinen initiativen und netzwerken schlimm, wenn die leute, die die empfänger kennen, genau sehen, wann wer welchen newsletter öffnet und welche links wie oft klickt, nicht dass das in großem maßstab nicht schlimmer wäre, aber diese persönliche ebene finde ich auch problematisch. und aktuell gehen immer mehr kleine alternative initiativen, freiberufler… zu mailchimp…

es wird auch eine interessante kampagnenfunktion geben, aber am besten schaut ihr euch das bei interesse an, wenns soweit ist.


wie von felix gezeigt, man kann direkt im text kommentieren :wink:


Kommunikations-Paket
#2

Das habe ich doch in meinem Post beschrieben, warum ich bzgl. dem CMS nicht explizit geworden bin.

Ja klar, ich will nicht weiterhin der Einzige sein, der in Sachen Webseite tätig ist. Ich möchte, dass das Ding mehrere Leute weiterentwickeln und das nicht nur an mir hängt.

Ist das quasi “dein letztes Wort”? Weil irgendwann hattest du mir auch mal etwas von Kosten geschrieben für die Entwicklung. :wink:

Habt ihr denn ein technisches Konzept auf dem das Ganze fußt? Es wäre schon wichtig, wenn man mehrere untersch. Netzwerke mit ggf. untersch. Bedürfnissen einbezieht, dass die Weiterentwicklung gut durchdacht ist – nicht, dass man irgendwann ein nicht mehr handlebares Monster an der Backe hat :wink:

Allet klar, dann schauen wir mal drüber, merci!

Jo, ich bin auch gegen Link-Tracking pro User.

Jau, geht. Man muss erst einen Text markieren, dann kann man über’s Kontext-Menü nen Kommentar einfügen.

Liebe Grüße,
Micha


#3

ich denke schon, dass man bei dem relaunch geld ausgeben kann. ich verwies damals v.a. auf design, migration und kommunkation. und das wir unseren stand der technik schenken können bzw eh machen. bei funktionen, die wir bisher nicht abdecken, kann halt sein, dass wir sie nicht machen wollen :wink: bisher habe ich aber keine gesehen.

wegen design: farben lassen sich sehr detailliert (ca 20 stellen) per farbkreis anpassen, ebenfalls im admin interface gibt es ein css editor für kleinkram. je nach bedarf sonst ein subtheme.

wir würden ein so großes projekt nicht ohne jahrzehntelange erfahrung und konzept machen. ich würde sagen es floss mehr zeit in wirkliche konzeptentwicklung, als in die implementierung.

es muss aber trotzdem für jeden anwendungsfall geschaut werden, ob es sinnvoll ist. bisher sehen wir zb nicht einzelne solawis als nutzer, durchaus aber einzelne transition initiativen. dafür würden einzelne solawis auf der plattformseite die möglichkeit haben recht weitreichende css funktionen für ihre unterseite zu nutzen (diverse inhaltstypen, rechteverwaltung, menü, baukasten, karte der verteilpunkte, möglichkeit die seite über subdomain mit eigenem css und ohne globalen plattform kontext zu erreichen, perspektivisch einfache mitgliederverwaltung) und bräuchten so keine webseite. eine solawi die gut mit wordpess kann, mag sich aber vllt doch lieber ihre eigene webseite bauen. wir wollen damit auch keine webseiten ersetzen, war nur ein nebenprodukt (es gibt ja viele gruppierungen, die facebook nutzen, weil es einfacher ist als sich was zu installieren).

wir müssten dann also ehrlich drauf schauen, was das netzwerk braucht, was wir bieten, wie die perspektiven sein können und was andere systeme bieten. dann sehen wir, ob es passt oder nicht. mit jeder änderung die individuell nur für ein netzwerk gemacht wird, wird der wartungsaufwand es gesamtprojektes größer, bisher ist das aber überschaubar und man kann einzelne features oder felder deaktivieren.

eine besondere herausforderung bei mehreren netzwerken ist auch das deployment und regelmäßige updates. ich denke wir würden unsere systeme alle paar monate aktualisieren, das soll dann über ein zentrales interface gehen: staging instanzen für alle netzwerke anstoßen, automatische tests, manuelle tests, dann live gehen lassen. auf diesem weg würden auch sicherheitsupdates eingespielt werden (drupal hatte in den letzten 5 jahren 3 GAUs die quasi in 12-24h geschlossen werden mussten und aktuell noch keine automatischen updates, wir hatten mit über 50 seiten aber auch noch keine probleme sie sicher zu halten, viele andere schon. das ist bei wordpress anders, wobei komplexere wordpress systeme auch manuell aktualisiert werden, dann aber meist das budget dafür haben. oder halt gehackt werden;-). wer es selber hostet muss das alles beachten und bei updates darauf achten, welche änderungen bei einem merge konflikt übernommen werden sollen und ggf von hand in die config dateien eingreifen. es ist auch möglich, nie mehr von unserem master zu aktualisieren und selber drupal core und module aktuell zu halten. für das selber hosten braucht es aber sehr hohes drupal knowhow, da es ein komplexes projekt ist.


#4

Das klingt gut – kannst du hier mal den Link zu eurer Dokumentation posten?

Diesen Satz verstehe ich nicht – kannst du ihn nochmals in anderen Worten erklären?

Wäre das Mapping auf eine eigene Domain ebenfalls möglich? Stand ja auch im Konzept. Ich denke, dass u.a. das den Solawis wichtig sein wird, um die eigene Identität behalten zu können. Wäre auch für die Usability der Webseiten-Besucher wichtig, damit man nicht mit Links à la solawi-vor-dem-herrn.netzwerk-domain.org/ueber-uns hantieren muss.

Ja, genau deshalb sehe ich da auch Potential, dass einzelne Solawis an einer fertigen Lösung interessiert sein könnten – weil sie es verständlicher Weise “einfach” haben wollen. Interessant wird es dann, wenn eine gemeinsame Web-Lösung später mal Schnittstellen zu anderen Solawi-Softwares bietet wie z.B. ernte-teilen.org und Open Olitor oder auch dem Software-Paket (wenn es denn kommt) bestehend aus NextCloud etc.


#5

Merlin und ich haben das Gesamtprojekt im Kopf. Für einzelne Funktionen arbeiten wir in Issues und Gesprächen am Konzept. Die Dokumentation für Plattformträger und User folgt dann, wenn eine erste Version fertig ist. Es gibt auch irgendwo schon eine Liste vieler Funktionen, quasi die Überschriften/Seiten einer Dokumentation.

Wenn du das Projekt nach erster Evaluation spannend findet, könntest du hier auch mit helfen und zur Dokumentation der beitragen.

Wir sehen SoLaWis nicht direkt als Zielgruppe, die sich das Projekt installiert oder von uns gehostet bekommt. Eher Netzwerkartigere Organisationen, wie z.B. eine größere Transition Initiative, die die Akteure ihrer Region sichtbar machen möchte und da auch viel Energie reinsteckt. Für viele ist Wordpress oder ein schlankeres Drupal oder … eine viel bessere Lösung.

Ja, Subdomain war falsch formuliert. Domains an sich werden für die Profilseiten möglich sein. Diese sind bisher Onepager (mit Menü), man kann dann den Kalender hinzufügen und an der richtigen Stelle platzieren und dann erscheinen dort die nächsten Termine, selbes für Blog. Für den Anwendungsfall den wir haben (Kampagnen) reicht das, evtl. könnte man später auch separate Blog/Kalender Seiten machen

Ernte Teilen will ja auch ne API haben oder hat sie schon, das wird also gehen. für die andern Beispiele könnte man single-sign-on einrichten.


ansonsten einfach abwarten, bis wir was fertig haben und weiter am Bedarfskonzept für SoLaWi arbeiten und andere Lösungen evaluieren.

ich habe da auch evtl etwas schnell gelesen, also ich kann mir vorstellen, dass es für den Relaunch der Netzwerkseite interessant sein kann, als ein Baukasten für SoLaWis sehe ich es nicht. Da würde ich eher ein Wordpress empfehlen (mit den Plugins ist ja auch einiges macbar) oder wenn es komplexer sein soll und langfristig genug Leute mit entsprechendem Knowhow in Reichweite sind, ein eigenes Drupal Projekt, ggf. basierend auf Drutopia.


#6

Das hatte ich befürchtet :wink:

Ich glaube hier liegt ein Missverständnis vor: es geht ja hier nicht darum, was ich toll finde, sondern was wir als Web Crew für sinnvoll erachten – das ist also eine gemeinsamer Prozess, bei dem hfftl. hintendran dann eine Entscheidungsgrundlage für den Rat (das Entscheidungsgremium des Netzwerks) herauskommt. Deshalb mein Konzept-Aufschlag hier, um eine entsprechende Diskussion anzuregen.

Ja, das befürchte ich auch. Eure Portal-Lösung würde in Bezug auf das Solawi-Netzwerk bei den Regiogruppen aufhören, meine Idee war jedoch noch einen Schritt weiter zu gehen. Aber gut, schauen wir mal wie eure Sache aussieht und ich versuche in den nächsten Wochen noch zumindest ein paar Solawi-ITler hier ins Forum zu bekommen, damit wir das Thema auf breiterer Ebene gemeinsam besprechen können.
Sofern es Richtung z.B. Drutopia gehen sollte: wärt ihr da mit im Boot oder habt ihr keine Kapazitäten?


#7

In Sachen Drupal Lösungen für Solawis hat das Kartoffelkombinat eine anscheinend umfassende Lösung entwickelt, die sie auch unter Umständen frei lizensieren würden. Vielleicht willst du sie dir ja auch mal anschauen, @hannes:

Finding a date for the presentation of drupal based Kartoffel Kombinat administrative platform


#8

danke @yova. habs am rande wahrgenommen, ich kann evtl spontan teilnehmen, weiß es aber nicht. admin zugang zu einer spielwiese und/oder datei der präsentation zum nachträglich anschauen, fände ich aber interessant - aus drupal entwickler sicht, schauen was die so gemacht haben und wie. auch wer das macht und was die sonst so entwickeln

synergieen gibt es zwischen uns aber wahrscheinlich keine, da ich vermute dass das hubs4change drupal und die drupal based administrative platform zwei sehr unterschiedliche und wichtige anwendungsfälle abdecken.