WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: BlackBird on January 08, 2014, 10:46:10 AM
-
*beep* *beep*
-
Das wird es aber nie geben, weil z.B. Module mit Abhängigkeiten von anderen Modulen per Definition nicht gelistet werden dürfen.
ich mach mir vielleicht Feinde, wenn ich sage, vielleicht sollte man die alten Zöpfe einfach abschneiden. :-o
Die einzige brauchbare Alternative zu AMASP ist ein endlich ordentlich gepflegtes und freies Modulverzeichnis HIER!
Unterstütze ich zu 100%, ich verstehe auch, wenn man Bedenken gegenüber von einander anhängigen Modulen hat, aber, wenn man es streng nimmt, läuft WB doch auch nicht anders.
Ein Kompromiss, mit dem ich gut leben könnte, wäre z.b. eine Rubriken-Trennung von Stand-allone-Modulen und anderen Modulpaketen. Es gibt zwei Voraussetzungen, die passen müssen (für WB nutzbar und open Source) und wer etwas anderes ausschließt, sollte für sich mal prüfen, ob das noch dem großem Ziel dient, wegen dem wir überhaupt hier sind.
Man kann sich nicht mit jedem verstehen, muß man auch nicht, man muß auch nicht jedes Modul mögen. Jedes Modul hat oder hatte seine Zielgruppe und mit jedem Ausschluß verliert man auch eine mehr oder weniger große Gruppe der Comunity. Vielleicht wäre es mal an der Zeit, die Friedenspfeife zu rauchen, man muß ja nicht gleich heiraten (wenn man noch nicht will).
wenn ich die Leute zu mir locken möchte, dann schicke ich sie nicht von hier wieder weg. Der interessierte User möchte eine einzige Quelle, keine im ganzem Web verteilten. AMASP war solch Anlaufpunkt, es muß aber auch gepflegt werden und das am besten von der Comunity selbst. Hier gibt es so viele fähige Köpfe, die auch schon oft das eine oder andere Modul aktualisiert oder repariert haben, aber vieles geht eben unter, weil es auf AMASP nicht aktualisiert werden kann.
Hier wurde ein Schritt gemacht mit dem Addon-Bereich, das Angebot dort wächst auch ständig. Für mich der einzig richtige Weg. Keine Ahnung, wie das rechtlich ist, kann ich als Nicht-Autor einfach ein AMASP-Modul nehmen, überarbeiten und hier anbieten? Wäre der beste Weg, finde ich
Und, wie oben gesagt, "Modul-Kombinationen" , libraryAdmin z.b., wird von einem Großteil der Gemeinde genutzt, sorry, aber das gehört hier her (Zustimmung der Modul-Autoren vorausgesetzt)
-
Ich sehe da kein Problem viele AMASP-Module auch hier anzubieten. Vorzugsweise durchgetestet.
Solche, die von den Devs geprüft/überarbeitet wurden können auch gern ein extra Siegel bekommen. Die anderen sollten halt funktionieren.
-
Zum Thema Amasp: Man sollte sich nicht so felsenfest auf eine "offizielle" Seite versteifen. Was auf Amasp rumfliegt, wird gerne als schlecht und doof und was-weiß-ich bezeichnet. Aber es gibt dort einfach viele Module, deren Funktion zumindest recht brauchbar ist. Aber zumindest finde ich es besser, als den jetzigen Kraut-Und-Rüben-Salat im Forum. Ich habe ja wiederholt dafür plädiert, den Dateiupload im Forum zu unterbinden... Egal.
Wir haben ja auch andere Dinge, wie z.B. Redmine, was so aber auch nicht angenommen wird.
Man kann das tollste Repository machen, wenn es aber keinen Anklang findet (was beim jetzigen, offiziellen ja ziemlich der Fall ist) - tja.
Meine ganz persönliche Meinung ist ja, dass der Grund für das Nicht-Aktualisieren von Modulen wo ganz anders liegt - aber die Diskussion hat hier nun auch nix verloren. :wink:
-
Meine ganz persönliche Meinung ist ja, dass der Grund für das Nicht-Aktualisieren von Modulen wo ganz anders liegt - aber die Diskussion hat hier nun auch nix verloren
Keine Ahnung, was du für Geschichten kennst, sicher alles vor meiner Zeit. :roll:
Egal, was es da an persönlichen Sachen gibt oder auch nicht. Man sollte auch sehen, das es oft auch nur einfach der Lauf der Zeit ist. Jemand hat ein Modul gebraucht und es der Allgemeinheit zur Verfügung gestellt. Irgendwann hat man andere Interessen, keine Zeit mehr, ist verstorben, was auch immer. Auf der anderen Zeite gibt es viele Leute, die wie ich, garnicht wissen, wie das auf AMASP läft. Man repariert es selber, wenn's nicht läuft oder findet Hilfe im Forum, aber dann? Keine Ahnung und ich finde auch nix an Infos. Natürlich winkt der Insider jetzt ab, alles kein Problem :roll:
Eine Sammelstelle für alles ist TOP, die AMASP-Adresse ist bekannt und oft erste Anlaufstelle, aber es kann nicht einer alleine machen. Ich war z.b. die letzten 4 Jahre mehr im Krankenhaus als zu Hause. Wenn das mein Job gewesen wäre und ein Modul-Autor, der mir eine neue Version schickt, bekommt in 4 Wochen keine Antwort, dann hat sich das erledigt, der fragt nicht nochmal.
In meinem Hinterkopf schwebt auch immer der Gedanke: niemand macht das Hauptamtlich, es ist alles Freizeit. Solch Projekt wie AMASP sollte nicht einer alleine machen, es kann auch zur Last werden. Mit diesen Modulen steht und fällt WB.
Was auf Amasp rumfliegt, wird gerne als schlecht und doof und was-weiß-ich bezeichnet
wie oben schon gesagt, alles, was dort gehostet wird, hat irgendwann mal irgendwem genützt, von daher kann es nicht doof gewesen sein - meine Meinung!
Das manches nicht mehr den heutigen Standards entspricht oder von verschiedenen Leuten anders umgesetzt würde, ist keine Frage, man muß halt nur dran bleiben. Der normale User erwartet einfach, das das angebotene Modul X oder Y in der jeweiligen WB-Version funktioniert und wenn es das nicht tut, geht er zu Joomla oder WP
-
Ich hab's ja kurz angerissen:
Was spricht eigentlich grundsätzlich dagegen, http://project.websitebaker2.org/projects/wb28x-ext als "Spielwiese" zu nehmen (mit den üblichen Klauseln "von da mit eigenem Risiko bla blubb"), und alles was dort "final" ist kommt ins offizielle Repository? So war es meine ich mal angedacht. Jedes Modul kriegt sein Repository, es gibt ein paar Leute, die das Ganze koordinieren (muss ja nicht die WB-Entwicklung sein) und gut ist.
Redmine bietet technisch alles, was man so braucht - sogar noch mehr.
Und wenn man es nicht selber hosten will - Atlassian bietet alles für OpenSource-Projekte auch kostenlos an. phpBB nutzt dies z.B.
-
Ich hab's ja kurz angerissen:
Was spricht eigentlich grundsätzlich dagegen, http://project.websitebaker2.org/projects/wb28x-ext als "Spielwiese" zu nehmen (mit den üblichen Klauseln "von da mit eigenem Risiko bla blubb"), und alles was dort "final" ist kommt ins offizielle Repository? ....
So oder ähnlich schlag ich das eigentlich schon seit langem vor. ;)
Mir persönlich geht es dabei mehr um das Tracking und die zentrale Auffindbarkeit von aktiven Projekten. Im Moment startet jedes mal eine Schnitzeljagd, wenn irgend etwas gesucht wird.
Wo dann das jeweilige Repo selbst jetzt gehostet wird, spielt da eine untergeordnete Rolle. Redmine kann die unterschiedlichsten Versionierungssyste me integrieren.Selbstv erständlich stellen wir auch Repos auf dem eigentlichen WB-SVN zur Verfügung. Die Minute zur Neuanlage überlastet uns sicherlich nicht. ;-)
Auch ein Projekt in Redmine anzulegen und direkt dafür einen Projekt-Admin zuzuteilen ist auch nur minimaler Aufwand.
Nur... man muss dazu einfach mit uns reden. Nicht im Forum in irgendwelche Diskussionen verpackt, sondern einfach mal eine konkrete PN / Mail oder Skype-Nachricht und schon ist das kurzfristig am Laufen.
-
@Blackbird: Nur kurz: Du kannst in Redmine natürlich ein externes Git / SVN / was immer angeben. Es geht hier eher um die zentrale Projekt / Modulverwaltung mit Bugtracker & Co.
-
Nur... man muss dazu einfach mit uns reden. Nicht im Forum in irgendwelche Diskussionen verpackt, sondern einfach mal eine konkrete PN / Mail oder Skype-Nachricht und schon ist das kurzfristig am Laufen.
Wenn es Fragen / Wünsche / Anregungen dazu gibt, kann man sich auch gerne an mich wenden
-
@BlackBird : Sagt doch niemand, dass Du irgendeins deiner Projekte in einem zentralen WB-Projekt unterbringen sollst.
Wer sein eigenes Github oder sonstwas Repo hat, behält das selbstverständlich. Es wird nur ein Projekt mit kurzer Beschreibung in Redmine angelegt und dann das originale Repo in Art eines ReadOnly-Softlinks eingebunden.
Das ist auch für User einfacher, da alles mit der selben Benutzeroberfläche erreichbar ist.
Das Argument, dass niemand in Redmine nach Modulen sucht, mag ja augenblicklich stimmen da bisher dort ja auch noch nie welche zu finden waren. (aber dann dürfte auch nie eine neue Kneipe aufmachen, denn "Da geht niemand hin, weil da ja noch nie jemand ein Bier getrunken hat..")
Ziel der ganzen Aktion ist es, Schritt für Schritt erst fertige Module, möglichst umfassend im Addon-Bereich der WB-HP für die 'normale' Modulsuche, mit Beschreibung und Download bereitzustellen. Gleichzeitig aber aus dem Addon-Bereich heraus mit Link zum jeweiligen Redmineprojekt den Usern einen Einblick in die laufende(oder nicht laufende) Entwicklung zu bieten. Auf Wunsch können dort auch Tickets erstellt werden, die dem Entwickler dann per eMail zugestellt werden und noch einige Möglichkeiten mehr. Was genau der Admin eines solchen Modulprojektes aktiviert und zulässt, bleibt ihr/ihm selbst überlassen.
Nach relativ kurzer Zeit könnte der Addon-DL-Bereich der Wb-HP einen vernünftigen Umfang erhalten und gleichzeitig einen direkten Kontakt zum Entwickler und seiner aktuellen Entwicklung ermöglichen. Dabei müsste kein Entwickler auf seine bisher gewohnte Entwicklungsumgebun g/Repository etc. verzichten und hätte trotzdem alles zentral, öffentlich zugänglich gemacht.
Der augenblickliche, zersplitterte Zustand mit unterschiedlichsten Adresse zu jedem einzelnen Modul, die weisderteufelwo zusammengesucht werden müssen, ist jedenfalls auf Dauer nicht tragbar.
-
Hallo, es ist auch der Spruch gefallen, dass Module mit Abhängigkeiten (module dependency) nicht in die offizielle Repo sollen?
Was ist denn da dran?
Das ist eher etwas kontraproduktiv.
Es gibt doch WB interne funktionen, mit denen sogar diese Sachen ins Modul angegeben werden können.
Gruß,
Stefek
-
Ziel der ganzen Aktion ist es, Schritt für Schritt erst fertige Module, möglichst umfassend im Addon-Bereich der WB-HP für die 'normale' Modulsuche, mit Beschreibung und Download bereitzustellen. Gleichzeitig aber aus dem Addon-Bereich heraus mit Link zum jeweiligen Redmineprojekt den Usern einen Einblick in die laufende(oder nicht laufende) Entwicklung zu bieten. Auf Wunsch können dort auch Tickets erstellt werden, die dem Entwickler dann per eMail zugestellt werden und noch einige Möglichkeiten mehr. Was genau der Admin eines solchen Modulprojektes aktiviert und zulässt, bleibt ihr/ihm selbst überlassen.
Nach relativ kurzer Zeit könnte der Addon-DL-Bereich der Wb-HP einen vernünftigen Umfang erhalten und gleichzeitig einen direkten Kontakt zum Entwickler und seiner aktuellen Entwicklung ermöglichen. Dabei müsste kein Entwickler auf seine bisher gewohnte Entwicklungsumgebun g/Repository etc. verzichten und hätte trotzdem alles zentral, öffentlich zugänglich gemacht.
Das ist eine gute Sache.
-
Hallo, es ist auch der Spruch gefallen, dass Module mit Abhängigkeiten (module dependency) nicht in die offizielle Repo sollen?
Man sollte sich davon lösen, das Ganze als "offiziell" zu betrachten. Github oder Sourceforge oder Google gehört ja auch nicht der Code / die Projekte, die dort gehostet werden.
"Offiziell" sollte in meinen Augen an Redmine unter http://project.websitebaker2.org/ lediglich der "Core" sein.
Alles andere sollte als unabhängige "Dienstleistung" / Unterstützung gesehen werden. Es ist ja gerade der Charme von Redmine, dass man viele Projekte, die in sich abgeschlossen sind, machen kann - und das auch noch so einfach zu bedienen, dass es kaum Schwierigkeiten geben sollte.
Warum ich die Idee gut finde ist einfach die Ordnung. Das Forum hat zwar seine Vorteile, ist aber für Diskussionen gedacht. In Redmine kann der Modulautor wesentlich mehr - wenn er möchte (man muss ja nicht). News erstellen, Co-Moderatoren ernennen, Dateien hochladen, Wiki erstellen... Was man eben so braucht. Sogar Forum ist für jedes Projekt dabei, ebenso Bugtracker.
Ob das jetzt zu viel ist oder nicht weiß ich nicht. Wenn ich manche Module wie Bakery oder die Editoren sehe denke ich das aber schon.
Grundsätzlich finde ich wird Redmine eh viel zu wenig genutzt, im Forum geht viel zu vieles unter, gerade was Bugs betrifft. Aber es wurde irgendwann mal "runtergefahren" und seitdem wird es halt nicht mehr genutzt.
Ja, aber warum sollte ich mein GitHub Repo im zentralen Projekt unterbringen wollen? Das verwirrt doch nur. Zumal jemand, der ein Modul sucht, nicht im Redmine nachguckt.
Es ist eine Frage der Etablierung. Vor 5 Jahren hätte auch keiner auf AMASP nachgeguckt.
Ob es jetzt das beste Tool dazu ist, um Module zu präsentieren - sei dahingestellt. Dafür gibt es ja das Addons Repository http://addons.WebsiteBaker.org/
Mir geht es hier eher darum, dass man Community Module schaffen kann. Sowas wie z.B. drupal https://drupal.org/project/token oder wordpress http://wordpress.org/plugins/all-in-one-seo-pack/ haben. Aber es soll natürlich nicht zum Zwang führen. Meinetwegen geht es auch, einfach nur eine kurze Übersichtsseite für ein Modul zu schreiben und das dann nach Github zu verlinken. Wobei sich hier die Frage natürlich stellt, ob es dann nicht besser gleich im Addons-Repository aufgehoben wäre. Es sollte halt eine engere Verzahnung zwischen dem Anbieten und dem Entwickeln / Bugreporten der Module geben, und das besser organisiert als mit irgendwelchen Forenthreads. Und wenn einer einen besseren Vorschlag dazu hat - ja gerne. Ich war halt damals einer, der eben genau deswegen Redmine mit eingeführt hat, und darauf gedrängt hat das olle trac rauszuwerfen (zum Glück ist's kaputt gegangen).
Das ist halt meine Sicht der Dinge.
Ich sehe es daher nicht als "zentrales" Projekt, sondern eher als ein "Marktplatz" (oder weniger kommerziell: "Sammelsurium") verschiedener Projekte, bzw. Module & anderes.
Das manches nicht mehr den heutigen Standards entspricht oder von verschiedenen Leuten anders umgesetzt würde, ist keine Frage, man muß halt nur dran bleiben.
Und wenn es ein Repository gibt, muss der Entwickler mal von seinen Elfenbeintürmen herunterkommen und sehen, dass es andere anders machen und sie auch lassen. Das was ich die letzten Jahre hier gesehen habe war teilweise furchtbar. Kaum hat einer ein Modul gemacht ist er in die Tonne getreten worden, nur um genau die Fehler die angekreidet wurden zwei Jahre später als offizielle Neuerung zu verkaufen.
Aber nochmal - die Diskussion will ich hier nicht lostreten.
Eine zentrale Stelle kann nur stattfinden, wenn Module auch gewollt sind. Und das waren sie in der Zeit zwischen 2.8.1 und 2.8.4 definitiv nicht, das wissen wir alle. Ich hoffe daher eindringlich, dass mit der 2.8.4 nun wieder Module geschrieben werden können, die Bestand haben - Coding Standards hab ich ja schon auf wb.org (zumindest auf versteckten Seiten) gesehen.
-
Hallo, es ist auch der Spruch gefallen, dass Module mit Abhängigkeiten (module dependency) nicht in die offizielle Repo sollen?
Man sollte sich davon lösen, das Ganze als "offiziell" zu betrachten. Github oder Sourceforge oder Google gehört ja auch nicht der Code / die Projekte, die dort gehostet werden.
Ich sprach vom offizellen Addon Repository.
Was wenn ich ein Modul mache, das ein anderes Benötigt (z.B. eine spezielle Kommentarfunktion, oder einen ImageHandler, der in mehreren Modulen verwendet werden kann)?
Meiner Meinung nach sollte alles rauf dürfen, was nicht schädlich ist und nicht, ob es dem einen oder anderen gefällt.
Letzten Endes entscheidet derjenige, der etwas verwenden will, was er auswählt und die Repo dient ihm nur dazu, zu sehen, was da ist.
-
Hallo, es ist auch der Spruch gefallen, dass Module mit Abhängigkeiten (module dependency) nicht in die offizielle Repo sollen?
Man sollte sich davon lösen, das Ganze als "offiziell" zu betrachten.
ja, und dann kommt noch diese Sache -> wer bezahlt, bestimmt die Musik
Wenn ich auf meinem Server alle Modulautoren einlade, dann ist das meine Sache, hier bin ich aber Gast und wenn der Hausherr NEIN sagt, hat sich das erledigt
Und wenn da nichts dran wäre, hätten wir das Thema ja garnicht :wink:
-
Hausherr? Das hier ist ein Community-Projekt.
-
ja, und dann kommt noch diese Sache -> wer bezahlt, bestimmt die Musik
Wenn ich auf meinem Server alle Modulautoren einlade, dann ist das meine Sache, hier bin ich aber Gast und wenn der Hausherr NEIN sagt, hat sich das erledigt
Und wenn da nichts dran wäre, hätten wir das Thema ja garnicht :wink:
Soweit ich weiß, gibt's nen e.V., der durch Communityspendengel der alles bezahlt, ergo ist der Hausherr der Verein. Oder ist unsere Mitarbeit hier unbezahlte Ausnützung mit kommerziellen Hintergedanken?
Ich bin raus, sonst eskalierts.
-
Oder ist unsere Mitarbeit hier unbezahlte Ausnützung mit kommerziellen Hintergedanken?
Hey, davon war überhaupt nicht die Rede!
Also bitte, ihr beiden, das habe ich weder gesagt, noch gemeint, noch in irgendeiner Weise andeuten wollen - nur um das klar zu stellen!
da kennt wohl wer das Sprichwort nicht? :-o
Irgendwer hat irgendwann aus irgendwelchen Gründen mal festgelegt, das z.b. Module, die Abhängigkeiten zu anderen Modulen haben, hier nicht gelistet werden sollen. Es wäre also zu prüfen, ob diese Festlegung immernoch gültig ist
-
:-) Wundert mich etwas, dass dieser normale Spruch so eine Reaktion auslöst.
Bei Dietmars "Aus, Schluss, basta" hätte ich das eher erwartet.
Für mich stellt sich das so dar, dass die Devs das letzte Wort haben bei allem und somit auch bei dem was ins Repo kommt oder wie die Coding-Standards auszusehen haben bzw. wie weit sich dran gehalten werden muss.
Also muss man so diskutieren bis alle Seiten überzeugt sind und schon geht alles.
-
mmm ... eigentlich ist der Ansatz, den ich aus DokuWiki.org kenne, ganz gut: da werden die Plugins gelistet, kurz beschrieben (auch mit Anhängigkeiten), die meisten sind im (installierbaren) Format auf github abgelegt, und (besonders wichtig!) die Kompatibilität zu den verschiedenen DokuWiki-Versionen angezeigt - wobei nicht immer der Haken sitzt (weil es noch niemand getestet hat), das Plugin aber dennoch läuft. Alllerdings ist die DokuWiki Community anders gelagert (nicht unbedingt kleiner!). Vor allem habe ich dort bislang keine wie auch immer beschaffenen Animösitäten, Ausschlüsse, Disziplinierungen verschiedenster Art, ... feststellen können.
AMASP hat ja einen vergleichbaren Ansatz: eine Auflistung der Module, Templates, ... und die Links zu den Developern und Supportforum (meist hier) werden aufgeführt. Das Design und die Aktualität sind (vorsichtig ausgedrückt) nicht aktuell. Die gelisteten Module direkt unter WebsiteBaker.org sind handverlesen und haben meist das wb approved logo.
Was (außer der dazu benötigten Zeit und Energie!) spricht eigentlich dagegen, AMASP in WebsiteBaker.org zu übernehmen?
Das Einstellen der (neuen und alten) Module könnte ja in vorgegebenem Format mit entsprechenden Mindestanforderunge n (Beschreibung, Autor, Website, Download, Latest Update, Forum, Kompatibilität, Voraussetzungen (!) ...) von den Developern selbst eingetragen werden (Member Logins ... Zugriff nur auf diesen Teil), in einen Bereich "ungeprüfte Module", und die Zertifizierung dann je nach Zeit vom Kernteam gemacht werden, bzw. angesteuert von der Community, worauf solche Module dann in einen anderen nicht öffentlich zugänglichen Bereich "geprüfte Module" verschoben werden? Viel Arbeit, zugegeben, vor allem dann in der Pflege der Infos ... aber dann gäbe es EINE Anlaufstelle für die meisten Module auf der offiziellen Projektseite, wo (Neu-)Nutzer sie ja auch suchen.
Ich gebe zu: VIEL Arbeit ... aber möglich wäre das schon, oder?
-
Edit: Die Info ist vom Mai 2013. Auf der "offiziellen Seite" des Addons-Projekts steht darüber nichts.
Stimmt - da steht dazu nichts.
Diese Info wurde auch nur als "Memo" an die Leute verteilt, die das Addon-Repo befüllt haben.
Und nur am Rande: Die DEVS haben damit nichts zu tun.
-
Ist das denn nach wie vor gültig? Im Formular kann man ja keine Abhängigkeiten angeben...
Ich frag dir gerne nach.
Meine Meinung dazu wäre:
- Einfach das Addon - Repo so umbauen, dass man ggf. die Module angeben kann welche benötigt werden und fertig.
Aber ich hab da nichts zu sagen :P
-
Ok, hab nun mal nachgefragt:
Egtl. sollte die Vorgabe lauten:
Keine Module die in "fremde" Module eingreifen (Code verändern, etc.)
--
Abhängigkeiten sind kein Problem - nur müssen dies entsprechend gekennzeichnet werden.
-
Nur um das nochmal klar zu stellen (obwohl ich das Gefühl habe, die meisten haben mich schon richtig verstanden): Ich bin für ein externes, vom Verein und den DEVs unabhängiges Addons Repo.
.......
Zur Erinnerung: AMASP steht für "ALL Modules and Snippets project".
AMASP hat durchaus Vorteile, es ist bekannt, es hat schon die benötigte Struktur - es sollte halt nur nicht eine Person allein damit belastet werden. Wie gesagt, ich kenne die Abläufe dort nicht, weiß nicht, wer dort was macht
Und was den Bereich hier an geht, ich meine, er sollte für alle offen sein und gehört eben auch KIT dazu, wenn es denn vom Autor gewünscht ist
-
Ok, hab nun mal nachgefragt:
Egtl. sollte die Vorgabe lauten:
Keine Module die in "fremde" Module eingreifen (Code verändern, etc.)
--
Abhängigkeiten sind kein Problem - nur müssen dies entsprechend gekennzeichnet werden.
Danke für die Klarstellung, Daniel.
Das macht viel mehr Sinn.
Gruß,
Stefek
-
Ok, hab nun mal nachgefragt:
Egtl. sollte die Vorgabe lauten:
Keine Module die in "fremde" Module eingreifen (Code verändern, etc.)
--
Abhängigkeiten sind kein Problem - nur müssen dies entsprechend gekennzeichnet werden.
Danke für die Klarstellung, Daniel.
Das macht viel mehr Sinn.
Ich versuchs mal etwas klarer zu stellen. ;)
In andere Module 'eingreifen' bedeutet im schlimmsten Fall, irgendetwas in das Verzeichnis eines anderen Moduls zu schreiben oder schreibend auf dessen Datenbanktabellen oder INI-dateien etc. zuzugreifen. (z.B. das wysiwyg-history Modul, das das originale wysiwyg-Modul verändert, dessen Tabellen schreibend benutzt und daher ohne erweitertes Wissen von normalen Usern nicht mehr deinstalliert werden kann).
Etwas einfacher aber oft nicht unkritisch ist eine einseitige Verbindung bei der ein Modul direkt Daten eines anderen Modules ausliest(nur lesen, nicht schreiben). Selbstverständlich funktioniert das zu dem Zeitpunkt, zu dem das gecoded wird einwandfrei. Was aber, wenn das abgefragte Modul im Zuge eines Upgrades verändert oder eventuell gar gelöscht wird? Meist hängen die Abfragen dann 'in der Luft' und das Script stürzt ab.
Wesentlich sinnvoller ist es da, mit dem anderen Autor/en Kontakt aufzunehmen und möglichst eine neutrale Schnittstelle zwischen den Modulen aufzubauen. Dann kann später jeder sein Modul nach Herzenslust ändern(solange die Schnittstelle unangetastet bleibt) ohne dass das jeweils andere Modul überhaupt was davon bemerkt und einfach weiterhin wie gewohnt funktioniert.
Schnittstellenlose Verbindungen: Sind absolut nicht gewünscht. Wer sie trotzdem aufbaut, ok. Aber er trägt auch das Risiko, dass sein Modul nach Updates etc. einfach nicht mehr funktioniert. Nennt man dann 'persönliches Pech'. ;-)
Generell: Auf Verbindungen/Abhängigkeiten zwischen Modulen muss unbedingt schon vor der Installation deutlich hingewiesen werden. Am Besten auch schon auf der jeweiligen Downloadseite. So kann jeder User selbst entscheiden, ob er evt. einen abhängigen Rattenschwanz von anderen Modulen auch noch installiert oder gleich verzichtet.
-
Generell: Auf Verbindungen/Abhängigkeiten zwischen Modulen muss unbedingt schon vor der Installation deutlich hingewiesen werden. Am Besten auch schon auf der jeweiligen Downloadseite. So kann jeder User selbst entscheiden, ob er evt. einen abhängigen Rattenschwanz von anderen Modulen auch noch installiert oder gleich verzichtet.
Ja, das muss sein. Die Repo sollte das aber hergeben. Z.B. ein Feld "Module Dependency" und wenn ja, dann mit der Möglichkeit, das Modul zu benennen, oder besser: zum Modul zu verlinken.
In andere Module 'eingreifen' bedeutet im schlimmsten Fall, irgendetwas in das Verzeichnis eines anderen Moduls zu schreiben oder schreibend auf dessen Datenbanktabellen oder INI-dateien etc. zuzugreifen.
Was aber, wenn eines der Module Tabellen zur Verfügung stellt, speziell für den Zweck, dass andere Module auf diese zugreifen?
Praktisches Beispiel: ein Kommentarmodul (nur als Beispiel) auf dessen Methoden mehrere, spätere Module, zugreifen können (eine bereitgestellte Klasse über den Autoloader), sowie in gemeinsame DB Tabellen schreiben (in diesem Falle {TABLE_PREFIX}mod_globalcomments_comments).
Ist es nicht so, dass eine uninstall.php ein phpScript ausführen kann, der dann, bevor ein Modul deinstalliert wird, auch eine Nachricht ausgiebt?
(Das sind theoretische Fragen mit einem praktischen Hintergrund, da ich nämlich im Moment an etwas arbeite, das in diese Richtung geht.)
Gruß,
Stefek
-
Was aber, wenn eines der Module Tabellen zur Verfügung stellt, speziell für den Zweck, dass andere Module auf diese zugreifen?
Praktisches Beispiel: ein Kommentarmodul (nur als Beispiel) auf dessen Methoden mehrere, spätere Module, zugreifen können (eine bereitgestellte Klasse über den Autoloader), sowie in gemeinsame DB Tabellen schreiben (in diesem Falle {TABLE_PREFIX}mod_globalcomments_comments).
Das ist der absolut klassische Fall für eine Schnittstelle in GlobalComments(auch mal API genannt) ;)
Dann genügt im abfragenden Modul beispielsweise die Simple Frage: (noch mit den Pseudo-Namespaces)
<?php
if (class_exists('m_globalcomments_Api')) {
// ist die Klasse noch nicht geladen, lädt sie der Autoloader
$oGlobalCommentsApi = new m_globalcomments_Api();
} else {
// sorry, da gibts kein API
}
Der Vorteil: Irgendwann passt GlobalComments evt. mal nicht mehr und wird umgebaut. Auch die Tabellenstruktur kann sich ändern.
Wird jetzt eine Schnittstelle benutzt, ändert sich für alle Module die darauf zugreifen praktisch nichts. Nur die 'innere' Seite der Schnittstelle muss auf die Änderungen angepasst werden.
Wenn ein Modul der Schnittstelle sagt: 'gib mir das und das... oder schreibe das..' dann spricht es nur die konstante Schnittstelle an. Wie die Daten innerhalb von GlobalComments verarbeitet, geschrieben oder gesucht werden, interessiert ein anderes Modul dann nicht im Geringsten.
Ist wie mit PHP-Befehlen.. Du schreibst deinen Funktionsaufruf und erwartest ein bestimmtes Ergebnis. Wie die Funktion das macht, ist Dir wurst. Ändert PHP in seinem Code mal was... interessiert es Dich nicht, solange der Funktionsaufruf weiterhin das selbe Ergebnis bringt.
Ist es nicht so, dass eine uninstall.php ein phpScript ausführen kann, der dann, bevor ein Modul deinstalliert wird, auch eine Nachricht ausgiebt?
Das kann in der uninstall.php des jeweiligen Modules passieren.
-
Arbeitskreis ist immer super!
Ich denke: zuerst sollte man versuchen, das AMASP wiederzubeleben. Das AMASP ist bekannt und im Grunde ja auch richtig.
Erst wenn das nicht geht - warum auch immer - sollte man eine alternative Lösung andenken.
-
@DarkViper
ja, genau so ist das gedacht und geplant.
Bezüglich "offizielle Repo", wer ist denn da Ansprechspartner? Ich weiß nur, dass Ruud es programmiert hatte.
Ich denke, sowas sollte im getrennten Thread besprochen werden.
Wir brauchen auf jeden Fall einige feste Spielregeln (Richtlinien, wenn man so will).
@Private Repos a lá AMASP und Co
generell ist nichts dagegen einzuwenden ALLE WB Bezogenen Module irgendwo abzulegen.
Wer da Lust hat, sollte sich nicht abhalten lassen.
Im Grunde denke ich, alles was die Nutzung und Verbreitung von WebsiteBaker vermehrt, sollte nicht gestoppt werden.
Ob AMASP es ist, oder jemand anderes es besser kann steht sicher nicht in den Sternen geschrieben und wird nur dadurch bestimmt, ob sich jemand dessen annimmt.
Ein "offizielles Repo" sollte dennoch so gemanaged sein, dass Autoren leichter mitmachen können ohne zu viele wenig Sinn ergebende Spielregeln beachten zu müßen. Die logischen Spielregeln ergeben sich quasi von selbst und wenn sie festgeschrieben sind, um so besser.
Gruß,
Stefek
-
Hi,
Ich denke: zuerst sollte man versuchen, das AMASP wiederzubeleben. Das AMASP ist bekannt und im Grunde ja auch richtig.
Erst wenn das nicht geht - warum auch immer - sollte man eine alternative Lösung andenken.
Was mich an AMASP damals störte, war der "Zwang", seine Module dort hochzuladen, was einen "erhöhten Pflegeaufwand" mit sich bringt, wenn man das ganze auch im offiziellen WB-Repo und auf nem öffentlichen Code-Repo (z.B. GitHub) haben wollte.
Eine damals nachgefragt Verlinkung (z.B. zum WB-Repo, GitHub etc.) wurde damals einfach abgelehnt. Ergo habe ich meinen AMASP-Account damals dann deaktiviert. Als ich dann im Februar 2012 drei meiner alten Module auf GitHub gehostet habe, wollte ich auch einen neuen AMASP-Account beantragen um die veralteten Module auszutauschen. Der Account-Antrag wurde übrigens abgelehnt. Da es seit ein paar Monaten ja wieder soetwas wie ein Lebenszeichen auf AMASP gibt, bleibt ein kleines Fünkchen Hoffnung für ein mögliches "Community-Projekt" bestehen :wink:
Gruss
-
Die Frage ist dann nur, wer ein AMASP2 hostet bzw. koordiniert.
Wenn es darum geht, Webspace / Domain zu hosten bzw. anzubieten sollte das kleinere Problem sein (kann wenn es sein muss und sich kein anderer findet ich auch machen, hab genügend freien Webspace), nur sollte das ja eben Bestand haben und nicht in einer Hand liegen.
Vor allem sollte es aber nicht wieder ein bürokratisches Ding werden.
-
Ich hab da kein Problem mit, nur möchte ich mich, wie gesagt, nicht dem Verdacht aussetzen, eigene Ziele zu verfolgen. Wegen Fork und so.
Zumindest ich bin in dieser Beziehung schmerzfrei.
Und weil ich natürlich bevorzugt mit wbProfiles arbeiten würde, das läuft ja in meinem Addons Repo auch. Wobei mir das eingesetzte Modul am Ende wurscht ist, so lange es funktioniert.
Das Tool sollte nicht das Problem sein. Wäre natürlich sinnvoll, ein "Standard-Tool" zu nehmen und nicht etwas, was nur rein für die Seite entwickelt wurde - einfach, weil wenn doch der Häuptling der das Tool geschaffen hat weg ist man nicht ganz alleine ist. Ob das nun Members, wbProfiles, Redmine oder Kit ist sollen andere entscheiden. :-)
-
Na - warum sollte ein Standard-Tool verwendet werden?
OK, wenns eins gibt, das exakt alle Eventualitäten abdeckt, aber sonst muss man schon reinfrickeln. Und das kann man dann ohnehin nicht mehr updaten. Is ja schließlich Open Source und wenns was hat, gibt es genug Leute, die so ein Problem lösen können.
-
Hi,
In Redmine kann der Modulautor wesentlich mehr - wenn er möchte (man muss ja nicht). News erstellen, Co-Moderatoren ernennen, Dateien hochladen, Wiki erstellen... Was man eben so braucht. Sogar Forum ist für jedes Projekt dabei, ebenso Bugtracker. Grundsätzlich finde ich wird Redmine eh viel zu wenig genutzt, im Forum geht viel zu vieles unter, gerade was Bugs betrifft. Aber es wurde irgendwann mal "runtergefahren" und seitdem wird es halt nicht mehr genutzt.
Habe gestern einen Redmine Account beantragt um das ganze mal unter "Praxisbedingungen" zu testen. Aktuell sind nur die Minimum-Features (http://project.websitebaker2.org/projects/cwsoft28x) aktiviert, das meiste wird einfach auf meine GitHub Repos verlinkt.
Sowas in die Richtung habe ich mir damals bei AMASP gewünscht. Kein Du musst hier hosten, sondern ein Du kannst wenn Du willst, musst aber nicht. Soll ja schliesslich eine WB-MODUL-LISTE sein :wink:
Gruss
-
Cool!
-
Cool!
Naja, so begeistert bin ich aktuell noch nicht. Bei 3 Modulen ist das ganze ja übersichtlich, wie sieht das ganze aber bei 100 Modulen aus, wie findet man da CodeSnippets, PageModule, AdminModule, Autoren, Funktionen...
Auch die viel "gepriesene Einbindung" fremder Repositories (wie z.B. Git) gestaltet sich bei näherem Blick nicht ganz so trivial wie Anfangs gedacht. Redmine bindet per Default (http://simonecarletti.com/blog/2009/07/configuring-git-repository-with-redmine/) nur lokale "Fremdrepos" die auf dem Redmine Server liegen ein. Etwas mehr Komfort bieten Redmine Plugins (http://mentalized.net/journal/2009/08/03/redmine_plugin_github_hook/), welche wiederum einen Rattenschwanz an Abhängigkeiten mitbringen.
DarkViper schaut, was man wie machen kann. Wird allerdings bis nach dem Release von WB 2.8.4 dauern.
Denke an einer "externen" vernünftigen Modul-Auflistung mit flexibler Suche, Möglichkeit der Kurzpräsentation (wie bei Redmine), Links zu externen Repositories, Webseiten bzw. Downloadquellen führt wohl kein Weg vorbei.
Warten wir mal ab.
Gruss
-
Ich mach mal einen praktischen Vorschlag: Wer Interesse hat, ein "AMASP2" aufzubauen, meldet sich. *handheb*
*handheb*
Kurz meine Gedanken (die natürlich überstimmt werden dürfen):
- Wenn WB sollte es schon 2.8.4 sein.
- Der erste Schritt sollte sein, die meisten Module zumindest zu listen.
- Notwendig wäre es auch, dass Autoren (wie in AMASP) ihre Module selber pflegen können.
- Ob die WB-Benutzerverwaltung dazu sinnvoll ist, sei mal dahingestellt.
- Grundsätzlich sollte die Kategorisierung der Module gegenüber AMASP vereinfacht / verändert werden.
- Die Einbindung eines Repositories ist ganz nett (war mit der Nutzung von Redmine ja auch mit mein Vorschlag), sollte aber nicht im Vordergrund stehen.
- Es sollte eine Möglichkeit geben, sich auszutauschen (Forum / Blog). Evtl. pro Modul.
- Es sollte die Möglichkeit geben, zu jedem Modul eine Wikiseite / "Infoseite" zu erstellen.
- Die Changelog, evtl. mit Download älterer Versionen (gerade wegen Abhängigkeiten 2.8.3 / 2.8.4 / 2.9) sollte möglich sein.
- Es sollte möglich sein, vom Team Module in Status "ungetestet", "stabil", "läuft nicht", "läuft mit Einschränkung XY" zu setzen.
- Evtl. wäre (längerfristig, nicht beim Start) sinnvoll, eine API zu schaffen, um mit einem AMASP2-Modul (oder wie die neue Seiten heißen soll, ich hätte z.B. www.easemod.com kurz für "Einfachheit von Modulen" frei) z.B. Module auf Aktualität zu checken oder sogar runterzuladen.
- Die Seite sollte primär Englisch sein, mir gefällt die Fokussierung von WB auf den deutschsprachigen Raum seit langem nicht.
- Übliche Links zu Autor, Forum, Webseite, Download
- Downloads sollten auf AMASP2 gehostet werden - wenn der Autor seine Seite löscht, kann weitergearbeitet werden
- Kommerzielle Module sollten angeboten werden, im Gegenzug evtl. einen gewissen Prozentsatz (z.B. 10% vom Verkaufspreis, siehe Google Play Store / Apple Appstore / Microsoft Appstore) an etwas gemeinnütziges - oder um die Webspace / Domainkosten zu decken.
- Ich habe vor einigen Jahren mal erste Gedanken hierzu gehabt - siehe Anlage. Die "wb-addon-automatism" ist eher dafür gedacht, wie offizielle Addons gecheckt werden - der Vollständigkeit halber aber mal aufgelistet.
Ist eher zum Festhalten, weniger zu drüber diskutieren - das dann lieber extern.
-
Hey, da bewegt sich was. Klaaaasssssssssse :-) :-) :-)
@BlackBird: Danke!
Jaaaaaaa ... EINE "offizielle" Informationsstelle für "ALLE" Module ... würde das Projekt endlich mal wieder ein grooooooßes Stück voran bringen. Aktuell fühlt(!) es sich einfach so an, als ob sich die Vielfalt der Module in den letzten Jahren in Luft aufgelöst haben (übrigens damit auch das Gesamtprojekt WebsiteBaker um es einfach mal klar zu sagen) ... sie sind einfach nicht präsent, vor allem weil man sich nicht darauf verlassen kann, was vorhanden ist und was aktuell ist.
Als nicht Profi-Entwickler würde ich gerne mal ein Sichtweise eines Einfach-WSB-Anwenders einbringen wollen, die ja immer eine andere ist ... aber eine Außenansicht und vielleicht auch etwas andere Gedankengänge schaden ja nicht!
Unabhängig oder offiziell?
Als einfacher User hielte ich es für WICHTIG(!!!!!), dass ein neues AMASP2 (oder wie auch immer) "offiziellen" Charakter trägt. Also: Hier kommen ALLLE(!) Module rein, die von ihren Authoren(!) offiziell als WSB-Modul oder WSB-Möglichkeit präsentiert werden sollen, - egal, wie schlecht oder unsinnvoll das Modul ist.
Die Plattform kann auch (bzw. SOLLTE!!!) als unabhängiges Comunity-Projekt geführt werden. Schon alleine deshalb, weil das Engagement anders nicht zusammen kommt. Allerdings sollten Domain und Server doch unter einer Zugriffs-Kontrolle des Vereins liegen.
Zum einen kann so der aus meiner Sicht sehr wichtige "offizielle" Exklusiv-WSB-Charakter dauerhaft gewährleistet werden ... was sicher wichtig ist für die Akzeptanz einer solchen Seite. Zum anderen kann so vermieden werden, dass das gleiche noch mal passiert wie bei der damaligen Gabelschlacht ... (Lepton-Werbung oder andere CMS-Systeme haben auf einer solchen Seite nichts verloren und schaden dem Gesamtauftritt von WebsiteBaker erheblich, was damals ja auch beabsichtigt war und wohl mit der nach wie vor bestehenden Werbung auch noch ist.)
@WebBird: Aus diesen Gründen denke ich, dass ein solches Projekt nicht ohne eine akzeptierende Zustimmung der Gesamtorganisatoren funktionieren. Zumal ein solches Verzeichnis auch nicht ohne die offiziell vom Entwickler-Team gepflegten Module auskommen würde und aus meiner Sicht auch das Add-Ons-Projekt dort integriert werden sollte. (Wir hätten sonst wieder unterschiedliche Anlaufstellen ...)
ABER, @Liebes Entwickler-Team: Als Comunity-Projekt sollte die neue Seite aber unabhängig sein. Das heißt, alle Module inklusive solcher von Amateur-Entwicklern, die Eurem hohen Programmierstandard oder einer vorgedachten WSB-Philosophie nicht entsprechen, sollten aufgenommen werden. Hier wäre das Signal von Euch wichtig, dass Ihr eine solche Freiheit der "Andersdenkenden" (sowohl bei den Machern der neuen Seite wie auch bei den Modul-Authoren) unterstützen würdet und die Unabhängigkeit auch gewährleisten(!!!!) würdet. Übrigens ist die Sicherstellung einer solchen Comunitiy-Neutralität durch die Organisatoren ein Erfolgsgarant für andere große CMS-Systeme.
Organisation und Respority
Ich bin zwar kein Profi-Entwickler, aber denke, dass auch hier Einfachheit für die Entwickler ein entscheidender Erfolgsfaktor ist. Wo jeder Entwickler seine Dateien pflegt und in welcher Form er sie präsentiert ist ja jedem sein eigen Ding. Ob bei Github oder einer Alternative und ob er das Modul im Forum beschreibt oder eine eigene Webseite baut ... ich vermute, keiner mag sich das vorschreiben lassen.
Andererseits ist das größte Erfolgs-Hindernis möglich Doppelarbeit.
Das bedeutet, das Einstellen von Modulen sollte so wenig Aufwand wie möglich machen. Ich vermute, dass ein Zwang, Dateien hoch zu laden schon eine Hürde sein kann, auch wenn es schön wäre, die Entwickler dazu zu animieren.
Aber eigentlich ...
und warum kompliziert wenn ...
... im Zweifel reicht für einen ModulEintrag auch der Link auf die Download-Möglichkeit aus, genauso wie Links zur offiziellen Infoseite (ggf. Webpage, Foraum, o.a.)
Eine einelne externe gepflegte Downloadmöglichkeit, auf die hingewiesen wird, ist mir lieber, als ein veraltetes Modul, das aus Bequemlichkeit nicht hochgeladen wurde, aber auch einer anderen offiziellen Seite aktualisiert vorgehalten wurde. Ein solche Verlinkungsmöglichk eit hielte ich damit für wahrscheinlich wichtig ... und gab es soweit ich mich erinner beim alten AMASP ja auch.
Es geht ja nicht darum, ein Resportory zu entwickeln um Dateien zu pflegen sondern um eine Seite zur Sammmlung, Bündelung und Bereitstellung von Informationen.
Im Zweifel reichen (vor allem am Anfang) die Information:
was, wie aktuell, wo
Kennzeichnung und Aktualität
Bei einer solchen Freiheit und Vielfalt von Modulen halte ich ein einfaches(!) und schnell(!) erschließbares Informationssysten für die Module für wichtig. Dabei meine ich nicht nur die Kategorisierung, Verschlagwortung, etc.
Wünschen würde ich mir ein auffällige Kennzeichnung (z.B. durch auffälliges "Siegel" oder "Icon/Symbol") der folgenden Art:
>>A>> Offizielles Modul,- von den WSB-Entwicklern gepflegt/supportet
Also die offiziellen Module aus dem Adons-Projekt
>>B>> Offiziell von Comunity-Vertretern (nicht dem DEV-Team!!!) geprüftes Modul:
Tested-Modul, - Funktioniert in der Modul-Version für die WSB-Version
>>C>> Vom DEV- und/oder Comunity-Team empfohlenes Modul:
z.B. weil es eine zentrale ergänzende Aufgabe erfüllt, der Modulauthor bekannt ist und das Modul regelmäßig supportet, das Modul besonders beliebt ist, ...
>>D>> Aktuelles Modul
Modul wurde vom Author für die letzte aktuellste WSB-Version aktiv frei gegeben.
>>E>>Optional: Modul entspricht vorgegebenem WSB-Programmierstandard
Ich glaube, das ist für einige Entwickler hier wichtig
Natürlich sollte nach all den Kriterien auch gefiltert werden können.
Modul-Abhängigkeiten und andere Spielereien
Solche Punkte scheinen für Programmierer ein wichtiger Punkt zu sein. Aber als einfacher Anwender kann ich dazu nur sagen: da verstehe ich die Diskussion über eine Nicht-Aufnahme solcher Module nicht? ALLE Module heißt natürlich ALLE Module. Und natürlich solche, die mit anderen Modulen interagieren oder dort den Code verändern.
Natürlich gehören die in eine solche Übersicht. ABER NATÜRLICH muss leicht erkenntlich transparent gemacht werden, dass diese Module von anderen abhängen oder andere Module ändern.
Auch hier könnten Info-Buttons helfen: Untermodul oder Verändert den Code von ...
Regeln
Ja, ohne Regeln funktioniert ein Comunity-Projekt nicht. Sie muss es geben, sie müssen transparent gemacht und vor allem auch durchgesetzt werden. Nicht gemäß persönlichem Gutdünken sondern eben nach den vorher definierten Vorgaben.
Aber die wichtigste Regel sollte sein: Offenheit.
Wer etwas reinstellen möchte, darf das auch. Selbst wenn es grottig Programmiert ist, unsinnig ist oder riesige Sicherheitslöcher in das WSB-System reißt, oder nicht funktioniert. In letzterem Punkt kann ja bei bekannt werden durch die Comunity beim Modul darauf hingewiesen werden. Aber die Ansichten über das, wa sicher, qualitativ ausreichend oder gar sinnvoll ist gehen ja (nicht nur hier) extrem weit auseinander ... und definiert auch hier noch immer jeder für sich selbst. Und wenn ich ein unsicheres System betreiben möchte, dann ist das meine Sache ... die Information ist wichtig, nicht das Bannen solcher Module.
Orientierung, ob etwas gut ist oder nicht, geben zunächst die oben beschriebenen Quality-Symbols/Merkmale und natürlich auch Rückmeldung in den Foren hier. Alles andere regelt sich automatisch von allein. Alte ungepflegte Module fallen durch die Filtermöglichkeiten ebenfalls automatisch raus.
Gabelhappen
Mit Gabeln Essen ist gut und jeder sollte die Gabel nutzen, die er mag. Aber für mich(!) wäre bei einer solchen Plattform tatsächlich ein WSB-Exklusives(!!!!!!!!!) Verzeichnis EXTREM wichtig. Infos zu: funktioniert auch in Lepton schrecken MICH(!) ab und gehören auch meiner(!) persönlichen(!) Sicht nicht auf eine WSB-Informationsseite.
Selbstverständlich kann auf der Informationsseite auf die Seite des Modulentwicklers verlinkt werden. Dort kann natürlich auch über Gabelfunktionalität en informiert werden, wer will das verbieten ... aber auf der geplanten Seite sollte es NUR um WSB gehen!
Dies ist ein persönlicher Wunsch und ein persönliches Empfinden, das für mich als Anwender sehr wichtig wäre.
Kostenpflichtiges
Da gehen die Meinungen ja weit auseinander. Ja, ich bin für Geldverdienen mit Webdesign und WSB. ABER: auch ich halte die Bewerbung kostenpflichtige Angebote auf Open-Source-CMS-Comunity-Seiten für problematisch. Zu leicht werden Foren oder solche Index-seiten zu Werbeplattformen missbraucht. Und das emfpinde nicht nur ich als unangnehm und stößt mich bei einem CMS-System auch ab ... da schätze ich die klare Regeln hier in den Foren keinen Bezug darauf zu nehmen SEHR!!!
Dem Gedanken der Offenheit würde es aber entsprechen, auf einer AMASP2-Seite in einem gesonderten Bereich und in einer gesonderten Suche (auch nach kostenpflichtigen Add-Ons suchen?) präsentieren zu dürfen. Der Support für diese Module sollte aber komplett auf eigene Seiten verweisen und nicht hier im Forum oder anderen offiziellen WSB-Seiten stattfinden. Vielleicht wäre das ein möglicher Kompromiss. Die auffällige Kennzeichnung solcher Module als kostenpflichtig hielte ich ebenfalls für wichtig.
Sprechen mit AMASP1
Leider lässt sich nicht verleugnen, dass das bestehende AMASP in der vorliegenden Form dem Gesamtprojekt WSB erheblich mehr schadet (meine persönliche Meinung und Empfindung!) als es nützt. Aber persönliche Emfpindungen und Erlebnisse führen manchmal auch zu solchen Reaktionen. Trotzdem: die Überführung des bestehenden privaten Projektes in den offiziellen WSB-Einflussbereich ... naja, sprechen kann man ja darüber ...
Aber um WSB auszubauen bzw. abzusichern denke ich sollte man an anderer Stelle sprechen:
Thema: Der hier angesprochene Aufbau einer neuen Seite AMASP2, die "offiziellen" Charakter hat, - deren Domain und ggf. Server jedoch im Einflusbereich des Gesamtprojektes liegen.
Gesprächsbedarf gibt es dann über:
Ein klares Votum, dass die WSB-Projektleitung das Projekt unterstützt
Abstimmung der Regeln für die neue Seite.
Verbindliche Gewährleistung der Unabhängigkeit eines solchen Comunity-Projektes.
Vertrauen aufbauen, dass das Tehma Unabhängigkeit und Nicht-Einmischung auch so gemeint ist.
Akzeptieren, dass die, die sich engagieren eigene Vorstellungen haben (dazu werden ja die Regularien im Vorfeld abgestimmt) und sich eben nur dann engagieren, wenn sie ihre eigenen Vorstellungen einbringen können.
... und natürlich das angebotene Engagement willkommen heißen.
Und so könnte eine WSB-Zukunftssichere Seite entstehen ...
LIEBES ENTWICKLER-TEAM:
Gerade hinsichtlich AMASP hättet ihr das vorgeschlagene Projekt schon längst angehen sollen. Ich fände es daher toll, wenn Ihr das Vorgeschlagene und auch das angebotene Engagement mit einem klaren offiziellen Votum unterstützen würdet. Denn ich mag WSB. Und denke, wenn eine solche "offizielle" Seite endlich wieder im offiziellen Rahmen aufgebaut würde, würde es dem Gesamprojekt einen großen Schub nach vorne verleihen.
-
(http://www.meerwinck.com/wsbwb.png)
-
LIEBES ENTWICKLER-TEAM:
Gerade hinsichtlich AMASP hättet ihr das vorgeschlagene Projekt schon längst angehen sollen. Ich fände es daher toll, wenn Ihr das Vorgeschlagene und auch das angebotene Engagement mit einem klaren offiziellen Votum unterstützen würdet. Denn ich mag WSB. Und denke, wenn eine solche "offizielle" Seite endlich wieder im offiziellen Rahmen aufgebaut würde, würde es dem Gesamprojekt einen großen Schub nach vorne verleihen.
Hier mal meine Meinung:
Dir ist aber schon bewusst, dass das aktive Entwickler-Team aus 2 Leuten besteht. Einer Davon muss sich gesundheitlich immer sehr zurückhalten.
Und eine Person allein kann nicht alles machen.
WB hat einfach das Problem: Zu viel zu tun, zu wenig Leute. Aktive User, die WB helfen kannst an 2-3 Händen abzählen (Inkl. WB-Team). Viele Team-Member (laut Webseite) haben einfach keine lust / Zeit mehr sich um WB zu kümmern.
Ich verstehe euer Anliegen - aber ich wollte nur mal klarstellen, warum hier sowenig weiter geht.
-
Hallo,
ich könnte mir vorstellen, auch an AMASP2 (Name tbd) mitzuwirken.
Vorab etwas Senf von mir:
1) würde für den Anfang nicht genügen, eine Linkliste zu bekannten und vertrauenswürdigen Quellen für Module anzulegen - Hier im Forum als Sticky Post und darauf dann dezent auf der WB-Website zu verweisen?
2) Diese absurde Feindschaft zwischen WB und Forks ist einfach grotesk und letzten Endes ein Knieschuss. Es soll doch bitte schön jede_r so machen können, wie er_sie will. Es wäre zum Beispiel ein extrem herber Verlust, Module von bestimmten Entwickler_innen von vornherein auszuschließen, nur, weil diese sich auf andere Forks spezialisiert haben.
3) Das Modulverzeichnis sollte ohne Entwicklerkenntniss e, ohne Login und ohne Spezialsoftware nutzbar sein. Irgend etwas, wofür erst ein Git-oder-was-auch-immer-Client (Redmine), eine Anmeldung (Github) oder was auch immer vonnöten ist, bringt genau gar nichts.
4) Nicht das Rad neu erfinden. Wie machen es die anderen (Wordpress, Joomla, oder auch Modified-Shop)? Warum funktioniert das da und hier nicht? Was könnte beim zu entwickelnden $WB-Modulverzeichnis besser/anders gemacht werden?
VG
-Florian.
-
2) Diese absurde Feindschaft zwischen WB und Forks ist einfach grotesk und letzten Endes ein Knieschuss. Es soll doch bitte schön jede_r so machen können, wie er_sie will. Es wäre zum Beispiel ein extrem herber Verlust, Module von bestimmten Entwickler_innen von vornherein auszuschließen, nur, weil diese sich auf andere Forks spezialisiert haben.
Ich glaub du lässt hier deiner Fantasie freien lauf...
Es wurde noch kein Modul ausgeschlossen nur weil der / die Entwickler_in für einen Fork entwickelt...
3) Das Modulverzeichnis sollte ohne Entwicklerkenntniss e, ohne Login und ohne Spezialsoftware nutzbar sein. Irgend etwas, wofür erst ein Git-oder-was-auch-immer-Client (Redmine), eine Anmeldung (Github) oder was auch immer vonnöten ist, bringt genau gar nichts.
Ich versteh dich absolut nicht - was hat bitte Redmine mit GIT zu tun?
Wenn man sein eigenes Modul veröffentlichen will, muss man sich an bestimmte Regeln halten....
4) Nicht das Rad neu erfinden. Wie machen es die anderen (Wordpress, Joomla, oder auch Modified-Shop)? Warum funktioniert das da und hier nicht? Was könnte beim zu entwickelnden $WB-Modulverzeichnis besser/anders gemacht werden?
nur meine Meinung:
Ganz einfach - weil man bei WB schon immer die Philosophie verfolgt hat: Erst alles schlecht machen, was neue ist - dann meckern ;)
-
Hallo,
Ich versteh dich absolut nicht - was hat bitte Redmine mit GIT zu tun?
Nichts, außer dass ich beides aus Endbenutzer (Anwender-, nicht Modulentwicklersich t) kompliziert finde und ich mich z.B. nicht an noch einer Plattform anmelden möchte, um Bugs zu posten oder etwas herunterladen zu können.
Erst alles schlecht machen, was neue ist - dann meckern
Das beziehst Du jetzt aber nicht auf mich, oder?
-
Nichts, außer dass ich beides aus Endbenutzer (Anwender-, nicht Modulentwicklersich t) kompliziert finde und ich mich z.B. nicht an noch einer Plattform anmelden möchte, um Bugs zu posten oder etwas herunterladen zu können.
Du musst ja da keine Bugs posten - diese Idee von DarkViper war eine Unterstützung für alle gedacht:
Im Redmine werden alle Module gelistet, die sich in Entwicklung befinden.
- OPTIONAL kann der Entwickler hier auch den Bugtracker etc. verwenden - will er das nicht ist es auch gut.
Hier wird keiner gezwungen.
Du musst bitte auch die Entwickler verstehen - die haben auch keine Lust, noch einen Ort zu haben an dem Sie Module pflegen müssen.
in der addon-Seite können dann alle Module rein, die von den Entwicklern freigegeben werden.
Somit hast du eine Liste der Entwckclungs-Versionen und die Module mit dem Status "Stable" schön getrennt.
Das beziehst Du jetzt aber nicht auf mich, oder?
Nein - würde ich bestimmte Personen meinen, hätte ich dies auch gesagt. Hier geht es allgemein um die User - Philosophie bei WB
-
@instantflorian
autsch ... ja Batman ... aber bitte keine Prügeleien hier ... bin Pazifist ... und Verfechter für die Rechte unterschiedlich geschriebener aber inhaltlich gleichbedeutender Sprachkürzel ... :-D
@badknight
Dir ist aber schon bewusst, dass das aktive Entwickler-Team aus 2 Leuten besteht. Einer Davon muss sich gesundheitlich immer sehr zurückhalten.
Und eine Person allein kann nicht alles machen.
Nein. Das ist mir weder bewusst noch ist mir bekannt, wer der vielen Helfer hier dem Team angehört und wer nicht. Beim regelmäßig unregelmäßigen Lesen hier und beim Anschauen, was da so bewirkt wird erschient mit die Gesamtleistung aber tatsächlich größer, als dass WSB ... alias WB ... ein Zwei-Mann-Projekt sein sollte.
Wenn das dann so ist, wäre dazu zum einen zu sagen: Alle Achtung! Großer Respekt.
Und es wäre aber auch zu sagen: Es erklärt aber auch die zurückhaltende Entwicklung der letzten Jahre erneut mit dem Respekt, dass zwei Personen trotzdem so viel Bewegen können.
Problem: Zu viel zu tun, zu wenig Leute. Aktive User, die WB helfen kannst an 2-3 Händen abzählen (Inkl. WB-Team). Viele Team-Member (laut Webseite) haben einfach keine lust / Zeit mehr sich um WB zu kümmern.
Ja, genau darum geht es ja. Im Allgemeinen und im Besonderen bei dem Thread hier.
Das, was ich schon öfter in verschiedener Form als Anregung zum Ausdruck gebracht habe ist ja, dass Projektentwicklung nicht nur(!) Programmierung ist. Und in diesem Fall wird ja Engagement nahezu aufgedrängt ... und da finde ich: schnappt zu ... redet, votet dafür ... und sichert den Vorschlag für WB/WSB ... das ist keine oder nur unwesentliche Extra-Arbeit.
Und Bitte nicht als Kritik verstehen, weil auch die Projektleitung ein persönliches Engagement ist, das jeder für sich selbst auch nach eigenen Vorstellungen ausfüllen muss:
Aber wäre ein Teil der Entwicklerarbeit in den letzten Jahren in solche Projekte geflossen (also nicht mehr Aktivität sondern andere Gewichtung der Inhalte), wäre WebsiteBaker (nur!) meiner persönlichen Meinung nach heute ein Stück weiter. Zu den Rahmenbedingungen gehört der Aufbau einer orientierungsgebend en Plattform (das, was hier vorgeschlagen wurde ist ein wichtiger Teil davon), Rahmenbedingungen, die es interessierten Leuten ermöglichen sich (natürlich im Rahmen von Vorgaben) nach eigenen Vorstellungen einbringen zu können (das Vermissen dieser Möglichkte wird hier ja besonders häufig geäußert) und natürlich auch ein wenig Marketing (aber da bin ich ja sehr speziell).
Und genau da würde ich gerne mal wieder ein wenig (nett!!!!) stubbsen (ohne Anspruch auf Umsetzung natürlich): Einfach mal den Kopf weg von programmierten Objekten und/oder einer v2.9. und einfach mal überlegen, welche anderen Dinge projektbezogen möglich sind. Anders gerichtete Gedanken und Schwerpunkte führen ja oft zu Ideen und Lösungen, die man vorher nicht gesehen hat oder nicht für möglich gehalten hat. Mit einer verbesserten "Plattform" und einem verbesserten "Gesamtrahmen" kommen mehr User ... und damit auch mehr Engagement ... und das mehr möglich ist, ist ja von früher her bekannt. Das kann wieder funktionieren. Denn WSB - oder für die sprachlich anders gepolten schlagwütigen Leser hier: WB - ist einfach ein tolles System.
Ich selbst erfahre das immer wieder, wenn ich das mal einem Kunden präsentiere ... und sehe auch, wie die Nicht-Programmierer-Aber-Einfache-Website-Besitzen-Wollende auf die Einfachheit reagieren. (Auch wenn es bei mir nur ein sehr kleiner Teil meiner Aktivität ist.)
@BlackBird
Ich fände es toll, wenn Du es machen würdest.
@BlackBird und EntwicklerTeam
Ich fände es toll, wenn das im Rahmen des Gesamtprojektes und nicht als Privat-Projekt umgesetzt werden würde. Noch eine AMASProphe in ein paar Jahren wäre nicht so schön. Aber gerade BlackBird ist ja trotz "Merhfach-Gabelesserein" auch eine der konstanten, zuverlässigen, engagierten und auch(!) loyalen WSB-WB-Größen hier (zumindest habe ich das so erlebt). Und in der Situation: Nicht fragen ob sie mitarbeiten möchte, sondern gemeinsam überlegen wie man das konkrete Engagement in das Gesamtprojekt einbinden könnte, so dass sich beide Seiten wohl fühlen ... inklusive weiterer möglicher Mitmacher natürlich ... :wink:
-
Nach einer Nacht mehr drüber schlafen bin ich noch stärker davon überzeugt, dass ein AMASP2 (oder eben "Entwicklerplattform" ) außerhalb der offiziellen wb.org Seiten / Entwicklung / Verein mehr Sinn macht als "hochoffiziell". Gerade wegen
Dir ist aber schon bewusst, dass das aktive Entwickler-Team aus 2 Leuten besteht. Einer Davon muss sich gesundheitlich immer sehr zurückhalten.
Und eine Person allein kann nicht alles machen.
Dann sollte der letzte Mohikaner nicht auch noch damit sich rumschlagen müssen.
-
Hat eigentlich schon jemand bei Erpe nachgefragt? Hängt er da wirklich dran?
SO schlecht finde ich das AMASP (in Aufbau und Struktur) nicht. OK, veraltet - aber nicht schlecht.
Ein paar Zeitgemäße Funktionen rein - und dann ist schon mal viel Startkapital da.
Jetzt nochmal was neues - macht das wirklich Sinn?
-
Auch wenn es nicht so ganz zu einem CMS passt: was spricht gegen ein AMASP in Form eines Wiki mit Rating per Eintrag und insbesondere mit offener Diskussion?
Die Einteilung in die Kategorien Module, Templates, Droplets, usw. wäre einfach gemacht (in Wiki-Nomenklatur: Namensräume); ein Standard-Template pro Eintrag eines (registrierten) Entwicklers kann hinterlegt werden, die Wiki-Syntax ist relativ einfach, Suche etc. ist integriert, und wie schon angedeutet: ein Zwang, den Download auf einer Entwicklerplattform zu hinterlegen, muß ja nicht sein.
Das Hilfeforum per Modul etc. sollte allerdings hier verbleiben - dafür ist eine Forum-S/W ja auch besser geeignet als ein CMS (nicht falsch verstehen: ich meine jetzt NICHT besser als ein Forum-Modul innerhalb eines CMS - aber auch für WB wird ja schließlich aus gutem Grund SMF verwendet!).
In einem solchen offenen Wiki könnte über eine offene Diskussion schnell gefiltert werden, welche Module wie gut in WB integrierbar sind - was jetzt in der AMASP nicht unbedingt möglich ist. Und über Kategorien wie Kompatibilität oder Nutzbarkeit kann ein Wikieintrag klassifiziert werden. Zudem kann eine Nutzerkommunität granular aufgebaut werden, so daß z.B. das Löschen von Einträgen nur wenigen erlaubt wird.
Nur so ein paar Gedanken, die ich für mein Prinz Eisenherz Wiki auch hatte/habe ...
-
@Wiki:
Mhh, ich bin nicht wirklich Freund eines Wikis, nachdem ich ca. 10 verschiedene Wikis aufgesetzt habe und jedesmal (!) eine Bauchlandung hingesetzt habe. Reine Wikis haben das Problem der sehr offenen Kategorisierung, was ich eher als Problem sehe. Zur Darstellung ist es finde ich einfach weniger gedacht.
Zudem ist der administrative Aufwand eines Wikis deutlich höher als gedacht - weniger am Anfang als während der Benutzung.
Als offene Spielwiese von Hilfen / etc.: Dafür ja, ansonsten eher nein.
Zudem ist die Frage, wie sinnvoll ein Rating in Punkten ist. Wenn, dann sollten mindestens Kommentare dabei sein - was dann natürlich wieder höherer Administrationsaufw and bedeutet. Aber was bringt einem, wenn (3,4 / 5) neben einem Modul steht, man aber nicht weiß, wie es zu dieser Bewertung kommt.
Wobei WB in Sachen Rechteverwaltung ja auch nicht gerade ein Highlight ist...
[joke=on] Dafür könnte man ja joomla nehmen.[joke=off]
Nee, WB mit mehr als 30 Benutzern ist auch in der 2.8.4 kein Spaß. kann das nicht KIT besser?
-
... aber genau durch diese (Eigen-)Dynamik kann diese Initiative wieder nach hinten los gehen?!?
Wieso kein Test-Wiki?!? Nun ja, wer kein Freund eines Wiki ist ...
... aber redaktionelle / inhaltliche Arbeit muß IN JEDEM FALLE, also unabhängig von der technischen Realisierung, geleistet werden - und da könnte ein Wiki mehr leisten als ein CMS ... nur meine Meinung. Zumal das Objekt der Darstellung (Module, Templates, Droplets) ja relativ fixiert ist durch die Erwartungen, die eine gute Link-Doku dazu haben sollte ...
Verzicht auf ein Eintragungs-Template ist m.E. in jedem Falle ein Manko: gewisse Mindestanforderunge n sollte ein Eintrag immer erfüllen müssen (unabhängig von CMS, Wiki, FTP Verzeichnis, ...), sonst sind Auswucherungen Tor und Tür geöffnet.
-
Hmm, man sollte denke ich erst einmal den Fahrplan aufstellen. Nicht, dass jetzt wie wild eingetragen wird.
Wer will, kann hierzu gerne http://de.groups.yahoo.com/group/amasp_ng/ beitreten. Der Vorschlag war ja schon einmal hier.
Ich möchte nochmal darauf hinweisen, dass man keinen Yahoo / Google / Facebook Account benötigt, um beizutreten. Hierzu bitte kurz PN an mich, dann kann per E-Mail ohne Probleme kommuniziert werden.
Ebenso, wer zusätzlich Moderator machen möchte.
-
Da außer BlackBird niemand ernsthaft Interesse an einem AMASP2 hat, würde ich hiermit das Projekt "beerdigen".
Es macht aus meiner Sicht keinen Sinn, ein Communityprojekt als "One-Man-Show" durchzuziehen.
Bitte nicht als Trotzreaktion verstehen, sondern eher als Realismus bzw. damit nicht unnötige Arbeit / Zeit in den Sand gesetzt wird.
-
Es läuft wie es immer läuft:
Einer fängt was an
10 Leute machen 18 Vorschläge.
Keiner steigt von seinem Vorschlag runter.
aus.
Frust.
Das WB-Forum scheint im Wesentlichen aus Individualisten zu bestehen, die eine Zusammenarbeit nicht so wollen/können.
Die Techniker glauben, sowas ist ein technisches Problem - und wenn sie es zum funktionieren bringen, dann ist es fertig. Das ist Unsinn. Letztlich braucht es auch Leute, die das ganze dann pflegen - die wollen es nicht, wenn ihnen die Techniker irgendwas vor die Nase setzen.
Das AMASP war die Arbeit von einigen Leuten - damals als noch "Lonesome Walker" der Außenfeind war, der die Community zusammenhielt. Mittlerweile, ein paar Forks und Streitereien später, ist die Personaldecke deutlich dünner, das muss man im Auge behalten, wenn man alles von Grund auf umreißen will.
-
Es geht ja nicht ums Umreißen ... entscheidend ist doch für einen solchen Neu-Afbau von AMASP:
- WIE soll es werden:
-- lediglich eine Linksammlung auf die individuellen Seiten/Foren/Downloads
oder
-- eine allumfassende Lösung, die alles abdeckt (incl. Downloads, Entwicklungsthreads, ....)
oder
-- irgendetwas dazwischen.
- WER verantwortet es
-- als Redaktionsteam (um Mis-Use zu verhindern)
-- als Betreiber der Website.
- WER stellt eine Qualitätskontrolle sicher
-- ist so was gewünscht
oder
-- führt man eine Kommentarfunktion ein, die die Nutzer der AMASP pflegen (also man lädt was runter und teilt dann seine Erfahrungen.
Solange aber solche Basics nicht klar sind, kann so etwas nicht funktionieren.
Natürlich könnte ich TECHNISCH ein solches System (als Wiki ;-) aufbauen und betreuen (und Platz hätte ich auch) - aber was würde das ohne Rückhalt beim Kernteam oder der Community nutzen? Kurzum: ich könnte mich - wie schon angeboten - da in die Pflicht nehmen, aber der Spaß daran würde schnell wieder vergehen, wenn sich dann zwei, drei, vier, ... Alternativen ergeben, die alle ein Stückchen von AMASP übernehmen ... oder keiner hat Interesse, seine Erweiterungen/Templates dahin zu verlinken ...
-
Hallo,
für mich ist es mehr die Frage, braucht es ein AMASP2, oder reicht auch EIN OFFIZIELLER "Addon-Bereich" mit wenigen ausgewählten, dafür gut gepflegten und lauffähigen Modulen inkl. Links zur Entwicklerseite aus?
Ich bin für mich persönlich zum Entschluss gekommen: ich brauche kein AMASP, sondern einfach nur EINE Anlaufstelle wo ich funktionierende Module (Bildergalerie, News- bzw. Blogmodul, Formular, Newsletter ...) schnell finde und bis auf evtl. Layoutanpassungen einfach installieren und verwenden kann. Für mich gilt hier eher: weniger ist oft mehr. Ich will mich nicht durch 100 halbgare Bildergalerien oder 20 fast identische Module wühlen müssen, um festzustellen, dass keines meinen Erwartungen entspricht.
Die Idee von AMASP war alles zu listen, damit man nichts verliert und gegebenenfalls darauf aufbauen kann. Ob es das heute wirklich noch in dieser Form braucht? Zumal keines der gelisteten AMASP Module "Features" der künftigen WB 2.8.4 nutzt und somit nur bedingt als Grundlage für Modul-"Neu"-Entwicklungen dienen kann (gilt derzeit allerdings auch für den WB Addon Bereich).
Dies ist aber wie gesagt nur meine persönlich Meinung.
cwsoft
P.S.: Auch vom WB Redmine SVN für Module (http://project.websitebaker2.org/projects/) halte ich aktuell recht wenig, da für viele Module viel zu unübersichtlich und für Leute mit externer Webseite, Downloadbereich oder Source-Repo irgendwie "doppelter Balast".
[Offtopic]
Manchmal hilft es auch, ein Projekt nach aussen nicht grösser darstellen zu wollen, als es in Wirklichkeit ist. Die WB-Teamseite listest aktuell ca. 16 verschiedene Mitstreiter auf - wieviele davon sind wirklich aktiv ??
Gefühlt haben AMASP/Lepton, BlackCat und WB je 2 "aktive Entwickler" und alle eine handvoll "aktiver Supporter" in der jeweiligen Community.
-
@BlackBird:
Mir geht es eher darum, dass AMASP2 ja aktiv alle / viele Module beinhalten sollte.
Wenn es aber nur die beiden Leute (Fork hin oder her) interessiert, die das Ganze aufbauen, gehe ich auch davon aus, dass es später nicht mehr werden die teilnehmen, und daher die Idee gar nicht angenommen wird.
Wenn jetzt noch ein paar sagen "Ja, gute Idee, wird würden zumindest etwas mitarbeiten wollen" würde ich mich ja auch umstimmen lassen.
Nur so habe ich eben den Verdacht, dass es von Anfang an zwei Leute sind, später auch noch und dann lieber ein AMASP3 und 4 aufgebaut wird als ein Communityprojekt. Kann mich auch täuschen, ebenso umstimmen lassen. Ist eben so meine Erfahrung der WB-Arbeiten seit 2006.