 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, TechCon for short. Welcome to our webcast on the new TechCon 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 of Wikimedia-office on fimo.net. Okay, so let me see if I can get the screen share going. So the TechCon 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, she 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... Looks like we lost Daniel. Okay, we did. We'll stand by for him to come back. I see an opportunity for post-production here now. Yeah, I can edit this out. So maybe, can you hear me? 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 record it so that folks can have access to it afterward. 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 it would be helpful to get everybody together here to give our views for how this piece has changed recently. Obviously, the architecture community has been part of the present 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 would be speaking of are consequences of that desire to make things, to make the community more effective in its support of the foundation. So, yeah, I don't know if Daniel realizes that you think about, 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. Shall I 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 can not see it just yet, right? Sorry? I see your screen share, Victoria. But not the presentation. No. Okay, so I need to screen share it differently. Just give me one second, and I will do that. So here we go. And here's the presentation, and I should put it. All right, so starting from the top, and of course, let's note that there is an embedded technical joke here, but I'm sure most of you have already seen. So this has 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 resolve tricky questions. And as you see, of course, from the constitution, the committee, there are folks there like Brian and Tim that have been here since the first line of code world has 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 makes sure how to do it, that like advise support from the architecture committee, as it used to be, and that would support those submitting RFC, and the Archcom would eventually get around to it and respond to the 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 Archcom or whether they were just there to provide advice. And clearly, this was a significant question. And in the technology committee as constituted now, 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 technologists 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 on this, 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 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 this kind of 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 university in which the tech home is operating. And I guess we've been operating like this now for, I wouldn't 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, 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 radial pent up kind of decision choices. I've had to make big choices about our staff. And I very deliberately get virtually nothing around those decisions, because I don't believe that in our movement, in our foundation, we'll be consistent with our 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 the technical 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 Pizzlers, you know, he's 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 we 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. So I see that you're on the purpose slide. Yes. Should I just pick up from there? All right. Sorry about that. Let me get the screen share going. Oh, 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. Before we continue, because I assume we'll cut this piece, there's a question on IRC. So who's taking the questions from IRC? So I can't see the question. So because I'm sharing the screen. So maybe Daniel, what do you take the question? The question is lack of resources to execute IRFCs. 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. Yeah, let's do that. Makes 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. Right. Not a scope would be documentation for Wiki users or Wiki 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, formally known as LABS, is out of scope. Of course, if you write something there and you want input from the technical committee or your opinion, we are happy to give an answer. But the idea behind having the Cloud Services, we need to give people a safe place to work on software without being slowed down by the bureaucracy that we need to keep the live cluster running. So there's 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's currently the only formalized way, but just by an email and then we can talk. Also policies and guidelines that affect how code is written or how 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. 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, the most important thing that we now have with the charter because 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 this. It's also important to note that technical committee decides based on its own expertise informed by input from experts and from the community. Now we can go on. Thanks. 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, so it's not only people like me who have been working on media wiki for a long time, but also people who know about the 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 too horribly long. I'm still very sorry about this. Now for the questions. Do we have? 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 now. I forgot what it was. It was about the lack of resources to execute IRCs. I can talk about that a little bit. 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 read that through the architecture committee and then nothing. We can say that looks good and then nothing happens. That is actually a pretty important point in terms of expectation management. This is still so. The architecture committee, no, the technical committee, sorry, I'm still stuck in the old ways, 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 and answer the question. So I think just to quantify that point, the committee does not have its own resources and either it 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, then that needs to be discussed at the technical committee. So 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're working on, that might at the same time create, take the baggage, break other things in other parts of the company. So the tech home is really the guardian, as Daniel was saying, of the integrity and really to some extent, the future of the software platform that we rely on. Okay, 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 have of course a depth summit coming up in January, the 22nd, the 23rd of January, and I sent out a heads up about the whole day, I can't say. 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 and 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 depth summits. So in other words, what I'm saying is you can expect to see the role of the tech home 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 in support of our overall mission. So leadership and technology leadership and foundation and the movement is much more pluralistic than it would be in any other in any company. And the tech home 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. And 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 minimum to be a member of the tech home and kind of 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 and is, 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'd say, yeah, excellent, we need exactly that kind of expertise right now, so join us. But honestly, I think it's a bit unlikely. Yeah, so in general, what's the minimum requirement? Well, we should, 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 a, actually it's a great question. I mean, I would say that the number one criteria is kind of technical seniority and respect thereof in the technical community of our movement. So that's like the number one criteria. So the committee that Daniel was saying earlier is 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 seniority 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 in order to become a member, the existing committee members have to re-vote you in. And, you know, I'm kind of new to this, I haven't been there 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 the primary skills that are needed to participate, we should absolutely let, you know, one of the committee members know just be aware that the bar is kind of high. And we want to, you know, we will keep it high. Don't, others 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, respect and organization, community, as well as coverage of skills that we need to have. Yeah. Conel 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 active, should be people who are already active in reviewing IRC, so who take part in the public meetings and are active on the respect of 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 into 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 in all these things. Do you have a question for them on the YouTube stream? There is one participant, but I am not understanding the questions. I'm not sure if it's for the R-Com. Sorry, I'm also in the old school, in the TechCom. And I apparently have hit my limit on comments in YouTube. So if you can access the URL, you can see yourself, maybe you will understand. I guess just one more comment. On my side, I would welcome diversity in the TechCom. As usual with matters technical, we're 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 the members of the TechCom community to a level that they can join. I would love to see that. Yeah, one of the things about volunteer contributors is always there's a kind of intrinsic bias there. If you are a highly skilled experienced volunteer, you probably got an offer or two from Wikimedia 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 of the IRC. It sounds like we've covered most of the questions that we've had. Kim, are you ready to wrap this up? Yes, I think so. Okay. So thank you everybody. Thank you, particularly to Daniel for our post-presenting and preparing the presentation, persevering through the global challenges that we've had. I really appreciate everybody's support so far in changing the charter, putting new members. I look forward to making the TechCom more and more kind of 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 kind of really thrilled to have the opportunity to work with them. I feel humble, you know, working with people like Daniel and Brian. Every time I show up on these meetings, I am 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.