 All right, welcome to the second day of the developer summit. Nice and rainy today, but at least we have fireplace in the back. That's pretty sweet. I just have a couple of quick announcements before we get started. The first thing is that we are adding an additional conference room today because we have so many unconferent sessions proposed. So upstairs on this side of the building, there is a room called Oak and we will have small unconferent sessions in there. Okay, so then for yesterday, everyone is taking notes on their sessions. On the wiki, we have pretty clear instructions about how note-taking should be done in terms of what formatting on etherpad, moving it to the wiki, and then posting it on the fabricator task. Trish will be in the back all day to help people with that or need help adding things to fabricator. And Melody Kramer is working from home creating etherpad sessions in advance of the sessions today for you. So all you have to do is go to the program, click on your session, and you have an etherpad ready to go, ready to take notes. I just want to address also some of the mid-event feedback that we got yesterday. Thank you so much for everyone who submitted feedback to us, either verbally or written. So we added some extra black tea for people who wanted that. We have some note pads available for people who needed them. We added some hand sanitizer to the front desk. And there was one piece of feedback that we couldn't address, which was a request to add tape lines from the reception desk to each conference room in different colors. So we were sorry that we couldn't do that, but in order to address that we tried to add some additional signage to the front area to help you find the conference rooms, and there are definitely maps at the front, and anyone up at the front can help you find any rooms that you need. And then we also added that quick little announcement in the morning for people for the unconference sessions so that they could pitch their sessions to make sure you all had time to vote. Not all of the unconference sessions today are going to get rooms, but remember that tomorrow the Get Stuff Done Day is exactly for following up on everything, all the great ideas that you had, and all of the sessions that you want to continue to run. So you can do that more informally tomorrow. So with that, I'm going to bring Kim up here, who's going to start our Q&A off. Four, five, six. Hello. Hi. Good morning. So I'm a bit scared because there's no slides in this session. So please bear with us. So this is the Q&A with Victoria and Wes, CTO and VP of Product at the Wikimedia Foundation. We started this survey a month ago or so. It lasted 25 days, and basically it was just a game to come up with some questions today. After 25 days, 1840 votes on 40 ideas, we got a prioritized list of questions. And what we're going to do here today is we're going to start with question number one, and we're going to hear what Victoria and or Wes want to share about it. We might discuss a bit that question, and then we'll move to the next one. I want to just explain the discuss a bit part because only the first question could get us for the entire summit. As part of the game, we are going to ask that whoever wants to ask, comment, say anything about a question can do it with one condition, that you're going to take an action related to that question after the summit. Anybody can say anything about a question with a condition that you're going to get involved with the answer after the summit. I think it's a fair trade. And be careful because we've got us note-takers at Kevin Smith, Nick Quiddity, and Andrew Clapper. They don't miss a thing, I can tell you. Plus, there's video recording. Plus, these three people are not only note-takers. They are also among the most avid creators of fabricator tasks. And they know very well how to assign it to people. Well, sorry, you get the joke. We try to find a balance between a session that is... We want to hear them. We also want to have a conversation. Good. Let me see if I'm missing anything. We also have Erika and Melody paying attention to what's happening online. This is being streamed live now. And I think that's pretty much it to start. So, Wes Victoria, just grab a mic. Thank you. I'm Wes Moran. I'm the Vice President of Product. And then for the last year, I've also served in an interim role. Yes, CTO, essentially. And I thank all the teams that I worked with over the last year and the managers who helped get through that process together. I also want to thank you and Rachel and the team for the event so far. It's been great, and I look forward to the next day. Nice to see everybody again today. I'm glad I made it in time. I had to drive up from Menlo Park today. And with weather like this, it's always a dicey proposition driving the Bay Area. I enjoyed the session yesterday very much, and I look forward to more of it today and tomorrow. I guess by way of introduction, I'm Victoria Coleman, the incoming CTO for the foundation. I joined November 7th, so this is almost two and a half months. So, you know, there are days when I think that the training wheels can come off, and then there are days when I think, no, no, no, no, bring them back, bring them back. So today it's going to be somewhere in the middle. I wanted also to thank Kim and the team that pulled this together when we started thinking about the session and what would bring the most benefit to you all today. We figured it was best just to give you the opportunity to think ahead about what you wanted to talk about today. And they put together, I think, a great kind of precedent through this all-our-idea system that personally I would like to keep going after the event today as well. So with that, far away. Yeah, actually, you make a good point. So don't expect any answers today. It would be suspicious if they could come out with, yeah, look, the answer is X. It's like, okay. Also don't expect any decisions in the summit in general, especially now in this session. All these are conversation starters or continuation of conversations. And also an important note is that I don't know how long we'll get today down the list, but 40 questions is a lot. But that's also relative because we will continue going through the list of topics that are relevant and we'll find the times and the venues to continue those conversations. Okay? All right. So question number one. How can we ensure timely reviews of volunteer contributions to Media Weekly Code? So who wants to take that? I think there's a number of things that we're going to start doing or that we've been building towards as far as the timely reviews are concerned. We've been talking with the team about doing better, setting up a code review session and team to focus on it specifically and give an owner to it. As well as some of the things that we discussed in the platform discussion yesterday, there's a lot of alignment as far as what needs to be done. And we want to actually start building that as far as the annual plan so that it has a commitment to it once and for all. So I think this touches on a kind of more general topic, which is about how do we, certainly keep our house in order, but also how do we do a timely job of both addressing new contributions, new contributions, as well as stuff that's been sitting on the floor in tech debt. Thank you, work, honey, for a very long time. So one of the things that I'd like us to see us do and we're beginning the process of pulling that together, I made mention of that yesterday, is to really start also a very systematic way of addressing tech debt. It's hard to do, and you all know the reasons why. I mean, there's always a new shiny object that you have to go off and implement. It's always kind of the latest and greatest feature to be built. But at the same time, we really do need to pay attention, both to stuff that we're going to do, but also stuff that comes from the community and sitting there waiting to be reviewed. So one of the things that we're going to do, at least in the technology team, and I know Wes is thinking that maybe this makes sense for the product team as well, but thinking about the work that we do, code reviews and all, and four different buckets. We have interesting rain. So we're going to have a bucket of goals that all the teams can pick up that relate to the top level goals of the foundation, whatever they happen to be. We're going to have some goals that relate to features that customers want us to build. Every team has customers and stakeholders. Then we're going to have some goals that teams are going to build so that their product, whatever system it is at the building is more responsive to what they feel is important for their users. And then we're going to have some goals that come from tech debt or modernization. And every quarter, all of us will sit together and will make the right choices. So this is a tool, hopefully, that will help us get some visibility into how we prioritize our work. It's really kind of difficult when your head's down and you're actually getting as fast as you can, and you start to think, oh, my God, I spent all this quarter building new features and I've done it in tech debt. Or, conversely, I've just spent six months doing just tech debt and nothing else. So hopefully, with that kind of visibility, we'll be able to make better informed trade-offs about the work that we do. I don't know if this kind of answers the question properly or not, but in my mind, code reviews is part of housekeeping, outside the kind of district confines of the foundation. Any questions in the room or any comments in the room or online? Good. We answered it. We have a brave soul there. So you're suggesting that we break engineers into roles to address different issues. I don't see how that fits with silos. Maybe I misunderstood. No, no, so what I'm suggesting is there are two categories. And we don't split them. Actually, we annotate them so that we make sure that we understand what the balance is that we are going for every quarter. So an engineer could be working on tech debt one quarter and feature the next. It's just overall, as teams and as technology and product, I understand visibility into how we prioritize our work at any given time. And silos are continuing the same work as usual. So I think silos are a loaded term. I think there is a team structure that for the foreseeable future is going to continue like it is. Although, you know, there are changes that are made as needed. And we can talk about those at some point today. For example, the labs team, I see Brian. Where's Brian? So Brian Davis will be taking on the responsibility of putting together a labs team. That's something that we kind of have today but we're making an adjustment to make sure that we give it a priority of needs and so on. So I prefer to speak in terms of teams versus silos. That's a good example where Brian is going to have an unconference session to tell everybody all the great things he's going to do. Just a suggestion. No pressure. Okay. Since this was a clarification question, we let Adam go back to his seat without any action. Okay. Okay. Second question then. During the next year or so, what balance do you think we should strike between new projects and technical debt? All right. Well, I don't know. So how do we... I certainly don't know but I do know a way of arriving at an answer that I think is halfway sensible. So as we plan our goals, actually this is the time for the goals for Q3. By doing this kind of annotation that I talk about, we're all clear about what it is that we're planning on doing. And again, you know, it's something that individual teams and managers need to think about. If you see that you're not making any progress on certain things, on features, because you're doing too much work on debt, swap that. You're going to be kind of sensible about it, right? So I think this... The question really depends on the context of what you're trying to do. If you're trying to do something completely new from the ground up, it's going to be all feature building. If you're going to work on something that's been there for 10, 15 years, chances are there's going to be tech debt. The point is... I don't think it's a balance that is necessarily lacking. I think what is lacking sometimes is attention to the proper trade-offs that we make at any given time. It's the way that the foundation does its work on a quarterly basis we will be making those trade-offs and we'll be making them, you know, as a team while the engineering leads together all the product people together. I would just add, there's a... Victoria came in and one of the first focuses is, well, what are we doing about technical debt? There's a session today. There's also like a commitment from the teams including myself making it more part of our regular cadence of how we're doing our work is the important thing and just to make a commitment to it, right? I would also add that hopefully we don't bucket our work into two different buckets we think more thoughtfully about the whole picture. So annual planning this year and our goals planning is going to be slightly different, which is a good thing. And so as far as new features though they should be thoughtfully done based on communities and so like the discussion in yesterday around platforms where you actually have a PM driving a roadmap and you have or an owner driving a roadmap and you have a commitment of a couple engineers is the right path to help, I think start telling that story what you need to build. So I think there's momentum in this area to balance it better but it's always going to be based on what happens in that annual plan that year input from users and events like this. So that's my answer. Questions, comments? Good. I think he has done a really good job frightening everybody, right? Or it's too early. Don't deviate the conversation. Number three how can we encourage more volunteer contributions to the Media Weekly code base? All right, well first of all I think doing a better job of communicating what we plan to do in more channels than we traditionally do them. Last year here has been interesting because we've been trying to encourage this in different ways. I think there's some progress in the community tech team and how we do the community wish list and we start getting involvement that way and encourage people to participate in what we're building. But I also think it's about not just relying on a mailing list to talk about the things we're doing actually getting out of conferences doing more engagement that way and just doing a good job with fabricator communicating what session was I in yesterday where we're talking about newcomers coming into the organization and having labels that aren't intimidating or confusing so that they can actually participate having mentors help them get on board and start engaging that sort of thing is really a good start. So there's a lot of places you can get I think go down holes and get lost with all of our documentation and our pages so some consolidation there too would also be very nice I'd like to see better documentation to actually encourage that participation. So I agree with everything that I said I guess just a more general comment about Media Wiki so we talked about this a little bit you know yesterday so we had a session on platforms or products too and I could not agree more and one of the you know one of the things that I have kind of personally seen actually in the technology team is that we don't seem to have too many kind of product managers when it comes to the platforms that we're building or maintaining as in the case of Media Wiki so that the fact that we don't have anybody with that responsibility that creates you know creates some problems part of the problem is if there are people in the community that did wish to make contributions to Media Wiki or to make them it's not clear what the pathway is from making a contribution and having that become part of the distribution if you like and that is really you know there needs to be a gatekeeper there needs to be a product manager whose job it is to maintain kind of the integrity of the piece of code in terms of features and so on so one of the things that Wes and I have been talking about with the teams more broadly is really kind of starting to redress a little bit this okay how can I say this politically I don't know how to say it politically but I you know when I look at the kind of code base that the foundation kind of relies on to deliver on this mission a lot of this is Media Wiki there's a whole bunch of other things that we do as well and Gabriel here runs a service system that is superb and while I believe the separation between Media Wiki and the services that will continue to build is a good one because we can't put everything that we need to run the foundation on Media Wiki it seems to me that we have also neglected it in the past few years perhaps I I would strongly favor addressing this balance a little bit and having a focus again a renewed focus on Media Wiki within the foundation to have a small team whose job it is to really address tech debt on Media Wiki help the community vector their contributions and the right way to help them incorporate them and more importantly having a single person whose job it is to put their arms around the product but both inside and outside the foundation people have a way of bringing their innovations and contributions to the God base so we are as you know these are early days for me we are going through we will be going through an annual planning process which will be the first one for me so I don't exactly understand how it works was understands much better than I but the intention that we have jointly is to make a proposal that we create such a small team going forward this coming year I'd also say the consistency of using the community wish list through hackathons through this event and focusing on that has been helpful to start creating that you know just a common way to understand how we actually address things and how to get involved and so that's been a nice thing to see over the last year and I'd like to see more of it all these volunteers for work note takers please take note so this is actually a clarifying question from someone on IRC we're not oh who am I I'm just a little later my name is Greg or this manager it's related it's not really clarifying but it's how do we utilize other affiliated organizations or communities or I guess communities is broad enough groups to be contributors to media wiki or wikimedia generally beyond the usual suspects like wikimedia dutchland etc is there a way to reach out to those that we haven't done the unknowns I think there's a lot of things we've tried or haven't done or can continue to grow I mean different things like ideal lab and other things that have been tried are great pathways and focusing on those a bit more would be a good thing I also think that as we go forward there's a structure data grant that we just got involves a lot of other partners outside of our normal engagement and we can have more meaningful conversations through those initiatives it's actually written into the grant so that helps keep us I think focused on the idea yeah so maybe just a plug for Kim's team is your team's kind of responsibility to actually engage with the community broadly and you do that through for example the WM stake great redirect yes and there's a task about this but our team is reluctant to engage organizations outside if when we finally get to excite them they start contributing and get against all these walls that we are talking code review, lack of roadmap etc etc so we have a loop to fix that I have a quick comment that uptails with what Greg says which is just that it seems like the first part of your answers before Greg pressed further seemed to me in some degree backwards in that I think one of the big challenges for open source organizations and for this one in particular is that we tend to hire all the good contributors our solution to getting more community involvement is to hire more people and bring more people from the community inside the foundation and then there's no one left outside so the community wish list in that sense is kind of a step backwards in that we're getting the community all excited about these things and then we're promising that the foundation is going to fix all their problems or at least the important ones where if we said there's a community wish list which the foundation promises to do nothing about but will really review your patches well it would probably be less popular in the community but it might actually encourage more of a community ownership of those issues and so that's I like Greg's question because I'm interested to hear more about how we can support community members without bringing them into the organization and without you know without sort of the other thing that you mentioned was bringing contributions from outside into running on the WMF servers into protection and that's a very common thing I hear is like I was just at the semantic media wiki slash page cargo session and that was all about like how can we get this running on WMF servers well yeah that seems to be the thing that we're saying is the way to get your thing like actually supported but it also means that if that succeeds the very vibrant community which is out there which is supporting semantic media wiki will feel like we're taking care of it now and they don't have to do that anymore so I'm interested in how we can do less to support the community more that's an easy question I mean I would just say documentation is one thing but also like consistent understanding of what it takes to go through code review to you know engage into fabricated types of labels are accepted that sort of thing mentoring people to come in to explore more things not being afraid to talk to people outside of our norms yeah my sense is that once we start really building and maintaining a roadmap a media wiki roadmap I think that's going to be helpful to people not only inside not only outside but also people inside the foundation because in many ways what you described is something for example that I have already seen in our research team so you know they've done spectacular work with ours and this is done in a lab kind of environment now the question is how does that go over to production and who maintains it once the service is out there so I think really the solution to all of this is to have a robust kind of roadmap for all the products that we build and once commitment is made to put something in the roadmap or to bring it into the product then the foundation really has to step up and maintain it that will go forward I think that's the value of having perhaps dedicated resource inside the foundation for some of these things just a reminder it was C. Scott and please tell your names before asking Hi my name is Darlian Hartman and I am a volunteer contributor to the media wiki code base so yesterday we had this discussion about easy tickets and how we can use them to help people on board basically into the process and I think that it's very important and one of the things that came out of that is also that this is a very fast moving bandwagon to jump on as a outside contributor and there's basically nothing more important than us going out there and basically mentoring people and making sure that they have the option of jumping on this fast moving bandwagon and there's a lot of human contact basically that is required to a human investment to make that actually happen like some people might not require that but those will be much more rare than the people who do require that human interaction to become a successful contributor and I think and I feel that there's not enough space for people to exercise that to do that because there's always higher priorities and any sort of whenever this happens right now this is purely a personal motivation which is good but I think we can be more motivating than just out of pure 9 in the evening personal motivation outside of work encouragement so that's what I want to say and I'd love to hear your thoughts on that I totally agree with you and again you know my expectation if that's not true we can certainly work to fix it is that there should be in the foundation a team that's dedicated to support the outside developer community and my understanding as of yesterday was that Kim's team is doing that perhaps Kim's team is not doing that today because you have not been infected that way but I couldn't agree more right I mean you need a team whose job it is to actually advocate for them as we you know make decisions within the foundation about what we prioritize and what we don't a team that gives them the tools that they need in order to come you know to be more productive and I mean for me honestly the analogy is you know I mean when I was at Tom we were building WebOS for you know tablets and phones we relied on third party up developers we knew that without them they would not succeed so we had a dedicated team that not only kind of did community work they actually did coding to help them so they would build out for example you know apps that you know showcased specific aspects of our frameworks and so on so you know you have to be very deliberate about it and very kind of consistent and it would be you know my desire certainly to make that I can like for my personal and I hope I'm not offending anyone but I sometimes feel that Kim's team is a bit okay I'm going to use the word a bit too siloed in that they don't have enough of a mandate to go outside of their own team because I think this is also an organization wide something that should be encourage organization wide and I sometimes have the feeling that even though officially that mandate is there in practice that mandate simply does not throw out the rest of the organization and I think that could be better understood I mean having authority doesn't it's not the same as exercising it so you need to absolutely I would just say that I agree with more personal interactions and opportunities for sure and that session was really great yesterday to talk about some of that Cindy Chickalice I'm also I guess a volunteer contributor although I don't not 9 p.m. on my own time in the evening only there's a lot of that but also I work for MITRE Corporation which is a federally funded research and development center and I have contributed both to media wiki core as well as a number of extensions and I would say that you know it's a wonderful community and I've gotten a lot of wonderful interactions with wikimedia foundation staff who've helped me with some of the patches that I've included and getting things merged it has not been a pain free process but it's been a still very rewarding and wonderful interaction I'm also a member of the media wiki stakeholders group and I hope to that we'll also be meeting with you guys to talk a little bit more about our interactions in the community I just wanted to speak again to the contribution of and the benefits of having the media wiki software used not only for the wikimedia foundation but also just in the spirit of having code, different pathways through code exercised by different people using it we've got a lot of our within government installations as well as other folks that we help with deploying media wiki as well as within our own organization have determined a lot of different use cases as well as different pathways to the code that have helped I believe make the media wiki code itself stronger and better and the more people you have contribute from more different perspectives really makes the code better for everyone and again I've really appreciated the interactions that I've had with the wikimedia foundation staff and I really do like what you say about having a stronger relationship and liaison in somebody, a team particularly supporting those outside users because I think we can all benefit I couldn't agree more I agree on both scores having more people exercise the code, results in better code for everybody and having people contribute features foundation can build stuff, we can't build everything that can be built in a broader community so I think it works both ways I couldn't agree more, honestly this makes perfect sense it's like we have two engines right now and they're not connected so we need to get the gearing right between the two of them and it would be my hope that we will address that sooner rather than later it's not like complicated we just have to do it this is a great opportunity for me to hear from all of you what you think is working and what is not quite working the way it should be because that then gives us the information that we need to go back to the investments we need to make and please by the way continue that feedback going this session is going to end but I think we're going to try and keep that list active Kim past the meeting today and we will also try to have I would favour having for example monthly IRC sessions we just do this kind of thing to stay in touch so I would welcome that thank you I'm from Wikimedia Foundation's research team so here we are mostly talking about expanding the developer base around media wiki core and improving media wiki core and in my experience as a volunteer I see a lot of opportunities for bringing in developers for non-media wiki core so basically there are a lot of things that are being done by the community for Wikimedia projects which are not about the core code base and I see a lot of opportunities for encouraging people to basically contribute to those areas and when I think about the work that we do in the Wikimedia Foundation I feel that a lot of our responsibility is basically empowering chapters and affiliates to bring these people in the whole ecosystem instead of thinking of basically taking all the work on ourselves basically Wikimedia Foundation to be more also about how to kind of have a more inclusive ecosystem in which the chapters are empowered to bring in more developers because at the end of the day we are very small and we are meant to be small and I certainly agree I mean part of some efforts with Wikimedia Deutschland was really exploring our chapter relationship and how we expand that from a development perspective and it's been a very rewarding experience for me personally but it's also been very great to see how it affects some of the efforts for the movement so but beyond that different types of technology we're a knowledge organization so we should explore everything right? I agree with Ulalia and Wes and again an observation I mean we're really fortunate in having people from the outside that they would be thinking about and doing what to what we're going to do I mean that is a privilege that is really wonderful and it's very unusual so we should make that kind of engine as efficient and productive as we can thank you Hi I'm Chad just to comment on what you guys were all just talking about I've thought about that for a little while now like my whole idea recently has been we have the community wish list and we're going to do the top 10 things like let's get items 11 and 20 and see if another chapter can take those on and try and get the other things done that we can't do but my question for you both is like with any organization sometimes projects don't succeed we have endeavors that we go down and they just don't work and my question is how do we measure when a project isn't working when something that we're trying to do just isn't going to work out and deciding to back away from it and not do it anymore instead of doubling down and trying to force the completion of what's going to work out do you want to take that? I mean first to start with a roadmap you got to actually say what's important to you as a group and then we don't do it well I'll just be blunt nobody does it well nobody does it well, some people do it better than us but you know sometimes it's about it's just making that decision and there's been a couple of instances this year where we've at least come together as a group as an organization to identify a couple things but we didn't look holistically at the entire backlog right and we need to get to that point where we can look at that a lot better building a small team to start that and look at the actual you know sheer amount of tasks that have been unhandled and also review all of the different things that we support is something that we're working on we have another session later today to talk about some of that stuff but I also know from the product teams we've listed out the types of things that we're supporting right now it's a better job of actually then supporting the things that we need to shut down we've done a couple things with services where we've looked into you know community adoption we've done some additional things around analytics to start understanding how much it's being used or not used now it's really getting to the point where you can say make decisions provide the rationale and explain it with everybody before you just kill it and move forward so I just to add to that starting things is easy stopping things is virtually impossible and I believe that's true for all organizations not just us so what can help well I think having really the fortitude the intestinal fortitude to say no when we know that that doesn't just mean management by the way that has to permeate the organization I mean more than any other organization whatever we do is paid for by contributions by people that read our products every single person here needs to be an advocate for those dollars that come in and the point that you see that something just ain't working say so don't wait I think that's one thing so it's cultural the other thing is the way that we do our work so if for example everything that we do has well defined and measurable goals and we see that quarter after quarter we miss our goals then maybe we can't do the work or maybe the goal is unattainable either case you take stock and you decide if you will continue or otherwise so I think it's both cultural but also the way that we manage our operations and how we decide what our goals are placed into that we have been 30 minutes here half of the time went to this question and actually we started deriving out of it so that's my contribution as facilitator we still have more about this remember that the more questions the more comments to this one are stopping the question number four okay following up on the earlier remark about scaling and averaging other people's work I think two developer audiences where we actually are relatively successful at doing that is using upstream code we have adopted quite a few projects that have a community outside of what we of the people that are in this room and we just use their work we contribute some things back but for the most part they are invisible right now but I think they still have a very large contribution to what we get to do and I think we should acknowledge that and possibly also manage that relationship a little bit more consciously because the contribution is huge and this is very scalable because they have a community of their own and they sustain them outside and they have ownership of the project the other is that Leila also emphasizes that we provide APIs and we have a lot of people building tools around that and I think that's a second distinct developer community that we invite and that is also very scalable because people have ownership of their respective parts so I think I see this as three different parts and one of them is the platform itself but the two others are kind of outside so good morning I'm James where I am something of a product owner who is partially funded by the Wikimedia Foundation but through grant making rather through product and so I work on software features for Wikipedia editors I originally come from the community over time I've recognized some needs the community had and I figured I'd turn this into an actual project and we're making some progress but it's kind of an interesting thing because there's actually a few of us now or is the AI service was originally a grant funded project and I think there's also now a content mining project that is also funded through a grant but we're in this interesting position where we're not part of the foundation but we're not totally third party either we're like midway between the foundation and third party and I do appreciate the independence to some extent because I think it gives us a better position to experiment than if we were a part of an institution on the other hand I do think we would benefit from some kind of coordination so that we're not totally outside of the loop and so I'm wondering what the Wikimedia Foundation can do to have a more untraditional but more inclusive approach to product development that where you have not only your internal product teams but you also have external product teams that somehow skunk works is what he said but how does you have a product team that includes the Wikimedia Foundation but also people outside of the Wikimedia Foundation that are all working toward the same goal for me that's starting to have common anchors of understanding whether that's best practices documentation or just code review practices things like that you need to have enough that there's some sort of consistent language but then the freedom to explore beyond the boundaries of what any one institution may have it'd be nice to blur the lines make it much easier for anybody to follow the same sort of set of ideas and then be able to contribute the code for everybody we do some of that well we don't do some of it well the process with the TCG technical collaboration guidelines is a step in a direction of trying to identify the types of things we hold important for doing development that's going to continue to grow and change and be discussed so that's one thing and I think since I'm one of the first people doing this like traditionally the grant making teams never funded software was one of the first exceptions but since I was going to do this anyway I know you want action items out of this but I think one of the I feel I'm responsible for coming up with guidelines on how to externally develop a product and just how to make that transition from being a purely community member to someone who is actively involved in the product process as someone trying to you know on a somewhat professional scale trying to actually develop things that users need and as opposed to just pure hobbyist development which is also useful but I would like to help in making that more reality for other people because I know that there are other people out there who are interested in this stuff so I look forward to making further progress on this so I thank you first of all for the volunteering and I think the comment that I want to make is that you know being able to kind of develop and deliver solutions of whatever variety to the world today is it's an ecosystem story anywhere you look right the most successful kind of technologies in people's hands that come from ecosystems and what you're talking about is you know how do we own or value take advantage of bringing to the fold that ecosystem on which really this foundation and its mission depends right so you know I again I want us to be very thoughtful about it and it sounds like you know we have a great deal you know of good material to work with you know we just need to make sure that you know we create these linkages between that community and what we do inside so I mean to me that actually it's kind of interesting I had more or less assumed that this was happening since it's not happening this is you know great feedback and I'm sure that you know you'll be hearing from us in the future thank you I have another one from IRC this one's from Katie basically the question revolves around the topic that we talked about yesterday about the architecture committee and platforms that whole topic her question is mostly around where and how does our RFC process fit in with road maps fit in with annual platting fit in with everything else that we do as an organization and I think it's depends on which way you want to look at it does the RFC fit up into the annual planning or is the annual planning affect the RFC process so take that please answer this question keeping in mind volunteer contributions which is the topic I think that's her perspective as well is I might be over speaking her point but that could be an avenue of affecting the road map you know I don't understand did you say RFC the architecture committee request for comments process where everything that the architecture committee does revolves around right now people propose RFCs explain the problem what's the solution so in my mind really it's the job of whoever is the product owner or the product manager for this platform to make sure that all that input is brought to the table, is discussed prioritized, sorted through and then committed to or not having that kind of determination be made plain without a focus of somebody whose job it is to make these calls you're in this Netherlands where people feel like contributions are made but they're like throwing pasta and it doesn't stick most of the time so I think the answer in my sense is that again you know we create focus through creating a product manager for for media wiki and other components of the platform other components of the platform some of them like get more you know more visibility just because they're new perhaps and some don't but I think it would be incumbent to have more kind of you know thorough delivery process for all the components and all parts of the community to a previous questioner Hi, my name is Marc Schubert and I'm a volunteer developer and my main focus is on math and I wanted to somehow share the experience I made as a volunteer and first of all I think the big game changer where it started to make fun rather than to be frustrating was when I got real contact at Wikimedia so actual people to talk to and I think this is this is one of the major points that you don't only have fabricator tasks code review and so on and so forth so that you have actual people that you can talk to and I'm a researcher and now I have a lot of students and I'm trying to motivate them to bring their research developments to actual products and to try to if it's possible to somehow move them into production and what I see is that that the reason why they somehow also face similar problems that I faced in the beginning is simply because they are making mistakes so they are filing fabricator tasks which have no real answers I mean they are hard to answer so like I want to build this and this project can someone help me to build it and of course nobody replies anything and I think it's maybe one of the most important things to have one contact for each person who wants to contribute to Wikimedia products that he gets some guidance and sees what is his mistakes and that you really get honest feedback because if you submit a patch which is bad probably everybody is friendly and nobody will say okay forget about it this is really crap. Thank you. We talked about some of the mentoring stuff that you can do to engage with someone to see their work through so if they take an easy task they don't just maybe it's not easy for them they can actually have some help and then there is some consistency to actually get it through to keep the conversation. One challenge I've noticed is we do office hours and we do different things like that but it's lacking some of that more personal connection that you get hackathons and that sort of thing so I'd like to see more of that too I think the personal connection helps grow things quicker being a remote person myself within the organization I get challenged with that on a regular basis There are still two people I think I can propose that please quickly and then let's move on to the next one That's good. I'm not very good at asking quickly so I'll really try so I work at the foundation I do a lot of mentoring programs and for me my experience is that our documentation is absolutely atrocious and it is a really, really huge barrier to entry especially to people who've never dealt with our code before it's really good to say that engineers should document more and for the most part we do for the code but we are not really good and trained and we have a lot of developers and wiki and stuff like that can we deal with this? Can we get someone to write these things that actually know a tech writer? Maybe a tech writer We tried to hire a tech writer and we couldn't or we hired them and they couldn't tech write We need to speak with Mike Let's not talk about a tech writer I figured I'll write my question so it's more concise I have been a volunteer contributor and developer for the past 11 years foundation employee for the past 4 years My question is how do you reconcile the desire of foundation to structure and plan and manage projects versus the open source movement culture and values of ad hoc development and contributions? Let me just take a crack at this The foundation is a very interesting kind of animal It's interesting because it cannot possibly succeed without participation from the outside In fact the foundation was very small few years ago and my understanding it's grown quite a bit but most of the work and the value that the project created came from the outside I don't think that there is a fundamental kind of divide inside or outside I think it's a matter of setting the right priorities at the right time and I think the only way that you can do that is by having everybody around the table is to having somebody whose responsibility is to learn what is needed from the outside as well as from the inside and bringing that in But I will tell you at the end of the day I personally couldn't care less if it's outside or inside What I care about is for the foundation to deliver on this mission which is free knowledge for everyone If that is kind of the yardstick that we use to measure everything we do we should be able to make those choices without too much heartache I will make a statement here which may be a little controversial in this room but suppose that there is a choice now to be made and again, either it comes from the inside or the outside that benefits the open source community that is built around the foundation but it's to the detriment for example of the educational goals of the foundation That's a hard one to solve How do you solve that? In my book, the mission always wins In other words, the open source movement has been critically important for the foundation's success but in my mind it means to an end versus the end This is Victoria speaking I'm not speaking now, there's corporate or anything like this, but that's how I would make those trade-offs I would say that great tools good documentation removing the friction of actually being able to do things not having to go through 12 people or anything like that to get something done, having a clear set of guidelines that you know if I'm going to commit this code, and I'm going to push it for release it's going to have the confidence of our community that it's been thoroughly reviewed and that it's not going to blow anything else up Providing tooling providing a better lab system that's like robust, confident, doesn't go down so that you can constantly try different things is how I see it we shouldn't be doing all of the work by any means we should be empowering the work that other people can do I think it follows some of the same things that being rigid in our approach to how we think about what gets developed and also encouraging more conversation bringing more volunteers into the organization that aren't rigid or siloed in their thought being more remote friendly those types of things all lead to a better conversation from a lot more angles if you only think from one perspective and you only follow one plan without being open to talking about it every quarter or every few months or all the time on the channel you eliminate the possibility of growth does that answer it better? OK so a bit more than 10 minutes to go I haven't cut anyone because as a privileged witness I can say that every single person who has come to the mic has spent plenty of time as a volunteer developer while being only volunteer developer also while working at the foundation or somewhere else 9pm or later so thank you we've also answered some other questions on the list as we've been going through the conversation so after we go back we'll try to correlate the notes to some of the other questions definitely but I'll keep my joke about the action no action point for all these people because they already like doing a lot of work in that direction so thank you very much personally thank you from me also clearly like I say this place doesn't work without contributions from the outside and like sorry if we ever fail you like I don't think it ever happens on purpose OK 10 minutes to go let's try with question number 4 what is the biggest threat to Wikimedia? in terms of technology OK so I have a team my titles maybe I should just talk about that for a moment so I think a couple of things one is like how do I say there's no English word for this monolithicity if that was a word you know the world is kind of very complicated right so we used to be able to do when I started the first time I wrote the program was 1978 back in 1978 like you wrote everything like everything in order to make anything work you know fast forward we now kind of rely on innovation and kind of code products from all over the place and that's how we make progress that's how we create a productivity that is you know through the roof and so on so I think you know having a notion that there can be one single piece of code that we as the foundation and its community you know maintain and advance and that can see us into the future I think is a fallacy I think you know we need to leverage what others are doing like crazy I mean you know all these companies in the valley they talk about open innovation so you get companies from all over the world they look into the valley to take part into open innovation and what they mean by that is borrowing technologies from others now to give you an example machine learning I mean every man and their dog on the planet are investing on that do we believe that within the foundation we can build the kind of machine learning algorithms in the planet no I don't believe that can we build things that are specialized to what we want to do absolutely should we be leveraging what others are doing like TensorFlow for example what would be crazy not to so I think that's kind of the first part that kind of I would like to kind of to share with you you know we need to keep an open mind and kind of leverage innovation from wherever it comes let's not be like religious about my goodness it has to be part of media otherwise it's not good forget about that the other thing that strikes me and again this is somebody who's really still on the outside I'm on the inside but also on the outside and I have not been an editor I've kind of toyed with it in the past never really thought about doing it seriously I started to use our products started playing a little bit with editing and it strikes me how kind of difficult how elaborate I mean it reminds me how programming was 20 years ago or something and why do I say that I think it represents really a trend not a trend it represents a status within the community and the foundation that has diverged a lot from what I call almost like you know casual computing if you like this is really visible in the case of editing it's also visible in the case of reading especially on tablets those of you that use the product on tablets you will see for example load time is atrocious and so on why do I say all that I think that as well as kind of understanding that innovation will come from many places and we should be open to bringing it to the mission the other thing that I think we are at a disadvantage today is this whole thing about mobility and I know the foundation in the past has tried to address this there have been ups and downs but nonetheless I think we are the place today where it almost feels like the world has passed us by when it comes to things like editing for example you know yesterday actually if you notice yesterday was the anniversary of the introduction of the iPhone so Steve Jobs stood up a few miles down the street here and introduced the iPhone to the world and he packed that and yes we have apps and we have this and that but actually what it has done is it took computing it took this really very kind of esoteric thing that some of us kind of learned back in the day when it was really kind of complicated and maybe something that is available on top to most people when you sit on your couch at night and you watch TV on top you know you don't think about you don't make an investment a deliberate action to have that computer available to you it's just there so you know what the iPhone and what the mobility kind of movement has done is it turned computing from an esoteric kind of you know infrastructure capability for the few to casual available technology for everyone so if you take that paradigm and you think about how that applies for example the creation of the quantum in Wikipedia we are behind there's no there's no drag and drop of images for example in Wikipedia I mean these are very simple things so I think you know what we need to do you know this is the kind of second step to the question if this indeed is a threat what do we do about it I think you know we just need to like to think how we want to represent knowledge what do we come from will it only come for example from truly encyclopedic communities would it also come from communities that create this knowledge casually as it is also consumed casually and I don't know the answer to that but I think that's a question that we should be asking ourselves as a community and as a as a foundation for me the risk is if we don't fund the team to work on the roadmap we're not going to make any progress that's to happen in our annual plan this year that's simple if we don't do that it's a huge risk we'll just continue to have the same conversations we've had for years over years and we need a point of progress commitment which means committing to removing code that doesn't work anymore and it's okay that's how you also progress rewrite the whole thing no just kidding but I think risk is something that you perceive either as a fearful thing or as an opportunity for me the risks of an action eliminates all opportunities right so commit to a date commit to moving forward on something it doesn't mean it has to happen that day just means that you have a milestone to work against and then lastly flexibility and I would include documentation and everything else that we talked about it for clarity but flexibility means not not being rigid our guest speaker said that yesterday you know learning a new language is an okay thing it's how you grow if you only if you don't bend with the wind you know you break so I think being flexible in all the different types of technology that are coming in in the different ways of actually conveying our content is something for us to encourage and to encourage that exploration and we have the opportunity in our roles to help empower that but we need clear concise proposals and plans to work with you guys to make those resources available so we're a risk if we don't understand what needs to be done just like we have the risks out there if we don't commit to a specific sort of timeline and specific set of teams so I'd really like to see this all happen this year of course ambitious I know you guys in different ways we've talked about the same things over and over again but I think it's time to commit to some stuff and move forward there's always going to be risks all right I think the time and the moment is good to leave it here thank you very much for all these ideas to both sides of the room and beyond in the internet so yeah Victoria West thank you very much so now we have a long-ish break and conference sessions are for the day are now scheduled in the world and during the break we are going to put them online in the program thank you very much