 I'm hoping that this session will be some discussion rather than just me telling you lots of stuff. So I've set up a Gobi thing. If you haven't used Gobi before, then if you have a laptop, you could try to, can anyone read that or not? No, it's tiny writing, but get install Gobi basically, and then connect to gobi.debian.org. And then if anyone does that, they can write down the amazing ideas that come from the audience or come from the discussion rather, rather than just forget them immediately. I'm just gonna work at my own master's done, okay. So in this session, I was basically hoping to think a little bit about how the teams in Debian operate and how we can use our teams better or make our teams work better. But I definitely want to hope to hear some other people's ideas. I'll try to keep the presentation part relatively short. And I just say in advance, I'm not focusing here on the kind of attracting new contributors to Debian or creating new teams aspect. And maybe there's another session, in fact, tomorrow afternoon, another discussion about paths into Debian, which maybe that kind of aspect is more relevant in. So just to know who's in the room first, who here would say that they are currently part of a Debian team? Yeah, that seemed most people, I guess, about half at least, but most, probably most. And out of those, without defining any terminology at the moment, but who would consider that they are part of a core Debian team? No one, no one feels that. Okay, that's interesting, that's interesting. And as a second question, maybe you can shut your eyes if you, or everyone else can shut their eyes if you don't want them to see your answer to this. But who thinks that teams in Debian are generally working well? Who thinks that, or who feels frustrated by problems that they, who feels that their Debian work is being blocked or has become frustrating because of problems that they see in Debian teams? Could be a team you're in or a different team? Okay, okay, a couple of people brave enough to say that. Okay, I get confused every now and then because I'm using, I'm not got inclined monitoring so I'm keep on having to move my mask backs and forwards. So when I look very confused, it's probably just that. Okay, yeah. So just to say, as a starting point, obviously the teams in Debian work within the Debian community. To say what is the Debian community is kind of tricky, but when you're at Debian, maybe we think primarily of kind of the people we're chatting to and having food with and falling asleep in talks next to and so on, which is about 270 people here. There is around about 1,000 people who are officially members of Debian. We then have thousands of other contributors, some of whom are informally or formerly part of Debian teams, but all of whom would be dependent on the work of various teams within Debian. And then we've got some extremely unknown number of users. But again, obviously any Debian team shouldn't really just be working within the kind of developer community. Every Debian team will have some final purpose at least, which depends on all the Debian users or interacts with them, even if it's not expecting to interact with ordinary users on a day-to-day basis. I have the cursor on this screen. Ah, I need to click maybe, okay. So the teams thing in Debian has been going on a long time, there's a discussion about it. In fact, some of you might remember back to Andrea Schilder's campaigning on the basis of small teams, which at the time was a kind of new thing within Debian that many most really, for many years in Debian, most people just thought of themselves as working independently, even if in practice they were working within some kind of team structure. People tended to think they were working on a package and that was just them individually. We then grew up packaging teams later, for example. We end up also with a lot of teams that developed over time that are oriented to particular tasks, which obviously could be things like translation teams or it could be things like working on the Debian website. As a second thing, and again this is a vague term I already mentioned once, there's some concept that comes up within discussions within Debian, typically in some kind of list flame war about the core teams. Normally this comes up as people complaining about core teams not being responsive to their needs or not listening to them or something. In a way, it's a kind of bad concept because it suggests that some people are fundamentally, well, it could suggest that some people should have a greater influence just from being part of these teams or should be listened to more or less. But still, there is some validity to it that it's useful in discussions to make a distinction between, say, a team that exists to update some package where the two users of the package are the two team members and a team that exists to decide who has a Debian account, for example, who is a member of the project. There is, although it's, I wouldn't necessarily want to be the person to decide where a cutoff is for core versus non-core, but there is some kind of boundary at some point even if it's a gray line, gray thing rather than a straightforward line. Again, those of you who have laptops with you or turned on may want to pair at these two webpages. I can actually, maybe in principle, I can open on the screen, then that may be. The one of these is the official Debian website information about teams, which is not necessarily very enlightening for people who are not yet involved in Debian. It's basically just has a big list of many, many teams and the people who belong to them. The second one here is a more recent thing, which is, as with much of the useful kind of web content, is somewhere in the wiki and not necessarily that visible. But it's an attempt to catalog some of the Debian teams and to try to document some aspects, not just who's a member, but for example, things that could be useful, like what the team actually does, which for delegated teams, you might be able to find out by searching Debian developer announced for some previous delegation, often that that could actually be out of date a couple of years later, and for other teams, apart from this kind of wiki page or a few other individual teams attempt to create their own pages, it doesn't tend to be very good documentation on this at the moment. So to think about what we would like in Debian teams before opening up the discussion, I mean, three things that seem to me to be useful ways to think about whether our teams are doing well or not or that we might want to see in our teams would be transparency, communication and openness. Obviously, the main thing we tend to focus on, which is clearly the absolute priority, is just whether the team is producing good output or not, whether it is doing its job well. But if we want to think about how the teams are functioning as teams, rather than just in terms of the output, then these seem reasonable ways to kind of start to look at them and say whether we believe they're doing a good job. So each of these we could apply at different levels. So for example, how they are to other people who are project members, are they transparent or communicative or open? How they are to people who are potential contributors who are either already involved in Debian or not yet involved? And how equally for teams, for each team, it's more or less of a direct relationship, but how they are also to the users of Debian? And just to define a bit more of what I mean by each of these, for transparency, I really mean that the team, I would like our, it seems to me a good idea if teams work, including the problems within teams, are visible to others outside the team. They shouldn't just be a black box that's there, even if it's producing good output, because even on a pragmatic basis, probably in the long term, if it's a black box like that, sooner or later there'll be a problem and it's much harder to solve in that case. This could include, for example, some equally clarity what the role of the team is and who's in the team, if there's a specific leader or leadership group who is that, how the team is actually functioning so that people who are outside the team and just trying to see how it's getting on or to interact with it, but also potentially people who want to join the team can work out what's going on. Again, even for non-delegated teams, it's good if they define a bit what their response, what they see their own responsibilities as being, because again, sometimes you have a discussion where people complain a team isn't doing something and maybe that team never felt that that was part of its responsibility or on the other hand, a team can be upset because someone else starts trying to do a job without speaking to it, which that team previously would have actually understood as being kind of within its area. And again, even on a shorter term basis, it's much harder to find the energy to kind of document things on this level, but it's really great if teams can actually document on a kind of week by week or month by month basis who's actually working on what. Even if that's just by having some posts on some mailing list that's possible to find, rather than it just being say a few people who hang out on IRC and only those people know what's going on. For communication, I guess I mean that again, teams should publicize what they're doing, publicize points of contact and invite input. Again, I'm not saying that teamers should ignore their own experience or ignore their own knowledge about an area, often the people who really know the most about some particular topic will be the ones within a team, but at least if they invite some input, then there's a chance for other people to put forward their views and to have some kind of discussion about it. And then obviously, there's no point in inviting input if you're not at all open to taking it. Again, some teams might justifiably have a very high barrier before they listen to other people's suggestions instead of their own ideas, but they at least need to have some kind of openness that they would potentially consider what they can usefully adopt out of suggestions that come from outside. And again, that also includes that when often teams will get some negative criticism from outside, but really it's good if a team can try to respond positively to that in some way, even if they don't really accept the basis of the criticism that even if their response is just to try to manage other perceptions of what's happening better. Again, the kind of worst case is when they just ignore this and things build up over a longer period. One topic I was thinking about on this, again, I don't know how other people feel things are working or not, but it seems to me a bit that a lot of innovation in WN doesn't really come from the most established teams. A lot of innovation really comes from individual people who may or may not yet be part of the teams. If they are part of the team, it's often very easy for them to push that out. Whether they're not part of a team at the moment, it can be a kind of struggle for them to push those ideas for a team to pick them up. And there's again a danger that in some cases it feels as if innovation can also end up happening completely outside WN in particular areas and we only then come back and pick it up later on once it's been kind of a bit more tested, which obviously in some cases may make sense, but it seems that we would like, again, I don't know what other people feel, but it seems we would like WN to continue to be innovative. It has in the past been very innovative in many ways. Within teams, again, there's a kind of change which happens, which even if, it's also true, even if you look at individual package maintenance, which could be even an individual kind of as a team for that package, but as soon as someone adopts a role of any kind like that, they kind of move a bit from just scratching the itch, which is the kind of what gets talked about is why people work on free software or one of the motivators, to feeling they have some responsibilities. And that's a good, again, in some ways it can be a good thing, but it can also lead to some issues or people just feeling weighed down by the responsibility of some work they have. In the team context, again, this can mean that people end up working on things that they really, on aspects of the team, they're really not interested in because they feel they're part of this team, they have a responsibility to do that. Again, in as good as that, it means that the work happens, but we also need to monitor a bit and make sure that you don't just have some team that's just full of depressed people working on something they don't really find interesting because maybe there's a team where that one part is interesting and there's a lot of mundane work every day. It can be a good motivator to get people to do the mundane work, but we also don't want people just to end up giving up or disappearing from the project over time. Again, within Debian, there are lots of different teams that work in different kinds of ways. Even where there is no official team structure, there'll tend to be some kind of ad hoc working groups, even if that just means, again, people who hang out on an RSC channel on a particular topic. At the other extreme, you can have something which is set out by a delegation officially and often even in some of the, again, some of the would-be core teams in Debian effectively also interact with each other and have not quite a hierarchical structure, we kind of hope, but it's actually in some way, this kind of become a kind of like a bigger company structure in some instances. Both extremes have dangers and again, it's not to say that one is necessarily better or bad, but again, we tend not to think too much about how teams drift between these extremes. It tends to be in practice that most teams over time, they will start off as nothing become, you'll get a kind of ad hoc team that turns up and then it will become much more formalized over time, which has benefits, but again, there's a danger that we just freeze in place some structure that happened to be sensible at a time, but isn't necessarily one that continues to be the best way to run things, but it's very hard if you, once you have some teams that exist or some delegations, it's, well, it's not constitutionally hard, but it's hard in terms of the politics between people to say, for example, that someone's team is going to be blown up and merged into another one. Again, I mean, one of the big reasons for that, which also affects many other issues is the kind of idea of ownership, which is, again, something that was always around to a greater or lesser degree at the package level within Debian. We had, for example, in the last couple of years, some discussion about the rights and wrongs of hijacking or salvaging packages and so on, but again, in the team context, it can also mean that some team effectively takes ownership of an area, and even if the people in the team really don't have the time or motivation to work on it, it's hard for other people to do that, and that people can either just be scared off trying to do it because they're worried about offending someone or worried about encroaching on it, or it can mean that they try it and it leads to some big blown up discussion, and then once that happens, it's, again, very hard to settle things down and make everyone work happily together. It's, I mean, yeah. And at the same time, a kind of related point is the kind of balance in Debian between conservatism and innovation, that yes, we want to keep things at work, and we don't want to just throw away either the way we've done things in the past, if it was working, or how teams have been functioning, or we don't want to kick people out of teams just because they're attached to a specific way of doing things, but at the same time, we do want to make sure that conservatism, which can be positive, is not blocking off innovation from happening. And kind of three, having said before, three kind of positive aspects I would like to see in teams, there's kind of three things that I see as dangers that happen in some of the Debian teams that we would like to try and avoid really. This is team inertia, non-redundancy, and too slow turnover. So by team inertia, the kind of case I see here is that typically when someone joins a team new in Debian, they're normally full of exciting new ideas. And unfortunately, very often, the people who are already in teams know why they're bad ideas. That if they really are bad ideas, that makes sense for them to be, to dump in them down, but there's also a danger, even when they are bad ideas, there's a danger that the new people stop being enthusiastic and stop trying to suggest things. And at the same time, we would... There's also a big danger in this kind of case that the people who have been in teams a long time just think that they know why they're bad because they always did some things in a certain way and that really actually trying something else might be worthwhile. For non-redundancy, again, even where you have a team that's working on something, on some topic, and it looks like it's not just one person we're depending on, it can often be that there's really one specific person in the team who always does that piece of work and that if that one person goes missing, no one has a clue how to do that and it's just lost. It can also be that often people who join teams, join teams together or they came in at the same time and then they often actually become missing in action at the same time as each other. Even if that's just because they're kind of the same age and get married and have children at the same time, whatever it is, or they are the same stage in university, whatever it happens to be, often it's not rare that multiple team members really disappear off at the same kind of moment. And again, because this is, Debian is a social thing and it's people doing it because they want to work on things, often people are working with people they already know well in a team and it can be hard for them to find the motivation to pull in new people and to try and train them up to work on the area too. Slow turnover is probably a more controversial thing to be worried about as obviously you can see it as very good if people stay a long time in a team and really get expertise. But at the same time to me, I kind of worry about it a bit that again, maybe we should be encouraging it to be faster in some way. Whether that means that we're pulling in more people to train them up is a kind of one positive way to put it but actually I would also be ready to look at the kind of other end and say that while I wouldn't want to propose a specific term limit or timeframe for any particular team, it seemed to me that it would make sense for teams themselves to think about things a bit that way just because of the fact that people, again, people become very conservative often enough if they've been in a team a few years but also the longer they are in the team the more likely it becomes they actually get a bit fed up with the work, a bit bored about it. They can start to be less responsive to new ideas, less responsive to requests from the teams, interactions and often in the end what happens is someone will just go missing in action or really become very unresponsive and once that's happened it's again, then becomes a problem to try to fix that situation and it seems to me that really it would be preferable in some way if we could encourage people to realize while they're still enjoying some piece of work even that they should actually find another new thing they really enjoy doing where they can take the skills or the experience they've had from the previous team and feed it across and give new ideas to the new team rather than just waiting until they get so fed up they want to give up. So I think that's pretty much the old kind of introductory ideas I wanted to go on. So I'd be interested really to try and open things up a bit and see what other people feel either about things I've already said or about other aspects of how Debian teams are working. I mean preferably not just attacking some particular team but on the other hand it might be interesting if people have a team they feel is really is the kind of good example of good practice in any of these aspects. So again, any kind of ideas but I mean three things in particular that I was wondering about that might be kind of practical outcomes of any discussion would be one is just kind of updating or clarifying any kind of best practice documentation for what people would agree as being good for teams to do which again it would be better obviously if it puts things at a more practical level rather than just two high level ideas. A second thing which is we've already has been discussed a bit in the last few months but actually partly due to me being traveling a lot that hasn't really happened at the moment was to so it would be good to find some more helpers would be the kind of idea of maybe not so much a team survey which has happened a few times before which was writing out to lots of teams about their status but at least some kind of at least within the kind of more obvious Debian teams some kind of census of what their activity is and I mean one thing I've been looking at for example is just trying to track a bit in our, in the delegated Debian teams when did people actually come in how long have they been doing these jobs? That's not information that's easy to find at the moment and it would be interesting for any of these kind of discussions to be able to monitor that a bit and see what's going on and a kind of meta outcome might be some kind of teams team as in it would seem that it makes sense for there to be some group of people who are interested in these kind of questions to form a team to look at how the teams are getting on the ongoing basis and see if there are more initiatives we can encourage in the future so hopefully some people have some points. It's on, yeah, okay. Thank you very much for this introduction. I'm reacting about the team's team idea I think it's very nice because it could be a way to rise red flags when we see that teams are underpowered or things like that and to like try to help us so that the underpowered teams to help to find teammates because when you are overloaded with work finding new mates is additional work which you already have too much. So, and finding new mates in your team is probably something that can be helped with by others. So I would very much welcome such idea and by the way, if someone else would want to join me in the printing team, I would welcome that. Thank you. We have anyone else who's got a point at the moment? Everyone else thinks that all teams are working perfectly? Having changed your mind during the talk? Whether or not all teams are working perfectly I wanted to mention that Enrico Zini and Sightly Eye but mostly Enrico are interested in contacting people who run teams and asking them to list the people who are active in their teams so that relates to the team census concept and I think he'll be talking about the more tomorrow at a day being contributors talk. So I thought I would mention that for this group. So do people think, who thinks or someone wants to respond or you've got a question? Yeah, well I can say something about the Debian Ruby Team which I'm a part of since I don't know, half a year, a year maybe. And I think there's a really good best practice document and the workload and what should be done and what is done and how to upload packages which is done through a script basically. So it's documented how everyone uploads also. Not the same in other teams I'm in or have seen. So this has been a really big help for me to actually see how stuff should be done basically. Which has enabled me to take a larger role in that team than I intended from the start. Does someone want to respond on how long they believe it makes sense for people to stay in teams? Maybe someone who doesn't just say for as long as they're doing the work or who does anyone think that it is good to have change ever within teams or bad or not interesting? So my experience on the Pearl Team is that the active members come and go a bit except for Gregor. But so I don't know if it's necessary to change the official team roster as long as the group of people doing work is changing. Yeah, I mean, I guess in, again, that's another aspect that varies a lot between different Debian teams that some of them have a much wider membership. And then it's easier to then change more who's really active at any given moment within that. But there's also a lot of Debian teams where maybe there's up to kind of four or five members, but really it needs all of them to be active or pretty much all of them to be active for things to work well. And then as soon as one or two people become busy, you start getting into problems. So yeah, maybe you could argue that the small teams idea itself is slightly flawed. It should be medium-sized teams or slightly less small teams, I don't know. I have a point from Ganef on IOC. Having changes is good, but for some teams there's a huge learning curve. So regular change can be quite hard to achieve. Well, actually answering that specific point, one thing that's quite easy to do is to try to batch the change in the team. That is, may issue call for helps and several new members arrive at the same time. Well, that works very well for teams where there's a strict membership policy, not so well for packaging teams. But if you get three new members, you actually spend the same time mentoring the three new members than if you had to mentor only one. So having like call for help every six months, for example, is really a good way to manage that. Yeah, I mean, in some teams, a practical thing that could be done is to effectively suggest that the new member is responsible for writing some documentation as well. A lot of teams lack documentation and lack the time to produce that and really expect that each new member just figures things out over a long period. But as if you are the person who's figuring things out, it's typically quite easier at that point to write some documentation that's useful to other people compared to if you're a member who's been in the team a long time and everything just seems obvious. So, Lucas, you just mentioned about having a strict membership policy on teams. When should a team decide that it should have a strict membership policy? And maybe Mauret, is that the difference between a core team and a non-core team is one that's got a strict membership policy? Well, I'm not saying that teams should have a strict membership policy just that some teams need a strict membership policy because there's access to some data or security. Yeah, security, but we have like probably at least 20 teams in Debian which have more strict or quite strict access policies. FTP master is an obvious example of a team that gives access to quite sensitive data. Yeah, I mean, the great majority of teams in Debian are packaging teams for specific areas and the ones of those which are kind of more up to date with things will tend to have some Alioth project maybe where you can just go and click and join. And a lot of these, quite a lot of these, if there's someone they've never heard of before, just some guest account on Alioth, they'll quite happily take them as a new member of the team and just see what happens. But then if it's some area where you really need access to infrastructure, it becomes a bit more difficult. And is anyone willing to say something about, I mean, a case where they, or in cases where people have seen problems with the Debian teams, are there other points people feel would really be helpful in fixing things or are things as good as they could be at the moment? I mean, does anyone feel that some particular issue would just have been fixed if there was some different mechanism or different procedures? Just intractable? So I feel that something where we could get better in Debian and we actually got worse than in the past is try to get the good ideas from various teams up into the projects. It was about your slide, about team innovation and project innovation. I think it was, oh, it was on the slide. That's something that, well, I'm a bit worried that some teams spend a lot of time developing their own workflows, great workflows, for example, but fail to upstream that to Debian. And well, I'm guilty of that as well. Well, my work in the Ruby team, some of it could be upstreamed, but yeah, we could be much better on that, that's up. You know what? Go ahead, if you have something to say, go ahead. I'll go now. Okay, thanks. That's much better. So I repeat what I said so that people on video get it as well. So what in Debian exists is a leader structure for the project itself and several teams, quite a lot of teams actually, within the project. So when I am about to join a team or if you think, well, I would like to contribute to some projects, some package or whatever. I always have difficulties in finding who is in charge. There is no one in charge because it's all well-equal and so, but well, there are some people in the team that are really experienced that have been on the team for quite a while and then you will see as well. So you join the IRC channel and then it would be good to know who to address for that special team. So what I'm actually asking if it needs more like a senior developer, junior developer leader structure within the teams, which could be left to the teams to just, yeah, do it or don't, but it would ease things for people who come by and think, well, I might like to contribute to a, who shall I ask? And then if you're not too shy, you'll find out after a while. And on the other hand, well, people are all pretty modest. That's what I experienced in Debian. So nobody would say, well, I know how it works, but you know, well, you need someone who tells you how it works. So the question stays unanswered, well, who shall I address and who is the one that can give the best advice or the best compromise of advice at that point? So that's one thing that I'm sometimes missing when getting into a new team context. Yeah, mentorship does seem to be an important consideration and I think it's useful for teams to list not only who's involved, but what their roles are and maybe even who is most experienced in terms of not, you know, authority but in guidance ability. And that's actually, you know, I have a webpage to update for the nascent cloud team, which is sort of in the process of forming, I guess one could say. So that's a good segue to my question, which is basically any advice for a team in our situation, which is not even well-defined yet, but various images surfacing with support from people wearing a Debian hat and a Google or Amazon or OpenStack or OpenCloud hat or more than one of these and collaborating very effectively so far but in a sort of free form way. So if anybody has advice, that would be interesting to hear. We're definitely going to apply a lot of what has been said already, so that's good, but maybe emphasis or extra stuff. On the, to respond slightly on the previous leadership or junior-senior thing, I mean, I think that's interesting how certainly we're interested to hear what other people, how other people feel that would work in their teams or not work, but one thing I would say as well is just, I think even just having clearly defined points of contact is useful. Again, even if that is just bothering to document what the IRC channel is in some way where people can find it, but preferably really just to say how does the team normally communicate? If someone wants to become involved, what do they do? I mean, do things really happen on the email list? Do they really happen on IRC? Do they really happen by some other way, for example? Just following up on that then. I mean, the team is quite small right now is what seven, eight of us also on the Debian Cloud list, so that's pretty easy. If it's larger though, the idea between senior developer and junior developer might be worth contemplating something like front desk and not making senior versus junior kind of distinctions. It's also not necessarily senior versus junior that would be the relevant distinctions in every team. In sum, it would be like, I guess, that's kind of the pattern, not so much developer focus, but that's the pattern that FTP master does, I guess. There is some coding, of course, but for example, in our team, it's not really focused on senior or junior, it's focused on maybe one person is expert on Debian, some people are expert on Debian packaging, some people are expert on the Cloud, some people are expert on interacting with the rest of Debian, et cetera. So areas of expertise and maybe quantities of expertise, some way of communicating who to talk to for what. Another kind of show of hands thing that should be interesting is for the people who said that they are members of Debian teams, maybe put your hand up again first, and then do people feel that their own teams that they're in are working well or not, and keep your hand up if you think your team is working well? Yeah, it's just interesting to see whether people feel that it's, and do you think, is anyone willing to admit whether they think that matches how the kind of users of their team perceive it, or? We have a small booth a few days ago with the security team. Yeah, the security team has two, I don't know how to call them. There is some kind of core team, which is the four private things and DSA release and some sort of collaborate team where this public work and some sort of back classification. And I realize that most of the people in the big team has no idea how the core team works, which is kind of embarrassing, but yeah. Yeah, our plan is try to document that thingy, but the problem is that the people who has the information don't need the information and the people who don't have the information need this. I mean, I would say actually that a team I've been involved in a bit, or two overlapping teams I've been involved with a bit is the press and publicity teams. And similarly, even for some of the people who are quite involved in the publicity part, there is really a lack of documentation or lack of clarity about what the processes are. It's, again, it's quite typical of Debian teams that, or when they're of the cases where there are problems in Debian teams, I mean, that there's a lack of people to do the work and of course people then have to become focused on getting the immediate work done, not on creating some amazing documentation, but equally there's a danger in doing that because maybe the fact that you're doing the work keeps things going a little bit longer but it doesn't really avoid some kind of future crisis compared to trying to fix the underlying problem more or to make it easier to get more people to come into the team. Is anyone else, I mean, for people who are in teams, are there things that you would like to do to improve how your team works at the moment? Or you just think it's okay? It's okay? Any other points? So I know there are people who are feeling alone and frustrated and close to burning out on core teams. So it's fine that they don't feel like saying so in this meeting, but I know that it's true. I realize, yeah, clearly it's unlikely people are going to jump up and say that their team is completely dysfunctional and really it's all the other fault of the other people on the team, or their own fault. So yeah. But I think it's, I mean, there is a wider danger, not about this session, but there is a wider danger if people don't think about these issues or don't try to address them and just try to always just try to do the kind of short term, nearest solution. For the kind of topics that were listed here, are there people that in the room who would be interested in putting it in kind of a better or more detailed, maybe best practices kind of document? I mean, people who would be happy to work on that in principle. Anyone? Anyone? Well, the security team have been both for documenting in two days, I think, the 17th. Saturday morning, yes, Saturday morning. And probably it will be so general that anybody with a similar problem could join. I mean, we have no idea if we should use a frontal pressure system or a wiki or so. Any ideas? And is there, I mean, are there people who feel enough that some better information about teams would be useful enough to try and work on that aspect? Or not of interest to people? Anyone volunteering? Nope, okay, anyway. Hopefully there was some interest in the discussion and hopefully some of you will secretly feel inspired to go and try and make improvements to Debian teams. And thank you very much for the points that everyone's raised.