Bernhard: Mehrere Fragen zum Wiki-Neustart

Tag!

Es sieht ja jetzt so aus, als würde das Wiki relativ rund laufen. Jedenfalls tut sich täglich was am Inhalt. Daher von wir ein paar Fragen:

1. Hat der Wiki-Neustart einen Einfluss auf das SelfHTML-Versionsschema? Sprich: Ist das, was gerade entsteht, SelfHTML 9? SelfHTML 10? Oder werden mit dem Wiki die Versionen ganz abgeschafft?

2. Eine Buchveröffentlichung ist ja wieder geplant. Davor wird die Redaktion wohl den Wiki-Inhalt in eine konsolidierte Fassung (einheitlicher Sprachstil, einheitliches Seitenlayout etc.) bringen müssen.

2.a)Ich hoffe, das wird im Wiki selber passieren...?
2.b)Wenn ja, wird es davon wieder eine Downloadvariante geben? (Ich hoffe doch!)
2.c)Nachdem ich schon davon ausgehe, dass a) und b) so eintreten werden, würde ich es auch sehr schade finden, wenn man dieser Fassung nicht eine Versionsnummer spendieren würde...

3. Es wurde ja in der Diskussion vor der Einführung schon mal angesprochen (von Stefan Münz, wenn ich mich richtig erinnere), dass Perl, PHP und Konsorten besser draußen bleiben. Momentan gibt's im Wiki aber Abschnitte dazu.

Sollen die bleiben? Zumindest aus einer konsolidierten Fassung würde ich diese Teile raus tun. Oder zu einem Abschnitt "Kurzeinführung in serverseitige Technologien" oder so auf 2 bis 3 Seiten zusammenfassen. Wurde da schon was entschieden?

Grüße
Bernhard

  1. Hallo,

    1. Hat der Wiki-Neustart einen Einfluss auf das SelfHTML-Versionsschema? Sprich: Ist das, was gerade entsteht, SelfHTML 9? SelfHTML 10? Oder werden mit dem Wiki die Versionen ganz abgeschafft?

    Das ist noch nicht entschieden. Ich persönlich würde die Fortsetzung einer Versionierung für bestimmte "Schnappschüsse" begrüßen (in welcher Form auch immer), aber ich bin da nicht dogmatisch, was das angeht.

    1. Eine Buchveröffentlichung ist ja wieder geplant. Davor wird die Redaktion wohl den Wiki-Inhalt in eine konsolidierte Fassung (einheitlicher Sprachstil, einheitliches Seitenlayout etc.) bringen müssen.

    2.a)Ich hoffe, das wird im Wiki selber passieren...?

    Selbstverständlich.

    2.b)Wenn ja, wird es davon wieder eine Downloadvariante geben? (Ich hoffe doch!)

    Das war geplant. Aber bevor wir über Downloads nachdenken können, sollte das Wiki mit den entsprechenden Inhalten gefüllt sein. :)

    2.c)Nachdem ich schon davon ausgehe, dass a) und b) so eintreten werden, würde ich es auch sehr schade finden, wenn man dieser Fassung nicht eine Versionsnummer spendieren würde...

    Ich kann mir gut vorstellen, dass die Downloadversionen versioniert werden während die Wiki-Versionen "im Fluß" bleiben. Aber wie gesagt: Es ist in dieser Hinsicht noch nichts festgelegt.

    1. Es wurde ja in der Diskussion vor der Einführung schon mal angesprochen (von Stefan Münz, wenn ich mich richtig erinnere), dass Perl, PHP und Konsorten besser draußen bleiben. Momentan gibt's im Wiki aber Abschnitte dazu.

    Sollen die bleiben?

    Die Frage sollten wir hier an der Stelle noch nicht beantworten, sondern erst, wenn es dann mal langsam soweit ist. Ich sehe aber z.B. kein grundsätzliches Problem darin, das in der Wiki-Version schon drin zu haben aber in der Download-Version erst einmal nicht, wenn das denn mal so entschieden werden würde.

    Nur mal grundsätzlich: Mit der Öffnung der Weiterarbeit als Wiki wollen wir durchaus auch, dass sich die "Community"[tm] an den späteren Entscheidungen mit beteiligt. Die ganzen Dinge, die wir zum Beispiel beim Start des Wikis vorgegeben haben (bis auf die Lizenz usw.) waren hauptsächlich Vorschläge, damit man mal einen Ansatzpunkt hat, um nicht komplett wie der Ochs' vor'm Berg zu stehen. Das heißt aber nicht, dass das in Stein gegossen ist. Wir (als der jetztige Verein) haben daher auch explizit nicht zu viel darüber vorgegeben, wie wir uns die Zukunft vorstellen, weil wir das eben nicht einfach so diktieren wollen, sondern auch die Leute einbinden wollen, die dazu beitragen. Das einzige, was uns so im Hinterkopf schwebte, war das folgende: 1) Download-Versionen soll es mittel- bis langfristig wieder geben, weil sehr viele Leser das wollen (und es auch sinnvoll ist) und 2) behalten wir eine Buchveröffentlichung im Hinterkopf, wenn später einmal Verlage wieder Interesse zeigen sollten.

    Viele Grüße,
    Christian

    1. Hi Christian!

      Danke für die Antworten, jetzt weiß ich Bescheid.

      Nur mal grundsätzlich: Mit der Öffnung der Weiterarbeit als Wiki wollen wir durchaus auch, dass sich die "Community"[tm] an den späteren Entscheidungen mit beteiligt.

      Ok, also hier nochmal zur Sicherheit meine Positionen:

      PRO Buch
      PRO Downloadversion
      PRO Versionsnummerierung

      contra serverseitige Technologien (in einer konsolidierten Fassung)

      Bitte um Hinweise, falls das Forum nicht der passende Ort für diese Diskussion ist. Ich gebe meinen Senf dazu auch gern auf Wiki-Diskussionsseiten oder anderswo ab.

      Grüße
      Bernhard

      1. Hallo Bernhard,

        PRO Buch
        PRO Downloadversion
        PRO Versionsnummerierung

        ACK bis hierher, wobei ich eine Numerierung des Wiki-Bestands für sinnlos halte. Numerierung nur für die Download- und Buchversionen.

        contra serverseitige Technologien (in einer konsolidierten Fassung)

        Hmm. "Contra" würde ich gerade nicht sagen. Das Wiki bietet die Möglichkeit, auch die serverseitigen Themen mit aufzunehmen, wenn sich Leute finden, die das machen möchten. Das würde ich auch nicht bremsen wollen. Du meinst vermutlich, dass diese Themen in einer versionierten Ausgabe nicht mit aufgenommen werden, auch wenn Material im Wiki vorhanden ist. Das fände ich dann okay.

        Bitte um Hinweise, falls das Forum nicht der passende Ort für diese Diskussion ist. Ich gebe meinen Senf dazu auch gern auf Wiki-Diskussionsseiten oder anderswo ab.

        Nö, ist schon okay.

        Ciao,
         Martin

        --
        Die letzten Worte des Systemadministrators:
        Nur gut, dass ich ein intaktes Backup habe.
        1. Bitte um Hinweise, falls das Forum nicht der passende Ort für diese Diskussion ist. Ich gebe meinen Senf dazu auch gern auf Wiki-Diskussionsseiten oder anderswo ab.

          Serverseitige Technologien erwähnen und behandeln: ja.

          Aber eine Redundanz zur imho äußerst umfangreichen PHP-Dokumentation zu schaffen (sprich die ausfürhliche Dokumentation jeder einzelnen Funktion) wäre ziemlich unsinnig bzw. erfordert eine enorme Manpower um das alles zu befüllen und aktuell zu halten.

          1. Hi!

            Aber eine Redundanz zur imho äußerst umfangreichen PHP-Dokumentation zu schaffen (sprich die ausfürhliche Dokumentation jeder einzelnen Funktion) wäre ziemlich unsinnig bzw. erfordert eine enorme Manpower um das alles zu befüllen und aktuell zu halten.

            Zumal die Manpower auch auf der Clientseite gebraucht wird. Und ich gehe schon davon aus, dass die Clientseite in Selfhtml eine höhere Priorität darstellt. Oder sieht das jemand anders?

            Grüße
            Bernhard

            1. Aber eine Redundanz zur imho äußerst umfangreichen PHP-Dokumentation zu schaffen (sprich die ausfürhliche Dokumentation jeder einzelnen Funktion) wäre ziemlich unsinnig bzw. erfordert eine enorme Manpower um das alles zu befüllen und aktuell zu halten.

              Zumal die Manpower auch auf der Clientseite gebraucht wird. Und ich gehe schon davon aus, dass die Clientseite in Selfhtml eine höhere Priorität darstellt. Oder sieht das jemand anders?

              Im Wiki setzt jeder seine eigenen Prioritäten. Daran kannst du nichts ändern. Du kannst lediglich bestimmte Engagements verscheuchen.

              Im Übrigen ist das der entscheidende Mehrwert des Wiki.

              mfg Beat

              --
              ><o(((°>           ><o(((°>
                 <°)))o><                     ><o(((°>o
              Der Valigator leibt diese Fische
              1. Hi!

                Im Wiki setzt jeder seine eigenen Prioritäten.

                Das geht nur, wenn die entsprechenden Optionen vorhanden sind. Wenn nur A zur Auswahl steht, kann niemand B höher priorisieren.

                Daran kannst du nichts ändern.

                S.o.

                Du kannst lediglich bestimmte Engagements verscheuchen.

                Stellt sich die Frage, inwiefern es einen Mehrwert bringt, wenn jemand z.B. _ausschließlich_ zu PHP o.ä. beitragen will oder kann. Es scheint mir, wie gesagt, wenig sinnvoll, zu einem bereits ziemlich gut dokumentierten Produkt wie PHP nochmal eine redundante Doku aufzubauen.

                Wenn jemand hingegen sowohl zu HTML, CSS etc. als _auch_ zu PHP beitragen will oder kann, dann läuft man ohne ein PHP-Kapitel nicht in Gefahr, dass Ressourcen dort eingesetzt werden, obwohl sie anderswo nötiger wären.

                Meine grundlegende Einstellung ist halt, dass
                1. serverseitige Technologien schon genug dokumentiert sind,
                2. daher eine über eine kurze Gegenüberstellung hinausgehende Dokumentation in Selfhtml keinen Mehrwert bringt und
                3. wir uns mit den Perl- und PHP-Kapiteln um eine Möglichkeit bringen, die vorhandene "Manpower" möglichst sinnvoll zu kanalisieren.

                Wenn jemand 1. anders als ich sieht, ist die Diskussion müßig. Sofern noch nicht ausreichend Dokumentation vorhanden ist, dann immer her damit.

                Auch zu 3. kann man von einer anderen psychologischen Annahme ausgehen und sagen: "Wenn wir die, die nur PHP können, 'aussperren' dann gehen uns womöglich Leute verloren, die irgendwann auch zum Rest beitragen." Das ist aber halt auch nur eine psychologische Theorie, die vielleicht stimmt - oder auch nicht.

                Ich messe der Sache aber nicht so eine große Bedeutung zu. Wenn Perl/PHP jetzt mal drin sind, ist das sicher kein enormes Problem. Schade wäre es, wenn man einmal auf eine konsolidierte Download-Fassung oder auf das Buch verzichten müsste, weil die Redaktion das drin haben will, aber der Inhalt dieser Kapitel unvollständig, fehlerhaft, uneinheitlich o.ä. ist.

                Grüße
                Bernhard

                1. Hallo,

                  Es scheint mir, wie gesagt, wenig sinnvoll, zu einem bereits ziemlich gut dokumentierten Produkt wie PHP nochmal eine redundante Doku aufzubauen.

                  da wird dir hier vermutlich niemand widersprechen, aber ich glaube, du hast das auch falsch verstanden. Ich denke, es geht nicht darum, im SELFHTML-Wiki nochmal das PHP-Manual zu duplizieren. Aber es wäre durchaus sinnvoll, dem Interessierten ein paar Kapitel über die *Verwendung* von PHP, über bestimmte häufig vorkommende Aufgaben und Techniken, sowie über das Zusammenspiel von HTML, Javascript, PHP und HTTP an die Hand zu geben.

                  Wenn hier also das Schlagwort "Serverseitige Techniken im SELFHTML-Wiki" fällt, dann verstehe ich das so, wie eben angedeutet. Um Einzelthemen weiter zu vertiefen, existiert genug Material im Web.

                  Meine grundlegende Einstellung ist halt, dass

                  1. serverseitige Technologien schon genug dokumentiert sind

                  ACK. Aber deren Verstrickungen mit anderen Techniken, der interdisziplinäre Aspekt, kommt in der Doku oft zu kurz.

                  So long,
                   Martin

                  --
                  Nicht jeder, der aus dem Rahmen fällt, war vorher im Bilde.
      2. Nur mal grundsätzlich: Mit der Öffnung der Weiterarbeit als Wiki wollen wir durchaus auch, dass sich die "Community"[tm] an den späteren Entscheidungen mit beteiligt.

        Ok, also hier nochmal zur Sicherheit meine Positionen:

        PRO Buch
        PRO Downloadversion
        PRO Versionsnummerierung

        OK und Hier meine Meinung:

        PRO Open WIKI
        PRO Modularisierung
        PRO statische Versionen von Modulen
        CONTRA irgendwelche Limiten, welche Buch oder statische Versionen einem Wiki aufzwingen. ich bin für den Mehrwert des Wiki.

        contra serverseitige Technologien (in einer konsolidierten Fassung)

        PRO Serverseitige Technologien.
        In modularisierten Editionen ist das durchaus möglich.

        Obsolet finde ich so etwas wie Selfhtml 10.0

        Es drängt sich wohl eher so etwas auf wie
        SELFHTML:GRUNDLAGEN-2011
        SELFHTML:HTML/CSS-2011
        SELFHTML:JAVASCRIPT-2012
        SELFHTML:Perl/PHP-2012

        Bitte um Hinweise, falls das Forum nicht der passende Ort für diese Diskussion ist.

        Allgemeine, nicht Artikelspezifische Diskussion zum WIKI ist hier immer richtig.

        mfg Beat

        --
        ><o(((°>           ><o(((°>
           <°)))o><                     ><o(((°>o
        Der Valigator leibt diese Fische
        1. Hi!

          PRO Open WIKI

          Weiß nicht, was du unter einem "Open WIKI" verstehst.

          PRO Modularisierung

          Könnte ich mir gut vorstellen.

          PRO statische Versionen von Modulen

          Das ebenso.

          CONTRA irgendwelche Limiten, welche Buch oder statische Versionen einem Wiki aufzwingen. ich bin für den Mehrwert des Wiki.

          Kann ich mir keine vorstellen. Einheitlichkeit im Erscheinungsbild, Schreibstil etc. schadet mMn auch im Wiki nicht.

          PRO Serverseitige Technologien.
          In modularisierten Editionen ist das durchaus möglich.

          Möglich ist das natürlich. _Sinnvoll_ glaube ich aber eher nicht, und zwar aus 2 Gründen:

          1. gibt es bereits umfangreiche Dokus zu PHP und Konsorten. Wozu das doppelt machen?
          2. habe ich die Befürchtung, dass das im Wiki Kapazitäten bindet, die auf der Clientseite nötiger wären.

          Obsolet finde ich so etwas wie Selfhtml 10.0

          Nein, das sehe ich eben anders. Was mir egal wäre, ist die konkrete Bezeichnung: ob da jetzt 10.0, 2011, oder "Selfhtml Vista" steht (s.u.).

          Es drängt sich wohl eher so etwas auf wie
          SELFHTML:GRUNDLAGEN-2011
          SELFHTML:HTML/CSS-2011
          SELFHTML:JAVASCRIPT-2012
          SELFHTML:Perl/PHP-2012

          Warum kann man dann nicht sagen, dass zB Selfhtml xyz (zB xyz = 2011 oder xyz = 10.0) alle Module in der Version xyz umfasst?

          Grüße
          Bernhard

  2. Ich halte nicht viel davon, Themenbereiche zu verbieten - die potentiellen Mitarbeiter am Wiki stammen vermutlich vorwiegend aus dem Web-Umfeld.

    Wenn man die Themen künstlich einschränkt - so wie das die deutschsprachige Wikipedia im Gegensatz zu anderen Wikipedias mit den Relevanzkriterien tut - läuft man Gefahr, protentielle Mitarbeiter zu frusten, wenn man ihnen Artikel unter dem Arsch weglöscht.

    Die angesprochenen potentiellen Mitarbeiter sollten alle soweit "Techniker" sein, alsdass sie mit Hausverstand beurteilen können, was thematisch dazupasst.

    Es wird wohl kaum jemand ernsthaft einen Artikel über den Kartoffelkäfer anlegen oder ähnliches - aber wenn jemand ein Tutorial über ColdFusion schreiben möchte, auch wenns niemand braucht, habe ich nichts dagegen.

    Wen das Thema nicht interessiert, der soll es einfach nicht lesen - fertig.