 Welcome everyone to this month's monthly activities meeting. This is a change from the previous name of the metrics meeting. We're going to be talking a little bit more about that during this meeting, but welcome. We're also going to have a movement update and talk a little bit more about mobile personas and the Wikimedia product principles, our monthly activities meeting, and have time for questions and discussions and wiki love. So for the movement update, for the hardware donation program at this year's Wikimedia, we were able to donate 19 foundation laptops to volunteer contributors. We also released the transparency report on July 20th that covers all of the takedown requests and requests for user data that we've received from January of this year. We also have a donation from the Bryn Rajiki Foundation. They're giving a gift of a million dollars to the Wikimedia Foundation continued from last year. And we have a new Wikimedia Commons picture of the year for 2018 with two Brazilian frogs by Renato Augusto Martins. And here is that photo. We also have a hackathon in Brazil that targets the technical community's presence. And Wikigraph's bootcamp will be in India this September as well to cover illustrations and digital drawings that can be used on Wikipedia articles. Wikitextorm will be taking place in the Netherlands in October. And now we'll turn it over to Daisy Chen and Margie Novotny to talk more about the persona's work in the logic department. Hi, this is Daisy. I'm a design researcher at the foundation and I'd like to talk to you a little bit about the mold persona's project we worked on. Next slide, please. So this is a little bit of a research overview of what happened. So I'm gonna talk about the process which has the stakeholder interviews, user interviews and the workshop sections and also get into the personas that we developed a little bit. And I want to give kudos right now. So thank you first of all to our logic department collaborators. They're based in Brooklyn, New York and we worked with them pretty extensively throughout this project. And also foundation staff from audiences, legal and communications for making every element of this project very smooth and successful. And of course, Margie, my co-conspirator in this. Next slide, please. All right, so this is just a nice picture of actually one of our personas. And I wanted to talk about personas overall a little bit. So the goal of developing personas is means of allowing all of us to build empathy with our users and our user groups. So essentially creating a vision of who we design our features for and allowing us to kind of understand what kind of challenges they face as they use our various channels and also how do we understand their motivations as they're working with us. And in turn, this will allow us to kind of figure out how to design for them and impacts the usability of all of our channels. And in this case, specifically our mobile devices. So our mobile web and our mobile apps. And a note that our design team over the coming months will be doing more of a push to kind of make sure everyone in the foundation and our communities are aware of personas we've researched and developed thus far and kind of make sure that we are all using them consistently and as much as possible across the foundation. And there is a link at the end of the my section of the deck that has resources about the mobile personas and also all the personas we've kind of developed so far. Slide. All right, so this is a little bit of the overview about what our stakeholder interviews came up with. So what we wanted to do with our stakeholder interviews was lodging department wanted to understand our collaborator. They wanted to understand what our research goal were and our priorities as well. In addition, since we wanted to talk to users they wanted to understand what priorities we had around what types of participants to recruit. So we ended up holding a workshop with a lot of our internal stakeholders and we paired this with a survey as well to get alignment on those research goals and recruitment priorities. And so some of these things that you can kind of see here we really wanted to understand user motivations. We really wanted to understand what user technology comfort level were. And we also wanted to know some other things like whether our users understand the difference between consuming and contributing and what their knowledge levels are about that. In addition, we also talked to our internal stakeholders about what we wanted in terms of recruitment priorities. And so we discovered that we wanted to make sure we understood which of these participants were readers versus editors or both which mobile devices were used, what types of entry points there were. So for example, are people Googling us first? Are people just straight going to the Play Store or the App Store to download our app and going to the app directly? We also wanted to know where our participants were in their education and life stage, gender, ethnicity and age, whether they were multilingual, et cetera. Next slide. And for recruiting, we did two rounds. For the first round was we had an existing pool of participants that were mobile apps users and so we emailed quite a few of them and we also reached out to our comms team so that they could put a push for this on our Facebook page. And then we also did a second round of recruiting which was another social media push both by Logics Department and our comms team. We ended up with 23 total interviews conducted and now I'm gonna talk a little bit about what we found. Next slide, please. So this is a picture that Sam Raditz from Logics Department took of one of our workshop whiteboards. So Margie and I went to Logics Department and we kind of workshopped with them over the course of two days and essentially went through the earlier stages of analysis and synthesis with the findings from the interviews. On the first day, we kind of concentrated on going through all the transcripts of the sessions and writing down on a bunch of post-it notes, what attitudes and behaviors we saw, goals and motivations and kind of just like interesting tidbits from the interviews that we collected. We ended up affinity diagramming all these post-its which basically just means grouping them into categories that kind of made sense. And then we ended up, yeah, so these were post-it notes about perceptions that users had expectations, that users had frustrations, frequency of use, that kind of thing. And so we ended up making buckets of these post-it notes and then the second day we kind of worked with those a little bit and found some patterns. So we can go to the next slide with that. So these are some of the patterns that we found and this is after going through a whole bunch of buckets of post-it notes that included a range of context of use, range of habits, types of searches that led to interactions with Wikipedia on mobile in some way. Thoughts about how much they trusted our content and why levels of frustration and the causes of those frustrations, what they were happy about and what they wanted to see more of and things like that. And so after we came up with all these posted buckets we did a couple of exercises that kind of helped us lay the groundwork for personal development. And one of these exercises was doing two by twos. And so taking kind of the most salient combinations of these bucket names and mapping them to kind of user experiences that were represented in these interviews that we just conducted with these participants and also past research. The two that were most salient after doing these exercises were motivation to read deeply on a phone and also the depth of editing on a phone. So we thought that the ranges of these buckets kind of covered the most ground in terms of our user, potential user personas. Now let's get into our personas a little bit. Next slide. So these are just some pictures. I didn't want to have too many slides on this deck because I wasn't sure how much time I would have. So these are just some nice pictures and we're gonna go to the next slide to see what they represent. All right, so Reina, who is persona A. So her tagline of sorts is kind of, she doesn't really know that much about editing on a phone. So her main attributes are around the slide right there are she reads briefly or deeply, doesn't really know that the Wikipedia app exists at all. And so our goals around this persona A is that we want them to read more. We want them to have more awareness of Wikipedia, and just the brand overall. We want to drive the user to download the app as much as possible. And then persona B, his tagline is more, he reads briefly and has low editing confidence. And so some things about him are that he will casually be in some type of scenario. Maybe it's trying to prove a point during an argument or is looking up a fact in trivia and we'll use Wikipedia for that. Is a little bit overwhelmed or concerned about how the contributions work in terms of the editing interface itself and also what happens after you make an edit on mobile. And so what we wanna, our goals around persona B are more, we do want them to read more and perhaps more deeply. And since they have low confidence around editing, we want them to kind of have more entry points to kind of convert them to become more comfortable editing, at least smaller edits at the beginning, maybe grammar typos and then perhaps more in the future. And then persona C, he is someone who would actually read topics and make very small edits on the phone. So this is someone who probably doesn't feel like a topic expert and will go to Wikipedia for information and has maybe had some experience with making very small edits. They tend to go to the browser to make edits because they don't feel comfortable with the mobile interface. And they're aren't as concerned because they may kind of be smaller edits. They are not really thinking about, oh, am I gonna be reverted or is my contribution gonna be deleted just because their particular types of edits are not super high in content. They're not as aware of editing policies. And so our goals around persona C are to just get them to edit more and possibly convert them to be more of Wikipedia advocates. Then persona D is more of a selective reader and might edit live or in the moment when something is happening. And they're kind of more bold in the sense that they'll just kind of make contributions and not really think about what will happen. And they are more aware of what features there are on the app and they feel like experts. They are not necessarily deep readers but that is kind of, again, that's their persona. They kind of just read a little bit and we'll do live edits in the moment. And so what we would want this type of persona to do is to be more like, similarly to persona C, we want them to evangelize and be advocates for Wikipedia and we want them to also drive them in some way to do more deeper edits. So even if there is something happening and they can edit that particular event that's going on, we want them to also think, okay, so if there is relevant evergreen content, can we get them somehow to contribute to those articles as well? And obviously this is kind of true for everyone but we want them to be more involved in the Wikipedia community. And persona E is someone who reads deeply and would edit on a phone if it were easier. So this person also has had some experience with editing on a desktop before and they feel more invested just because they feel more like subject matter experts and they possibly feel more passionately about certain topics. And these are the, this is the type of persona who would actually be able to fill knowledge gaps in various content categories. And so they are more aware as well since they've had experience editing that there is kind of an ecosystem behind Wikipedia that monitors and they know what flagging is and they know what deletions and reversions are, things like that. And so we want them to feel more comfortable editing on a phone. We want them to not just maybe edit once in a while deeply but more frequently as well. We also want them to kind of teach what they know about Wikipedia with others. And we also want them to be in doing so kind of more of a bridge to other community members. Next slide. And this is, these are two links that are where kind of all of our personas are living. And the mobile personas link is a full report of what I just went through. So thank you. Thank you, Daisy for sharing more about the personas. We're now gonna have Josh Minor tell us a little bit more about the Wikimedia product principles. Hello. Excellent. Morning, good afternoon, good night, et cetera. Just a quick introduction. I'm Joshua Minor. I'm the product owner of the iOS app for Wikipedia, but I also work on some audiences, department-wide initiatives around product strategy and cross-cutting kind of what have you. Today I'm actually here to talk about the Wikimedia product principles, which we generated last year as part of our annual planning process, but also to help us set us up for the three to five year planning and strategy discussions and moving us in the direction of the movement strategy. So kind of trying to put some framing around that before we get into the actual work of doing that. Just real quickly, for those of you that are new to the org or are watching online or just aren't familiar with the intricacies of the foundation, the audiences department works on the user experience of the Wikimedia projects. So we develop and maintain what might be called the front end of the Wikimedia projects and examples of what we do include like the visual editor, the notification system, the mobile apps and website, the Wikimedia or media Wiki extensions and APIs that power those things, so that kind of stuff. So briefly I'll be going over the purpose of these principles. I'll touch on the process that generated them then I'll actually obviously go over them. And finally I'll give some sort of context or rationale about how these principles relate to the larger movement direction and kind of the values of the audiences department and the foundation and the movement as a whole. So on purpose, so the audiences previously known as the product department has been through a lot of changes in development over the years. It went from a department with one project, the visual editor to a department with many sub teams working on many different projects. And we thought now would be a good time going into the longer term movement strategies, thinking or trying to turn that into plans to step back and kind of reassert and rethink about the kind of products that we're building. So before we start actually making lists of features we're gonna build, or talking about projects we're gonna do, let's talk in the abstract about the kind of things that we want to be doing. This also helps internally to kind of distill a shared sense of purpose across the teams. Obviously teams working on the community wish list and the teams working on the apps don't always have a shared sense of purpose because we're just working in different spaces on different scales in different ways. And so one goal here was to create a shared sense of why we are all doing the things that we're doing. It gives audiences leadership and particularly at this time there was some new leadership coming in or sort of being solidified and give them a chance to sort of set expectations around what we're trying to do, what the team should be aiming for. And you'll see the word aspire and expect are in here. And I think one other way to call this instead of principles would be aspirations. So these are not rules that we're gonna follow. These are not a checklist, but they're basically the hopes and dreams of what we're trying to achieve. And then one of the things that we hope it'll do is what I'm doing here, which has helped explain what the audience's department does and what we're trying to do to other staff members and to the communities that we work with. And then finally, I just really wanna reiterate this is not meant to be a strategy and it's not meant to be a new direction. You won't see any plans or commitments to specific feature development and it's not meant to replace or to displace any of the existing principles or movement strategy direction. It's really meant to articulate this department and this group's place within that larger thinking or framing. So let's talk very briefly about process. We basically gathered up the product managers, a few of the engineering leaders and most of the design leaders and the audience's department. And we went through what is a pretty classic Wikimedia and process for those of you who've been around. We basically got people together, had them think with some prompts and some structured discussion around questions like if Wikimedia was a place, what kind of place is it? In the abstract metaphorically, what are we trying to build here? And I think you can look on Wiki to see what the actual answers were or what the groupings came out. But the real sort of core beliefs there or sort of mentions were diverse urban environments, so complex urban spaces that have emerged with lots of different people interacting successfully to live in a city together and essential cultural institutions. So things like museums and libraries that have been around for a long time and are expected to live in perpetuity to be a repository for our global culture. The next thing we did was ask those people to put a single word in for what our products must do. So one thing that product managers have to do and we in the audience's department have to do is prioritize out of all the many good things that we could be doing in the world, what should we spend our limited resources and time on? And so part of what we were trying to do is force people to think to, if you can only get one, what do you aspire to do? And what came out of this was a lot of verbiage around the word empower. So a lot of the team really wanted to make it clear that what we do is help other people to do what they wanna do. But there was also some, and you see the next one exploding in power, there was also some concern that empower in particular carries a connotation of a power dynamic or control on our part, that it's our job to apportion power, reapportion power. And that's not really our role, it's not what we're seeking to do with our software. So we kind of rethought that a little bit and more put it in terms of enabling or making people capable of the things that they wanna do rather than taking power from one group, giving it to the other. And then we worked with Juliet from the comms team who gets a huge shout out for the final version of this and really had a big hand in making it readable and understandable, hopefully. And helping us also to really frame it clearly in the light of the movement strategic direction and make sure that we were tying what we were saying to the direction that we were headed as an organization and as a movement. So I'm just gonna read them because they're kind of precisely wordsmith and I don't wanna mess up anything. But we came up with four. So the first one is community centric. So that means our product should be enabling a welcoming, vibrant community place where people come together to create, share and discover knowledge through positive collaboration. They should be usable for all. And we believe that the product should be promoting equity through usable, useful and inclusive tools and services that meet the needs of a diversity of people and machines across user experiences. They should be intentionally transparent. So obviously we're a little bit transparent by default because we work in the open and things are posted on fab and stuff, but the products themselves would really work to demystify the knowledge creation process, encourage participation and really do that by giving everyone visibility into how the information on the Wikis is created, verified and improved over time. And then last but certainly not least is extensible and sustainable. So we wanna be creating products that create the conditions for people and machines to use, reuse and build on top of our platform and really extend the free knowledge that we have and support a sustainable future for the Wikimedia platform and movement. So I will talk a little bit briefly as much as I can about the sort of the framing of where these come from and how they relate to the movement strategy. So the first one in particular and many of these in general kind of rest on this contention which is Wikimedia is a place and not a database. That doesn't mean databases are not important, that we don't store data. It just means that we really believe that Wikimedia is and must remain a vibrant place on the internet. That a welcoming space is vital to the work of building and maintaining the knowledge on the Wikis and providing readers, in addition, a place to consume and engage with free information is more indispensable than ever. So that means that we really must build tools that promote positive collaboration and engagement with a vibrant knowledge community. It doesn't mean our information can't be reused or remixed or any of those things, right? But that the core of what we're doing here in terms of the product is keeping a beating heart of the Wikis and the sort of the process of knowledge creation and generation alive. So the next one which is kind of ties back into what Daisy was talking about in the earlier presentation, which is usability and particularly usability as an equity issue. So a lot of these principles are a couple of them really rest on this contention, which may be a little controversial, but that free software isn't really free if you can't actually use it. So we really wanna make the Wikimedia software as highly usable and useful for people as machines as possible. And we really wanna break down the software barriers that prevent equitable participation while giving users the tools to customize their experience. So we stole a motto from Larry Wall, the creator of the Perl programming language, which is make the simple things easy and the hard things possible for as many people as possible. So I wanna kind of dive into this just for a couple minutes because again, it's a little bit dense and also I said a little bit provocative, I guess is the word. And what we're trying to do here is really say our commitment is to make open source software usable. And that's not to say that free software values, free licensing and code openness are not important or necessary, but just that they're not sufficient. And in particular, our department is aspiration is to look beyond that bar as it exists and that traditional notion of source open and cost free and claim that we need to do more to make software truly free. And we think this is really necessary as a prerequisite for bringing equity to the knowledge creation generation and participation process. I would love to go more into the nerdy political science background of this, but I probably shouldn't. I will just say this is based on an idea called synthetic or real versus formal freedoms. If you're interested, there's a book called Real Freedom for All by somebody named Van Pargis. I'm horribly butchering that. If you look on the Wiki, you can find a little bit more about this. But the core sort of summary is that in most systems of political freedom, including the ones that sort of underlie the origins of the free software movement, freedom is defined as kind of a universal and in the negative about what the authorities can't do to stop the freedom. So I'll give an example. So under this concept, whether you are poor or rich, English speaking, Chinese speaking, whether you're blind or sighted, we don't care, the license is still the same, the cost of the software is still the same. It still costs you zero dollars, it's still freely licensed. But the reality is, and the negative part is we can't stop you from doing that, right? As a foundation, we can't change the license to make it less free, we can't start charging you money. And we act as sort of the civil authority in this case. But the reality is, if you are a blind Chinese speaker with a mobile device, you cannot participate fully in Wikimedia right now. You can try and some people are very motivated and they make the best of it. But the real issue is that basically you can't actually engage with the software the way that other people can and you're excluded from it. Sorry, I'm going off the edge of my notes as you can probably tell. Thank you. And I think we all kind of feel this, but free software as much as the free software as movement has done is very hard to use, right? Usability has not really been the core free software. We're in a very privileged position at Wikimedia to have the resources and the people who are motivated and the movement strategy to say this is a real issue. This is something that we can make better. This is something that we can bring more people in by focusing on usability as an aspect of equity. And I just want to leave off with a quote from another book that kind of inspired this thinking which is called Inventing the Future by Strynek and Williams which is actually over on the bookshelf over there which is, they call it the synthetic freedom, but synthetic freedom recognizes that a formal right without the material capacity to exercise that right is worthless. And that's kind of what we're hoping to make a change there and make that material right to exercise that capacity a more real thing for more people. And last but not least, many of these and especially the last one about transparency and being a sort of a vital place on the internet really rest on one of the more striking findings from the movement strategy research that we wanted to grapple with which is the really vital but poorly understood role that we play in the larger free knowledge and media ecosystems. And we really want to work to make our products not just a source of information but also a way of increasing knowledge literacy and making sort of understanding of how the content is generated a part of everyone's experience and kind of break down that wall between a totally naive consumer that knows nothing about Wikimedia and the rest of the movement where people do know some stuff and are actively working together to push forward the vision. And we really think that we can do this by helping expose people to how the Wikis work more clearly and effectively and again encouraging people to participate in an appropriate way for their level of skill the device they have what the community that they participate in needs. So that covers a lot in a fairly short time. It's pretty dense. There's a wiki page obviously. You can also email me if you have questions. We're gonna be hoping to sort of apply these and use these in our three to five year thinking so you'll probably see them come up again. But if you have questions in the meantime or like I said, wanna talk about any of these ideas you know where to find me or to find the talk page. Thank you. Thank you so much Josh for explaining the thinking of the audience's team and your accessible approach to building or new products. I also wanna introduce Greg Barnum who's gonna talk a little bit more about this meeting and how it is now the monthly activities meeting. Greg. Thank you. Okay. So first actually I realized we forgot to applaud Daisy when Daisy presented. So let's do that real quick. Okay, great. I seem to have lost the clicker though. Well there we go. So back in February I spoke at the meeting and talked about how we might be doing some changes to the meeting. And as it turns out that is in fact happening. Probably the most noticeable thing that you've noticed is there's a new name. Now I, like all of you, am still going to probably call it the metrics meeting. I recognize that's what we've been calling it for a long time. We're all going to fall to that habit. I get it. But newsflash, we haven't actually shown metrics at the meeting in about four and a half years. So calling it that seemed to be a mismatch to our audience who couldn't figure out. We were kept getting asked by new community members where are the metrics in this metrics meeting? And we had to explain, oh we've moved them online, which is great because now you don't have to wait a month to get them. You can get them any time you want. And then they would logically say, well then why do you still call it the metrics meeting? And I had to say, I don't know. So we've renamed it. So the name has a few different things that we're trying to convey with it. One that we're not doing metrics anymore that those happen online as they have for about five years. The second is that it's not just about the foundation. So a long time ago when this was named it really was just about the foundation. It was an internal meeting. It was meant to convey to staff. And then we realized the community might be entrusted in that information and those metrics. So we made them public. And then the community said, oh we have things we would like to share. So we started to invite them to it. And over the course of the years, it's really no longer a foundation metrics meeting anymore. So with that we decided with this new name we really wanted to put more of a focus on community presentations. And that's really what a lot of the shift that we're doing over this month and over the last several months has been. That the lot of the feedback we got is that most of the elements people liked. They liked the presentation. They actually liked that there's a large number of staff presentations. So we want to continue that. But they definitely wanted more community presentations. And we want that too. We spent a little bit of time experimenting with some ways. We spent a couple of months reaching out to community members, Sam. And I have fond memories of these experimentations over the last several months. And what we've concluded is we need your help. We want the community present. We've heard from you that you would like to present. So we want to make that as easy for you as possible. We need your help in doing that. So we've put up a new Metawiki page. It looks somewhat similar to the old one but has a bit of a facelift. It has quite a bit of the same content. But one thing you'll notice is a link to sign up to present. And there's also a button. And we've set up a page that's a little bit easier for people to sign up if you would like to give a presentation. So our ask to the community is we very much want this to be a community meeting. We want you to be here more. We want to see more of your wonderful faces during this meeting. But it's a little weird for us to go out and try to find all of you. So we need you to come to us and let us know what you would like to present on rather than us just generating ideas and coming to you all which didn't work. So if you would like to sign up to present, we obviously can't guarantee that we'll take every presentation but we're going to certainly try. And we want you to go to the Metawiki page which is Wikimedia monthly activities meetings. Also all the other metrics links redirect to it. It's the same actual page. So you'll get there a few type in metrics and then go and sign up. So that's what we're hoping for. We are interested in your ongoing feedback. We will continue to evolve the meeting based on that feedback. But this is a sort of a culmination of a couple of years worth of work. I know it's a very minor cosmetic change for the people working on the team. It's a pretty significant thought change for us. So with that, I will pass it over for our Q and A section. Thank you, Greg. I'm sharing more from the community in more recent meetings and thank you to the comms team for all the work you've done on redesigning these meetings. Now we want to open it up for all of you to ask questions as we have some times for questions and discussions. And I also realized I forgot to introduce myself at the beginning of this meeting. My name is Elena Goli. I'm the benefits administrator on the talent culture team. So it's nice to meet you. So you can direct your questions to James Forrester on IRSE or if you're here in San Francisco, please come up to the mic so that we can share your questions and hear them on the video. Thank you. I have two questions from IRSE, apparently. Greg was g-chatting me and I have two questions. So is it okay if we start with them? Yeah, go ahead and start. Okay, cool. Are you gonna read them James? Do you want me to read the questions out or do you want to read them out yourself? Oh, I'd throw away. Okay, I'll read them. So Pine has a couple of questions around the mobile persona work. So the first is, I'd like to understand more about the context and goals for the persona work. Was the goal to improve the user experience and or deepen engagement for users with mobile devices? And the second question was, could you describe what types of users you were seeking for interviews while you chose those types of users and how you use the information from the interviews to design the persona? All right, thanks James and Pine. So Margie is also gonna be answering questions with me. So I'm just gonna answer them real quick and then see if Margie has, yeah, I'll pass it over to Margie as well. So first question was, I'd like to understand more about the context and goals for this persona's work. Was the goal to improve user experience and or deepen engagement for users with mobile devices? So the short answer is, I hope that inherently interviewing participants about their experience will deepen their engagement. And in terms of improving user experience, I would say that persona's work is more of a, under the generative umbrella of design research. So it kind of seeks to understand the current experience of users. And by doing so, it will then inform either product direction or how we iterate on the products we're already working on or features products. So it's, I would say, personas are kind of an intermediary step to then inform our further research, which may be more usability focused specifically. Margie, would you like to add to that first question? That's a great answer. The only thing I would add is that the qualities or characteristics of the people we spoke to were the result of kind of a poll, kind of an ongoing poll among the product development team and designers about what are the kind of demographic and lifestyle qualities and characteristics that they wanted us to be focused on. So the people that we interviewed and reached out to were kind of derived by consensus that way. And I don't know if we mentioned, I don't think we did, that we're doing the same exercise now, but in India. So we've done research in four regions, I think four cities and a couple rural locations and over 10 languages. And we will be having basically the same or a comparable set of personas starting to show up probably next week. And we can come back to this group and maybe present a follow up to this. But same process of pulling the product development team for characteristics that they're looking for or would like to have insights on, working with the language team to understand stuff that would be valuable to them. And then using, rolling all that stuff up into what we call a screener, which are the characteristics we're looking for when we go out to do any kind of participatory research and then doing interviews based on the people who meet those criteria. Daisy, did you want to talk about the other question as well or are you done? Sorry. Sure, I can add a little bit. Margie touched on the second question a little bit already, but I can add a little bit about the types of users. So as Margie said, we are also currently doing this, essentially same personas project in India, but this first round, we were kind of pressed for time and also budget. So we wanted to, in the sense of looking at metrics, we was also kind of statistically okay for us to start with the North American demographic, which is what this project focused on. In terms of the specifics of recruitment, we wanted to kind of have an equal spread as much as possible of readers and editors, kind of a wide range of mobile devices, iOS, Android, and also users who primarily were using mobile web. We also wanted to get a mix of gender and age and life stage is kind of related to age, but we just wanted to have as many, as much of a range as possible in our participants. And so I think we did that as well as possible, given our response rate. So again, readers, editors, mobile devices, entry points, life stage, gender, number of languages spoken, internet access, things like that we tried to cover as much as possible. Brilliant, thank you both. We also have a question at the mic. Can you hear me now? All right, I also have a question about the personas. I'm not sure that I, I may miss or remember, so sorry if I am. But when you introduced the personas, there was, it struck me that there might be like an assumption going on and I wanted to verify if that's the case. There was kind of like this presentation of, there's a person that really knows how to read a lot, but doesn't really edit, doesn't know, so we want to push them towards the mobile app. And I think that's an assumption a little bit and I'm trying to understand, we have mobile in general like solutions. One of them is the apps and another one is the mobile web. And it seems like both of these are awesome but might answer different needs. And my answer is that when you're looking into these things, are you treating both of those or are we trying to push people towards the app itself specifically? No, we're definitely looking at both of those. So we were looking at all mobile entry points. And these personas reflect that. Thanks. Yeah, I would add that for different personas we have different goals. And so for someone who does read and does not seem like there is that much tolerance or interest in editing, we may want to, that would be rena persona A. So we would want to push them towards that because the reading experience there is, has improved a lot. But for someone like Marco, who is persona B, they have a little bit of experience, possibly negative with editing, but there is kind of that desire there. And so we have different goals for that. We wouldn't want to push him towards apps just off top. We would want to make sure that, for example, our new contributors project slash team is working on understanding the experience for mobile web editing using visual editor on mobile web. And so that's something that would be relevant for Marco in theory. So. And there's a follow up question, Daisy, also for you and Margie, which is what is the process from going from interviews to persona? So yes, the process is a lot of post-its and grouping them into buckets. That makes sense. And then from there kind of doing exercises to see which of these buckets kind of are more, are the most salient for the types of experiences that we've seen and heard from, not just from these persona interviews from this project, but also in the past. And then from there, we kind of take bits and pieces and say, okay, this particular element or characteristic is going to ground this persona. And then from there, we kind of, you know, some things like, persona A doesn't need to be a woman. But if we kind of see that a lot of women are from our interviews, are kind of using the app to quickly read about things, we might just make persona A rena a woman. And then kind of adding bits and pieces to the persona as we kind of work through the details. So it's a bit of, it's kind of a going deep into all the details when we're reading through all the interview transcripts and then kind of pulling back a little bit and then jumping back in. It's kind of a, yeah, it's kind of a micro and the macro and then micro a little bit process, if that makes sense. Thank you. Marky. I would just add that we have a very detailed documentation of the process on Wiki. So if you go to where the personas live, which were linked from the presentation, there's a great document that goes through every step of the process. So it was a great process and it's one that I think we can follow repeatedly because it seemed to work really well and I think we got great results from it. One more question from IRC. Any questions here in the room? Yeah, two related questions, also there is one would be the other rough sense of which of these personas are more frequent among our general user population. Is it like persona? Is it more general reader-wide and persona is very invested editor and does a general sense that these are more rare, I guess, and which doesn't mean we need to get less attention to have a rough sense on this. And relatedly, if you make statements like persona X prefers the app or develop, do you feel that 23 people is a large enough sample to make this kind of statement with statistical significance? I will answer the part of the question I remember, which is, is there, I think the question was, is there a persona that we kind of want to concentrate on, is that right? Not more, if I have a general sense of how frequent each persona is among our general user population. I'm not sure that I would say, yeah, 23 among all of our mobile users, it's not necessarily, we definitely wanted to talk to as many different types of mobile users as possible, but I don't know if we can extrapolate statistically, just based on the 23 people that we talked to. Margie, your thoughts? Yes, we definitely can extrapolate statistically. The way this kind of research works is you have a relatively small sample, but by talking to a bunch of people, you do see patterns, and like even with as few as eight people, you see strong patterns. And so what the personas reflect are the sets of patterns that we observed. So no one persona is representative of some specific constituency. It's more that personas are like code for grouping a bunch of characteristics together. So yeah, the goal is not to be making any kind of claims about the percentage of these users that exist in our ecosystem. It's more about understanding a spectrum of users. And one of the things you'll see if you go back into the site to look at the process is the recommendation that we kind of focus on Marcos. I think is persona B as it's typical that you use one persona as a primary persona and others as secondary personas. So if you focus on solving problems for one main one, often you solve many of the problems for others. And then you use the more extreme outliers as checks on your assumptions when you're trying to solve problems for the main persona. That makes sense. Any more questions? Either on IRC or in the room? Give it a couple more seconds before we move on. Okay, so we're gonna go ahead and end with wiki love as we always do. It's an opportunity to give a shout out to someone who has done some amazing work or who you worked with on a project and also to thank someone. So you can also pass along your wiki love to James on IRC or come up to the mic. You're in the office. All right, is this on? Hi, I wanna give some wiki love to the organizers of Wikimedia in Cape Town, to the volunteers that were involved in that, to the people that planned the program for several months to Wikimedia South Africa for hosting us. I just wanted to say kind of outside of the foundation, the work that people did to make that event possible was amazing. And then within the foundation, the work that the travel team did to once again, seemed to get us all there and back is amazing. So a lot of wiki love for Cape Town. So I'd like to give out, give some wiki love to the people across the organization who support maps. Some of you who are reading the internet today might notice that there's been a big incident of unpleasant maps vandalism. That affected us about three weeks ago and actually the team on a Sunday detected it and reverted it before really anyone can notice. So, good job, y'all. Hello. I would like to give some wiki love to Karen Zwicker and Rachel Farrand for helping me out when I really, really needed it. When I was at Wikimedia in Cape Town, there was an emergency on the last day of Wikimedia that I had to get home for. And I didn't know how I was gonna do that. My flight was not actually gonna be for another week and I was kind of panicked about it. Rachel was crazy helpful late at night talking to me and helping me figure out what I needed to do. And then Karen was able to right away book me on the first flight to get back out. It was just like incredibly helpful at a time when I really, really needed it and I have major wiki love for Karen and Rachel. Thanks. I also wanted to give props and wiki love to the travel department and also Jasmine and Max Binder for helping me to plan three off-sites simultaneously, which are coming together great and I couldn't have done it without all of their help. Do we have any wiki love on IRC, James? Another few minutes for people in the room who wanna get some wiki love. Well, thank you all for attending the first monthly activities meeting for your presence here in your discussions and we will see you next month. Thank you.