 Hello. Welcome, everyone, to the March 2018 Wikimedia Foundation Metrics and Activities meeting. I am Chuck Rostloff. I am a lawyer here at the foundation. And I'll be hosting today this month. So the theme for the meeting this month is Wikimedia beyond its beginnings. So as we all know, this all started with Wikipedia. And so we will be taking a look over the next hour at things that have been added to the Wikimedia sort of movement since then. We've come very far, and we'll talk about some of the exciting changes. Here is the agenda. I'll be welcoming, give you a brief movement update. There'll be a presentation about Wiki Voyage, a presentation about structured data on Wikimedia Commons and a Glam update, and a presentation about Visual Editor. And then you can ask questions, and we'll have time for Wiki Love at the end. So the movement update. First, we've begun to release results from research on Wikipedia readers, illustrating some of the reasons why people read Wikipedia. Launched autosave edits feature. And the foundation has released its latest transparency report, highlighting requests received from July to December 2017 to alter or remove content. Coming up in April, there is the Wikimedia Conference 2018 in Berlin for Wikimedia affiliates to discuss issues. There's a survey for Wikimedia contributors and communities for this part of the Community and Engagement Insights project, and it's launching this week. And there is a Glam Wikicon conference being held in Tel Aviv in November that is now accepting submissions. So first up, we have Alexander Tsirlin with an update presentation on Wiki Voyage. Good morning. Thank you for the introduction. Let me make sure that you hear me. Can you hear me? Yeah, good. So I'm going to share some experiences that we have at Wiki Voyage. And I will be grateful if you change the next slide for me or actually one slide more. Yeah. So Wiki Voyage is a free travel guide. It has been known for quite a long time as Wiki Travel. But in 2012, the community decided to migrate and become a sister project of Wikimedia Foundation. That means that beginning of this year, we celebrated the fifth anniversary of becoming the sister project of Wikimedia Foundation. Wiki Voyage is a practical travel guide. It covers different practical aspects of travel. It tells you where to go, why to go, how to reach the destination, what to see there, and where to stay and eat. And we used to say that Wiki Voyage is written by travelers and for travelers. It means that you go on a business trip or on a holiday trip, or maybe you just go to a new restaurant in your city. You get some experience, some firsthand experience, and then you share it with other travelers using Wiki Voyage. This is one important difference from Wikipedia that we rely on the firsthand experience on something that Wikipedia considers original research. The second difference is that we do not organize our content as long texts, but we used to organize it into listings. And that's something that you see in the right part of the slide, that we have all the content structured. First goes the name of the place, then goes the address, then maybe the phone number, the opening hours, and then the text description. It's also important that our content is geocoded. You see that each listing is preceded by this colored box with the number. And this number, if you click on it, it brings you into the map. So you can see where the objects are in the city and that you can navigate the city using Wiki Voyage. So that was the very short, basically one minute, introduction into Wiki Voyage. Now let's go to the next slide. And, well, when I have seen the name of this meeting, I knew that I have to present some metrics. And so here is the metrics for Wiki Voyage. We write it in 19 different languages. And then the first line of the table, you can see the number of articles divided by 1000 for each language version. You may notice that these numbers are not very high in comparison to Wikipedia, but this is because Wiki Voyage only writes articles about travel destinations. There is a limited number of places where people may want to go. So there is some intrinsic limit on the number of articles in Wiki Voyage, but these articles are never finished in the sense that they have to be updated because some travel information changes every now and then. So we constantly have to update our articles. And this is reflected in the fact that the number of edits per article is quite high. It's basically similar to Wikipedia in the same language and it's much higher than in other system projects like WikiVersity or WikiBooks, for example. The second metrics parameter that I wanted to mention today is the number of very active editors, those editors who made more than 100 edits per month. This is a rather high threshold, but it tells you basically how many people are involved into each language version of Wiki Voyage as an active community. How many people come to the project every day to do some protein maintenance work, to do patroning of recent changes and things like that. And you see that we have some substantial number of contributors in five language versions, but in all the other language versions, we have the numbers between zero and two. So there are maybe one or two people who are interested in the development of the project, but they feel quite lonely because they don't really have a community to share and to discuss. And we felt it is a problem and we tried to get some, to increase the participation in the WikiVoyage by doing some advertisement by means of the central notice and by means of organizing and editor tone. Let's go to the next slide now. This is about the WikiVoyage editor tone and I believe that many of you have seen this central notice that appeared in Wikipedia and in comments during February and the central notice invited you to make some edits in WikiVoyage. By the way, let me thank once again, Joseph, for setting up this central notice for us. We suggested that new editors make rather simple edits that they add new objects of interest for travelers and that they update information on the existing objects. The motivation was mostly interest. We tried to arrange some prizes, but you can see that only two languages managed to find some small prizes, some small souvenirs, and others just relied on the interest. Nevertheless, the level of participation was quite high and now we have the statistics for February. We can see that the number of edits and the number of editors increased between 50 and 100% compared to our normal level. I think there will be some more statistics on this right after my presentation, but now let me also mention that one month after the editor tone, we see some problem with editor retention. Basically in bigger language versions, some of the new editors prefer to stay and really see the increased number of persistent editors. But in smaller language versions, we have seen people who came to make edits in February but on 1st of March, the left. So they're still facing this problem with smaller language, smaller language versions of WikiVowage, how to attract really interested participants, how to attract active travelers. Let's go to the next slide now. Yeah, so here I basically list several other travel related projects on the web that can be considered as direct or indirect competitors of WikiVowage. So we know that many people prefer to use not crowdsourced content in WikiVowage, but they choose the commercial or printed travel guides because they believe that this information is more trustable, is more reliable than what they find in WikiVowage. Also when it comes to the writing, some people say that they prefer a more personalized writing style and therefore they prefer to leave reviews on sites like TripAdvisor or they prefer to write something in their own travel blogs and not use some community style that we have in WikiVowage. So we have quite tough competition in this field of travel related information and we have to really fight for the new readers and editors. There are several things where we believe WikiVowage is really better than others. I list these aspects on the slide. Let me explain just one of them. The fact that we have no space restrictions means that we can put a lot more content than for example the guidebooks that you can buy in the store. We can use many illustrations and we can also cover many destinations that are not so often visited by tourists. We think it's quite important because nowadays more and more people travel but they used to travel to the same places like everyone who goes to Europe wants to go to Paris or to Venice and it means that the cities become extremely crowded with tourists. On the other hand, there are lots of other interesting places you do not find in guidebooks but they're still worth visiting. For example, the photo that you see on the slide is my personal discovery from last year that's the city of Sarajevo, the rare Muslim city in the middle of Europe and that's something that you do not find in normal guidebooks but on WikiVowage we have very extensive content on the city and we really have enough information that you need to go there and to organize your visit. Still, all these advantages that we have they're mostly related to the content and that's something that we continue to develop but we also think that the technical developments are very important and that's something that I'm going to cover in the rest of my talk so let's go to the next slide now. That will be about the maps because maps are very important for every travel guide. We basically realized it from the very beginning so already in 2013 we had some simple script written by one of the community members from German WikiVowage. The script was collecting geodata content in an article and then displaying this geodata on the map. Then later on the same idea was integrated into the cartographer extension that was developed with great help by Jury Astrahant. Now if you go to every WikiVowage article you will see such a map like the one that I show on the slide so you can click on different objects you can see where they are, you can explore them, you can also click on the map markers and then you will see this photospopping conference so you can really explore the city using WikiVowage. Of course there are still many open problems with this cartographer. Extension for example, everything works very well when we have the map of San Francisco but if you try to open the same map for the city in China you will see that all the labels are in Chinese so that's not terribly useful for most of us we cannot read it which means that we have to do some language localization. And there are in fact quite a few issues with these maps and that's one of the reasons why WikiVowage was behind the maps as one of the community wish list. It's one item in the community wish list from last year and we really hope that this direction will be continued because every travel guide heavily relies on the maps. Another aspect and this is the subject of the next slide. Yeah, could you change the slide for me? Thank you. Yeah, so another aspect is about using the structured data not in the sense of structured data on comments but also in the sense of having some data that we use stored at WikiData and then shared between different languages. For example, we have information like prices or opening hours and this is the obvious data to be stored at WikiData and shared. But of course we have to make sure that our editors can easily update this information because it changes this time and it has to be updated. We actually try to develop this using the so-called listening editor which is the visual tool for editing individual parameters of the listing. Something you can see on the slide that if I click on the small edit button next to the listing I open this table and in this table I can see all the different parameters. This is a German version so I already think it's in German and then I can edit any of these parameters independently and this is very useful for new editors who do not want to work with the standard Wiki markup. So now we try to connect this to WikiData and you see that some of the fields are already coming from WikiData but there's still quite a long way to go. Arrange all the necessary features and well in fact we are curious if the situation can be similar to the maps if someone else may be interested in similar functionality and if we could do something together because this feature will be very useful for all Wiki voyagers. So finally let me mention a few other aspects that will be the last slide. Hope you can change it for me. Yeah, here. So here I would like to mention just one feature the mobile application, the mobile app. Well nowadays we all use information on smartphones and storing the text content in smartphone is one thing but for travel we need not only the text, not only the travel guide itself but also the map. So we need some way to simultaneously download maps and travel guides into smartphones and we think that if such a solution would be created then it will be rather unique because nobody offers anything like that on the travel market. And this is something that this could be a very efficient way to use the content of WikiVoyage and then if more people use WikiVoyage then also more people come to edit WikiVoyage. So okay now I think my time is running out. I would like to stop here. There are a few points mentioned as summary. We have some technical developments that started on WikiVoyage. It's related to the cartographer extension and also to the VTDate page banner. We hope that we can also do more in the future and I would be happy to answer your questions. Thank you. Thank you very much Alexander. Next up we have Joseph Seddon from Advancement to talk about central notice. Yeah so this is just to follow up on what Alexander just discussed. So as we was mentioned we used a central notice campaign for this editathon whereby we were showing banners on Wikipedia and other projects and directing people to WikiVoyage. Next slide please. So it's no surprise that when you even use a fraction of Wikipedia's traffic to showcase a small project to readers that it has a huge impact on its ranking. In terms of wikivoyage.org's collective Alexa rank it increased from 24,000 to 15,000 for comparison WikiTravel has a Alexa ranking of around 10,000. Next slide please. So the more interesting thing is that this campaign has had a long-term effect potentially on the readership of WikiVoyage post-campaign. On both mobile and desktop we saw significant increases on the number of readers paid views on WikiVoyage editions. I'd be apologize if it meets the one. Sorry about that. And this increases are persisted three weeks after the end of the campaign. Next slide please. As you can expect daily unique devices also increased on this is just information for the English WikiVoyage 10% increases in terms of daily unique devices. The interesting thing is that the new readers that were coming onto the site were actually reading more page views now. And so overall engagement with the site has also increased by 14% in terms of page views per unique device. Next slide. So this was entirely an accidental discovery. This means that we have a lot more questions that we need to look into. Are these readers going to be persistent in terms of their staying power? Is this accumulative of effects that we can build up over a period of time? Are these just simply lapsed readers that we're bringing back into the project? And we need to kind of examine whether there's any kind of ceiling effect. And so the next step will be in conjunction with the WikiVoyage community is that we're going to rerun this in a more focused and controlled experiment. We're going to focus on reader engagement. We're going to split this up into two cohorts across two different experiments. And that will really examine whether there is a long-term possibility of being able to bring smaller projects like WikiVoyage, like WikiNews, more into the mainstream, increasing their readership and hopefully providing more sustainability for them in the future. Well, thank you very much. Next up, to kick off this presentation on structured data on Commons, I'd like to have Amanda Bittaker. She's a program manager. You can click her as well. I mean, you can do the clicking if you like. So yes, I am Amanda Bittaker. I'm the program manager for structured data on Commons. I'm actually here just to give a super brief intro about the program in general before Sandra, one of our GLAM strategists, shares a bit about the research that we've been doing and especially the GLAM generative user research that Jonathan Morgan and the structured data on Commons team did about one of our key audiences, GLAMs. So the program in general is about making Commons more used by making it machine-readable, right? We want to make media and metadata easier to upload, edit, find, and reuse, overall goal. And the way that we want to do that, the changes that we want to see are these five things. And notice one of them is satisfy the GLAM use case. So GLAMs share a lot of quality educational content on Commons and we want to make sure that as we're making all these changes on Commons, we're considering their needs and what works best for them. And so Sandra is going to share a little bit about the process that we're using all the way through the generative user research that JMO did through how that is, how we're incorporating that into our product design decisions. So Sandra, are you online? I am very ready. I hope everyone can hear me well. Thanks Amanda for the introduction. I'm Sandra, I work as GLAM Wiki strategist for the structured data on Commons projects. In this slides, you see a very random but still quite representative sample of the kind of content that GLAMs contribute to Wikimedia Commons. In 2009, approximately the GLAM Wiki movement as you could call it started, collaborations with GLAM institutions, cultural institutions with Wikimedia volunteers. And today from the 45 million files that we probably have on Commons, we know that several millions of them have been contributed through collaborations with cultural institutions around the world. So they contribute the diversity of files from historical photographs to scientific specimens. On the bottom left, you see a big heart. If you were wondering what that red block would be, digitized book scans, maps, historical maps, long form documentary videos. We have cultural institutions who contribute historical newsreels, et cetera. Two also more STEM materials, including 3D models and medical research slides. That's the very pink thing at the bottom is a medical research slide. I think it's a scan of some kind of fires. I'm not very familiar with the exact content of that. But that shows a bit, you know, the breadth of what GLAMs contribute to our content and content that is also very broadly used in illustrating our Wikimedia projects. So GLAMs are a very important target audience for structured data on Commons, especially also in the long run, we hope to see much more broad and diverse contribution to Commons through them. Next slide, please. So quite at the beginning of the structured data on Commons project, we wanted to know very well what this target group of ours, what this audience really needs from Commons. And as Amanda said, when she introduced the project, Jonathan Morgan and Nihara Kavet from the research team at Wikimedia Foundation have done some very thorough research on GLAMs and their needs on what with regards to Commons. How do they currently use Commons? How do they do uploads? How do they collaborate with our volunteers, with our affiliates? And what are the pain points and the difficulties they encounter? The research itself started, in fact, in February 2017, when a group of European GLAM wiki coordinators from European chapters and affiliates gathered in Paris. This group came together and talked about, you know, the first steps that should be taken for such a research. And then by the last quarter of last, not fiscal year, but 2017, so from October till December to 2017, Jonathan did thorough interviews with GLAM staff members, so not really community members, but also people working for GLAMs from five continents, quite diverse group. And following that, we also did a survey that was advertised through a lot of the typical GLAM wiki channels that cuts more than 100 responses. And that resulted in quite rich research results that I will talk about a bit later. One of the things we also did, and especially Niharika worked on, that is we created personas that are kind of, you know, average, kind of randomized or anonymized, typical GLAM contributors. For instance, on the right of this slide, you see the persona of Sammy. She is a young wiki media resident still trying to get familiar with our community and the persona shows what kind of activity she does on Commons and what kind of difficulty she encounters with that. Next slide, please. One thing we did together with the research, when the research itself was happening, when the interviews were being conducted and the survey was running, was to map out the typical workflows that GLAMs do on Commons. And that's a quite complicated workflow. I won't go too deeply into that. It's also something that is not documented on wiki yet. It's still in internal documents, but I think it's quite valuable through these interviews that we analyzed and through, you know, the context that we have in our own experience. We now have a quite precise idea of the kind of different steps that GLAMs do when uploading and reusing content from Commons. And that's something that we can use in the project. Next slide, please. Another step that we did is we took the research results that Jonathan very well summarized on Meta. And we went through them in quite a lot of detail. So we analyzed the research results very thoroughly. And what we did is we summarized them in a very big spreadsheet, which we lovingly called the list of pain. In fact, a list of pain points and difficulties that we broke down into different categories. And with our whole team, we took quite a few hours to go through that list very thoroughly and to assign the different difficulties, the difficult pain points encountered by the different types of GLAMs and to assign them to the specific teams, either product team or the outreach team and people like me, GLAM strategists. So at this moment, you will see some fabricator tasks if you're into that popping up that are quite closely related to the findings that have been discovered in the research. Next slide, please. Just for fun, this is a very small selection of our list of pain spreadsheets, which shows how we broke down all the points that were outlined in the research, the difficulties that GLAMs encounter and how we analyze them, they determined whether they were in project scope, not in project scope and who within our teams would tackle them. Next slide, please. So what's next? I guess that's probably the most interesting parts. We could build upon quite solid research and as I hope I could demonstrate, we analyzed the research quite well and I hope as a team, we could process them quite well. For my work as a GLAM strategist, this has quite direct consequences and for instance, the work that we'll kick off in the next quarter. From April on, we will start, for instance, doing pilot projects with GLAM institutions and weak comedians and affiliates. One of the things that came out of the research as a pain point, as a general pain point for both GLAM contributors to comments but also for volunteers contributing to comments is the severe lack of documentation. And that is of course only going to get more complex and worse when Wikimedia Commons is being converted to structured data and when new technology is introduced there. So there will be a very big need for documentation and for good examples on how to use this new technology. So one of the things that I will be focusing on in my work as a direct result of the research being done in the previous quarters is to go look for very good pilot projects, diverse pilot projects that highlight all the new ways in which structured data can be used on Wikimedia Commons in the future and to document this very well. That's one thing you will see coming when you follow the project. Next slide please. A second problem that we saw and it's a quite complex problem is in fact, GLAMs have a hard time translating the data that they have to run in their own databases to Commons. GLAMs have diverse ways to describe things. If you're familiar with libraries, libraries tend to use for instance, Mark as a meta data format, archives have their own formats, museums have their own ways and to describe things in their databases. And that is often we notice a very hard thing to map to the way that media is being described on Wikimedia Commons. So this mapping is a difficult, a pain point you could say. Another thing that I will do in response to that, also discovered in the research is to work on mapping the GLAM meta data schemes, the most typically, most broadly used meta data schemes and meta data standards in the GLAM fields to Wikidata and to Wikimedia Commons to make sure that in the future through structured data, the upload process and the reuse process will become smoother than it used to be. Next slide, please. And this is a conclusive slide. This was just a very thin slice of all the work that is going on in structured data on Commons. It's just about the GLAM work. If you're interested in more of the things that are going on, please go to Commons itself, search for structured data. You will find our information page about the project with lots of FAQs and information materials. And we do have a pretty nice newsletter that is sent out every two or three months, which will keep you up to date about the project. Thank you. Thank you, Sandra and Amanda. Next up, to talk about the past, present and future of Visual Editor, we have Ed Sanders, Principal Software Engineer on the editing team. Hello. Can you get my slide shared? Okay. Yes, I believe we are seeing the slides. Good, we're good to go. So hi, I'm Ed Sanders, the lead developer of the editing team, and I'm gonna talk to you a bit about the past, present and future of the Visual Editor. So I thought I'd start with this quote that I think really nicely summarizes how far we've come with the editing experience. For a lot of people who've been editing since the early days, Visual Editor is still seen as a fairly recent development. And they still do most of their work in WikiText. But I think enough time has passed now that we have a whole subset of the community who won't have known of Wikipedia without Visual Editor. And it's been their primary editor since day one. So I thought now would be a good time to look at how our communities have changed since then and the effect that Visual Editor has had. So going back to day one, here's how that team looked when I joined. I've mostly just included this slide so we can wonder how Rowan hasn't aged a day. But more importantly, this is how Visual Editor looked back in 2013 when I joined the team. Over the next four months, leading up to our first rollout before Wikimedia Hong Kong, it was, we improved on this a lot. We added supports for images, templates and references and other bits and pieces. In our testing, we were already seeing a very low rate of bugs resulting in bad WikiText and the editor was released as an optional feature. But when we multiplied that very low rate by the number of users on the English Wikipedia, it resulted in a fairly reasonable amount, reasonable addition to an already strained review queue. So understandably, a lot of users weren't happy about it. But over the next few years, we fixed many of those bugs and added some indispensable features such as table editing and automatic citations. We worked with newer communities who are happy to use this tool to attract more users and weren't facing the same struggles with backlogs that the large communities were. Importantly, we weren't in a hurry to force Visual Editor on the communities that have pushed back. And eventually this paid off. Two years ago, the German Wikipedia, the second largest Wikibike activity formed this Visual Editor Appreciation Society and organized amongst themselves making Visual Editor the primary editor on the site. That was a huge turnaround from just a few years ago when they were writing site code to forcefully disable the editor. And I think is a real testament to the hard work the team put into the product. This table shows us that 16 of the top 20 Wikipedia's are giving Visual Editor as the primary editor to new users. It's also available as the secondary editor on those other sites. In fact, out of about 300 Wikipedia's, only three communities are not making Visual Editor the default action. There's another nine, including Chinese, that are held back because of language variant support. It's also worth calling out the Japanese, Korean, Arabic and Farsi from this list as they are a few of the 55 Wikis where Visual Editor is the only editor we present to new users. And it's actually not hard to see why because Wikitext can be even harder to read in languages that don't use Latin script as Latin script words are still used for tags and far names on those Wikis. And it's especially bad on right to left Wikis. This is a snippet, so I'll just wait for that slide. This is a snippet of Wikitext from near the top of a featured article on Arabic Wikipedia. So this is very typical. I highlighted in green a ref tag. And as you can see, it's all over the place. And even one of the angle brackets is flipped. This is not a bug. This is actually how it's supposed to look. Please direct your rage at Morial who I'm sure will be happy to explain why this is all perfectly logical. But even in English, let's not forget how off-putting Wikitext can be to new users. Before we launched in 2013, we did some user testing with a group of users we thought were qualified to be great editors that hadn't edited before. I encourage you to look up the videos, but here's some highlights from the transcripts. So this is their first reaction to seeing Wikitext. These are people with advanced degrees who'd be great contributors. And another one. But one look at the Wikitext and they thought, this isn't for me. There was a study done in 2015 that I think a few of us will be familiar with which showed that giving people Visual Editor didn't improve the edit success rate for new users. There was a problem with this result in that it was only looking at people who signed up and at least tried to make an edit. So it did exclude people who simply clicked edit and immediately were put off by what they saw. So what I want to show you now is the raw data we've been collecting since then for all users interacting with the different editors. This is simply the success rate of editors making their first edit in Wikitext versus Visual Editor. As you can see, the difference is quite striking. And if we zoom out, you can see the comparative success rates for people who've made more than one edit, more than five, more than 10 and so on. You can see that over time, the success rates of the two editors rise and converge which is what you'd expect as users become more experienced. But crucially, we're seeing much better success with new users. So it's no surprise that we see Visual Editor as the recommended tool in editor-thons. Here are some lovely quotes from people who've run editor-thons recently. It's really great to see our tool making such a big difference in this process of getting new people into editing. The other thing I'd like to talk about is technology and research. When you put a lot of effort into solving hard problems, you often end up with a lot more than you set out for. For example, we all know the space race didn't just put a few people on the moon. NASA ended up inventing things like Tang, Velcro, and Teflon, right? Okay, maybe not. But they did invent a bunch of other things. Oh, and while we're on the subject of NASA, I did hear recently that NASA's EVA team are using Visual Editor on their Wiki and it's really helping with adoption. The more people we can convince to use Media Wiki in this way, the better technical feedback we'll get back from the community. So what I'm trying to show here is that there's a whole technological ecosystem around Visual Editor. On the right, you can see Parsoid, which is the new Parso we had to build to make Visual Editing possible. And that in turn has made projects such as content translation possible, as well as other improved services like the mobile content service. Visual Editor has also been embedded into other projects such as structured discussions, which is really lowering the barrier to participating on talk pages. On the left, we have some code that started off in Visual Editor, but has since taken on a life of its own. Visual Editor had to create a new UI library to meet its complex demands, which we called VE UI, very imaginative. And that then became OUI. And now that project is bringing improved accessibility, right to left support, improved widgets and consistent UI to projects across the Media Wiki platform. We've also recently been working on Visual Diffs because naturally, you'd expect to see a Visual Diff when you make a Visual Editor. That project was possible because of Parsoid and Visual Editors' improved modeling of the document, and that work is being upstreamed so that it can work outside of Visual Editor on history pages. Let's not forget the technology developed for Visual Editor itself, the Link Inspector, one-click citations from a URL, a usable template, table editing, image searching, and other bits and pieces. So I also want to talk a bit about the future. Occasionally, some of my friends ask me, hey, isn't that project you're working on Wikipedia finished now? And then I taught their era off for half an hour until they regret asking. So there you go. One of the things we've always had under development is mobile support. We took some technological steps early on to ensure the editor would work on touch devices, as opposed to say Google Docs where they took an approach that forced them to build native apps. And we've also stuck to some design principles throughout, such as avoiding interactions based on mouse hover. There's still a lot of work to fit more of the UI into that limited space and work out which tools to present to the user when. But we're in a great position to get this version of Visual Editor out of beta and made the primary editing experience like we did on desktop. By the way, some of you will have noticed the article I'm editing is about a roller coaster at Disneyland, and the very eagle eye might have spotted that I'm sitting on said roller coaster. I'm fully expecting that extreme Wikipedia editing will be the massive trend. Another thing that we've been working on recently is unifying the editing experience so that the hard work we've done improving the usability of the editor is available to Wikitext editors too, things such as those one-click citations. This should also help new editors make an easier transition to using Wikitext when there need arises. This is still in beta, and hopefully a lot of you will have had a chance to use it on OfficeWiki. And there's still plenty to do on features, performance, and general bug fixing. And finally, looking a little further into the future, another thing that we talk about a lot on the editing team is the potential for multi-user editing. Some of you will know that C Scott has spent the past three or four Wikimaniers talking about the implications of this with the community. And whenever we've given proof of concept demos at Hackathons, we've gotten a very enthusiastic feedback from the community. We've always designed Visual Editor in a way that makes implementing this not too difficult. And some of the work we've done recently on Autosave, which was mentioned at the top, will make this even more feasible. So in summary, we really have come a long way in the last few years, especially in how we're perceived by the community. And we're now the primary editor for a significant portion of the community. The edit success rate is especially great for new users, which is exactly what we set out to do with this project. And we've built a stable and extensible platform for the future. And in doing so, we've seen work from the Visual Editor team spreading out across the organization. We've also got a lot of work in the pipeline and no shortage of ideas for the future of editing. Thank you very much. Thank you so much, Ed. We now have quite a bit of time actually for questions and discussion. So if you are here in the room with me and you have a question, there's a microphone right there. And if you are remote there, we are taking questions on IRC. Do we have any yet? We currently do not have any. Ah, you're real. Yeah, I have some, can you guys hear me? I have some good news for Alexander about the maps. He mentioned a number of problems with maps, having to do with internationalization. It's actually true that right now maps only display the labels on the map in the language of the territory map rather than in the wiki where the map is. And he mentioned the community wish list item about maps and I'm happy to tell him that, and everybody, that collaboration team is working on those very problems. And we should actually be able to release that internationalization improvement in a couple of weeks. And we're working to make maps in general more stable and easier to maintain. So I'll reach out to Alexander and talk about that offline, but I just wanted to make that, make his day, I hope. That's great news. So, Ed, I've got a question slash response for you from Erin. So first a correction, then a question. We did look at edit completion rates in the 2015 study. And at that time the rate of edit completions decreased compared to the control wiki text only. Has there been a controlled study since then that demonstrates the higher edit completion rate you said you were seeing? Yeah, thanks. So yeah, I know that that study did look at the edit completion rate. My point was that it ignored data, ignored people who abandoned before they even typed. And so our raw data is looking at the total edit completion rate for all users. That's not a randomized AB trial like Erin's test was, but it does include everyone, whereas the original trial filtered out the people who clicked on edit and then abandoned straight away, which I thought was, which was kind of one of the things we were aiming for in the first place though. That's why I highlighted that study compared to the other data we have. Thanks. Do we have anything else? Questions about structured data on comments or wiki wage? Okay. If that's it. Where are you in London? Yeah, I didn't mention I'm in London. This is, well, this is where I live. This is the home of football. Oh. This is you on, you want to include in on that. That means it's the home of Arsenal Football Club. If there was a game when it'd be really nice to let up, but unfortunately you can just see the glow from the lights feeding the grass. Okay then. We have, I think something changed here. Could you advance the slide? Because then we have some time for wiki love. If anyone has any sort of shout outs or thanks or just expressions of gratitude or appreciation that they would like to share about anyone. Now is your opportunity to do so. I'd be happy to bring a microphone to you, which one? I just want to say I do love visual editor. Yay. And I love whoever that was. Anything else? The checks in the mail. This is Anne Gomez. I just want to shout out to Zach for being just a really great collaborator. It's been really fun working with him or you wherever you are on all the campaigns. And thank you for your positivity and your energy and your commitment to delivering. Online. Ceddin who apparently lost his mic says he loves the wiki text visual editor. It's just brilliant. And Paul says thanks for the collaboration team being ahead of expectations with the maps work. One thing that I realized I forgot to remind you all is that you can submit proposals for things to discuss in future metrics and activities meetings on I assume on meta. I encourage you all to do so. Any other wiki love. Okay, I think that's it then. Thank you all so much for attending and we'll see you next month, if not before.