 Moray, we'll start talking about DevConf in Devian. Well, technically, I think the title this year is something like DevConf Organization. But for anyone who hasn't been at the last few years sequence of buffs on similar topics, we thought we'd quickly run through, slight, well, the slides from last year and to say, basically, if anything as well, where things have changed, if it's changed at all. So yeah, we're not in Bosnia anymore, even though the slides might say that. One of the things we did in the past couple of years that most of you probably are familiar with is that we defined what the point of DevConf is or what it's for. This had always been kind of known by people, but we had never actually agreed in any formal written-down thing what that was. So there were slight disagreements. So we decided that we'd have primary and secondary goals for DevConf since it is a conference. The main thing is about the face-to-face interaction, but also at the same time, within the primary goals, then providing the talks and video that can be seen by people anywhere in the world. And anytime later after the fact. And providing time for people to work on Debian during DevConf itself, as well as during DevCamp, both of them, that's also part of the point. And in fact, that's one of the things that the sponsors value most. It's much easier for us to get sponsors to give us money if we say people will be working on this or that technical part of Debian than if we just say, well, it's, we'll have talks and then it will have a benefit later on. And we also recognize that there are other things that DevConf can be positive for, including motivating contributors who have a nice time and giving some benefit to the local free software community and the places we hold the conference. But the outcome of the discussion was that these, although we want to promote both of those purposes, those are somewhat secondary to the first listed points. So another thing we had achieved leading up to last year's DevConf was sorting out the different, how it beats organizationally. So there have been, as in many things in Debian, there were different views about what was reality rather than just straightforward disagreements about how things should be. So the kind of extreme positions were, well, there was a group of people, for example, as previously with, say, the Dams, Debian account managers, there were people previously who used to say that because they existed before the Constitution, they weren't controlled by the Constitution. About DevConf, well, DevConf started when there was already a Constitution, but it started as a project that was linked to Debian but wasn't inside of it. So for many years we were run separately, we didn't share, well, what you will soon say, we never shared the budget, we didn't count on Debian, until we had these agreements and they formalized everything. So hopefully by now it's much clearer that everyone agreed whether or not they thought it already was, everyone agreed that going forwards DevConf was part of Debian and that it should be managed in a way that reflected that. So. I just want to add to this part about DevConf finances and Debian finances, that, well, we have hit reality, I mean, it's not as easy as it sounds. The accounts for Bosnia were just closed about one month ago, or one and a half months ago, so. Well, one week ago we were here. Anyway, they were closed just very recently, there was an overlap of when we had DC-11 and DC-12 budgets open, of course in very different states, but yeah, we will have to work how this flow should be managed. And this, we should try, I think, we should try harder before we give up on this point, so, I mean, since we're talking about this anyway, also if people want to jump in and say things, please do, this is not just a presentation, but the kind of agreement made here on this point was that DevConf would, in the long term, try not to cost money for general Debian funds, effectively, which means that we, in practice, that means we should always try to keep some, each year we should be aiming for it to make a small profit for Debian, effectively, so that in the longer term, we have the opportunity to have some financial problem and take money back from Debian. Well, and on this line, for example, this year the lateness on the travel sponsorship was due to us being maybe too careful, but well, careful enough, because we were approved to spend some money over what we got last year, last year we had a nice surplus, we were approved more money, but we decided to use it responsibly, aiming to still to be not below zero after the conference, I hope we can manage. Yeah, I mean, because again, although there is a kind of group of people who are calculating, who calculate the numbers very precisely, and therefore say, this last year we had, whatever it is, one $10,112.34 extra, and therefore we can spend that this year, but that doesn't really reflect the spirit of the kind of agreement if we just try to spend the money, because maybe two years later, maybe we have a disaster and a big loss. So, although it's, although we, in a way, the money that we, if we have spare money, in some sense that's kind of available for us, but I don't think it's correct for us just to, to view it as being there to spend in the same way as money we have raised in the current year. Yeah, I completely agree to this, that it should be handled that way, but I think we should also try to do is, that to see the Depecant budget as soon as it's agreed upon by the team and by the DPL is money we're actually allowed to spend, without fulfilling the income side at each step. So, we can, in the phase where we're still gathering money, already spend more money than we have, because on both sides, it's just an expectation of how much we will need or how much we will get in. And if this doesn't match in the end, we have to learn for the next year to do it better. Yeah, and two points in relation to that quickly. One is the, we agreed that the overall budget should be taken to the DPL and effectively the project and approved, and that hasn't happened yet for this Depecant. So next time, we should try to actually do this. Specifically on the point of travel sponsorship, again, although our own accounting people have been quite cautious about it within Depecant, there is a absolute permission from the Debian project via the DPL that if we want to spend, for example, travel sponsorship money in particular earlier on, yes, we should agree that not just within our team, but that's fine to do. We don't need to have sponsorship income yet at that stage to spend it. And maybe one thing to add also is that it becomes easier to understand that we can spend early money if you unzoom. I mean, if you take a look at across the years, then it's a rolling budget and we are just spending money that we have left from last year also. Yes, again, I'm cautious about- Yeah, of course, but I mean- It's not our money, but just because it's from last year, it is, from my point of view, I'd say, at the end of Depecant, it is just Debian money. Yes, but what I mean is that it's not a wallet that is empty when you start the organization that fills and that becomes empty at the end. It's the wallet, but you still have a bank that you can go and get money from. Yeah, we are part of Debian, so we can take one. So we had this discussion with Godin's earlier in the week, whether DSA can spend, for example, the Depecant's profit to buy hardware. If it's a rolling budget, we can't. If it's not, then we can't. So this is something that I haven't heard a clear answer. This is the first time I, from you, I heard something, but it still seems some disagreement with the team. And it would be nice to have a clear view, and this is, I realize it's not only- So again, at the moment, this is another, this is effectively a point, the same problem, that there is meant to be an agreement, but people disagree about exactly how to interpret that agreement, so yeah. And I think- No, there's a, yeah. Knowing how much we will, I mean, going back to what you were saying before, that we have not done this explicit step of going through the DPL to give the estimated budget, the thing is, at least this year, I don't know how it will be next year or following, not because it's Switzerland, but because every year is different. This year, the budget changed so much, so many times, that at any given point, we would have been approved for something bound to change sharply, and so. Could you, I wasn't involved in this yet, if you could say in a few words why this happened? Well, first of all, we, well, the team originally proposed a different venue, which was, it seemed like the only place in Managua that would be able to support something this size. Then we, after some adjustments, for example, turns out that due to the crisis in Europe and due to being more expensive to travel here than some expected and whatnot, we had less attendance than last year. So costs went down, but also accommodation requirements. And we, somebody thought about coming to this university and the, well, at first, we had a, a budget, well, yeah, an estimate of like $30,000 for renting the university, but insisting on it, they reached an agreement to pay about one third of that. So that's the reason the university is listed as a sponsor, because they're giving us a huge discount, even though we're paying. Things like that, we didn't count on any of the government's help earlier on. In the end, we received a good part of the costs of the hotel and so we really helped us, I mean, we're paying about one third of the cost of the regular rooms, so two thirds. Well, yeah, yeah, the budget was reduced many times. So, I mean, yeah, no, but you requested details. When you make a budget at the start of the year and you send the DPL and you have like, also covered like a 10% more for damages or whatever, then, and if you make a profit, it's all the better, but the problem is if you're over budget as, and my nationality proves that, but. Yeah, anyway, I think we, no one is against us trying this experiment more like another time to see if we could see if we can make this work. There's a short note to the changing budget. I think the way to do this is if it changes significantly, we just have to re-approve the budget or re-approve the changes. Maybe we can come back to the money topic but just come through some of the other points in the meantime. So, yeah, one point that is still not really, there's been a little progress and maybe there'll be more following Debcon that is not really resolved at the moment is because of the way things developed and the people involved. We have a kind of entire, well, a separate infrastructure for Debcon, including things like db.debcon.org for the account management, which, yeah, it does actually make sense in a way, but also it is another service that we have to maintain, so on, yeah. None of this is really urgent tasks. More the, yeah, exactly, which is why not much has happened in the past year, but it is something we should bear in mind because as people who have been managing these services become more busy, we should ask whether it really makes sense to find a new set of volunteers to take them on or whether we can merge them back into existing Debian infrastructure and then it's not the problem of the Debcon team at least to find those volunteers. I mean, again, at the moment, they've been very well managed, everything is great, but again, it would be a pity if in the future, for example, we lose the list archive because someone who, we don't have proper volunteers to look after it, for example. In point of fact on that, I found that each, at least on the front desk level, each front desk of every venue, of each venue that we've been to has been run completely differently and they're reinventing the wheel each and every time we come in. So there's, there always seems to be mass chaos, there always seems to be mass communication issues, nobody knows what's going on anywhere and it seems like they're just reinventing it at each specific year and I think it is important to have overlap each year with the same people just to keep those concerns and those communication issues done. But this also relates to a thing that's been developing during the last year and we should try to continue even in these next months after Debcon, which is the Debcon of manual, which is just pages in the wiki but it's trying to document some of the processes including things like front desk. Did you want? Yeah, I want to comment on this as well. Front desk is one of the places where most of the local population can easily relate to and we often prefer somebody local to always be at front desk because if somebody asks about where to whatever or I need help translating whatever to this language, well it will need a local. Here I cannot do many things because I don't know Managua and I don't know many ways. So that's maybe one of the main reasons why the workflow is different because it's different people running it. Now this year for example, I saw Mori spent quite a lot of time at least at the beginning. I think it was also like being as training wheels for the team to be there. Well this relates a bit to something that's also on this slide. I think it was not so hard this time but we were a bit worried earlier on this cycle that after we got the formal delegation it seemed that people who were regularly involved in DEF CONF organization took a couple of steps back because there were now delegates and locals. Then maybe some people felt they were not needed. I'm not saying this was for everybody of course, I know there were many reasons for people to reduce the involvement but at some point we did feel it was the three of us and the locals with sporadic intervention from others. So we have to find a way to keep a bigger team. I think on this point there has been a problem over several years that in the past we have always recruited new core DEF CONF team people from previous local teams. But maybe we have got a couple of people say from New York but they're more in specific areas for example in networking or other topics like this not so much in the general management because of people's time availability and so on. And then again from Bosnia say we've got some people who are interested but again no one who is really stepping in to be a kind of core person. I think we should actively ping the people from Bosnia as we're going close to Bosnia. I'm sure some of them will be in Switzerland. But again I mean as though it's... No problem. Yeah but again the local team here I know at the moment everyone is completely exhausted and probably after DEF CONF you don't want to think about DEF CONF ever again but if any of you can it really is good for the organization if you can just even if it's just to come to some of the IRC meetings or occasionally read the mailing list and send your view because so much of our experience is really with the local teams. I mean even in this kind of DEF CONF like this even while we have the chairs we see some things but a lot of the practical experiences with the local team. And if the local teams don't stay involved then we lose a lot of the benefits that we can have for the future teams there. Well something that we should consider and now that it's been slide like one year and a half from the delegation is whether we should explicitly rotate the chairness. So one thing we've done as well as having the chairs we now have there exists as an idea what we called the DEF CONF committee. At the moment this has only been used for the decision process of between bids to avoid it just being a sort of cabal of a few people. It would what I would like to see I don't know how we formalize it I'm sure other people have some ideas about this I would like as if we could not to write more rules and procedures necessarily but to see if we can make the people also who join the committee not just fail a responsibility for the decision but also to feel that it's well as support for the general process. And again some of these people maybe they don't have time to come to every meeting or to read every message on the lists but these are all people who have had some experience from running DEF CONFs before. So again if we could find a better way to draw on their knowledge this would also be very beneficial. So yeah I don't know exactly what's best in that but we should be trying to think how we can draw these people in better. So it seemed like we jumped over the infrastructure overlap thing. Well it has been it has been improving I think it is not an urgent problem but it is something whenever we see a good way to move something without breaking things we should consider doing it. Yeah yeah no I we are trying well a guidance was approaching me to discuss on how to split our current SVN to get and of course that will go to. Yeah this is not actually solving the problem because we already moved that to Alioth anyway. Well yeah that's a different question. Okay right but for example the pentabarff instance we have now one of the main blockers is it's very hard to hack on it because the only machine I should be making changes to while developing is so slow I cannot use it so I can only work on the live copy and whenever I make a modification I have to restart the server which breaks the system for like half a minute so if people are busy I cannot fix things. If we were running on DSA hardware. Just since it was mentioned there actually this question of migrating the VCS I'm on a technical level I'm very I agree entirely I just wanted to point out again this question of keeping our knowledge and experience that I'm very worried if we migrate to a more secure solution where current local where the new local teams cannot access all data because that would really be bad. Maybe actually Felix could say something of what he as a current local team person how whether you think this is useful data but yeah. Okay so I don't know if it's planned to have time to have this discussion here so because I talked to several global and also to Felix I think and we discussed this a bit and I think I really understand your concerns and I mostly agree. One thing is that I think that most people for various reasons some are more valid than the others might want just to move to Git because it's the new cool thing and also because of valid reasons like you can work offline and stuff. But I agree that most of the Git features we actually don't need. I think they won't do harm because if you don't push it others won't see it so it's a bit worth it so there's incentive to push. And on the organizational level I think we need to split the repositories if we go to Git because it's no longer possible to do partial checkout. You can have partial trees but you need the whole Git repository and it's just too big. And for the access rights my proposal now after thinking about it a bit is to have it as for Debcon data to stay with the current model as it is and to have breed access public and easy access for writing and for Debcon team that's something we developed together with Gunnar. The proposal is to have each year one trusted person from the locals in the admin group so he can at his own discretion add people and that we do after each Debcon we do a cleanup and throw out people that no longer need that access. But until like this we can avoid to have projects per year because I agree that that's a hassle and then we would have to add some selected locals to the previous years to guarantee your access and I think that's really valuable to have the previous memory. I don't know if people here agree that that's a good way to go. Again part of my worry is not just about the having access or not but if it's too much effort to access the old data people won't bother. I didn't check the size exactly but I think it's doable to have all of Debcon team in one Git repository. I know it's also actually on the point there is some data in the team repository that just shouldn't be there so we should consider when we although it obviously is nice to import and keep our history blah blah but we should also consider just deleting some of these things that it shouldn't be there in the first place. Yeah so if people send me specific SVN revisions to drop I can just drop them that's easy. Darst already sent me something I will drop if I do that conversion. Yeah I think it's important to keep history and the track of how things were developed following on time but that's mainly on the data that changes and we want to track the changes. I think that the private team repository doesn't have to be we don't have to import a history the version's history. We can lose that the changes. Yeah the changes. We want to keep the whole of the data that's there we may keep the I mean the historical SVN doesn't bother us too much but I think yes we can delete some things by just taking a snapshot of how it is today. I don't think there is any value on getting all the data since five years ago I think it was started. I think there's a value. I don't know if it was because our team wasn't really involved in Debian before but for us I think for all of us it was really nice to have more than five years backlog for 2Depkont because even though in the last three years maybe things or in certain areas some things weren't like really important or weren't like really working as good as before it was really good to go five, six years back sometimes and just look at it and I really started checking out branch sub-directory by sub-directory and at the end I ended up having almost every year in my computer. No yeah yeah yeah but what I mean I mean having the whole of the information we have we should keep everything but if we are facing this decision of we have some data that should be cleared some private personal data that should have never been in the repository we can just clear the issue with the least amount of hassle possible by taking a snapshot of the whole of it and deleting the history. We don't need it. I mean if there is need for it I will shut up and accept it but... Yeah I think we more or less agree on this. So people agree that we do want to do this conversion in the way we said now and then I will just go forward and talk to Ganev how to do it technically or do you think it needs more discussion? The only thing I see from this is that it might be useful to have a period when there's a proposed new version and people can check through for other data that shouldn't be preserved. Okay so but then I will do a proposed conversion and wait like one or two weeks and then we'll do it. Okay. So jumping off to topic. One thing that has succeeded from our point of view is that we killed off the Debian press team and we now use the Debian press team instead. We should get better at using it though. Paul's thinking about saying something. The Debian press team is currently understaffed so we need Debian people in the team as well. I was pressed going into this. Yeah. One other thing, I'm on the Wiki Admin team. This came up, emerging the two wikis came up last year and I talked briefly on ISE with people on the Debian press team channel. It seemed there was a little bit of resistance to that idea. We spent quite a long time before not that many years ago de-merging it. I think it would, from my point of view it would be the best solution in a way which is not necessarily one that the wiki team would like is that the wiki people on the side of doing the admin for the main wiki they also kind of press the button and just copy the same configuration across for Debian Conf 1. Because at the moment it's a different wiki system which is, well that's maybe our fault we should solve it but even for the namespace it was kind of got ridiculous before when we had everything under wiki slash Debian slash Debian, slash Debian, slash Debian, slash Debian, slash Debian Conf 12, I mean whatever. It doesn't make a nice thing for people to find. I spend most of the day typing penta.debian.org slash penta slash penta bar. Regarding the infrastructures, the other infrastructure things, like I'm not going to get out of the list because that's the least mastered but regarding UDLDAP or other CIS admin stuff and with my DSA hat we've never heard anything from Debian people like this is what we need and either you're not doing anything in this area which I understand what's going on but I hate it to see people trying to work around things. There is a Debian Conf CIS admin team most of whom are inactive but the policy of the Debian Conf CIS admin team has been that they like having their own services. So we haven't, yeah, Gunnar wants to. No, no, continue please, finish your idea. Well, no, I mean it's not really a it's just that's the status. There's no reason for me if there are people doing the work in the Debian Conf although I don't think it makes sense to duplicate it it's also not nice to tell them that their work is useless and yeah. Yeah, it's definitely not useless but yeah, the most visible part of the team is your he's of course a great administrator. He, well, he likes having control and yeah, there's been, I mean I hope I'm not talking behind his back. Sorry? Yeah, I trust that my account privileges are dropping by the minute. That's good because I don't want to be responsible for. No, but I think this policy of we want to administer our own stuff is because he is the most visible part of this team. So, well, maybe we should discuss this but not here, but in the list and with you as part of, well with DSA as part of the discussion. But I'm not sure what you're saying here. It seems to be an agreement that you need to merge stuff with Debian and then you're saying that, well but this is separate and work so we shouldn't merge. My view is that it should be merged and that this will happen at some point but that it's not beneficial for me to try to push this in the short term. So maybe again, some of these other points here under this heading, which again I think it's better if we discuss on the list or subsequently. One point I would like to raise again here is this at the top of the page now the about, again, we've only got a couple of minutes so just to flag it up as an issue is this Debian Fundraising Team. Yeah, fair enough. So just on the UDL about that stuff I think at least part of the reason for keeping them separate wasn't the way around you're just presenting it but to keep random people that aren't ever going to be DDs out of UDL depth and that's the reverse driver for keeping them separate. I want to say something about the Fundraising Team. What I saw and what I've seen in all depth cons as far as I know there's no continuity in who were the sponsors who was the contact, who wanted to sponsor but didn't sponsor at the end who doesn't want to know anything about us anymore. So like having at least like this documented would help I think every new team for the next years just to know to write to and it's not like the best way to rely on people like doing a call and hoping that people stand up and contacting every year again their contacts. So I think the first step with this is doing a list and then there are other things that I just think that it would be good to keep in contact with sponsors. I think that sponsors should at least get a final report in an email. It's just nice and it helps that every six months they get a notice from depth cons. So I definitely think that it would be a good thing that it would help in the future to get it more organized. I want to bring back an idea. I put forward on the mailing list after 2010 the idea of having permanent sponsors so being actual sponsors not only the network sponsors that will help us a lot and it will help our sponsors a lot with the planning that means we give them a figure before December so they can budget and they don't need any brochure because they are already permanent sponsors so we can invite certain people, certain companies to become permanent sponsors and we put their logo on DevCon.org. From my point of view, this sounds fine but I would think this is a thing for the Debian fundraising team to think about. Rather, again, this is the kind of thing that if we had a proper fundraising team as preferably even with some people somehow found to actually have experience in this area not just some geeks like me trying it for the first time then people can actually, I mean there are people who work professionally even as fundraisers and they know what does or doesn't work. We don't really know but I'm sure we can get if there was a team really working on this even if we can't get those people directly into the team I'm sure we can get some information from some people with a positive attitude to Debian and really learn what's better. The other reason it's to be in the name Debian fundraising team is because other parts of Debian until recently basically didn't spend money but they're starting to do this and there's a big danger if we don't, what's the, well yeah if we don't work together then we could actually cause problems. A note to that, quick note. Gordon's approached me the other day about us DSA which we recently also announced that we have a five year plan that involves spending around 30,000 euros or dollars I remember per year so Gordon suggested to me that DSA should coordinate with Debian sponsorship team so that we ask sponsors once instead of twice and I don't find this entirely, I find it reasonable to coordinate but I don't find reasonable DSA talking with Debian which are very different requirements. So I would to support a unified fundraising team which can also have unified benefits. So if someone comes to Debian and says here's 100K to buy servers then I would expect them to be on Debian partners even if they didn't give money to Debian itself or the other way around maybe. Yeah when we originally talked about this together I was a bit skeptical. I think I'm a bit skeptical still but I see that there should be in theory in an ideal world this one fundraising team. The problem I see is that if this happens and there's kind of a shift of responsibility we might end up just having no fans at all because I think in Debian we don't have people that are genuinely interested in just to fundraising but they're interested in doing fundraising because they want this cool new hardware or because they want to run this cool conference. So I think, and as I see it now I think we should have this common team but it should be staffed by those actually needing money. So it should be staffed by DSA, it should be staffed by Debian team and if others want to participate every Debian team should be very open and I would love to see people just doing fundraising but if we just rely on this happening out of nothing it's bound to fail. Okay I think that's all we have or we are over time by some margin so we should really stop and let the video team which means Phil and other people stop if they're still awake. But anyway, thank you and thank you everyone for coming and hopefully we can continue these discussions on the lists and IRC once everyone gets home. Thanks for coming.