 Okay, the event is starting and we're live. Hi, I'm Daniel Kinster from Wikimedia Germany. I'm the chair of the, I was going to say the architecture committee. No, the technical committee now, TechCom for short. Welcome to our webcast on the new TechCom truck. Right. I have a little presentation prepared. I will share it with you now and then we will walk through it briefly. It's not a very long presentation and then we'll hopefully have time for questions via IRC. If you are not on IRC and want to be, it is the channel Wikimedia-office on a free note on that. Okay, so let me see if I can get the screen share going. So the TechCom charter a few months ago, or for a long time actually the architecture committee and later the technical committee has been wanting to give itself a charter where we write down what this committee is all about and how it functions and what its duties are. And about a month ago, shortly before Wikimedia, we actually got around to writing and passing such a charter. So I want to tell you a little bit about it today. The technical committee today is Brian, myself, Gabriel Giuseppe, only recently he just joined us last week, Rowan, Tim Teemo and Victoria. And Kevin is often helping us out with notating in other organizational duties. What's the idea behind the technical committee? The idea was originally, and still is, really, to have a place to resolve tricky technical questions. Too often things just get stuck because there is nobody around to actually make the tough decisions. So a few years ago, there was an opportunity for a post-production of the technical committee and we had a lot of people who were working on this. So I think it was a good idea to have a little bit of a discussion here now. Yeah, I can edit this out. So maybe, can you hear me? Well, while we wait, maybe I can give a bit more color. Yeah, we can hear you. Oh, okay, good. So until Daniel comes back. So Daniel made this presentation at Wikimedia in Montreal last month. But obviously not everybody is able to attend Wikimedia. So we thought it would be helpful to share it here again. More broadly, and also recorded so that folks can have access to it afterwards. Partly, the reason why we decided to do this was a specific set of questions that came from the community about the new tech hub. People had questions, so we felt it would be helpful to get everybody together here to give our views for how this piece has changed recently. And obviously the architecture committee has been part of, you know, it presented leadership to the technical community of the movement for a long time. And the opportunity here for us was to make it even more effective. And this is what we, this is what we tried to do. So all the changes that Daniel will be speaking of are consequences of that desire to make the community more effective in its support of the foundation. Let's see. So, yeah, I don't know if Daniel realizes that you think I'm up. Maybe Kim, you can send him a quick note. I pinged him on IRC. The thing is, if you're presenting full screen and you are talking, you can go on for 20 minutes without realizing. So, let's see, maybe I can go ahead and share my screen also. So I'll just share my screen. I have the presentation from over here. Well, I think we need a plan B. So if you have the presentation and you want to continue, Victoria, I think that would be great. Yeah, so presumably you cannot see it just yet, right? Sorry? I see your screen share, Victoria. But not the presentation. No. Okay, so I have to screen share it differently. Just give me one second and I will do that. So here we go. Let's see. And here is the presentation and I should put it. All right, so starting from the top. And of course, you know, let's note that there is an embedded technical joke here that I'm sure most of you have already seen. So this is already been covered by Daniel. So the committee is a place where we aggregate some of the most senior people in the technology part of the community. And they are there to help the rest of the technology community to resolve tricky questions. And as you see, of course, from the constituents of the community, there are folks there like Brian and Tim, that have been here since the first line of code, more or less, have been written. So we have a great deal of legacy and of knowledge into what powers of the movement they are. The way that the committee has worked so far is primarily through the RFC model, where, you know, somebody is trying to do something that no share, or contribute and like, advise support from the architecture committee, as it used to be, and that would support the RFC. And the art form would eventually get around to it and respond with advice. One of the things that was not working very well was it wasn't clear whether the RFC would in fact be executed, if you like, by the art form or whether they were just there to provide advice. And clearly, this was a significant question. And, you know, technology can be as consecutive now, you know, we are very clear that we don't have resources in this committee to be executing on RFCs. But what we do have are some, as I said, the most senior technologies in the community that can advise others that are undertaking projects that are big and significant for the movement. So, in order to capture the intent for how the committee should now be functioning, we spent, I think, and Kevin can correct me, we spent of the order of the quarter, I think, debating to try and come up with a charter that is much more accurate in supporting its intent and kind of communication about the intent of the community. So, this charter was approved, I think, about two months ago, roughly, and has been subsequently shared. So, if we start working through it, first of all, the mission of the committee is to go to place behind technical decisions and what does that mean? Well, these are decisions that are strategic, that are cross-cutting, or they are hard to undo. So, this is how the committee defines what high impact meant. And in addition to that, there's a bunch of stuff that perhaps don't fall into these categories right off the bat, but there are also other aspects that the committee is responsible for as the guardian. And that is the integrity of the code base, the consistency or approach, the stability of the code base, as well as its performance. So, this is really the universe in which the tech home is operating. And I guess we've been operating like this now for, I would say, the last month or so. So, the purpose is really to provide technical leadership. These are the people that we trust the most with the technical foundation of our work. And we want to make sure that they are able to provide advice, not only to the projects that they are working on, but more broadly into the evolution of our code base. And in many ways, the tech home acts as an extension of the city of the foundation. And I knew that kind of very literally. When I joined the foundation, there was, there still is a great deal of pent-up kind of decisions, choices that have to be made, big choices about our staff. And I very deliberately did virtually nothing around those decisions because I only use that in our movement, in our foundation, we'll be consistent with the principles to have one person make these determinations. But it is much more appropriate and actually I continue to much better outcome to have that responsibility shared with other very senior technology experts in the foundation. And that's really the tech home in a nutshell. I mean, it captures the most senior than thinkable expertise that we have and applies it in support of the mission. And also, we wanted to make sure to affirm that the tech home is not something that is exclusive to the foundation, kind of far from it. In fact, Daniel Kisler, you know, is not an employee of the foundation. He's an employee of, hi Daniel, welcome back. He's an employee of the media in Deutschland. But we would like to make it so that the tech home addresses and is open more broadly within the volunteer community. So Daniel, now that you're back, we'll take over from here. And I'm happy to present, continue presenting so that you don't have to worry about that. Okay, I have no idea where I left off because apparently Google decided to just kick me out and I didn't notice until I was actually finished presenting. I'm at the purpose slide. Can you see my slides? I see that you're on the purpose slide. Yes. Should I just pick up from there? Yeah, I'm going to do that. All right. Sorry about that. Let me get the screen share going again. Shall I share my screen or shall we keep using yours? Let's just use mine to avoid any more needling of Google. All right. Sorry if we continue because I assume we'll cut this piece. There's a question on IRC. So who's taking the questions from IRC? I can't see the question because I'm sharing the screen. So maybe Daniel, why don't you take the question? The question is lack of resources to execute IRCs. How about fabricator? For the first one, I kind of have an answer. The second one, I have no idea what to say to that. That would need a little bit more elaboration, but I would prefer to finish the presentation first. It's like five minutes and take questions after that or answer questions after that. We can collect questions all the time, of course. That's the best sense. Okay. So Victoria, will you change slides while I talk? So I'll just move to the next one. All right. Yeah. Scope of the committee. The idea is that the technical committee is really about all the software that serves Wikimedia users. Of course, this includes first and foremost MediaWiki, plus all the extensions that are deployed. But it also includes things like mobile apps. Our focus is particularly on software and system architecture, but also on performance, security, database, and so on. Of course, well, in the end, it's all about quality, ensuring software quality, and that also includes automated tests. It also includes documentation or conventions for documentation, coding conventions, and so on. Can you just slide, please? I can't. Not a scope would be documentation for Wikimedia users or Wikia owners. So things not aimed at developers. The tools used by developers, even, well, we may have recommendations there or opinions, but in the end it's up to anyone what they want to use to develop the software. Similar team processes or other social aspects of collaboration are not something that we have any authority on. Also, anything running on the Wikimedia Cloud Service, formerly known as LABS, is out of scope. Of course, if you write something there and you want input from the technical committee or an opinion, we are happy to give an answer. But the idea behind having the Cloud Service is really to give people a safe place to work on software without being slowed down by the bureaucracy that we kind of need to keep the live cluster running. So there is no requirement for anything running on LABS to go through the technical committee. Next, please. One important aspect is that we try to establish the technical committee as part of the software development process in general and make it so that a review of the software and system architecture becomes a normal part of the design of any new feature or subsystem, just like security review or performance review are. The established RFC process is the default process for this, but it is not the only way to interact with the committee. It is currently the only formalized way, but just write an email and then we can talk. Also, policies and guidelines that affect how code is written or how code quality is insured are in scope of the committee and the committee should be involved in the development of such policies. I keep trying to change the slides and it keeps not working. The committee's authority is derived from the authority of the CTO and as such, any final decisions by the committee are authoritative and any conflicts should be escalated through the CTO. It should be resolved through the CTO. That doesn't mean that everything that the technical committee says is set in stone. We may offer opinions and recommendations, but in the end, if there is a definite decision, then it does have the authority of the CTO, which is actually probably the most important thing that we now have with the chugger. Previously, the committee did not have any formal authority whatsoever. Anything we could do was hope that people would listen and we cannot still hope people do listen. It's also important to note that the technical committee decides based on its own expertise, informed by input from experts and from the community. The technical committee is self-selected, so we decide ourselves who should be a member and who shouldn't be a member and we are pretty free in that except for the fact that the CTO is always a member of the technical committee. It would simply be silly to do it otherwise because otherwise you would have two bodies that essentially exercise the same authority, but no close interaction between the two. That would just be annoying. Our goal in selecting new members is of course to find people with lots of expertise and lots of experience in the area of media wiki and related software. We try to cover as many different angles of this as possible. It's not only people like me who have been working on media wiki core for a long time, but also people who know about operations side of things, people who know about mobile devices and so on. We are currently still very much focused on media wiki core, but we try to expand the kinds of expertise we cover. I think on the last slide we have a few questions that may serve as an inspiration to what we could talk about over the next half hour or so. These were questions that came up while we were discussing the charter draft on media wiki.org. But we can also talk about other things if you like. That's my presentation. I hope it was informative and the break wasn't horribly long. I'm still very sorry about this. Now for the questions. I see some things on IRC, but it's probably better if someone else collects them and asks them. Maybe I can... There was one question earlier that I said I could answer. No, I forgot what it was. It was about the lack of resources to execute IRCs. I can talk about that a little bit. Basically, in the past it was often the case that someone came up with an idea for a feature or how things should be changed internally and ran that through the architecture committee and then nothing. We can say that looks good and then nothing happens. That is actually an important point in terms of expectation management. This is still so. The technical committee does not have any authority over resourcing and doesn't have any resources on its own. The committee members also don't have a lot of time reserved for doing committee work. We estimate roughly four hours a week. Certainly no time to actually do software development. We have now been saying that if you bring an IRC, it should already be resourced. If it is not resourced, we will probably not discuss it because that's just a waste of everyone's time. We have not been very strict about this in recent times, but I will try to be a lot stricter about that aspect. That answers the question. I think just to quantify that point, the committee does not have its own resources and neither can do allocation of resources on behalf of other teams. That is something that happens locally, but where a team has a plan to build something that would fall in the strategic, in the crosscutting, in the Cartoon to category and affect also stability and security, the things that we talked about, that needs to be discussed at the technical committee. That's the place where we make sure that we don't make decisions by locally optimizing what is good for this particular project that we are working on that might at the same time create, take the baggage, break other things in other parts of the company. The tech home is in the garden, as Daniel was saying, of the integrity and really to some extent, to a great extent, the future of the software platform that we rely on. Are there any other questions? Kim, if you're talking, you're muted. I'm not talking, there's no questions so far. If there are no questions, one other thing just to get out there to remind people, we'll have of course a depth summit coming up in January, the 22nd and the 23rd of January, and I sent out a heads up about the whole day, I'm saying. The technical committee will have a great deal of influence on how we select topics and how in general we run depth summits, both this coming January and in the years, calling that to make sure that we use that event, the investment that we're making in terms of resources and people time and so on, the best way possible, the most productive way possible for the future of the movement. So in this particular case, a good subset of the technical committee will be participating in the program committee for the summit. So in other words, what I'm saying is you can expect to see the role of the tech com to grow over time, significantly to cover really some of the core methods and tools and projects that we pick to work on as a community again to support overall mission. So leadership and the knowledge of leadership and foundation and the movement is much more pluralistic than it would be in any company and the tech com is how that gets personified. I see no more questions. I think that's great. I want to thank you Daniel for preparing this great presentation and the team for creating and publicizing the event. Also the team that recorded it here for posterity. Let's make it available to people that were not able to be here today. Yes, we will wait for more questions as they come in. Apparently there are some on the YouTube channel. Does somebody ask those questions on behalf of the people on the YouTube stream? Okay, so there's one question. What does it take a minimum to be a member of the tech com and can a volunteer like me be part of this committee? Hence how should we apply? So volunteers can be part of the architecture committee. In general, we go looking for people and we don't. So far nobody has had the idea to actively apply. The question is, so if someone applies, the question is then are we actually currently looking for a new member who does the expertise that the person offers actually fits? In general, we are looking for people with a lot of experience with the development of media wiki and related software and the likelihood, so it's quite likely that it will be someone that we already know. It's possible that someone would just show up and tell us how great they are and we say, yeah, excellent. We need exactly that kind of expertise right now, so join us. But honestly, I think it's a bit unlikely. So in general, what's the minimum requirement? Well, you should convince us that we can trust you to understand the consequences of any proposed change that any proposed change could have in your area of expertise and can assess it with respect to its merits and its strategic impact. Can I take a stab at this question as well? Because it's actually a great question. I would say that the number one criteria is kind of technicality already and respect thereof in the technical community of our movement. So that's like the number one criteria. The committee that Daniel was saying earlier is it consists of seven members now. Ideally, we'd like to have about 10. So we are actively kind of considering and looking at new members. One of the things that we look at as well as the majority is balancing the areas of expertise so that we can cover kind of the entire kind of domain, if you like. And also I would say that the committee is self-selecting as Daniel was saying earlier. What this means is that in order to become a member, the existing committee members have to re-evolve you in. And, you know, I'm kind of new to this in the last year, but the way that I interpret the workings of the committee on this topic is that there's always very deep and social conversation and in every case that I'm aware of consensus for new members. So I guess it's possible that, you know, a member or two may disagree about extending an offer to become a member for somebody, but I've not seen it happen yet. So this committee seems to have a way of working that is very collaborative and very consensus driven. And I expect that to continue in the case. Having said all that, if somebody feels like they have the time and finally the skills that are needed to participate, you should absolutely let one of the committee members know just to be aware that the bar is kind of high and we will keep it high. Don't, members, don't get disappointed if the answer is no, maybe the answer is not now, maybe in the future. Again, you know, this is driven from the basis of seniority and respect for the organization and the community as well as coverage of skills that we need to have. Canel just mentioned something on IRC that I think is actually a pretty good point. It says, you would think that people wanting to join TechCom should be people who are already active in reviewing IRC, so who take part in the public meetings and are active on the respective fabricated tickets. And I think that is probably true. That is a good way to show that you're qualified and it's also a good way to actually practice and get more practice. This is not like a sports event, right? But basically getting an understanding of how this process works and what the criteria are and all these things. We have questions here on the YouTube stream. There is one participant, but I am not understanding the questions. I'm not sure if it's for the TechCom, and I apparently have hit my limit on comments on YouTube. So if you can access the URL, you can see yourself and you will understand. I guess just one more comment. My side is I would welcome diversity in the TechCom. As usual with matters technical, we are not very diverse. I would love to address the balance both in terms of gender and having more gender groups there, but also in terms of having volunteers be part of it as well as staffers. And one of the things that I would like us to do, and I think for some of the hackathons or for the great opportunity to do that, is to become acquainted and bring up Italian aspiring members of the TechCom community to a level that they can join the community. One of the things about volunteer contributors is always there is a kind of intrinsic bias there. If you are a highly skilled experienced volunteer, you probably got an offer or two from the community at some point. So essentially if you are a highly skilled experienced developer, chances are that you will become an employee at some point, which kind of means that there are not that many highly skilled and experienced volunteer developers. There are some who have resisted all tempting offers so far, I guess, but it's really not many. Any more questions? I don't see any to the IFC. It sounds like we've covered most of the questions at Google Head, Kim. Are you ready to wrap this up? Yes, I think so. Okay. So thank you everybody. Thank you particularly to Zudaniel for post-presenting and preparing the presentation and persevering through the Google challenges that we've had. I really appreciate everybody's support so far in changing the charter, putting new members, and I look forward to making the tech more and more a key forum for significant decisions for movement when it comes to technology. I believe there are, you know, like most of the way there, we just need to bring it over the edge. And I am really thrilled to have the opportunity to work with them. I feel humble working with people like Daniel and Brian. Every time I show up on these meetings, I'm surprised at the depth of knowledge and expertise. In fact, even I always learn something. Thank you everyone. Have a great day and please follow up with any more questions either to myself or Daniel or any other member of the committee. Thank you all.