 Zonen drauf und so. Sehr gut. Schön, dass ihr alle da seid zur letzten Session von WorldCamp Nuremberg. Ich habe mich sehr auf dieses WorldCamp gefreut. Natürlich auch, weil ich hier ganz viele bekannte Gesichter wiedersehen wurde, das wusste ich schon vorher. Auch noch viel mehr, weil es hier ein Barbecue Restaurant gibt, worauf ich mich sehr gefreut habe. Ich war mit Dominic Schilling vorgestern unterwegs in der Stadt, haben sie ein bisschen die Allstadt erkundet, war super. Wir haben auf dem Weg natürlich auch die lokalen Sehenswürdigkeiten uns angeschaut. Hier haben wir die Nurn gefunden. Also ich nehme an, das ist die Nurn, wir sind ja in Nuremberg. Fanden wir dann gut genug, dass wir direkt noch ein Selfie dazu gemacht haben. Genau, wir sind dann weiter auf die Burg hoch. Also Nuremberg ein wirklich wunderschöner Ort, um einen WorldCamp zu halten. Gestern hatten wir schon eine Q&A. Heute freue ich mich, dass ich den letzten Slot habe, um das WorldCamp so ein bisschen abzuschließen. Fangen wir mit dem Plug-in-Verzeichnis an und starten mit einem Rückblick zu den ersten Tagen des Plug-ins-Verzeichnisses. Wer weiß, seit wann wir das Plug-in-Verzeichnis haben, seit wann gibt es das? Weißt du es jemand? Wann im Jahr 2007? Also im Jahr 2007 wurde das Plug-in-Verzeichnis vorgestellt. Es sah damals so aus, gerade kam auch Version 2.1 von WordPress raus. Davor wurden Plug-ins in Plug-in-Track gepflegt quasi. Also es gab schon ein SWN-Repository, in dem man Plug-ins hochladen konnte oder halt eben hosting lassen konnte von WordPress. Und es gab einen Track, wo man sich die Plug-ins dann runterladen konnte auf seinem Rechner und sie dann eben in WordPress hochladen und verwenden konnte. Es hat aber gedauert bis zum März 2007, bis es ein User-Interface quasi gab, das es ein bisschen komfortabel gemacht hat, Plug-ins zu suchen, mehr über sie zu erfahren. Also das hier ist die Single-Ansicht von einem Plug-in, in dem Fall Akkismen. Genau, das war im März 2007. Das Projekt wurde damals auf BBPress durchgeführt. Wer hat hier noch nie von BBPress gehört? Alle anderen haben von BBPress gehört. Das ist ja unfassbar. Okay, gut, dann werde ich das auch nicht weiter erklären. Wurde auf BBPress erstellt und hat in den letzten neun Jahren diverse Erweiterungen und Refreshes gerade im Sachen Design erfahren. Also das war dann im April 2008, also knapp ein Jahr später. Also das Ganze dann schon so aus. Wir haben ein paar mehr Plug-ins drin. Es ist schon relativ nah an der 2.7 Admin-UI auch drin. Magst du fragen? Wir können auch gerne fragen. Genau, so sah das nochmals aus. Auch hier wieder die Single-Ansicht für Akkismet. Da erkennt man auch schon relativ viele Elemente, die bis heute noch so geblieben sind, zum Beispiel das Average Rating, überhaupt die Ratings, die da drin waren. Und auch Teaser für diese Ratings, die eben abgegeben wurden. Oder wie gesagt, oder halt Support-Anfragen. Wieder ein paar Jahre später, das ist Januar 2009, habe ich diesen Screenshot mir runtergezogen. Da könnte ich da auch noch erinnern, wie das damals aussah. Also für mich war das auch so ein in den Erinnerungen-Schwellen, als ich diese Screenshots erstellt habe im Web Archive. Und was ich auch ganz faszinierend finde, war die Anzahl der Plug-ins, die wir damals hatten. Es waren jetzt noch unter 4.000, das ist jetzt 2009, 6, 7 Jahre her. Und jetzt haben wir direkt 10 mal so viel, als wir vor 6, 7 Jahren noch hatten. Download-Zahlen waren schon damals beeindruckend, so sah das Ganze aus. Da haben wir auch schon, die Reiter sieht man sehr schön, mit Installationen und Stats, die dann auch zur Verfügung gestellt wurden. Das Ganze ist immer noch im Becken, also unter der Haube sah das immer noch technisch gleich aus. Es war immer noch Bibi-Press, ist es bis heute. Es gab eine weitere Reiteration, das kommt wahrscheinlich auch bekannt vor. Da ist man wieder zurückgegangen im Design, das war Dezember 2011. So sah das dann aus und da wurden dann auch diese Header-Images eingeführt. Ja, die gibt es schon wirklich sehr lang inzwischen. Sieht ein relativ neu aus, aber die haben wir schon wirklich sehr lang. Und das sieht ja schon fast so aus, wie es heute aussieht, mit dem Unterschied, dass es inzwischen einen schwarzen Header gibt. April 2015 wurde der eingeführt. Also dieses schwarze Design. Das stimmt gar nicht. April 2015 war der Refresh von der Homepage, also dass man da diese Kartenansicht hat, wie es im Admin Installationsscreen aussieht. Das war so das letzte, was daran gemacht wurde am Plaggenverzeichnis. Ja, knapp ein Jahr her, das war kurz nachdem das neue Theme Verzeichnis auch online gegangen ist. Das war im Februar 2015. Da hat man dem Ganzen auch nochmal ein kleines Facelift gegeben und das dann zusammen vorgestellt. Genau, das Theme Verzeichnis ist ein schöner Stichboard. Wir haben damals das Theme Verzeichnis, was auch auf BibiPress lief und von der Architektur eigentlich genauso aussah wie das Plaggenverzeichnis. Haben wir genommen und auf WordPress umgezogen. Wir haben alles, oder den ganzen Code haben wir geopened. Der ist heute einsiebbar auf Metatrack. Da kann man sich das Plaggen und das Theme anschauen, mit dem es erstellt ist quasi. Damals, weiß ich noch, habe ich dann angefangen, mich in diese BibiPress-Geschichte ein bisschen reinzufuchsen und zu schauen, wie das Ganze aufgebaut ist, um ein bisschen zu verstehen, welche Struktur ich da übernehmen muss oder welche ich da neu schreiben kann. Das Ganze begann dann mit diesem Kommentar, der an dem Code steht. Da ist dann auch direkt die Motivation groß. Und so ungefähr sieht es auch mit dem Plug-in Directory aus aktuell. Es ist natürlich noch ein bisschen verzweigter, weil es noch ein paar mehr Funktionalitäten gibt. Also gerade, was das Administrieren angeht von den Plug-ins, indem man da Committer hinzufügen kann sich an die Commits, ja, die E-Message Christian machen kann, für die Commits, ist tut mir leidig. Alles auf Englisch im Kopf, muss ich immer auch Deutsch übersetzen. Genau, also man kann ja abonnieren, das war der Wort, genau, Englisch. Man kann Commits abonnieren. Solche Geschichten, das war ja im Theme repository zum Beispiel, nicht so erfahren. Ich habe euch in der Beschreibung der Session, habe ich versprochen, dass es einen kleinen Blick unter die Haube vom Plug-in Directory gibt. Ich habe da nur zwei, drei Slides vorbereitet, dass es so ein Überblick darüber, wie es aktuell aufgebaut ist. Also als Basis natürlich das SVN repository, in dem alle Teams, die Plug-ins, die Plug-in Dateien gehostet sind. Es gibt dann eine Track-Instance für die Plug-ins, in denen die Dateien sich angeschaut werden können, die Veränderungen, ja, die Change-Sets auch aufgeführt sind und in denen man auch Tickets erstellt werden können. Wie bedenkt? Fahrscheinig, genau. Auf der rechten Seite habe ich Bibepress eingezeichnet, das ist quasi der Datencontainer. Also da werden die ganzen Daten verwaltet und auch in der Datenbank noch gespeichert, also Metadaten über die Plug-ins selber. Daten, wie zum Beispiel, wer hat Commit dazu, die ganzen Geschichten, die in der Readme Text drin stehen, die werden auch noch inzwischen gespeichert, dass man sich dann direkt rausholen kann und auf dem Plug-in Verzeichnis darstellen kann. Zwischendrin haben wir Glotpress, was die Translation-Strings sich raussucht aus den Plug-ins und die in Glotpress verfügbar macht für die Translite zu übersetzen, was allerdings nicht mit Bibepress direkt zusammenhängt. Und mit Bibepress meine ich übrigens auch, dass das Frontend des englisch-sparkigen Plug-in Verzeichnissen ist, weil das auch auf Bibepress läuft. Und darauf aufbauten haben wir die Rosetta-Seiten, das heißt alle internationalen Plug-in Verzeichnissen, also zum Beispiel auch de.wappers.org.plugins, die sowohl auf die Glotpress-Translation-Strings aufbauen, die dann übersetzte Plug-in-Beschreibungen anzeigen und natürlich die Plug-ins API, die sich die Informationen von Bibepress raussucht und die an die verschiedenen WordPress-Installationen zurückgibt, die nach Updates fragen und nach Installationsfaden quasi. Das heißt, wenn ihr in eurem WordPress-Atmen-Bereich unter Plug-ins hinzufügen, glaube ich, heißt das auf Deutsch, klickt, dann schickt es eine Anfrage an die Plug-ins-API und sagt, hey, was sind denn die aktuell beliebtesten 6 Plug-ins und die API schickt dann die Antwort zurück und die werden dann angezeigt. Also alles dauerhaft basierend, genau. Ich habe vor der Session kurz angerissen, vor zweieinhalb, zwei Monaten haben wir angefangen, genauso wie das Stream Verzeichnis, jetzt auch das Plug-in Verzeichnis neu zu schreiben und auf WordPress umzuziehen. Also wir werden WordPress verwenden, ganz revolutionäre Gedanke. Und das Ganze wird dann so aussehen, dass wir statt dem Bibepress-Part dann einen WordPress-Part haben und hoffentlich ein total schönes und schnelles JavaScript basiertes Frontend haben, was sowohl auf den internationalen als auch auf den engesprachigen Seiten läuft, genau. Da sind wir gerade aktuell dabei, die ersten Schritte in der Umwandlung zu WordPress zu machen, JavaScript-Frontend, da sind wir noch ein bisschen weiter davon entfernt. Da gibt es die ersten Bestrebungen, also gibt es die ersten Wireframes über ein Design, aber es gibt noch kein wirkliches Design, deswegen habe ich euch was, was ich wirklich zeigen kann aktuell. Wir sind aktuell mehr damit beschäftigt, den Atmenbereich für Plug-in Autoren fertig zu machen und auch den Bereich für Plug-in Review fertig zu machen und ein Review Workflow quasi zu erstellen. Wie sagt man das auf Deutsch? Ich habe keine Ahnung. Ihr wisst, was ich meine. Also wenn man Plug-ins kontrolliert, das ist halt total leicht geht. Genau, das ist das, was wir aktuell so machen. Ein großer Teil natürlich wird dann auch die API sein, die dann statt auf WordPress aufbaut und sich dann statt einem Topic, sich dann einen Post holt, um die Informationen weiterzugeben. Genau. Ich habe das Thema kurz angerissen bei der Q&A, also das Thema, dass wir ein neues Plug-ins verzeichnet haben und auch was da die generellen Ziele sind. Noch mal zusammengefasst. An erster Stelle ist das Ziel des Verzeichnisses und auch die API geopened Source, dass jeder sich das angucken kann. Aktuell ist das leider nicht der Fall. WordPress verwenden ist das zweite riesengroße Ziel, das sind die beiden Wichtigsten. Daraus ergibt sich, dass Leute dann auch zum Plug-in Verzeichnisses beitragen können. Das heißt, ihr seid alle in der Lage, nicht nur Tickets zu erstellen im Metatrack und zu sagen, hey, ich finde es total super, wenn ich mein eigenes Supportform verwenden könnte, sondern ihr seid dann auch in der Lage zu sagen, okay, hier ist ein Patch, so könnte das aussehen und so könnte man das machen. Was natürlich den Leuten, die Meta unterhalten, pflegen, maintainen, das Leben hoffentlich ein bisschen einfacher macht. Aber eine Frage hin? Okay, hoffentlich ein bisschen einfacher macht. Dann ganz wichtig auch im skalierbarer Review-Prozess. Aktuell ist es so, dass es wirklich nur in der Hand voll von Leuten gibt, die ein Plug-in reviewen können. Es ist aktuell auch so, dass nur ein Plug-in... Also, dass ein reviewer nicht weiß, ob ein anderer reviewer gerade ein Plug-in reviewed sich anschaut. Also, solche banalen Probleme, im Moment haben die aktuell immer noch zu kämpfen. Und das ist natürlich mit dem Postlocking von WordPress relativ easy zu umgehen. Da gehört noch ein bisschen mehr dazu als nur das, aber das sind so die Voraussetzungen, die eben damit erfüllt werden, um halt diesen Review-Prozess zu skalieren und auch mehr Leuten genauso wie im Theme-Review zuangegeben und da ein bisschen die Last zu verteilen. Schnelleres Frontend ist natürlich ein... Zwischen all diesen Zielen ist es eher ein untergeordnetes Ziel, aber das ist auf jeden Fall ein einfacher Gewinn, den wir damit erreichen können, schätze ich. Also, gerade mit den Erfahrungen, die wir aus dem Theme-Verzeichnis oder mit dem Theme-Verzeichnis gemacht haben, wir werden eine aktualisierte API haben. Das heißt, wir können auch diese Daten nutzen, um dann das Plug-In-Verzeichnis mit Daten zu füttern, genauso wie es aktuell im Theme-Verzeichnis der Fall ist. Also, wenn ihr das Theme-Verzeichnis zum ersten Mal lädt, dann ist es noch eine Server-Ausgabe. Sobald ihr irgendein Link klickt im Theme-Verzeichnis, sind das alles Daten, die über die API geholt worden sind und die das dann halt relativ schnell aufbauen. Und ganz wichtig, ich hätte glaube ich die Punkte noch tauschen sollen, ganz wichtig ist bessere Suche auch, das ist einer der Top-Anfragen, die wir bekommen, also einer der wichtigsten Anfragen, die wir bekommen. Wir werden dazu... Ja, also, die Suche ist was, mit sich zwei meiner Kollegen schon mitbeschäftigen aktuell und da auch relativ weite Fortschritte schon gemacht haben, die verbessern, nicht nur Wordpress zu verwenden, sondern eben Elastic Search zu verwenden, um dann schneller und einfacher, bessere Suche-Ergebnisse zu bekommen und das Ganze den Leuten dann schöner vortragen zu können. Also, ich hoffe, da wird es eine erhebliche Usability-Verbesserung geben. Genau. So sieht das Ganze aus, von wegen unter der Haube, also so sieht das Ganze aus, wenn es dann eines Tages mal fertig ist, hoffentlich werden wir einen Plug-in-Directory-Theme haben, ganz unten, was so das Frontend darstellt für den User mehr oder weniger, was auf der Plug-in-API basiert und da die Daten herbekommt. Wir haben ein Plug-in-Directory-Plugin, das ist ein Plug-in, das dieses... Wir haben einen Custom-Post-Type, der das Ganze powered, das wird alles in diesem Plug-in gepflegt, was aktuell auch schon auf Metatrack ist, alles schon open-source, ihr könnt euch das alles angucken, wie das funktioniert. Ihr könnt auch schon Tickets fallen und vielleicht freuen wir uns sprechen und dazu beitragen, wenn ihr wollt. Genau. Wir haben auf der anderen Seite den Uploader, das ist auch noch eine der größeren Änderungen, glaube ich, die wir einführen werden, ist, dass wir weggehen von einem Formular und einem Link zu einem ZIP-Datei und hingehen wie beim Thiemverzeichnis zu einem Uploader, der uns erlaubt, automatische Co-Tests durchzuführen. Genau. Und das ist dann eben dann auch die Dateien, als ersten Commit in das Repository schon mit reinzubringen, wenn ein Plug-in akzeptiert wurde, approved wurde. Genau. Plug-in SVN und Track habe ich schon erwähnt, das wird auch weiterhin so bleiben. Das Ziel ist, wie gesagt, die Hauptziele sind open-source und WordPress, welches Versionsmanagement-System wir verwenden ist für diese Iterationen am Plug-in Verzeichnis nicht wichtig. Also darauf fokussieren wir uns aktuell nicht. Jetzt habe ich gesehen, Internet funktioniert. Das heißt, ich kann euch tatsächlich die Live-Seite zeigen oder den aktuellen Stand zeigen. Ich muss euch nicht mit Screenshots abspeisen. Das heißt, wir werden eine Live-Demo jetzt machen. Ja. Ich bin auch ganz aufgeregt. Schauen wir mal, also mal hier. Zack. So, das ist die Übersichtsseite quasi des Plug-in Verzeichnisses. Ihr seht da ganz viele Plug-ins aufgelistet. Als Plug-in Autor seht ihr nur eure Plug-ins, zu denen ihr Commit-Zugang habt. Also nicht nur Plug-ins, die ihr selber hochgeladen habt und die eure eigenen sind, es gab eine Anfrage, dass es doch schön wäre, wenn man ein Dashboard hätte, in dem man einen schnellen Überblick über seine Plug-ins und den Status dieser Plug-ins hat. Das haben wir direkt immer noch mal auch. Das ist natürlich jetzt hier, seite 45. Ich habe keine Ahnung, ob das dann besser ist, weil ich sehe, gerade die Active Installs sind alle 10.000 hier. Also alle 60.000, okay. Genau. Wenn das mal live ist eines Tages, dann seht ihr auf der linken Seite im Menü wahrscheinlich nicht diese ganzen Punkte, die sehe ich jetzt nur, weil ich gerade in der Atmenrolle drin bin. Wenn ihr als Plug-in Autor da drins seid, dann wird sich das auf diesen Mein Plug-ins Reiter beschränken mit Plug-in Handbook und dem Read Me Validator, der dann auch dort verfügbar sein wird. Die Reviewer werden dann auch WP Atmen verwenden. Die haben dann eine andere Rolle, ein paar mehr Rechte, um dann eben auch Plug-ins zu sehen, die nicht nur von ihnen sind, sondern eben Plug-ins, die einen Status haben, in dem sie einen Review benötigen, zum Beispiel. So, jetzt können wir uns ja mal eins anschauen. Plug-in Name, super. Edit, gucken wir mal, ob das funktioniert. Sehr gut. Die Single Ansicht. Wir haben die ganze Meta-Infektion dann aufgelistet. Das ist jetzt für den Plug-in Autor natürlich eher sekundär. Das ist allerdings für den Reviewer viel schöner zu sehen. Als Reviewer wird man dann auch noch einen Internal Notes haben. Man wird dann die Möglichkeit haben, sich mit anderen Reviewern auszutauschen und dann Nachrichten zu hinterlassen über diese Plug-in. Auf der rechten Seite haben wir Committer. Wir können dann hier auch also in dem Fall mich zack und natürlich auch ganz einfach dann wieder entfernen. Nein, natürlich nicht. Ah, okay, nicht. Das hat auch schon mal besser geklappt. Genau. Da kannst du dann auch... Ich kann mich immer noch nicht selbst entfernen. Also, ich kann jemand anders entfernen. Machen wir jetzt mal nicht. An sich ist es egal, weil... Nein, das ist natürlich nicht leichter. Genau, und dann hat man oben rechts den Status, der dann geändert werden kann in die diversen Pending oder Close oder Rejected-State. Ich glaube, das sind auch noch nicht alle, die wir da drin sehen. Das ist eher wichtig für den Reviewer. Ich glaube, es wird dann nicht sichtbar sein für den Plug-in Autor am Ende des Tages. Was allerdings sichtbar sein wird, ist hier dieses kleine Drop-down, in dem man festlegen kann, mit welcher Version von WordPress man muss dann nicht mehr einen neuen Commit machen mit der Readme-Text, um das zu ändern bei jeder neuen Person. Dankeschön. Genau, es gibt auch noch Kategorien, gibt es noch dazu, und Tags, die werden... Plug-in-Tags ist auch noch was, wo wir an sprechen sind gerade, wie wir das machen, wir werden das wahrscheinlich ein bisschen einschränken. Und eher so machen wir bei den Themes aktuell, dass man ein bestimmtes Spektrum an Tags hat, was man für ein Plug-in kann und das eher einschränken und für den User ein bisschen einfacher zu bedienen machen, als das aktuelle Fall ist, wo wir knapp über 80.000 verschiedene Tags haben. Genau, ich glaube, das ist das... Man kann das Fronten angucken, aber das ist irgendwie nicht so sonderlich interessant aktuell. Das funktioniert und sieht aus wie immer. Wie gesagt, wir haben noch keinen Design. Das ist aktuell nur die... die Entwicklungsversion mehr oder weniger, damit man das halt nutzen kann. Genau, das ist der aktuelle Stand. So... Bam! Gut! Jetzt kann ich auch direkt durch die Slides gehen. Also Übersichtsseite und... Singlesite. Ja, jetzt ist es so, dass wir nur relativ wenig Leute sind und wir dringend Hilfe melden. Das kann natürlich gerne Hilfe sein beim Erstellen von Code, beim Feature bearbeiten, was uns aber auch schon viel weiterhelfen würde, Meinung zu teilen. Wenn ihr auf Metatrack geht, euch die Tickets anschaut und wenn Fragen aufkommen, euren Input gibt. Was ist euch wichtig? Damit wir das Plug-in-Verzeichnis so gut wie möglich machen können für auch die Plug-in-User und die Plug-in-Autoren, die das am Ende des Tages verwenden. Es gibt in Metatrack, so sieht die URL aus, eine Plug-in Directory-Component, nennt sich das. Das ist die Komponente, in der alle Tickets zusammengefasst sind, die das Plug-in Directory betreffen. Da könnt ihr euch die Tickets anschauen, die für das neue Plug-in Directory erstellt wurden und die auch die Feature beschreiben, an denen wir arbeiten. Es gibt einen Blog, dort werden Updates gepostet, wie zum Beispiel das neue Design, wie zum Beispiel, hey, wie sollen wir mit Text umgehen in Zukunft? Und da ist natürlich auch jeder Input, ist natürlich appreciated. Dankbar angenommen, genau. Und wir haben einen Chat, der allerdings zu einer Unzeit für Mitteleuropäer stattfindet, weil wir mit den Australien zusammenarbeiten müssen in diesem Projekt, dürfen. Und wir es für Sie so angenehm wie möglich machen wollen. Das findet aktuell um 1 Uhr UTC statt, das heißt 3 Uhr morgens deutscher Zeit. Wenn ihr schon schlaflosen Nacht habt, Donnerstags, das schaut doch mal vorbei. Ansonsten werde ich auch schauen, dass wir das in Zukunft auf dem Meta-Blog dann zusammenfassen und in der Summary schreiben, damit Leute dann auch im Nachhinein noch Kommentare abgeben können oder im Slack-Channel, im Meta Slack-Channel dann ihre Meinung kundtun können. Wenn ich irgendwas vergessen habe, dann dürft ihr mich gleich danach fragen. Mein Name ist Konstantin Obeland. Ihr findet mich im Web unter Obeland, also auch unter Twitter und GitHub. Ich habe einen fantastischen Foto-Blog unter konstantinobeland.it. Und ich arbeite für Automatic in einem Team, was 100% fokussiert ist auf WordPress-Core und der WordPress.org-Infrastruktur. Ich trinke gerne Bier und Whisky und esse gerne BBQ und stehe euch jetzt für Fragen zur Verfügung. Das Support-Forum bei WordPress war die Frage. Die Antwort ist ja. Da wird es auch Arbeit daran geben, in diesem Jahr sogar noch, hoffentlich, wenn wir die personellen Ressourcen bekommen, wird das aktualisiert, also die WordPress-Version wird aktualisiert. Da sind wir gerade heftiger am lobbyieren bei den Leuten, die uns mehr personelle Ressourcen zur Verfügung stellen können. Aber ja, das wird auf jeden Fall, oder wird auf jeden Fall wie WordPress bleiben. Ja, das war ja, ja, bitte schön. Wie messen wir den Erfolg bei der Umstellung vom Alten zum neuen Plug-in Directory? Ich glaube, der Haupterfolg ist, wenn die Download-Zahlen und die Aufrufzahlen nicht komplett abfallen. Das ist... Genau. Wie gesagt, das Ziel ist ja nicht, dass wir die Download-Zahlen erhöhen oder dass wir die Besuchszeit auf der Seite erhöhen, sondern das Ziel ist, Open-Sourcen und WordPress zu verwenden. Und wenn wir damit den Rest nicht kaputt machen, dann ist es schon ein Erfolg für uns. Natürlich wollen wir es einfacher zu bedienen machen. Natürlich wollen wir auch... Was zum Beispiel beim Team Directory der Fall war, war, dass wir zu JavaScript übergangen sind und die Pageload-Zeiten massiv nach unten gegangen sind, ist die Anzahl der Seitenaufrufe pro Session ist nach oben geschnellt. Also die Leute haben sich viel mehr Themes und Seiten angeschaut. Das ist was, was wir natürlich hoffen, was auch beim Plug-in Directory dann passieren wird. Wir können es natürlich nicht garantieren, aber das ist was, was wir hoffen, dass es dann eben auch der Fall sein wird. Bitte schön. Ja, das wird bestimmt... Also die Möglichkeit, was das geben, aktuell sind wir dabei... Oder ist unser Bestreben, die Feature gleichzuhalten. Also möglichst wenig Feature wegzunehmen und möglichst viele Feature beizubehalten so um. Wir haben noch keine konkreten Überlegungen angestellt, welche anderen Statistiken wir zur Verfügung stellen können und welche Sinn machen. Das ist zum Beispiel, was man diskutieren könnte im Metatrack. Genau, das ist der aktuelle Stand. Also ja, möglich, aktuell gibt es noch nichts Konkretes zu sagen dazu. Ja, bitte. Okay. Die Aussage war, es wäre schon mal mehr Kontext zu Stats bekommen könnte. Stimm mich zu. Ja, bitte. Wie werden aktuell die aktiven Installationen gemessen? Ich... Dominic korrigier mich, wenn ich falsch liege. Aber ich glaube, wenn eine WordPress-Institution anfragt bei Wapps.org, welche neuen Versionen der Plug-ins zur Verfügung stehen, dass dort der Aktivierungsstatus mitgeliefert wird und wird dadurch feststellen, bei wie vielen Seiten dieses Plug-in aktiv ist. Dominic nickt. Ja. Die Frage ist, was ist mit Multisite? Multisite Installationen werden als einen aktiver gezählt und nicht als mehr. Wird übermittelt, ob es netzwerkweit aktiv ist oder ist es pro site? Da weiß ich die Antworten nicht. Dominic, weißt du das? Nee, wissen wir nicht. Wissen wir nicht. Danke, Billgo. Morgen, nicht vergessen, Contributor Day. Wenn ihr noch nicht angemeldet seid, Zeit habt und lesen und schreiben könnt, dann seid ihr auch in der Lage, zur WordPress-Weite zu tragen. Ich würde mich freuen, euch morgen wiederzusehen. Ich werde zur Verfügung stehen, um an dem Plug-in aktiv mitzuarbeiten und neue Änderungen einzubringen. Bitte kommen morgen zum Contributor Day. Es wird mich sehr freuen. Dankeschön.