 Let's go ahead and get started. So we've got the rules assigned. You'll see here I'm doing the split screen thing. This was an experiment we did in the code review section where we had a separate meeting summary up above and then a detailed notes down below. And I'm going to make at least an effort to keep both windows focused on the right areas of this. But the idea is that we'll have a summary that describes at least what we're doing. The thing that I found works the best for the summary, or at least this is my hunch, is that we stick with a list of, like, as we summarize, we only summarize. These are the questions that you can find if you read the minutes. And that's like the one thing that I think sort of keeps the conversation going while still at the same time you can, in real time, frame things as a question in an NPOV way and then have the detailed minutes there where the presumed answer is as you have the discussion for it. Anyway, we're slowly gathering the quorum here. So thank you, everybody, for I had a wonderful time. I hope you all did too. I think it was a great summit this year. And I, but we'll have surveys to find out what you really thought. And I'll let Kim and or Rachel talk about that a little bit more. And where did Kim take off to, by the way? Oh, there you are. So the thing that we did this year was we divided things up into areas. And as I talked about these areas at the beginning, we have what I thought were a reasonably clear division of responsibilities, but reasonably clear. Not that there were crisp lines or anything, but we had a reasonably complete list of questions, big problems that we were trying to solve. And I would love for these areas to survive. And I think the theme on this wrap up is to try to figure out what do we do next with in each of these areas? And how do we keep ownership and survival of these areas? I'm certainly going to, I will take it as an action item upon myself to help make sure that these five areas stay alive, but there is going to be a limit to what I can keep alive if there is no prospect for keeping, if there's not a thing to keep alive there. So let's go into the specific areas and what we talked about there. And I'm going to go in what I think is chronological order here of the various area plenaries that we had and talk about each of these areas. So the first working area that we had a session for was the user interface presentation area. And that's basically trying to figure out how do we make our software more usable and make it more of a joy to use it. And it's basically the user experience of our software. And in many ways, it's what the front end standards group was already focusing on. And so in some respects, the answer to, can we keep this area alive? The answer is obviously yes. We have a user experience group at Wikimedia Foundation. We also have a front end standards group that is pretty much focused in this working area. But that said, and actually furthermore, that we have the idea of the user interface, or we have the front end standards group. Actually, we have two front end standards groups. And so maybe, Volker, maybe if you can take a microphone and just explain, or either you or Timo, whichever one of you wants to do it, and just explain the front end standards group, and does this make sense to keep alive? Is that the right model for keeping this alive, or is there some other model we should be exploring? So I was very happy to be here and to work on those issues that we agreed on upfront. I think we had fruitful conversations in, first of all, bringing all people on a certain level of what the challenges are. The front end developer standards group might, there's a big overlap in topics, and we might even focus further on the topics, especially raced in this summit. There's also things that affect certain groups within the foundation, certain teams within the foundation. So we try to come up with action-enabled items. There will be, towards the skinning system, there will be a hackathon part tomorrow, where we want to continue the work. And maybe, Tim, will you want to add some words to the outcomes? I'll provide a bit of a summary of the actual two sessions we had. And there's also been a few breakout sessions separately. I didn't attend both of those. I don't have all the notes from that. So our session followed right after the talk about potentially using service work and the various splitting up of the architectures in the back end of that. And so we actually had a few action items that I'll briefly describe here, that were quite universally heard as something that we want. So for one is further use of OEOI between extensions, core, and even perhaps towards the user side of things in templates and Lua modules to allow better reuse of components between different wikis and between different pages while still allowing different skins to sell out differently. And that is one of the things that is currently a real hurdle for mobile fun and for mobile apps where a lot of things are hard-coded inside pages and generalizing these with OEOI would help. This doesn't necessarily require that they look different, just that they use a different HTML structure part by that. Another one is, again, it came up many times in the different meetings is page components, using components that can be expanded afterwards rather than as part of the parsers so that we can give more power towards different apps and different skins into how to expand these different modules as well as without needing to do cache recommendation and different reuse of that in a more semantic way. And lastly, the one that just came up in the setting in a session right before this and also in the session yesterday is we really want to sanitize things like info boxes, nav boxes and all those things. That is in a long time coming and is now more clearly becoming a blocker for certain future changes and different ways of presenting content to users that we really want to sanitize on it. It's about time that we actually start to tackle that problem. And do you guys feel like you have sufficient agency and authority to enact the things that you want or is there still some lack of clarity on that front? I think there's still a lot to be done there. It does help a lot. So we constructed a few goals towards the end of the session with Trevor. Do you have any here right now? I don't see him. So to further help the resourcing of these things, it really helps to also have certain goals in mind, like what do we actually want to solve? There's a lot of good ideas out there, but you need to be able to execute and prioritize them. You need to have some goals. And so the main goal that we try to focus on in justifying what we include and what we don't is being able to treat apps, mobile, desktop and especially logged in users, the same way that we treat logged out users. So we need to unify certain infrastructures to be able to allow that to actually happen, as well as from a performance perspective. In terms of resourcing, I think the front-end group has a lot of people on it that are both designing things as well as actually implementing things, but it is still mostly on a more or less volunteer basis. So I think we do have some of a need there for some kind of recognition, to be able to actually assign things to people or to teams, like who is responsible for these things and what are the more user-facing and results that we can justify for these resources. And do you feel like assignment is the right model or do you feel like sort of inspiration and getting people excited about? Yeah, I don't think direct assignment is the actual model that we want here. I'm going to space that a little bit. Ideally, civic changes in the software are justified indirectly, as opposed to just a change themselves, instead you justify it because it allows something to be done that a team actually needs. And so that naturally solves the assignment issue because it would actually be something that someone wants to achieve a particular goal of theirs. If a change is only a change itself with no actual end result, then lack of resourcing is probably good. Yeah, and one of the things that we've talked about in the architecture committee is to have a working group model. And the front-end standards group has been a working group. In fact, it's been sort of parallel to the architecture group and so there's been some question as to whether or not these two organizations are peers or if the architecture group is back-end and the front-end standards group is front-end or whatever. Do you see the front-end standards group as a model for how we should be thinking about working groups in this, just in the same way that we don't have authority necessarily per se, it's about collaboration and inspiration. Do you feel like the model that we have right now is a workable one in that the other four areas should aspire to be working groups like the front-end standards group? Or is there some other model that we should try to shoot for? I'm not sure if our model would work for other areas. It might. I know it works really well for us, but it works well because we're able to use this group as a way to present more or less consensus forward towards the rest of the organization. Perhaps in an indirect way, we do have the authority, but I would like to believe that that still lies in the architecture committee for a wider direction because there have been some changes in the front-end standards group where we've decided on something that turned out not to scale well once we actually applied to production. So I think it is still good to have that level authority from the architecture committee on top of that, regardless of how we structure the underlying teams. Okay, and where the architecture committee, I think in the past, has saw a lot of its responsibility as been to basically be the gauge of consensus, like not necessarily to be the group that is coming down from on top and saying, thou shalt do X or Y or Z, but is the group that basically says, do we have consensus to do this? And then sort of enforcing the consensus gathering process and wanting to be members of the group with which consensus is gotten, but not necessarily like the last holdout. Yeah, I mean, I'm not necessarily the most neutral person as a consensus I am in both groups, but I would like to believe that it's not something to strive to be a member of the architecture committee to be able to be part of the consensus, rather it is our job as architects to try and reach out and as you say, gouch, what the consensus is with an added filtering to seek for what is responsible in the longer term and to be able to correlate different things in terms of performance and scalability and correlate that. Because the most common opinion is not necessarily the best one to go forward. So there's still some responsibility of our own experience to be mixed in there as well. But yeah, overall, we should gouge for what the consensus is and not use our own, of course, yeah, absolutely. Great, thank you. Any other comments that either of you wanna make right now or should we move on to the next group? Okay, great, thank you. And thank you for being the guinea pigs for the process. These guys were the first in this, which they had the advantage of having already had the front-end standards group, but at the same time, like this was an area where we didn't know how to run this particular type of meeting and so we learned as we went. And so the next inline in the learn as we go is the content format area, which Tim and I were up on stage for. Tim was the leader for that. And so maybe, could somebody hand Tim a mic? So yeah, either or you can step that works too. So yeah, I guess, so the content format area is one that there was certainly going into this much less clarity as to what the group was responsible for and we still don't necessarily know. Do you feel like you have a better sense of what this area, how this area is scoped? Yeah, I think I have a good idea of how it's scoped, although it's still a very broad area. And the initial focus discussion was very wide ranging. We had a lot of speakers lining up at the microphone to say their bit about where they think this area should be going. And so what do you see, like just to bring up a couple of examples, like if you can think of a couple of examples of like an example of one that a proposal or an IRC that's clearly in scope for this area and then one that is not in scope for this area that somebody might think is. Yeah, I mean there's definitely IRC's which kind of straddle areas. When we talk about content format, I guess we're thinking about storage, about content representations, things like the maps and graphs and things like that, they sort of touch on both user experience and storage and content format. Yeah, so I suppose they involve discussions in both areas. Yeah, and in fact, what we're gonna find with a lot of these areas I think is that there's significant overlap. It's not like there's any one particular area that has authority over this, but there's certainly gonna be areas that have expertise and should be consulted. I think is the better way of thinking about this. And so like let me just, let me pull up a random example myself. So like let's say a couple of years ago, there was the big debate about which codecs we should allow to upload to commons without weighing in on that one, because that one is like third rail territory if you know like the whole US politics metaphor there, but basically like kind of a dangerous touchy subject. Would you consider that in scope or out of scope for the content format area? Yeah, it's probably out of scope. It's mostly out of scope because, yeah, I don't know. It's something that like a codec is pretty self-contained. Most of our sort of infrastructure is pretty much independent of what codec you're using if you know what I mean. I don't know how you feel about that, but. So perhaps one way of thinking about it is the sort of normative format because we have to store the video in some format. When we're not gonna store it uncompressed, right? So the normative version of the codec is one is within content form or potentially within content formats. The delivery format you would say is outside. But the storage of it is within content format, but then how we deliver that to the user can be any number of other codecs, right? So for example, we could store it on disk in a free format, but then the delivery of it in a non-free format might be out of scope, for example. That's just my idea, but that's like that shows you the complexity of like figuring out these areas is that front. So yeah, Daniel, please weigh in. I've been wondering about the word format in this context because I'm kind of with Tim, right? I wouldn't care what format people actually use for images or video when they upload it. I care about infrastructure. I care about transcoding stuff on the fly or whether it's a good idea and stuff like that. So perhaps a better term would be content representation. It's about how we represent our content internally, how we structure it, how we store it, how we compose it. So in my mind, when we focus on the representation, it becomes more clear what is in scope. Yep, that's a good point. If we were adding closed captions to videos, then we would have more interesting discussions, I think. Well. Right. Okay. So yeah, given that there's a lot of stuff that probably is in scope for this area, how would you see keeping this area alive? Should we start up yet another mailing list? How would you, what is the best way do you feel just top of your mind, what might work or do you have no idea? A fabricator backlog, I guess, a project in fabricator, which is regularly checked and tasks assigned by maybe by the architecture committee. Yeah, I think something along those lines. I don't know, like making a mailing list doesn't necessarily guarantee that people use the mailing list. I guess if you have a team, then a mailing list for that team makes sense. Yeah. Okay, and yeah. Can I say, I think one of the things that was useful for me in other sessions about this is the idea of a roadmap, even a sort of tentative roadmap. So for example, info box related stuff came up in a lot of other sessions and I could sort of more or less confidently say, oh yeah, that's related to this, but we have a good idea for how we're going to move that out and eventually do composition so we can do semantic image styles later with the sort of confidence that we can generalize this to info boxes and nav boxes, that we have a plan for that, right? So not just like a backlog of things, but a backlog of ideas that we know we can delegate to this team. Like these are things on the roadmap. That's fascinating. So possibly even the each area, like there's a wiki page associated with each area which has the roadmap from that area's perspective and we debate the contents of that roadmap. The multi-content revisions I think came up in a lot of cases too and very different things wanted to sort of think about articles as a collection of different pieces, right? And so letting them know that they don't have to solve that problem themselves, that it's, you know, but that maybe they should pace themselves to sort of wait for this working group to get done with that and implement that, you know? Gotcha. Okay, great. Thank you. So any last comments, Tim, or anything you wanna add? Okay. So let's move on to the software engineering area. So Daniel, yes. So I guess some of the same questions here. Do you feel like the scope of software engineering is reasonably clear in your mind? I think by now it is. Though I really see software engineering or engineering best practices as an aspect of, well, it should be an aspect of everything we do, right? There is very few ROCs that are particularly about this. It's just something we should always have an eye on. And it makes a lot of sense to, you know, talk about best practices and figure out which kinds of techniques or approaches or patterns we want to use. And do you, so I know you and I, like we had, it was quite a while before you and I got on the same page on what the scope of this area is. Like how, and that's just like two people, right? Like there's probably a room full of people here who may not have as clear an idea of this stuff. Do you feel like we have a reasonable trajectory to help people learn about this area? Actually, what I find most difficult is to distinguish it from, well, what the architecture community is about, right? This basically is about how we build software. So it's about software architecture, more or less. It's also perhaps about documentation and how we make software, well, how we structure things so it's more accessible to other people. I think, I mean, from just seeing the name, it's probably not that clear, but at least to people who were in the session, perhaps it is now more clear. I mean, the session was focusing on two proposals or two subjects, more concrete subject areas, the service-oriented architecture and dependency injection. And perhaps we could get a sense of what the overarching needs are that drive these two things and maybe also the similarities. I don't know, I can't speak for everyone else. I now have a better understanding of what this is about, yeah. Yeah, I mean, I think that the way that I see it is that software engineering is an aspect of what the architecture committee should be responsible for, but I feel like the architecture committee should be responsible for all five of these areas to some degree, and so how do we sort off the things that really are about these sort of computer science best practices and or rather computer, you know, software engineering best practices, regardless of whether it's sort of trained PhD level or volunteer who is self-taught, like what are the best practices? I think that's where, that's kind of more the software, is more in the software engineering's purview, but and that has to do with dependency injection and service-oriented architecture as sort of modularity components, but it also has to do with the release frequency, the amount of testing that things should have, how we should write tests, all of that are those things. Yeah, actually, testing infrastructure and continuous integration is one aspect that is quite important in this, I believe. It's one that we didn't cover in the session today. Actually, yeah, but I think I did not, I did not attend that session, sadly. Yeah. Yeah, but I agree that also plays a big role. It's not just how you, what you put in which class. It's also about what components exist, how do they are they bundled together, how are dependencies declared, how do we make tests run, how do we make sure that our code is high quality. Yeah, and I guess, how do you see the best way of keeping this area alive and moving forward with potentially as Scott suggested, like having a roadmap. How do you see that, what is the best way for this area to stay alive? Roadmaps are nice, but I'm not sure how useful they are if you don't have anything to really back them up with. So I mean, I can make a roadmap for things I am going to do or some team I lead is going to do. I could, can also make up a nice plan for what I think people should do, but I have no idea whether that will actually happen or in what order. So in practical terms, I agree with Tim that it would definitely be good to have a fabricator board that we can look at. Basically have a tag for things that belong to this area. And we as architecture committee or I and a handful of other people could look at this regularly and make sure that those things on there don't get stuck or at least get the attention of the right people. Yeah, in terms of process, well, it would be very nice if we could identify some like key points that should be taken into account for like quarterly planning or something. Things that we believe should be addressed rather sooner than later. The problem with software engineering part is this is typically about things that are important but not urgent. And I'm always struggling to find ways to prioritize important versus urgent. Yeah, I think that's a fundamental problem of scheduling. Okay, well, do you have any other comments before we move on to the next area? No, I don't think so, not right now. Okay, thank you. So next up, Content Access and API. So yeah, Gabriel. Yeah, do you feel like this area is, like do you feel like you have a reasonably clear understanding of what the scope of this area is? I'm not sure, I think there's a lot of overlap as Tim and others mentioned. If you think about exposing content, you have to think about the format, you have to think about the API and they're both connected because the API shapes the format and the format shapes the API. So I'm honestly a little unsure about the granularity that we should shoot for in these groups, like the number and given the amount of overlap. So I think it might be worth revisiting where there's a lot of overlap because I think right now it seems like we would be going from an architecture comedy to an architecture comedy plus five working groups and it might not be given the amount of overlap, it might not really be feasible to attend this many meetings and all that stuff. So I think there's a trade-off there that we have to be very conscious about and maybe be careful about spitting up these things on a more and as needed basis. So one of the... It seems right now that the development was more we need to structure the program for the Dev Summit and that's how these things originated and now it's, I think we have to should revisit this before turning it directly without the different goal of turning it into like working groups because originally it was only about prioritization for Dev Summit. Well, and mind you, the way that I looked at it was I wished that these existed at the time that we were trying to figure out how to prioritize things for the Dev Summit and so it's like, okay, well, we don't have these areas, we'll make something up now and we looked at the way that things were put together for the Dev Summit but like so far they seem to have held together. That said, how would you see, what is the right way of changing the areas or do you think we should do away with the idea of where it is? No, I think the idea of working groups is a good one, especially if we are clear about what the responsibilities of these groups are and how they integrate with our decision process, which I think we haven't talked about yet. So would these working groups, for example, make decisions about our sees? What is the relationship to the architecture comedy? I think those are things we should get clarity on because that determines a little bit about how much effort we should put into them, if there are more discussion forums where we can work out things together than to present to the architecture comedy or basically that's all one big complex that we should get clarity on. Yeah, and I think, let me sort of describe very quickly why I keep coming back to the IETF model and I'm sure you're sure at least some of you are sick of me droning on about the IETF model but some of you probably don't even know what I'm talking about. So the IETF is the Internet Engineering Task Force. They're the folks that are responsible for the base protocols of the internet. And the way that they are divided up is there are working groups that are formed to solve specific problems. Those working groups are divided into areas and there are area directors, I believe, but there's long-standing members that are long-standing areas in the IETF that have moved around a little bit but there's only a handful of those. Things like there's a security area and there's a transport area and there's an applications area. And then the heads of each of the areas make up what is the equivalent in the IETF of the architecture committee. It's the IESG, the Internet Engineering Steering Group. Now, the reason why I go off on that tangent is because I feel like there's bits and pieces of that model we can borrow and certainly most of the work happens in the working groups and then it's up to the folks, quote, higher in rank to just make sure that the rules are being followed. It's not so much to make the decisions. There's generally a respect for the decisions that working groups make, provided that they're in the process. And so I'm wondering, is there something we can do that is similar to that? Yeah, I personally like the Rust model a lot. So I've been talking similarly as you have been for talking about IETF. I've been talking about Rust. They have a nice RC about their RC process with a stabilization period and they actually have working group that make decisions after no new arguments have been discovered and there's a stabilization last call decision. And that is an online process. That seems to work pretty well, which I find very interesting. That would give these working groups a little bit more teeth and they also have some rules around having a champion for an RC to push it along and make sure it progresses in a timely manner from the working group. So that is one of the responsibilities. That is a discussion we can have separately. I think so. Yes, that's fair. Yeah. All right, well, let's see here. How are we doing agenda-wise? Well, we're actually in okay shape, but so yeah, I guess is there anything else? Like how do you see keeping this area alive at this point? I think the discussions will stay alive by themselves because they have been going on for a while and will continue. Whether it's a group that meets in a formal setting or something like that, I think that remains to be seen. I think there's a lot of overlap and so I would rather have a look at it afterwards and then see how does it make sense to group this and structure this because I'm not clear yet about what the intention is. I think some of it is for people to have the right audience to appeal to and to have at least some responsibility, just like in the conversation we had earlier about Code Review, about like it sometimes not, like one of the points that was made was that it can be, it might be better to be a jerk and respond than to not respond at all and to sort of silently let something die. The Linux community for all of its faults, that's one of the things that you get is you get a response. It may not be the response you want, but you get a response reasonably quickly is the idea. Now that's sort of a romanticized view of it in some respects but is, so part of that is my characterization accurate because I see Matt standing up and probably is having a reaction to that characterization and then the other is is there somebody who can own up to giving a timely response or being the sort of person to or smaller set of people to appeal to on something? Well, I could see maybe, my fear is basically that there's too many groups with too much overlap and it's lack of clarity of where something falls when it straddles all these things and if the majority of the things straddle these things then I'm not sure what the separation of the groups achieves. So I could see for example, content access and content format to work very well together as one group possibly. What if we just think of three good areas and just define those, start working with that and then see if we need any more? I mean, why would we be too much attached to having a very fixed specific area that needs to fulfill a certain role and they have a certain amount of people supporting that role as well. Because we should not forget that there's not an endless pool of people that we can pull this from. So why not just find just three areas to create working groups for? Start with that, see what falls in there, what falls out of it and see what we can adapt from there. I think that might be a better idea to take care. Just my idea. Let me give the other side perhaps, which is, so I'm just nervous about canonicalizing the people who happen to show up to this one particular meeting at this one particular time. So there were a number of things which were discussed, which the actual people who are affected or the people who know most about that weren't here. And the working groups have the ability to incorporate more of those people over time, but this division is sort of nice and equal for the people who are here but doesn't necessarily weight the other people as well. So I think I'm more open to the idea that there'd be a somewhat larger number of interested people. I think the most valuable thing about these working groups is the ability to pull people who are interested in a particular topic together to discuss something for some period of time. And so as advisory groups, it's great. And I actually like Rob's idea about just getting an answer from people who are knowledgeable about the area and being able to put it in front of them in a timely fashion. I'd be more concerned about the opposite is empowering these groups too much because they are a little bit artificial now. Like down the line as time goes on, the groups change a little bit, people migrate to one that perhaps they could grow in power over time, but initially it seems like their usefulness would be more, for me, I'd be more comfortable with them as advisory groups than as decision-making bodies. That's all I have to say, thanks. Yeah. Yeah, I did want to respond to that briefly. I agree with the goal of trying to get stuff reviewed, but there are some caveats to that. First of all, like in some cases, the people with the experience to review a particular extension are very limited in number. So there's factors that need to be taken into account. Is that patch actually important to the roadmap? Do I have time to review it? Is this extension itself being actively maintained? So there are various different reasons. But it's a valid question like, okay, so what do we do in those cases? Should I just not respond? Because I don't have time to, or should I make a brief response saying, unfortunately I don't have time to look at that this week? So there's a valid question of how to deal with that exactly, but please don't just respond and be a jerk and say, no, this is all wrong. And anyway, I have the time to review it anyway, so don't submit trash. Don't do that. Fair enough. Yeah, I was admittedly trolling you there. All right, any last comments, Gabriel, or should we move on? Okay, great. And collaboration area. So Kim, yes. Yeah, so do you feel like, I'll ask the same question, starting question. Do you feel like you have a reasonably clear idea of what this area is about? I think I have a clear idea, but I don't even know how spread this idea is. So if others would agree or disagree, collaboration is a fuzzy concept. And I think we have a good idea of something central, like, for instance, code review, the last session we had here. But the thing is that, or in fabricator, et cetera, tool-based collaboration. But the point is that none of these pieces is useful if the whole process of collaboration doesn't work. So if code review is great, but then we just suck at understanding what our communities want, then yeah, we are just reviewing excellent code that actually doesn't solve the problem that should be solved, or the other way around. So I really would like, I think this summit was a good occasion to start introducing more views of the different areas of collaboration that we should improve. But I think a lot more work, a lot more discussion needs to happen in order to have at least a common sense of the problems of collaboration we want to solve. And then, so I think some of what I see is potentially being a distinction, like the tool-based collaboration, like I saw as being in the code review area, like that seemed to be very close to the software engineering area in many ways. There are some that seem more squarely placed in the collaboration area, just in terms of how we collaborate, how we behave, some are standards of conduct, and that sort of thing. How important do you feel that it is to the collaboration area for you? Well, I think this is, so the very important point is when you organize an event like this, then the context is biased by the people who are attending this event. Some others I've mentioned this in different ways. In the case of problems of collaboration, is a systematic problem is that those suffering the problem more hardly probably are not here to discuss about it. So in code of conduct, the most likely victims or people that are most likely to suffer problems when someone is misbehaving, probably are not here in this room happy to just go on stage and say, hey, look, this happened to me. Or when we are talking about discussions with the non-developers, the non-technical communities, well, guess what? They are not in a developer summit. So we need to actively be thinking about them and find ways to get them involved or just bring their voices to this forum and make decisions that really take them into consideration, actually making decisions on their behalf in some cases. I'll just bring one example, for instance. Some people were wondering why I'm so stubborn about the shadow main spaces thing. And I have no idea about the topic itself. Slowly I'm learning. But the thing is that, for instance, I have this idea that we have all this gadget and template and module developers or pseudo developers or copy pastors all spread in hundreds of weekies and there's some benefit. I don't know exactly what, but there's some benefit, for sure, having all these people closer to, for instance, the MediaWiki.org space and all the other areas of development. So here we see a case of purely technical implementation on something really hardcore, shadow main spaces, that actually has direct implications on how we can collaborate better, helping people that are not here in its majority. Yeah, okay. And I guess one of the things is not just helping the people, the sort of individuals that aren't here in thinking of them as individuals, although we certainly should be doing that too, but the organizations that are not here. So this is a very Wikimedia Foundation, like there's a huge number of people here who are from Wikimedia Foundation. What do you see as sort of the future of the collaboration space to make this not such a Wikimedia Foundation-specific event? Well, there's two main areas here to work on. So one is, are we seriously willing to be an open source project as we consider open source projects? You know, where there's multi-parties and there's processes and nobody like no organization really owns something unless you are the official foundation for that piece of software. You know, are we really willing to have more developers contributing to our code? Because if that is the case, then we need to change some things in the way, like our product development process needs to be different, our planning needs to be different, our road mapping needs to be different or just happen, et cetera, et cetera. This is one area. So us as an open source project, then we have Wikimedia as a very interesting source of free content that people can, developers can play with through an API or through many APIs. And this is another area that it's totally marginal in our discussions and it's something that, especially in the Bay Area, is something amazing. So everybody that has some lighty tiny pieces of content of users, the first thing they have is an API documentation and everything and just have developers working on do things with this. And for us, it's almost a side effect. We are starting to pay attention to that, but even when we talk about APIs, most of the discussion is still internal, APIs for ourselves as opposed to APIs for others to work with. So I think these are two big questions that we need to be really serious asking ourselves is, how serious are we as an open source project? How serious are we as providers of content? And for all this around API. Yeah, and Matt, you stood up for a second. I'm assuming you've got a question. Yeah. As a gatekeeper, I was wondering if anybody who is at the MediaWiki stakeholders open meeting wanted to talk about the MediaWiki Foundation idea we were talking about there? I can summarize. I was in the session. So this is also one of the examples of MediaWiki for non-Wiki media users. So MediaWiki for third parties. And there was a session led by the MediaWiki stakeholders group where we had some progress in terms of defining what the Wikimedia movement, what the Wikimedia Foundation would be likely to help or not help, but this is another question that really we need to clarify. So it's MediaWiki for third parties important or not, because basically we are keeping this situation where we say it is important, we act as it is not as important. And this ambiguity doesn't help anybody. So one of the other interesting things to me about this is that the content side is very underrepresented, right? So even, we've talked about this before, like template authors and people who actually use their platform to write code aren't represented. And at the risk of belaboring something which I've been nattering on about to lots of people, one of the random ideas that came to me in conversations over this was the idea that the foundation itself could have an organization, a working group, but whatever whose job was, we'll call it content migration, like the Library of Congress has people whose job is to take all the old floppy disks, scan them, re-record them on CDs, and then 10 years later take all the CDs, re-record them on whatever the newest media is, right? And so as a foundation, we have held content at arm's length and sometimes I feel like hurts us, hearts are interacting with the community. And so this might be one, you know, just sort of throwing this as, you know, why we don't get more collaboration with other people. It's not just other hacker developers, it's also template authors we don't interact with. And every time we make a change to like info boxes or whatnot, we incur some technical debt to migrate old content to new stuff. And we've sort of had an inconsistent response to how that's actually resourced or thought about or described. We've done it, like we've done lots of projects, we've done annotation of Cummins metadata when we sort of did the legwork to migrate that. But that's something that I'd like to see treated as a slightly more first class, just content in general and content maintenance. Yeah, so one last question and then I'll let you also just free from whatever comments you have. So what, how do you see keeping this area alive? Well, it is the job of my team to keep it alive. So in one way or another, it will be alive. What I don't know if it's the best, if we can be the foundation team is the only possible framework for this. So if nobody comes with a framework, so if we don't have an alternative framework, we'll have still one. But I think we can, yeah, we could have, I mean, it would be useful then to be, for instance, one of these pieces there. Just saying that if any of that doesn't happen, we will continue doing our work. Okay, and actually this connects with my last comment that I wanted to do. So our team is, are going to use a framework to have solved many questions, well, not solved, to actually find answers for these questions in the next six months. We need to participate in the Wikimedia Foundation strategy and the annual plan for the next fiscal year. And actually, I want our team to be asking these questions. Is media wiki for third parties important? Yes or no? Is code review important? Yes or no? Et cetera, et cetera. And then at least find answers in terms of, how do we get, where do our resources go at the end and what are top priorities? Not just spontaneously in a summit, but no, this is our plan, but what we have decided as part of a wider framework. Great, thank you, Kim. Yeah, so, Danny, so one of the things we wanted to do was talk about the community wish list that we touched on in the opening session and I won't take any more of your time. All right, hi, everybody. So actually, I'm not gonna take too much time. Really, the thing that I wanted to talk about for a second is all the stuff that's under the top 20, or I'm sorry, under the top 10 on the wish list survey. So where that stuff came from, if we haven't actually explained it, was we put out a call as far as we could to Wikis all over the place and ask people to come in and offer proposals for projects that they think are important or features or fixes, things that they wanna done. So it was sort of a huge open session for two weeks. People came in and wrote proposals and endorsed proposals. And then after that, there was two weeks where people could come and show their support. So there was a two week voting period and we were only counting support votes. People could discuss and offer opposes and various discussions to encourage or discourage people. But we just are including the support to see kind of what inspired and what excited people. So that top 10, as we talked about earlier, that's what the community tech team sort of has responsibility to investigate and address. But there were 106 good ideas on the survey. Actually, I'm sorry, no, there's a handful that aren't that good. You'll recognize them when you see them. Look, they can't all be good. But there's a lot of really, really good ideas that are there that our team isn't gonna have time to address. And so how you can find that just to make it easy. I put on the developer summit schedule, the unconference session that has to do with community tech. I put a few links there if people wanna go and look at them. One is for the whole results list, all 106. And that table has all the votes and then also links to each of the proposals and a link for each to the fabricator ticket. There's also a wishlist survey fabricator board that people can go and take a look at. That has everything and actually in numerical order because I'm a nerd. And so we're really encouraging folks who are working with developer relations. And we're also talking about, especially with Kim about like, what can we offer at the hackathon? What can we encourage people to do in Google Summer of Code? There's a lot of really good ideas and I would really like to encourage people to take a look. And if there's anything that you think is inspiring, it is potentially a really good measure. You look at something and you say, wow, and that was voted as 23. Like there's a lot of show of support for that. That would actually be a really exciting thing to work on. So I'd like to encourage you guys to go and take a look and to do that. And then also please keep talking to us. We've had a lot of really great conversations just about the top 10 over the last couple of days and it's been exciting to do that. And that's all I have. Thank you very much. Thank you and thank you for everybody sort of setting patiently through this session but just in general, thank you. It's been, I've learned a ton from you all and I'm honored and privileged to work with you all and I hope you feel the same way. So yeah, with that, we should talk and by the way, a big round of applause for Kim and Rachel for setting this fantastic job with a great place for us to have conversations. And for Rob, who had lots of patients with all of us. And so yeah, we should talk about what's next in the day. Hey, just a couple of things. I know a lot of you are probably jet lagged so we'll wrap this up. Also just some other people to thank are Sarah and Megan who are currently at WMF setting up the party for you guys and it's Megan's birthday tomorrow so you should say happy birthday to her because she's working at the event on her birthday. So tonight, we're just taking the bus to WMF. There's gonna be some good food and some beers and some non-alcoholic drinks and whatever you want. And not that. And I sent out an email about tomorrow with a whole bunch of information so just do me a favor and actually read it because there's gonna be a lot of questions that I wouldn't have to answer if you read it and if you're one of those couple sneaky people who snuck in here without registering, ask someone next to you to forward it to you. And just to be clear because I've heard a couple miscommunications about what tomorrow is, there aren't actually any scheduled sessions tomorrow. We have the whole third floor and the event space on the fifth floor of WMF reserved for this. All the conference rooms are reserved for this and there's gonna be no such thing as a private meeting tomorrow so all the conference room doors are gonna be open and everyone's gonna be able to access any meeting that's happening and hopefully I don't have to go around and police that and open doors but yeah, it'll be really fun I think. And all announcements, this is the last time you're gonna be addressed on a microphone, all announcements are gonna be on WMHAC, the IRC channel, if for some reason you don't have IRC, we'll be projecting it in the fifth floor event space all day tomorrow. And the final thing about this event is that I'll send the feedback survey out tomorrow so that you guys can tell us or you all can tell us, I did it again. Can't say guys. You all can tell us how the event went and what we should do differently next year because we'll listen and take that feedback into consideration. If this was not enough for you we have some upcoming events that are gonna be great to you. Like Danny was talking about, we're gonna be focusing on the community wish list at the Wikimedia Hackathon in Jerusalem which is gonna be in March. March 31st to April 3rd actually. And besides community wish list stuff another focus of the event as always is onboarding newcomers and mentoring volunteers and newcomers and each other and anyone who's there. And then the Wikimedia Hackathon, Wikimedia Hackathon in Asino Lario is also gonna be similarly focused but we haven't worked that one out as much yet. So with that, unless anyone else has anything to say. The event is closed for now until tomorrow and the buses are gonna be here probably a little before five to take us back to the office. So thank you so much for coming.