Immer Ärger mit den Pageviews

Ich glaube, die Lage mit den Abrufzahlen ist komplott verfahren. Dass man durch Komemntare schreiben auf anderen Seiten nichts verbessern kann, habe ich inzwischen eingesehen. Aber oh weh, schaue ich mir die Statistik des Blogs hier an, so gehen die Zahlen sogar noch zurück, und das bei einem niedrigen Ausgangswert. Vor 2 Tagen hatte ich doch tatsächlich einen täglichen Pageview von 2. In Worten zwei: das heißt, aus dem kompletten Internet haben genau 2 Leute dieses Blog hier gefunden und da besteht noch eine hohe Wahrscheinlichkeit, dass das nur Bots waren. Und wenn man im Statistik-Menü von WordPress einmal schaut wie sie die Seite gefunden haben, so steht dort gar nichts. Offenbar ist es aktuell gar nicht möglich über Stichworte die man bei Google eingibt hier auf den Content zuzugreifen, so dass man wohl sagen muss, dass das Blog hier komplett verweist ist. Das ist nicht einfach nur ein C-Blog, das entwickelt sich langsam aber sicher zu einem C- Blog.

Auf der anderen Seite ist das weit weniger tragisch als zunächst gedacht. Denn inzwischen habe ich entdeckt, dass man sich bei Wikipedia sehr gut austoben kann und dass es dort sehr viel Traffic gibt. Im Grunde reicht es, wenn man sich einen Artikel raussucht der häufig angeklickt wird (gute Texte im Bereich Informatik haben bei Wikipedia einen täglichen Traffic von 2000 Abrufen) und diesen Artikel verbessert man einfach oder schreibt ihn komplett neu. So hat man dann Content geliefert, der wirklich viel gelesen wird.

33C3 — beste Hackerveranstaltung seit langem

Der jährliche Chaos Communication Congress hat sich dieses Jahr erneut übertroffen. Stattgefunden hat eine gut durchorganisierte Hackerveranstaltung die Maßstäbe gesetzt hat. Kritiker wie https://tuxproject.de/blog/2016/11/chaos-orchid-club-der-33c3-ein-teures-missverstaendnis/ sprechen von „abgehängter und abgehalfterter Möchtegern-„Hacker““ und das angeblich das Niveau der Veranstaltung im Sinkflug wäre. Aber das muss nicht unbedingt etwas schlechtes sein. Was hingegen zu beobachten ist, dass die Veranstalter professioneller agieren. Der Kongress wird jetzt ähnlich geplant und realisiert wie ein Popkonzert wo die Nachfrage nach den knappen Ticket marktwirtschaftlich bearbeitet wird und wo sich sogar ein Schwarzmarkt etabliert hat. Auch in der öffentlichen Wahrnehmung ist es chick geworden, auf einem Chaos Congress vorbeizuschauen. Teilweise mussten die Leute richtig viel Geld bezahlen oder aber jemanden vom CCC persönlich kennen.

Die Zielgruppe ist relativ einfach festzumachen. Es sind meist jugendliche Hipster, die einen iPhone Handyvertrag haben, sich normalerweise auf giga.de herumtreiben und vermutliche eine schnelle DSL-Flatrate besitzen und mit Apple Geräten ausgestattet sind. Und ja, diese Verflachung ist etwas gutes. Nur zum Vergleich: die ersten Hackerveranstaltung in den 1980’er bestanden aus maximal 200 Leuten, die zu fünft an einem Commodore 64 saßen — der gesellschaftliche Impact war gleich null. Heute ist das zum Glück anders: der Deutschlandfunk war mit einem Ü-Wagen vor Ort, die Tagesschau berichtet und es gibt Live-Streams auf Youtube. Den Organisatoren ein großes Lob. Man kann nur hoffen, dass der eingeschlagene Kurs beibehalten wird, und nächstes Jahr nochmehr Besucher und nochmehr Pop-Themen aus dem Bereich Netzpolitik auf den Bühnen zu sehen sind.

Die spannende Frage lautet: wie man kann das Event noch mehr auf den Massengeschmack ausrichten? Sollte man womöglich mehr in Richtung Gaming gehen? Bekanntlich gibt es innerhalb der Gaming-Branche ja auch Hacker, welche beispielsweise Aimbots schreiben, Mods entwickeln oder Independent Games entwickeln. Sowas würde auf einer Hackerparty Sinn machen.

Jabref installieren für Ubuntu User

jabref

Die Installation von Jabref in Ubuntu ist nicht einfach, aber es lohnt sich. Leider ist die Version in den offiziellen Paketquellen hoffnungslos veraltet. Viele neue Funktionen wie das Anlegen von Einträgen über die DOI Nummer sind noch nicht vorhanden. Deshalb empfielt es sich, die „.jar“ Datei für Jabref direkt von der Herstellerseite herunterzuladen (30 MB) und mittels „java -jar jabref.jar“ zu starten. Man kann auch ein Bash-Script anlegen um den Start zu vereinfachen, das speichert man in ein neues Verzeichnis namens jabref/. Dort kann man auch gleich die bibtex-Dateien selber hineinschreiben, sowie Exportfilter die man anlegt um eine Jabref Datenbank nach Wikipedia zu exportieren.

Um die Bedienung sich zu erleichtern empfielt es sich nach dem ersten Start in den Settings-General die Benutzersprache auf Deutsch umzustellen. Damit sehen die Menüs schon sehr viel mehr adorable aus und alles geht leichter von der Hand. Ansonsten kann man noch das Gruppen-Fenster einblenden um längere Literaturlisten thematisch zu unterteilen. Tja, und dann kann die Arbeit selber auch schon beginnnen. Jabref ist das zentrale Tool für Wissenschaftlicher und alle die es werden wollen, egal ob aus den Natur- oder Geisteswissenschaften, es gibt derzeit kein Programm was mächtiger wäre. Im wesentlichen sucht man sich über Google Scholar ein interessantes Paper heraus, kopiert den Bibtex-Eintrag in die Zwischenablage und erzeugt dann einen neuen Eintrag bei Jabref. Man kann so in kürzester Zeit längere Listen anlegen und wenn man dann daraus zitieren will reicht ein Rechtsklick und ein „Bibtex Key kopieren“.

Die meisten anderen Funktionen die sonst noch integriert sind wie „Online-Suche“ oder Verbindung zu LibreOffice aufbauen braucht man in der Praxis nur selten, es ist aber gut dass sie da sind. Gerade in der aktuellen Version macht Jabref einen gut durchdachten Eindruck und kann da es kostenlos ist, zur uneingeschränkten Nutzung empfohlen werden. Als kleiner Schönheitsfehler gibt es beim Starten des Programms immer eine Fehlermeldung auf der Komamndozeile die auf eine falsche Anpassung an den Java-Interpreter hindeutet.

ARBEITSWEISE
Bei der täglichen Arbeit wird man folgende Funktionen nutzen. Einmal den + Button um neue Einträge hinzuzufügen. Wenn man bereits Einträge hat und eine URL hinterlegt hat, kann man über einen Klick auf die Weltkugel das PDF aufrufen was im Webbrowser angezeigt wird. Zu guter letzt benötigt man noch die Export-Funktion um alle Einträge in das Wikitext Format zu exportieren. Und hier gibt es noch ein kleines Schönheitsproblem. Leider liefert Jabref standardmäßig keinen Wikitext-Exportfilter mit. Den besten, den ich mir selbst programmiert habe sieht so aus:

<ref name=\bibtexkey>{{cite journal
 | author = \author
 | title = \title
 | year = \year
 | journal = \journal \booktitle \organization \publisher \school
 | volume = \volume
 | pages = \pages
 | url = \url 
}}</ref>

Dieser wird in die Datei „wikicite.layout“ geschrieben und in Jabref eingebunden. Das ganze ist aber nur ein Workaround, weil einfach alle Einträge in das Journal-template exportiert werden und die Felder „booktitle usw.“ dann im Feld Journal erscheinen. Soweit kein Problem weil das in Wikipedia alles sehr gut angezeigt wird. Das heißt, die Angaben sind wenigstens vollständig und einheitlich formatiert. Ob dieser minimalistische Exportfilter bereits der Weisheit letzter Schluss ist darf bezweifelt werden. Womöglich muss hier entweder der Jabref-Programmierer oder die Wikimedia Foundation nochmal nachbessern und etwas besseres entwickeln. Bis dahin kann man mit diesem Exportfilter aber ganz gut arbeiten.

Streng genommen ist Jabref ein Editor um damit Bibtex Dateien zu bearbeiten. Man könnte das auch in einem Texteditor erledigen hätte dann aber das Problem dass man erstens nicht über einen Mausklick die PDF Datei öffnen kann und auch keine Exportfunktion in andere Formate hätte. Ebenfalls nützlich ist die Jabref Funktion die Einträge sortiert anzuzeigen was in einem normalen Texteditor nicht geht. Ich würde sagen, dass gleich nach Lyx, Jabref das zweitwichtigste Programm ist wenn man wissenschaftlich arbeiten möchte. Einmal kann man es verwenden um für Lyx Literaturdatenbanken zu pflegen aber man kann es auch einsetzen um für Wikipedia Literaturdatenbanken zu erstellen.

Edit Wars führen und gewinnen

Die Anleitung innerhalb der Wikipedia ist betont sachlich geschrieben. Da ist die Rede davon, dass Neulinge an einem Mentorenprogramm teilnehmen sollen, wo sie lernen mit der Wikisyntax umzugehen, da wird davon gesprochen bei Meinungsverschiedenheiten eine dritte Meinung zu beantragen und es wird das kollaborative Arbeiten erläutert. Trollerei, Edit-Wars und Vandalismus sind hingegen verpönt. So der O-Ton in der Hilfe.

Wer als Neuling jedoch Bekanntschaft macht mit Wikipedia wird erkennen, dass die Hilfeseiten nicht die Wahrheit berichten sondern von einer Utopie ausgehen die sich so in der Community nicht wiederfindet. Die Realität bei Wikipedia ist, dass diese Community konfrontativ angelegt ist. Der Normalfall ist es, dass sich die Leute anschreien, Edit-Wars führen und auf Konflikteskalation setzen. Die Frage ist weniger wie man einen Edit-War vermeidet sondern die Frage ist, wie man ihn so führt dass man ihn gewinnt. Das soll im folgenden beschrieben werden.

wiki

Zur Veranschaulichung soll die obige Abbildung dienen. Dort ist der selbe Absatz auf drei unterschiedliche Weise formatiert. Einmal als Rohtext, dann mit sogenannten Inter-Wiki-Links und zum Schluss in seiner endgültigen Version. Man kann diesen Absatz mit Munition vergleichen, die man in einer Schlacht benötigt um den Feind zu bekämpfen. Jeder Absatz besitzt eine unterschiedliche starke Sprengkraft. Der Absatz 1 ist relativ schwach. Wenn man ihn zu einem vorhandenen Artikel hinzufügt, wird es vermutlich einen Löschantrag geben. Die Prognose lautet, dass nach spätestens 1 Stunde ein Admin vorbeikommt, kommentarlos auf den Revert Button drückt und den Edit damit rückgängig macht. Wenn der Admin einfühlsam ist, schreibt er noch hinzu „fehlende Belege“, was nur ein kleiner Trost ist.

Die Variante 2 des Textes ist schon ein wenig effektiver. Immerhin wird auf weitere Wiki-Seiten verwiesen. Dadurch wird Sinn erzeugt. Es werden bekannte Stichworte in einen neuen Zusammenhang gebracht. Hier ist die Wahrscheinlichkeit hoch, dass der Absatz zumindest toleriert wird, wenn er Teil von einem guten Artikel ist. Er wird entweder gar nicht gelöscht oder erst nach 2 Wochen entfernt weil jemand einen besseren Vorschlag hatte.

Um einen Edit-War mit der maximalen Wirkung zu führen muss man Absatz 3 verwenden. Dort sind nicht nur Inter-Wiki-Links gesetzt sondern es gibt auch noch Literaturangaben. So ein Absatz kann man nach dem Fire-and-Forget-Prinzip in eine Schlacht einbringen und er wird in dem Artikel auch noch in 2 Jahren unverändert drinbleiben. Er enthält keine Rechtschreibfehler, keine inhaltlichen Fehler und ist ausgezeichnet durch externe Quellen abgesichert. Diese verweisen auf Dokumente, die über Google Scholar gefunden wurden.

Umgangssprachlich ist Absatz 3 gleichbedeutend damit jemanden anzuschreien. Anstatt jedoch ALLES IN GROßBUCHSTABEN ZU SCHREIBEN, nutzt man bei Wikipedia die hochgestellten Ziffern. Das Ziel ist dasselbe: es geht darum die Gegenseite niederzubrüllen. Wer diese Strategie einsetzt wird im Regelfall Edit-Wars dominieren, das heißt wenn jeder der Anwensenden einmal auf den Edit-Knopf gedrückt hat, bleibt am Ende der Text stehen der am lautesten war.

Die Kunst besteht darin, laut zu schreien dabei jedoch nur wenig Aufwand zu treiben. Eine Methode wäre es, wenn man einfach hochgestellte Ziffern nach belieben verteilt und sich die Quellen ausdenkt, also etwas zitiert was gar nicht da ist. Doch leider wird dieser Trick ähnlich schnell erkannt werden als wenn man Plagiate nutzt. Die einzige Methode wirklich zu schreien besteht darin, „unique Content“ zu liefern. Hier haben Ghostwriter einen Startvorteil, weil sie ohnehin das Arbeiten mit Quellen gewohnt sind. Wenn ein Ghostwriter bei einem Edit-War beteiligt ist, kann er einerseits sehr laut schreiben (also mehrere Absätze mit unzähligen Fußnoten erzeugen) gleichzeitig jedoch in relativ kurzer Zeit.

Ghostwriter zeichnen sich dadurch aus, dass sie im wissenschaftlichen Arbeiten geschult sind, bereits mehrere Dissertationen geschrieben haben und Literaturverwaltungsprogramme wie Citavi oder Jabref einsetzen. Auch verfügen sie über ein hohes Allgemeinwissen und können sich in neue Themen schnell einarbeiten. Es ist anzunehmen, dass die derzeitige Wikipedia überwiegend aus Ghostwritern besteht. Diese müssen formal nicht über mehr Rechte als normale User verfügen, auch hinter einer anonymen IP Adresse kann so ein Ghostwriter stecken. Schaut man sich einmal die Lebensläufe von langjährigen Wikipedia-Autoren an, so wird man als Gemeinsamkeit erkennen, dass sie sich aus dem Bereich Ghostwriter, Hochschule, Lehramt, Bibliothekare rekrutieren und mit diesem Background auch bei Wikipedia leichtes Spiel haben.

Als Märchen kann man hingegen abtun, dass Wikipedia Autoren aus dem Bereich OpenSource, Web 2.0 und freies Wissen kommen würden. Die Fähigkeiten um einen Linux-Kernel zu entwickeln unterscheiden sich grundlegend von den Fähigkeiten um eine Disseration zu schreiben. Die Bereiche sind zu verschieden voneinander. Der typische Wikipedia Autor dürfte eher mit MS-Word plus Citavi arbeiten und wenig bis gar keine Ahnung von Technik haben. Das kann man übrigens auch in der Wikipedia selber aufzeigen wo Themen wie Politik, Geschichte, Literatur überstark vertreten sind, während bei Informatik, Roboter und Softwareentwicklung es große Defizite gibt.

„German Sichtung“ in Wikipedia

Zunächst dachte ich, dass die Eigenart der deutschen Wikipedia „Sichtung“ ein absolutes Fail wäre den man abändern müsste. Für den Autor ergibt sich durch das Sichtung Features folgender Workflow. Er schreibt mit viel Aufwand einen Artikel, drückt auf Upload und dann passiert gar nichts. Der Artikel hängt in irgendeiner Warteschlange und erst wenn jemand der Admins vorbeikommt die Sichter-Status haben und sein OK gibt, gelangt der Artikel in den Live-Betrieb. Konkret kann soetwas bis zu 10 Tage dauern. Es gibt sogar eine Statistik, wonach man teilweise bis zu 40 Tage warten muss. Und was besonders anstrengend ist, dass es auch keinen Counter gibt, wie lange es noch dauert.

Aber, ganz so schlimm wie zunächst angenommen ist das Sichtung Feature auch nicht. Zunächst einmal werden die meisten Artikel innerhalb von 24 Stunden gesichtet was in der Praxis keine große Verzögerung darstellt, und wenn es dochmal länger dauern sollte, kann man auf der Seite https://de.wikipedia.org/wiki/Wikipedia:Redaktion_Informatik/Sichtungslisten nachsehen wie lange es noch dauert. Dort steht zwar nicht direkt, wann der Artikel freigegeben ist, aber der eigene Artikel taucht in der Liste auf und man kann zählen wieviele Artikel noch davor sind. Bei mir waren es vor 2 Tagen noch 134 Artikel die davor waren, heute sind es nur noch 100 und so kann man ungefähr abschätzen wie schnell oder langsam der Sichtungsprozess vonstatten geht.

Was da genau während der Wartezeit passiert ist ein Geheimnis. Vermutlich wird da gar nichts passieren, am Ende drückt einfach irgendwer auf den OK Button und das wars dann. Kritiker sagen, die ganze Prozedur ist reine Schikane gegenüber den Autoren und in der englischen Wikipedia gibt es sowas gar nicht. Auf der anderen Seite ist der ganze Ablauf durchaus spannend. Wikipedia gibt sich offenbar Mühe, dass die Autoren immer bei Laune gehalten werden. Das heißt gleich morgens kann man nachschauen wieweit die Sichtung schon ist und wenn dann irgendwann das Ok kommt kann der Tag gleich viel angenehmer beginnen.

Ich will zwar nicht unbedingt sagen, dass man das Sichtungs-Feature behalten muss weil es einen Mehrwert bietet, aber abschaffen würde ich es auch nicht unbedingt. Es hat vielmehr für alle Seite eine Funktion und hilft dabei die Langeweile zu vertreiben. Unter der Hand gesagt: natürlich ist die Sichtungsfunktion eine Beschäftigungstherapie damit sich die Leute nicht langweilen, also typische Bürokratie die dazu dient nochmehr Bürokratie zu haben. Aber egal, ich glaube gerade US-Bürger wären enttäuscht wenn sie etwas in die deutsche Wikipedia hineinschreiben ohne dass es dort die Sichtungsfunktion gäbe.

Man kann sich das ungefähr so vorstellen: Jimbo aka Jimmy Wales besucht die deutsche Wikipedia-Niederlassung. Setzt sich dort an die Workstation und editiert an seinem Lieblingsartikel herum. Normalerweise wäre seine Änderung 1 Sekunde später online, in Deutschland jedoch kommt Jimbo erstmal in die Sichtungswarteschlange und wird dort dann abgefertigt.

Natürlich habe ich mir angeschaut ob es irgendwelche Gemeinsamkeiten zwischen Artikeln gibt die länger in der Warteschlange verbringen. Zuerst dachte ich, dass vorwiegend verwaiste Artikel davon betroffen sind, dann dachte ich dass es längere Texte wären, die länger gesichtet werden. Leider gibt es offenbar keinen Zusammenhang, vielmehr scheint es entweder Zufall zu sein oder es gibt Merkmale die darüber hinaus gehen.

Traffic erhöhen klappt nicht

Vor einiger Zeit hatte ich begeistert davon berichtet, dass man durch Kommenatere schreiben auf anderen Blogs den eigenen Traffic steigern kann. In der Tat gab es damals eine minimale Trafficerhöhung hier im blog. Inzwischen hat sich der Pegel jedoch auf den alten Wert normallisiert und wie zuvor greifen nur noch 10-15 Leute täglich auf dieses Blog zu. Das ganze hier ist und bleibt ein reines C-Blog ohne Aussicht auf Besserung. Ich glaube immer mehr, dass es wohl inhaltliche Gründe sind, die gegen dieses Blog hier sprechen. Wäre das ein Mode oder Koch-Blog gäbe es vermutlich mehr Traffic. Leider kann ich am Inhalt nichts ändern. Robotik und Künstliche Intelligenz ist nunmal das, was hier in der Überschrift steht, daran wird sich in Zukunft nichts ändern.