 It's all right and I'm going to switch over to the other tab. I'm going to go ahead and have started here with a quick intro. As Adam said, prior to the recording starting, this is the goal of this meeting is to give everyone update on where the teams within the inaccurately named reading group are with their annual plan, particular kind of status update on Q1 goals and then looking forward a couple of quarters while we're planning for Q2 and Q3. Particularly with the eye towards sort of why we're working on those things and also how the dependencies we have on each other and things that we will need. So we're going to go by a product owner and Olga is going to kick us off. So I'll go whenever you are ready. I would say go ahead and get started. Hello, everyone. Can everybody hear me? Yes. Yes. Wonderful. Cool. Well, first slide. Okay, so while a lot of the teams this year will be focusing on your editors, our goal was a little bit different. We want to better support current editors, in particular, veteran editors by bringing their preferred workflows to the mobile site. And we hope that this will make mobile contributions a little bit easier and potentially increase the rate of mobile contributions among veteran editors. And we're also working on a second project throughout the year, which is to invest in the mobile front-end and urban new front-end architecture. And this is basically a refactoring of our code so that it's easier to use for developers and so that it is ready for future architectural changes that might come. Next slide. Okay, so for our first project this quarter, we mostly wanted to focus on research to find out which pages were the most important for editors on mobile, as well as how to sort of approach how we're going to navigate those pages and how we're going to be offering this functionality. And in terms of navigation, generally making the mobile website for these users feel a little bit more familiar and feel a little bit more like they have similar options to what they would have on desktop in the rectors again. So what we did is we conducted around 30 interviews at Wikipedia. We've been working on determining the list of pages that we want to provide special attention to. We tested a couple of prototypes for the navigation and we're slowly collecting somewhat of a task force of interested editors that we can reach out to directly for feedback so they can test their prototypes, etc. In the last couple of weeks, we've also been looking a little bit more into the data that we currently have around mobile editing and around who's using what skin and why and also which pages and which special pages are being used the most. So before investing the mobile front end Minerva new front end architecture we're working on two of the epics. The first one is automate asset bundling in mobile front end Minerva and the second speed up unit unit test execution and increased code coverage and we'll also be working on those throughout the first two quarters of the year. Next slide. I have a quick question. What is the asset bundling. It sounds like there's an audit. It sounds like there's a manual process that is being turned into an automated process. Yes, and there's a lot of that in also the unit tests and there's a lot of kind of automating and basically a lot of work that will make developing a lot easier and faster, hopefully. Fantastic. I mean, I think the one like this is probably just a detail, but it might be interesting to. Add something about that in the goal itself. Like. Invest in the architecture to make it make development faster something like that. Just for. When people see they know what they know what we're doing just minor detail. To consternation. You're talking about like on the wiki itself right or where the school is described. Making sure that that outcome of. Yes. Oh, good. Did you hear that? I think you probably might be. Yeah, I can take it. All right, I'll take it. I can take it offline. You guys still here. Yeah, the audio is I can. I can hear bits and pieces, but I can't hear everything. Am I coming in? Okay. You're fine. Yeah, it's not important. It's it's emailable. Okay, okay. Okay, so for the next quarter for advanced mobile contributions will continue doing some kind of testing and working on our prototypes and making sure we're focusing on working with our communities making sure that we're covering their needs. This is our first project that is focused more on editors, and we're really kind of looking forward to sort of building relationships with specific people that we can reach out to and get feedback from because feedback is kind of more important now than it was in the past. And we'll also begin development on the navigation the opt in experience. And for their refactoring project will be continuing those two epics that we started in this quarter. And then Q3 and Q4 will continue developing. We'll probably hopefully in Q2 will finish the navigation and opt in all of that and you might even start in the special pages Q3 we're hoping to continue doing some of the special pages. Pick a first set of those that can include in the first deployment where the first set of Wikis iterate a little bit more add more special pages and then deploy everywhere. And then Q3 and Q4 will also be doing the second two epics in the refactoring project which is making Minerva completely independent of mobile front end, and also reviewing and refactoring Minerva components. Next slide. Next slide. Oh, it's there just taking a second. Okay. You're on your, we're seeing the why slide at this point. I'll read it off of the, I have the deck open. I read it off of that. Okay, so why basically want to focus because we're not left out along with this process of focusing on new editors that we also providing tools for the people that have been doing this for a longer amount of time, and that we also have tools for when we convert these new editors into veteran editors. And our other main motivation was also moving editors away from using the desktop mode on their phone which is not a very good experience and providing them a better more mobile focused experience. And we're hoping that exposing these special pages in the Minerva scan which is the approach that we're taking will give us both kind of that. So, good functionality, good mobile functionality, but also this kind of familiarity and being able to access the tools in places where they would be expected, similar to what vector can do. And for invest in the mobile front end Minerva new front end that architecture. I mentioned this a little bit in the beginning but it's basically around improving our infrastructure so we can be prepared for the future, and also so developing could be a little bit more smooth. And so, no potentially as well we can attract kind of different more new developers to the foundation, and to the team. Next slide. So, we'll be working with community relations very closely, mostly on kind of, like I said, building being able to build a group and expand into as many people from the community as we can get involved as possible we want to hear from a lot of this group of editors and we will be able to identify what the best venues to talk to them are. And in particular, we'll also want to expand this idea of like a task force of people that are very closely involved in the project that we can talk to directly. And we'll also be working with the editing and growth teams, mostly because we're touching similar things while we're not working on the exact same functionality will want to coordinate with these teams and make sure that the decisions that are made and processes don't overlap in some way and also that our objectives are aligned to make sure that we don't do things in a way that doesn't make sense later on in the future. We have a platform evolution dependency or attack dependency here. Yes, so the second, the second project, the big refactoring project that one is also a part of the platform evolution program. And so for that will probably be checking in mostly through conversations and quicker check ins to make sure that we're that we're be able to work along with them with whatever comes out of that program as well. And this is exciting. Let's get started. All right. So Android school this year is to increase mobile contributions. We are particularly focusing on attracting and retaining new contributors in emerging markets or historically underserved markets and languages. So these are markets or languages whose, you know, presence in the world does not currently match their presence in wiki projects. So we want to make contributing to the various projects by the app intuitive so that it's it's easy to use you can understand where you have to go and what you have to do to make your unique contribution, but also supportive. So for people who are new, we want to make sure that, you know, they feel like they are supported through the process of learning all of the the new rules processes guidelines stuff like that that you have to know in order to make a useful contribution. Next slide. All right. So our Q one goals. Last quarter, we built to prototypes for how to redesign the navigation on the Android app to bring the article reading experience to to the forefront. And we think, you know, if you are using the Wikipedia app, then what you probably want to do is to read articles that spend kind of a background thing until now, so we're bringing the ability or the the functionality of reading articles in two different ways. We're about to begin testing on those this week. We're very excited to see the results in app notifications. So we are beta testing a version zero of in app notifications that we hope will encourage repeat editing. So that's code complete. We are doing some analytics on it and we're looking for to design sign off. And then we have started engaging with the community around editing features. Chris has been absolutely wonderful at helping us with that. We have a page on media wiki. It's called Android editing features. So if you're seeing this later, you want to post on the talk page. Let us know. We are trying to to get our sort of later iterations of the road back out front of the community for their feedback and input. Next slide. All right. So Q2 that now we get sort of into the meat of how we hope to attract newer contributors to edit on the app. So right now, in almost all of the languages, users can edit wiki data descriptions on the pages where there is not a another description. Through the app, we want to allow users or, you know, put forward for users other sort of little things that they can add or edit or translate so that there is always something that they feel that they can do a contribution, although it might be small that has a big impact that they can make. So we'll be prototyping that during quarter two and hopefully productionizing it in later quarters. We are following the lead of iOS and mobile web and doing other features like native top pages or watch lists that we hope will be very useful to not only our newer contributors but also people who have been contributing for years. And we'll be integrating additional notifications and things like that. So although Android is focused on those newer contributors, the things that we're doing, we hope will be of great ease and value to people who have been contributing for a long time as well. Next slide please. All right, so why are we doing this? Why are we focused on those historically underserved markets and those emerging markets? And the simple one word answer is equity. So we can attract content that we might not otherwise have gotten by targeting those markets. We can make sure that communities who are in those markets are feeling sort of supported to attract and retain contributors. And we want to make sure that contributing is a rewarding experience for people. It's something that they're doing probably in the comfort of their homes and newer contributors, they don't always sort of feel that there is a community necessarily. So we want to make sure that people, they kind of feel the love, we're spreading the love around. And we hope, like I said, that all contributors will eventually feel like this is something that is supporting them and is making their lives as contributors easier. All right, next slide. All right, so our friends in common, so Ramsey and Amanda, we have been talking with them about the edit action feed and how we can allow people to make a contribution to the structure data project through the Android app. We'll be working with the reading infrastructure folks on other parts of the edit action feed. And then, as I said, we'll be working with both iOS and mobile web to figure out sort of where we go with top pages and watch lists. And thank you, thank you, thank you to the Community Phasons team or whatever they're called now, the design team. And obviously my friends in Android, y'all are awesome. I love you guys so much. All right, the end. On that note, it's going to be a hard act to follow, but I will be talking about iOS and iOS. I'm just going to check the chat room. Great, so I was part in the portfolio this year is really to focus on increasing the efficiency and usability of the existing editing flows for mobile. So sort of along in between the Android, new editors focus and web, extreme experience editors, all the tools focus, we're trying to focus on sort of those people that maybe are, you know, a couple of times a week there are editing, but we want to make the experience particularly delightful and efficient for mobile in a way that are so I think we kind of sum this up in our project page and mission statement as basically bringing the same user experience quality and focus on usability that we brought to the reading experience over the last couple of years to the editing. So in terms of Q1, we had sort of similar to Android, we had some wrap up work for readers that's built into this quarter. So that is actually done as of last week that shift. There is going to be a bug fix release probably this week, but pretty much done subsequently with that update. And the next big feature that we're just starting working on that is actually for editing is just looking at description editing. This is a feature that already exists on Android. We're just putting it over part of the reasoning for this is because it's already been proven to be successful on Android. And also because, as you guys all know, this is moving on to editing features is new for these teams. So we wanted to pick a feature that was pretty well defined and pretty well fleshed out so that we could dip our toes into some safe waters. So hopefully we'll be knocking that out this quarter and that just starting on development. And then the real sort of bulk of the work looking forward has been a lot of design research so I just want to call out Carolyn yet again got a lot of stuff got shared over the status updates but she's just putting in a ton of time and work on comparative analysis of editing tools but also best ways to do wikitex entry best ways to show wikitex syntax and again, thinking from a user and usability perspective about the next. Yeah, and all those updates, not just from my OS team but from across the organization have been like special treats in the weekly updates like I read lots of them, and they're just just to see the quality of that work and how that's going into the product is really exciting. Yeah, and so looking forward sort of past the descriptions again, as you've seen the updates you've seen, we kind of in the design and thinking product thinking with focus on wikitex keyboard with predictive text entry so predictive text is explained very briefly means sort of like you've started something we know there's only certain ways to finish it we should just offer you shortcuts to finish it that way rather than you having to remember what's the rest of the syntax for this, the two squiggles or three squiggles at the end. Highlighting ability so taking our existing highlighting syntax highlighting and making it again particularly mobile friendly and using some sort of more modern best practices around readability of content. And then just sort of again we have some basic usability fixes that we need to get knocked out sort of the. You know, submitting, literally submitting an edit that kind of thing just clean up not nothing too exciting there but preliminary work to make sure the rest. It's together. For key three key four will probably be focusing on talking user talk improvements. So obviously, talking about pages and getting feedback on user talk is an important part of editing process and collaboration process that's not well supported in the apps. And as Charlotte mentioned, we just want to kind of take a look with the other teams involved at sort of the best ways to promote mobile, especially. It's entirely new for us. And then along with that again is sort of another core component of that every collaboration experience, which is visual tips, page history. Some of which have sort of prototype versions already in the apps but are not particularly super usable or well integrated with the rest of the editing. Next slide. So I actually had to talk to so much about why we're working on this general area but why we picked the wiki text editing surface of it. So, many, many thanks to our Android. And to meet you in particular who put together a prototype keyboard and that got done in time for wikimania testing and some other testing at the. And that just really got a very positive response. We think it's a way to get some really quick utility is something that doesn't exist on mobile yet. And so that kind of give us the sort of initial focus for that related to that then is once you're working on the surface, you might as well be working on the whole editing surface. And so that's kind of where our initial thinking around what we're going to be delivering first, right, is that if you're going to be editing a talk page, you still have to be editing wiki text. If you're going to be editing an article, you still have to be editing. So we're focusing on this shared tool that is core to so many of these workflows gives us hopefully significant bang for the buck in terms of rolling out other features in the future. And also, I think part of it was just Carolyn did some pretty amazing design research and we all thought that there were some real big wins that we could get here that there's some real improvements that are possible over what we have now. And that they're very tangible and Liverpool and so we wanted to knock those out where some of the other things that we have to figure out like talk pages are a little bit more big about how we're going to figure that out and obviously have some more community aspects to them that we're going to be figuring out. And then I just wanted to talk very briefly about sort of how iOS is going to be deciding on features. So I know, you know, we're trying to present as much forward thinking roadmap as we can. But as a team, and as a part of manager I really try to focus on sort of the sources of where features come from. And so the priorities of those rather than a feature list a roadmap, so that people understand, not six months from now what features going to be delivered inside, what features going to be delivered and kind of have four sources of feedback that we're looking at with that user feedback of people who actually use the app. Community obligations so that's things that the community needs us to do in order to support mobile editing and be a functional part of the existing duration systems research recommendations so I also wanted to just want to give a big thanks to Abby and James and Marque, who, when Abby James do the amazing amount of work on the research taxonomy workflow taxonomy that helps us make decisions and helps us sort of figure out how to piece features out in a way that is hopefully sustainable and sensible. And then last technology needs. So just again, editing has not been our focus we have some preliminary work understanding that that will be put in. So just briefly our dependencies again kind of echoing one of the people said community resources department or group, particularly for us on the iOS side maybe a little bit of a unique challenge and that we have to find people are interested in what we're doing they exist but it's unlike many other teams here we don't get a shower of feedback whenever we post things we mostly get sort of polite knots. And so one thing we're trying to do is figure out how to sort of really engage people who are iOS users and who will edit in the app. So to give us, you know, meaningful feedback, we've created participants or one challenge that we're kind of thinking through is language support. So we are targeting some of these that we don't have language capabilities for and given the way that we tend to develop and try to be really focused on users and user feedback. And that kind of feedback loop is a little bit going to be a challenge when we're supporting people in Korean, for example, a language that nobody on the team speaks, reads or writes so we're trying to figure out how to resource that and work with the sales to make sure that that's a sensible data transition. So this is really dependent outside the team but we are on iOS trying to get more data oriented and really implement a better understanding of our users through collecting a lot more quantitative data around what doing especially editing flows and Chelsea is really leading the attack on that but it will take support from other people on the data product analytics team and then last but definitely not least is we'll be talking with the editing team, Dan Gary and sort of what used to be known as visual under your team. Parsing which you'll hear from school later on, and the community tech groups just for their expertise right so I don't think we have any upstream build dependencies for this couple quarters but we do. We are going to be having questions and need pointing to documentation. That's just where I was. Sorry super. I think Ramsey you're up. Yes, can everyone hear me. Yes. Okay, let's go to the first slide please. Alright, our team mission for now at least is to build out and launch the first part of the SDC project which is insane and extremely complicated but I'll try to condense it all into a few minutes for the purposes of this meeting. Our first launch targets are going to be multiple angle file caption, and then the text tags along with other wiki based style statements. This work is primarily targeted to people who already know what structure data is on the commas community, as well as the wiki data. Next slide please. If you want me to have three major goals go one is to do all the tech work to actually jam the wiki based stuff into the text pages and make it all look nice and neat and integrate together. That is very complex thing to do. It is a new thing to do. There's no prior art to refer to so we're really inventing things as we go. That's the work is a progress on schedule. We hope it's complete the next couple of weeks. Second goal is working on prototypes for the thing we're going to launch in January, which is the fixed statements. That is also insanely complicated and complex. And we are making progress right now on the search aspect of the fix and other statements. And then next month we will do up the research file page work. We are doing progress and so far relatively on schedule, relatively. And our last goal is to actually document a lot of the stuff that we kind of invented, particularly for search and how the new features for STC work within elastic search and some of the other search functionalities. Next slide please. For the forthcoming quarters. We have even more work to do. We will actually launch multilingual file captions in October, hopefully crossing fingers and toes. The quarter after that we will actually launch the picks that depicts tags along with the other wiki based style statements. Next slide. Why are we doing captions and depict statements well, two different reasons one, again, we're doing a lot of new stuff here. In many ways kind of a reinvention of the guts of commons. And there's just a lot of new stuff built on top of new stuff and to be safe, we're starting with a very small MVP, if you will, and the smallest element we could do was file captions. Once that's released so much surely after which we'll start doing the big stuff and the complicated the picks features and the implementation of other wiki based file statements that will make commons look a lot like with the data. That work is critically important. It's the foundation of all the subsequent work that we'll be doing for the project. And in many ways, it's, it's the game sheet, the game changing features that will define the success of the project. So, the plan has always been start small, but then very shortly after go big. And we really couldn't think of a better way to do it because, again, this particular feature being depicts and other statements are just really, really critical to the rest of the work that we have to do. Next slide, please. Dependencies. Well, at times it seems like we recruit engineers from every department in audiences at one point or another, but right now we're working with the MCDR team slash core platform team. We've got a lot of work from community liaisons mostly Keegan who's embedded with our team, but we also recruit some other liaisons that necessary non then product analytics team. We haven't been using them too much recently, but that's going to change like as of today or tomorrow to help us figure out some wiki data stuff and also helps define metrics later on. And Ben's team, the glam folks, Sandra, Alex, etc, have been really helpful in making sure that we're covering grant requirements and meeting the needs of our institutional partners in the glam world. And many, many, many thanks to everyone who has been involved in the projects so far. Very soon you're going to start to see the fruits of all that labor and we'll actually have features out there in the wild. That's it. Okay, I'm going to try to step in and cover stuff on infrastructure. So the reading infrastructure readers infrastructure team exists to support the different teams within audiences and specifically readers rework on apis service endpoints. So with that nature, we're going to be pretty heavily involved in the platform evolution program throughout the remainder of the fiscal year, and probably beyond. And we're also starting work on what is called the better use of data program. So that's improving our practices and technology around event logging and AB tests and things of that nature. We've been doing a bunch of things. We've been helping out with the multi content revisions project. We've also been taking over support of our maps infrastructure. We continue work on the page content service mobile content service. I'm also known as PCS and MCS. We are improving the summary endpoint so that we can get things like preview cards for wiki data. We're getting more requirements for that so that we can build the service or enhance the service the right way. And as I mentioned, we're working on better use of data. This quarter has been a quarter where we're focusing a lot on hiring and establishing the relationships early. Firming up the relationships with our different partners across the organization. Next quarter, and only talk about next quarter because we only have a little bit of time left will continue working on PCS will continue working on better use of data. We'll be reaching out to a number of our colleagues to talk through what we need in terms of requirements for instrumentation and AB testing. So we'll want to be upgrading our event logging libraries, for example, on the client side, and we'll continue to be involved with the platform evolution program. Specifically, we're involved with the wikimedia tech count technical conference where we'll be talking through where we want to take our platform over the next three to five years. As always, we'll continue to support the different client teams. For example, helping out the Android team, and I think the iOS team and do time on edit the prototyping. And I'll hand the mic over to Subaru just a second while I disable my microphone. That's a lot. In the mini pies. Can you guys hear me? Yes. Okay, can you go to the slide Adam. So broadly the team mission since 2016 is to look at the three pieces of what we do, which is the input with the text output HTML on the tools that go. And so this year, the primary focus is on the tooling the parsers. So as some, as you might know, there are two different parts of right now. One is the classic PhD parser that just converts wiki text to HTML. And the other is part side, which can convert both wiki text to HTML and HTML to wiki text. And it's used to support tools like visual editor, content translation, linking, etc. And the broad goal of this last piece is to get at a single parser instead of having two different parsers for different needs. And there are two components to this one is to bridge the differences between the output and the features between the parser and PhD parser. And we have been at it in about 2015 and most recently replaced ID as one of the projects along this. And in 2018, the we've been working to move part side to core in order to address the architectural and language complaints of the part side. Next slide please. So in terms of goals q one, once again, broadly the two goals high level goals are one prototype on the value of the part side for two PHP. And the second one is to reduce the differences between part side and PHP parser. And for the first goal we've been working to implement testing and performance features in part side. Some work was done the previous quarter and this quarter we are putting all that code to PHP and more to follow. And the main highlight for the second goal is to address the media output difference between PHP parser and part side. So some work has been done and it's right now start another maintenance and other goals here. And we'll pick this up again. Next slide please. So no surprise in terms of the high level goals next quarter as well, but specifically I think we're going to put more code to PHP and devalue performance. And for the second component, we want to kind of finish bridging the media output difference between PHP parser and part side as well as complete language reading support. And also there is some work we're doing to kind of make sure we can support extensions that are currently being done in PHP we can also support in part side. That's it. Thanks everybody for presenting your road maps. I'm going to turn off the recording now. We're at meeting time. I suspect some people might have some questions. I actually need to drop off of the meeting. So I'll leave it to you all if you'd like to discuss further otherwise I'd recommend people catch up over email or video chat.