AMASP und Download-Bereich

[DarkViper]

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.

[Stefek]

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

[DarkViper]

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)

Code: [Select]

<?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.

[fischstäbchenbrenner]

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.

[Stefek]

@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

[cwsoft]

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

Gruss

[easyuser]

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.

[easyuser]

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.  

[fischstäbchenbrenner]

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.

[cwsoft]

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 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

Gruss

[Stefek]

Cool!

[cwsoft]

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 nur lokale "Fremdrepos" die auf dem Redmine Server liegen ein. Etwas mehr Komfort bieten Redmine Plugins, 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

[easyuser]

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.

[Yetiie]

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.

[instantflorian]

[badknight]

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.

[instantflorian]

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.

[badknight]

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

[instantflorian]

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?

[badknight]

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

[Yetiie]

@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 ... 




@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 ... 

[easyuser]

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.

[fischstäbchenbrenner]

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?

[hillschmidt]

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 ...

[easyuser]

@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?