Qualität von Modulen

[chio]

Es wurde seit der Veröffentlichung der Templateguidelines kein einziges Template im Forum gepostet, welches sich an diese hält.

Ja, das kenne ich. Kein einziges davon ist auf Anhieb durch den Validator gegangen, von den Guidelines ganz zu schweigen. Aber was solls, die Leute haben andere Kriterien.

Bezüglich Sicherheitslücken:
Gibt es da eigentlich irgendwo eine Checklist, auf was zu achten ist?

[doc]

Hi,

Gibt es da eigentlich irgendwo eine Checklist, auf was zu achten ist?

Die absoluten Basics sind im Hello World Modul erklärt. Zu beachten sind insbesonders: Dateien vor Direktaufrufen zu schützen, Benutzerberechtigun gen zu prüfen wenn nötig, und JEDER Benutzereingaben zu misstrauen, bzw vor dem Eintragen in die Datenbank (addslashes; mysql_real_escape_s tring) und vor der Ausgabe auf dem Bildschirm (strip_tags, htmlentities ...) unschädlich zu machen.

Im Prinzip halt die gleichen Checks, die man auch für andere PHP Programme verwenden würde die online aufgerufen werden können. Guidelines hierzu findest Du zuhauf im Netz.

Christian

[Mux2]

Hallo,
nach ein paar Schwierigkeiten (Neuregistrierung, da irgendwer meinem Account den Schreibzugriff geklaut hat!) will ich mal was zum Thema sagen.
Also, ich habe die beiden Module jokebook und small_ads aus dem Guestbook zurechtgebastelt. Eigentlich erstmal nur für mich...Die Fehler, die aufgetreten sind, habe ich inzwischen korrigiert und bei amasp in Form einer Version 1.01 hochgeladen.
Dass gar nix funktionierte, lag daran, dass bei der Änderung sprich Übersetzung  des Modulnamens und des Modulverzeichnisses ins englische (Witzbuch zu Jokebook und Flohmarkt zu small_ads) schlicht vergessen wurde, die Verzeichnisnamen in sämtlichen Modul-Dateien anzupassen, es wurde lediglich die info.php geändert.
Ich hatte mich ja hier im Forum gemeldet und angefragt, ob auch Andere Interesse an diesen Modulen haben. Und so nahm die story ihren Lauf, Bitte um upload bei amasp, Bitte um Änderung der Namen zur Internationalisieru ng des Ganzen... und schon waren die beiden Teile öffentlich,  das ging alles sehr schnell. Wahrscheinlich ging's auch deshalb so schnell, weil es einen gefühlten Mangel bei der Entwicklung neuer Module gab und Einige deshlab jedes neue Modul möglichst schnell veröffentlichen wollen. Ich bin eigentlich gar nicht  in der Lage, eigene Module zu erstellen, weil mir noch die Programmierkenntnis se dazu fehlen. Aber zum Umbau von existierenden Modulen zumindest für den privaten Gebrauch reicht es. Undwas ich mir so zurechtbastele, gebe ich natürlich auch gern weiter, und so war das damals.

Ich denke mal, ist auch gut, wenn es so läuft, nur sollte vor so einer Veröffentlichung wie bei amasp (und den folgenden Verlinkungen auf diversen anderen Seiten) ein Modul tatsächlich nochmal getestet werden, und zwar NICHT NUR vom Entwickler sondern auch von anderen Personen. Dann passiert sowas auch nicht, wie mit den beiden Modulen.

Ich habe mich aus dem Grund auch bereit erklärt mitzuwirken beim Testen neuer Module. Wenn das dann zwei drei Personen machen, sollten ja zumindest solche derben Fehler nicht mehr auftreten.
Also, sorry für die Fehler, jetzt wie gesagt gibt es die korrigierte VErsion mit der eindringlichen BITTE, dass ein paar Leute das nochmal durchtesten!

Grüße, Mux

P.S. und an die Mods dieses Forums: wär nett, wenn ihr mir meinen Schreibzugriff wiedergebt, da muss bei der Veränderung meines Status' irgendwas schief gelaufen sein.

[Stefek]

Hallo,
als kurze Info: Es haben sich einige Interessenten bei mir gemeldet, die sich für das module testen interessieren.

Yo.. ein paar Good News.

Hallo,

klingt alles ganz nett, so mit Module testen, Modulguidelines definieren etc.

Wer Guidelines erstellt braucht auch Leute, die die Einhaltung dieser Guidelines überprüfen. Und Guidelines führen nicht zwangsläufig zum Erfolg. Es wurde seit der Veröffentlichung der Templateguidelines kein einziges Template im Forum gepostet, welches sich an diese hält.
Gruss Christian

Hallo Christian.
Das stimmt. Es hat anscheinend einige "verschreckt". Kreative Leute mögen in der Regel keine "Uni - Formen". Das trifft sowohl auf Designer, aber auch auf Coder zu. Kaum einer gibt sich mit zu vielen Kompromissen zufrieden (von persönlichen Eigenheiten bei solch einem Zusammenschluß will ich gar nicht erst anfangen - hier ist einfach Toleranz gefragt).

Ich persönlich unterscheide auch bei Modulen (Erweiterungen allgemein) zwischen Ideen und Durchsetzungen.
So gibt es viele Module, die schon als Idee versagen, weil sie entweder keiner sonst braucht oder weil sie nicht einfach umzusetzen sind. Andere sind wirklich gut umgesetzt und finden dennoch nicht ihren Platz auf die offizielle Addons Liste (z.B. das Topics Modul, welches wirklich mehr bietet als das Newsmodul aber mehr von der Community "gefordert" wurde als von "offizieller" Stelle.)
Als anderes Beispiel: User Katerchen hat an der Image Gallery weiter gearbeitet und der inständige Ruf, es auf der Addons Seite als Nachfolgeversion hochzuladen wurde immer überhört - so scheint es zumindest.

Ich bin der Meinung, dass Beiträgen einfach zu wenig Aufmerksamkeit geschenkt wird. Und das entmutigt auf Dauer.
Richtlinien hin oder her: Jede Richtlinie die Produkten und Ergebnissen im Wege steht verfehlt ihren Zweck und sollte entweder revidiert oder fallen gelassen werden. Richtlinien sind einfach "Arbeitsgrundlagen" für Gruppen und enthalten bewährte Prinzipien.

Warum läuft es bei anderen Projekten?
Haben die bessere Ideen oder bessere Richtlinien? Wohl kaum.
Die Arbeiten einfach härter daran, den Workflow zu vereinfachen und Beiträge geltend zu machen.

@Mux:
Sorry, dass wir diesen Thread hier zweckentfremden.

Gruß,
Stefek

[chio]

Naja, so Module wie "Topics" sollten zum jetzigen Zeitpunkt nur von Leuten verwendet werden, die zur Not auch mal an ihrer Datenbank herumfrickeln können.
Das hat auf der offiziellen Seite nichts verloren.
Und wie man sieht ist zb auch "members" nicht vor Fehlern gefeit...

Einerseits denke ich, man sollte die User selbst mal die Module bewerten lassen, die sie verwenden. Aber das birgt die Gefahr, dass sowas zu einem Supportforum wird, also nicht bewertet, sondern gefragt wird.

Erst dann - wenn man sieht, ein Modul wird häufig verwendet, scheint aber Probleme zu machen, dann sollte man mal genauer reinschauen. Sonst wird man NIE fertig.

[Stefek]

Erst dann - wenn man sieht, ein Modul wird häufig verwendet, scheint aber Probleme zu machen, dann sollte man mal genauer reinschauen. Sonst wird man NIE fertig.

Ja, ich denke wirklich dass eine solche "Ermittlung" als erster Schritt genau das richtige wäre.
Wie macht man aber eine so ausgereifte Umfrage-Aktion?

Irgendwelche Ideen?
Bis auf Kommentarfunktion auf AMASP fällt mir noch das "Formlist" von Thorn ein. Man könnte es eventuell "zurechtzimmern", dass es den Zwecken dient und anschließend verschickt man jemand ein "Newsletter" an die Kommune mit der Aufforderung, an der Umfrage teilzunehemen.


Gruß,
Stefek

P.S. @Topics - hm.. wusste nicht, dass Du da noch soviel geplant hast. Scheint alles gut zu funzen soweit.

[erpe]

Ich denke, dass zumindest die Anzahl der Downloads einen Hinweis auf die Häufigkeit der Nutzung geben kann.
Ansonsten kann man ja den eigentlichen Modulthreads jeweils eine Standardumfrage bzw Bewertung voranstellen. Die wächst dann ja auch mit der Zeit. Aber richtige Objektivität wird es da auch nicht geben.

Gruss

erpe

[doc]

Hallo,

Ich denke, dass zumindest die Anzahl der Downloads einen Hinweis auf die Häufigkeit der Nutzung geben kann.

Naja, als erster sehr schwammiger Indikator mag die Downloadzahl dienen, aber einer allzugrossen Aussagekraft würde ich dem nicht beimessen.

@Stefek:
Wenn Du schon zitierst, zitiere bitte richtig 

Es wurde seit der Veröffentlichung der Templateguidelines kein einziges Template im Forum gepostet, welches sich an diese hält. Gut es wurde auch vorher keine Templates mehr gepostet, aber die Erstellung von Guidelines ist kein Garant für irgendwas.

Vor allem der zweite Satz ist recht wichtig. Die Templateguidelines haben nicht dazu beigetragen, dass es mehr oder weniger Templates gibt, es wurden bereits gut ein halbes Jahr zuvor keine neuen Templates mehr gepostet. Denke die Verunsicherung über Template-Lizenzen hatte da deutlich mehr Einfluss als die Templateguidelines.

Und zum Thema Richtlinien. Das mag für Templates ja vielleicht noch zutreffen, aber wenn man über Schwachstellen in Modulen die Datenbank manipulieren kann, oder z.B. Dateien hochladen kann, ist das Geschrei gross und das Image von WebsiteBaker schneller ruiniert als man denkt. Was bringt denn eine riesen grosse Liste mit Teils bescheidenen oder gar unsicheren Modulen? Da hilft es auch nichts, wenn man die als Alpha, Beta Gamma bezeichnet, die gehören einfach nicht in die freie Wildbahn. PHP ist leider eine Sprache die auch ohne fundierte Kenntnisse schnell "scheinbar" brauchbare Ergebnise liefert. Viele Module enstehen daher nach folgendem Kochrezept. Ich nehme Modul A (welches ich nicht wirklich verstanden habe), ändere es hier und da etwas um und nenne es Modul B. Dumm nur, wenn Modul A Sicherheitslücken enthält, denn die sind dann auch mal schnell in Modul B. Ist man dann bei Modul K angekommen, denkt man sich hey das machen alle so, das muss so sein ...

Funktionstest bei Modulen in allen Ehren, aber die kann jeder Notfalls selbst auf einer lokalen Testumgebung durchführen (kostet max 2 Minuten). Um herauszufinden, ob ein Modul WWW tauglich ist, muss man im Quelltext gezielt nach Schwachstellen suchen - und das kostet Zeit (und nein, die automatischen Scanner die es gibt taugen nicht wirklich). Schwachstellen können je nach Geschick des Programmierers und Grösse der Module teils schwer bis gar nicht zu finden sind, es sei denn man ist ein ausgesprochener Sicherheitsexperte in Sachen PHP und Co.

Für mich sehr wichtig ist eine durchgegehende, sinnvolle und selbsterklärende Beschreibung, was das Modul eigentlich macht und dazu per Lightbox oder was auch immer einige aussagekräftige Screenshots des Modul Front- und Backends (so wie in der existierenden Machbarkeitsstudie). Dies würde es erlauben vorab zu prüfen, ob das Modul einen weiteren Blick wert ist oder eben nicht.

Was sehr viel Sinn macht, ist es Module in aller Ruhe zu testen und zu bewerten und diejenigen die sich lohnen weiter- oder fertigentwickelt zu werden gesondert auszuzeichnen. Module die den Namen Modul nicht verdienen, nur wieder ein x-ter Klon von irgendwas sind sollten dann lieber in die Kategorie "Sondermüll" wandern. Motto, gute Idee, scheiss Umsetzung, vielleicht nimmt sich ja jemand dessen an 

Gruss Christian

[erpe]

Zumindest ist die Downloadzahl ein erster Gradmesser für Interesse.
Vielleicht nicht optimal aber ich wüsste zur Zeit keinen besseren.

Gruss

erpe

[doc]

Hi Erpe,

bei der Downloadzahl wäre halt wichtig wie oft das ganze in welcher Zeit runtergeladen wurde und wie oft welche Version eines Moduls. Aber als erster Indikator mag es reichen.

Denke aber wir werden nicht umhin kommen, alle Module mal wirklich auf Herz und Nieren zu testen, alle Fehlermeldungen, Warnungen und Ungereimtheiten aufzuschreiben in einer Liste zusammenzufassen und daraus dann eine Empfehlung oder Gruppierung abzuleiten.

Wenn die Spreu vom Weizen getrennt ist, kann man im nächsten Schritt dann auch die Modulbeschreibungen und Screenshots überarbeiten. Wie aber in meinem ersten Post bereits erwähnt, braucht es dazu die Mithilfe möglichst vieler Freiwilliger und nicht nur die Mithilfe einiger weniger (umgangssprachlich die "Deppen") 

Also wenn sich genügend Freiwillige finden lassen, wäre ich dabei.

Gruss Christian

[erpe]

die Mithilfe möglichst vieler Freiwilliger und nicht nur die Mithilfe einiger weniger (umgangssprachlich die "Deppen")  smiley

Da hast du sicher recht, aber der letzte Aufruf zum Mitmachen gibt ja wohl ein wenig Anlass zu Optimismus, wie Matthias angedeutet hat.

Dann sind wir mal alle zuversichtlich.

Gruss aus dem Norden in die (verschneite?) Schweiz

erpe

[BerndJM]

Abgesehen von der Qualitätssicherung bei den Modulen, die unumstritten ein sehr wichtiger Faktor ist, fehlt mir aber noch ein anderer (in meinen Augen) sehr entscheidender Punkt:

Wer arbeitet gerade an einem Modul, bzw. arbeitet überhaupt jemand dran oder ist es total verwaist und damit quasi für Arbeitswillige "zum Abschuß" freigegeben.

Praktisches Beispiel:
das "Calender 1.0 RC6"
nachdem wohl vom Initiator nichts mehr kam, bzw. zu erwarten war, habe ich ja auf Grund einiger Featurewünsche eine Zeitlang dran gearbeitet, bin aber auf das Problem gestoßen, daß die gewünschte Einbindung des FCKE für die Terminbeschreibung Probleme bereitet, wenn es auf der Seite in der der Kalender eingesetzt ist noch WYSIWYG-Abschnitte gibt.
Das Problem hatte ich damals auch im Forum gepostet, aber es kam leider kein Feedback, also hatte ich das Ding erstmal auf Eis gelegt. Denn ohne eine fehlerfreie Funktion im Umfeld mit anderen Abschnitten macht es schließlich auch keinen Sinn.

Grade vor ein paar Tagen hat sich nun ein anderer User an der Geschichte versucht - im Prinzip alles das aufgeräumt, daß ich bereits bearbeitet hatte, und den Editor eingebaut ... und siehe da: er hat das gleiche Problem.
Fazit:
jede Menge Arbeit doppelt gemacht - Ergebnis trotzdem "unbrauchbar".
Oder anders gesagt, jede Menge der eh schon knappen "Resource Mensch" in was verschlissen, was immer noch nicht brauchbar ist.

Gut, ich muß mir da selber "an die Nase fassen" - ich hätte mein damaliges Zwischenergebniss veröffentlichen können (natürlich mit entsprechendem Hinweis) - was ich aber wohl wissend der Tatsache, daß es immer wieder Zeitgenossen gibt, die des Lesens nicht sooo mächtig sind und erstmal ausprobieren und hinterher meckern, einfach nicht tat.

Was ich sehr begrüßen würde, wäre auf dem AMASP eine klare Kennzeichnung der Module - vielleicht in der Art wie z.B. beim Wiki von ubuntuusers.de:
Baustelle! wird bearbeitet von user "xxx" Fertigstellung voraussichtlich dd.mm.yyyy
Wobei der Bearbeiter das Fertigstellungsdatu m auch selbst verschieben kann und/oder sich aus dem Teilbereich verabschiedet (weil er's halt doch nicht schafft) und ggf. einen Nachfolger einführen kann.

So könnte man vielleicht manche "Doppelarbeit" vermeiden und/oder auch ambitionierte Entwickler zusammenbringen.

Nur so meine Überlegungen ...

Grüßle Bernd

[doc]

Hallo Bernd,

alle Module deren letztes Release bereits mehr als 1 Jahr zurückliegt und dessen Hauptentwickler nicht mehr im Forum aktiv ist, wird auch nicht mehr weiterentwickelt. Das dürften so an die 95% der aufgelisteten Module sein. Ein Anhaltspunkt findest Du auf der Addons Seite (letztes Update + Liste der Autoren).

Da wo z.B. zusätzlich zu anderen Namen der Name von Matthias, Thorn oder mir drinsteht, wurden kleinere Korrekturen oder Sicherheitspatches von uns eingebaut. Ich spreche mal nur für mich, aber ich denke nicht im Traum daran diese Module weiterzuentwickeln. Ich betreue nur die von mir ursprünglich initierten Module (Anynews, Zitate, Post Its, Userstat, Addon File Editor und gebe Support für Hello World und FCKEditor).

Nimm dir das Beispiel Calendar. Ich hatte mir Anfangs überlegt das ganze zu "debuggen". Beim Betrachten des Quellcodes kam ich aber schnell zum Entschluss, dass es einfacher ist, das ganze vernünftig neu aufzusetzen und dabei z.B. die Funktionen der 2 Kalendermodule zu vereinen und auch etwas in Richtung Joomla und Co. zu schielen.

Das war auch mein Hauptziel beim "Addon File Editor". Ein Tool für alle Addon Dateien, welches dann die 7 Klons des Originals: "Template Edit" überflüssig macht (Module Edit, Template Edit, Lanugae Edit, Toogle Module Edit, Toogle Language Edit, Toggle Module+Language Edit).

Auch hier hat man schön gesehen, wie "Module" entwickelt werden. Mann kopiert Modul A (das übrigens nicht wirklich sicher war), ändert ein paar Zeilen und speichert es als Modul B (Module Edit). Dann kommt jemand und kombiniert Modul A+B und macht daraus Modul C. Letztendlich sind wir bis Modul G gekommen, aber immer noch die Codebasis von Modul A. Das nenne ich doch mal Fortschritt 

Also, die Module herausfinden, die am meisten genutzt werden. Schauen, welche Module ein CMS wirklich haben sollte (z.B. Forum, Gästebuch, Bildergallerie, Calender, Poll, Download Gallery ...). Schauen ob es bereits Module für diese Felder gibt und diese dann überarbeiten.

Bei den Bildergallerien würde ich mal einen Blick auf die Foldergallery werfen, die hat das Potential eine der Standardgallerien (FTP hochladen - fertig) zu werden. Der Entwickler verwendet bereits Templates zur Trennung von HTML und PHP.

Ich schlage vor wir erstellen mal eine Textdatei mit den Kritierien und den Infos die es zu sammeln gilt und hängen diese an den Thread. Dann können wir das ganze mal weiterspinnen und hätten auch gleich was, sollten sich doch noch genügend Helfer finden. Anbei mal die erste Version (Textdatei, Excel Datei und CSV comma seperated values Datei).

Gruss Christian

[chio]

Die Bildergalerien...
da hab ich mir schon mal vorgenommen, was da war, in Vor-AMASP-Zeiten. Ist in der Zwischenzeit wieder ein Haufen dazugekommen...
Ich denke schon länger daran, das wieder aufzunehmen: Alle installieren, checken, beschreiben.
Und ansonsten werde ich mich wohl  auch mal wieder mehr um _meine_ Module kümmern.

[erpe]

Hallo Doc,

noch eine Liste halte ich nicht für den richtigen Weg................
Die meisten Daten auf der Liste kann man doch mit einer DB-Abfrage bekommen.
Ich werde mal schauen, was sich da so machen lässt.
Auch das Thema mit Install/Deinstall hat so seine Tücken in Abhängigkeit von der Umgebung.
Ich glaube, das ist noch nicht der richtige Weg.

Vielleicht sollte man erstmal unterienander schreiben, was man denn genau erreichen will und daraus dann ein Konzept ableiten. Bin gerne mit dabei, wenn es um so ein Konzept geht.

@Bernd
Kann dich mit deiner Meinung nur voll unterstützen. Deswegen haben wir auf Vorschlag von Ralf (Berlin) damals den Punkt upcoming items bei AMASP aufgenommen........ ......Interessiert aber auch nur die wenigsten, stellt man mal auf die Beteiligung ab. Die meisten Module erscheinen einfach "urplötzlich". Es wäre wirklich prima, wenn sich im Vorfeld der jeweilige Autor mal über Vorlagen oder andere Arbeiten informieren kann. Vielleicht liegt es aucvh an den Informationen, die noch nicht weit genug verbreitet sind.

@doc
Auc ich bin der Meinung, dass es vielen Modulen gut tun würde, wenn Sie einerseits überarbeitet und andererseits auch "zusammen gefasst" würden. Keine Frage. Meine Hoffnung geht dahin, dass das vor dem Hintergrund der Entwicklung der 3.0 Version geschieht, wo (so hoffe ich) die Entwicklung/Überarbeitung der Module einfacher wird und eben entsprechend Zeit bis zum Erscheinen der 3.0 ist.

Also ich denke, Eingigkeit herrscht darüber, dass da etwas passieren muss, allerdings ist der Weg und das Ziel für mich noch etwas unklar. Bin aber gerne bereit, bei der "Findung" zu helfen.

Gruss

erpe

[BerndJM]

@doc:
sicher ist die Weiterentwicklung bestehender Module nicht unbedingt "so der Brüller", andernseits gibt es doch etliche die es eigentlich Wert wären, hat doch der Ursprungs-Entwickler schon ordentlich Hirnschmalz reingesteckt.
Manchmal (sehr oft) wäre ein Neuschreiben weniger Zeitaufwändig, aber andernseits sieht man durch das "weiterbasteln" auch immer mal wieder ganz andere Ansätze oder stolpert über "Fallen" die einem so gar nicht in den Sinn gekommen wären.

@erpe:
die "Upcoming Events" ist schon klar - für neue Geschichten, allerdings passieren halt manche Dinge einfach quasi "über Nacht". Mir ging es primär darum bei bestehenden Modulen zu sehen was daran passiert (oder ob sich da überhaupt was tut.

Allgemein noch etwas, was mir auch immer bischen auf den Magen schlägt:
diese sehr unglückliche Versionierung. z.Zt. vergibt doch jeder die Nummern nach seinem Gusto.
In meinem Empfinden ist es ein Unding ein grade frisch fertiggestricktes Modul mit eine 1.irgendwas zu versehen. Irgendwas >0 vor dem . hat es erst verdient, wenn es in der Praxis bewährt ist. Auch sollte mal Klarheit her wie die Nummerierung nach dem ersten Punkt auszusehen hat: ist es eine 0.2.1 oder eine 0.21
Hier sollte mal durchgängig aufgeräumt werden.

Grüßle Bernd

[doc]

Hi,

sicher ist die Weiterentwicklung bestehender Module nicht unbedingt "so der Brüller" ...

Wenn man es gescheit machen will (Mehrsprachigkeit, Trennung von HTML/PHP/CSS/JS etc.) kommt man bei den meisten Modulen nicht umhin, so ziemlich alles neu zu schreiben. Nur meine Meinung, wer bestehende Module ummodeln will - nur zu   

... diese sehr unglückliche Versionierung. z.Zt. vergibt doch jeder die Nummern nach seinem Gusto

Alle meine Module starten bei v0.10. Allerdings komme ich meist nie über eine 1.0 hinaus; ab v0.50 sind die Module meist Stable. Ob nun v0.20 oder v0.2.0 ist mir ehrlich gesagt Wurscht. In WB 2.8 wird beides gehen (0.21 = 0.2.1). Wichtig ist denke ich der Status: Alpha, Beta, RC, Stable. Es gibt zig verschiedene Versionierungssyste me in der IT, einfach mal bei Wikipedia nachschauen. Denke das sollte "intern" festgelegt werden und nicht hier öffentlich diskutiert werden. Wenn wir schon bei Unding sind: Für mich ist ein Unding, wenn jemand 2 Zeilen im Quellcode ändert und sich dann freach in die Liste der Autoren einträgt. Üblich ist die Nennung als Autor bei Quelltextänderungen > 10-20% vom Gesamtquelltext (nur so als Beispiel). All dies könnte man in Modul-Guidelines (an die sich dann eh wieder keiner hält) aufnehmen.

noch eine Liste halte ich nicht für den richtigen Weg.......

Hi Erpe. Die Idee war schon, dass ich die DB Abfrage für die Addons Seite mache und eintrage, Du von AMASP und einträgst. Diese Liste können wir dann als gemeinsamen Startpunkt nehmen, nicht mehr nicht weniger.

Gruss Christian

[Stefek]

@erpe:
die "Upcoming Events" ist schon klar - für neue Geschichten, allerdings passieren halt manche Dinge einfach quasi "über Nacht". Mir ging es primär darum bei bestehenden Modulen zu sehen was daran passiert (oder ob sich da überhaupt was tut.

Also was schon mal gut auf AMSP ist, ist die Angabe wer der Autor ist und welcher Thread zum Modul gehört. Hier wurde tatsächlich darauf geachtet, es möglichst (ich sag mal) "offiziell" zu halten. Und so hat man auch zumindest einen guten Anhaltspunkt seinen Ansprechspartner zu finden, wenn man an ein bestehendes Modul heran will.

Eine Kommentarfunktion wäre sicher eine gute Ergänzung dazu.
Aber auch die Möglichkeit für den Entwickler, eine extra Eingabemaske + Checkbox zu haben, wo er angeben kann, was auf der TO DO Liste steht und ob das Modul ein "work in progress" ist, oder ob die Entwiclung gegenwärtig auf Eis liegt.
Auch kleine "Hilferufe" könnte der Entwickler dort eingeben, falls er bei einer Sache ins Stocken gerät.

@Doc
Viele der "Duplikate" ergeben sich einfach, weil jemand eine klitzekleine Abweichung des bestehenden Modul benötigt. Gutes Beispiel ist X_Form. Es kann einfach MEHR, ist in vielen Aspekten handlicher und wurde dennoch nicht richtig unterstützt - obwohl viele Leute danach fragen.
Man kann aber solches "duplizieren" und "replizieren" weder verhindern noch stellt es ein wirkliches Problem dar. Man muss nicht jeden Schrimms "listen". Da schaut man nach Tauglichkeit und ob die wesentlchen Kriterien (über die momentan keine Einigkeit herrscht) eingehalten wurden.
Ich würd es nicht so verteufeln, dass sich keiner mehr an Module herantraut.

Gruß,
Stefek

[doc]

Hi,

Ich würd es nicht so verteufeln, dass sich keiner mehr an Module herantraut.

Joo dann Augen zu und weiter so wie immer. Ruhig auch Module posten die coole Features erlauben, wie z.B. das ändern des Adminpassworts aus dem Frontend ohne angemeldet zu sein, oder das hochladen einer PHP Command Shell falls das nicht ausreicht. Beide Funktionen konnte in einigen "älteren" Modulen genutzt werden, obwohl diese Module eigentlich etwas ganz anderes machen sollten.

Es spricht nichts gegen "replizieren" oder "anpassen". Ich spreche davon, dass es viele Module von Leuten gibt die gerade Ihre ersten Schritte mit PHP machen und das ganze dann gleich als WB Module im Forum posten, dann auf AMASP und dann im WWW über Google und Friends einfach zu lokalisieren sind.

Gruss Christian

[Stefek]

Ich würd es nicht so verteufeln, dass sich keiner mehr an Module herantraut.

Joo dann Augen zu und weiter so wie immer.

Hehe... auch wenn ich hier gerne mit einer Software arbeite, die urprünglich in Australien initiiert wurde, habe ich mich der von Dir beschriebenen Strauß-Mentalität bestimmt nicht verschrieben.

Wie schon gesagt, man muss nicht jeden Schrimms listen. Hier werden sicher Aufnahmekriterien gebraucht. Vor allem auch für Leute, die möglicherweise in der Zukunft aufkommen und die von Haus aus wirklich versierte Coder sind. Man mus nicht immer vom Schlimmsten ausgehen - es gibt nämlich auch gute Leute da draußen. Und die gilt es mit den WB spezifischen Kriterien vertraut zu machen.
Die kleinen Beiträge die "keiner sonst" braucht (was auch eine oft subjektive Sicht der Dinge ist) und die vom Gesichtspunkt eines richtigen Coders aus Schrott unter der Haube haben... Nun, wenn es eine gute Idee ist, kann es einer aufgreifen, aber wenn es nur Schrott ist muss man die dann auf die Modul Aufnahmekriterien hinweisen und "Sorry" sagen. Ganz klarer Fall.

So oder so wird einer dafür Verantwortlich sein müssen, was nun "Salonfähig" ist oder nicht.
Eine Maschine wird es nicht übernehmen. Höchstens dabei helfen (Stichwort Ermittlungen).

Und es geht hauptsächlich darum, zunächst die Goodies rauszupicken und während der Arbeit an so einem Pilotprojekt werden sich "Richtlinien" heraus kristalisieren.
Sie vorher festsetzen zu wollen ist als ob man eine Fahrradtour auf dem Mond vorausplant.
Dinge die im Voraus geplant werden können sind höchstens Verantwortlicher, Crew, Werkzeuge, Zielsetzung. Und wie es aussieht ist die Klärung der Frage dringend notwendig: wohin damit, AMASP oder Addons. Oder welcher Part wohin und auf welche Weise.

So, und jetzt stülp ich mir eine kugelsichere Weste über.

Stefek

[doc]

Hi,

nachdem sich ja die meisten hier einig sind, dass es so wie es derzeit ist nicht weitergehen kann, sollten wir vielleicht einen internen Thread aufmachen und das ganze weiter zu diskutieren. Schlage vor jeder der Interesse hat an einem gemeinsamen Konzept zu arbeiten, schickt eine PM an ruebenwurzel und dann sehen wir weiter.

So kann man die "Freiwilligen" von Anfang an mit einbinden, bzw. im Vorfeld prüfen was personaltechnisch überhaupt machbar ist und was eben nicht. Ideen gibt es viele, aber die Umsetzung dieser Ideen ist ja bekanntlich nicht gerade die Stärke von websitebaker 

Gruss Christian

[Stefek]

Hallo Christian.
Wenn Du der Meinung bist, dass auch das Look & Feel der Module im Backend eine Rolle in den Kriterien spielt (ich bin dieser Meinung), melde ich mich gerne.
Wie ich neulich bekannt gab, habe ich gegenwärtig nicht sehr viel Zeit, aber auch das wird in Zukunft besser.
An einer Etablierung von Modul Backend Design Guidlines mitzuwirken bin ich sehr interessiert, habe schon einiges ausgearbeitet und nachdem diese Regeln stehen, bin ich sogar persönlich geneigt viele der Goodies gemäß dieser Regeln zu überarbeiten.

Ideen gibt es viele, aber die Umsetzung dieser Ideen ist ja bekanntlich nicht gerade die Stärke von websitebaker 

Ja, tatsächlich scheint es, als würden die "individuellen Beiträge" WebsiteBaker am Leben erhalten. Bestenfalls kleine Teams. Daher ist die Bildung von Aufnahmekriterien für Module eine Sache von großem Interesse für alle Beiteiligten - solange in "der Stränge der Richtlinien" noch "Raum für Individualität" vorhanden ist.

MfG,
Stefek

[doc]

Hi,

Wenn Du der Meinung bist, dass auch das Look & Feel der Module im Backend eine Rolle in den Kriterien spielt (ich bin dieser Meinung), melde ich mich gerne.

Denke alles zu seiner Zeit und vor allem einen Schritt nach dem anderen.

Zuerst sollte mal die derzeitige Situation analysiert werden und ein möglicher Workflow für Templates and Module skizziert werden. Auch wäre es wichtig zu wissen, wer an der Umsetzung des ganzen mitarbeiten würde und wer welche Fähigkeiten mit einbringt. Es bringt nichts jetzt Luftschlösser zu bauen und dann festzustellen, dass das ganze wieder nur an ein paar Hanseln hängen bleibt. Da lass ich es lieber gleich ganz 

Gruss Christian

[Stefek]

Ne. Ist schon klar.

Ich dränge trotzdem mal darauf, zu schauen welche Aspekte berücksichtigt werden müßen - grob gesehen.
Und einer davon ist eben, wie die Dinger aussehen.
Ein weiterer Teilbereich ist natürlich, wie man sie präsentiert (und wo; SCNR).
Ein weiterer sind die Dokus.

Nur so am Rande ein paar Sachen die weniger mit Codierfertigkeit zu tun haben.