 Well, this talk is about the question that's here. Are we really devoted to our users? I think it's an important question that we have to ask ourselves many times. And I've been thinking this question for a long while. When I posted my paper, I got a lot of messages replying to the question and I've got the final answer. The answer for this is it depends, right? So we are going to see on what it depends and several aspects of that. Well, first of all, I want to start citing the social contract. The social contract is what distinguishes Debian from every other linear distribution. We have a social contract and many people have joined Debian because of that. It's what has attracted a lot of people because it's not just working for fun. It's not just working for a technical achievement. It's because we want to do something for the world, right? We want to take over the world. And this quote from the social contract, we will be guided by the needs of our users and free software. My feeling is that Debian has spent a lot of strength on the free software part, but very little on the our users part. So that's what motivated me to give this talk and try to rethink that our users part. So the first step to know if we are really devoted to our users or not is to know who our users are. Some people think that our users are other Debian developers or programmers or geeks, people that know how a computer works, people that can spend hours and hours making a kernel module work or something. Yes, those are our users, but those are not the only users we have. Other distributions like Hentoo or Slackware or something like that can have only those users, but we are the universal OS. We want to have more broader spectrum of users. We want everyone, everyone out there is a potential Debian user, right? So a house wife or a government employee, a kid, a five-year-old kid, a 20-year-old grandmother, everyone out there is a potential Debian user, right? So it's a broad spectrum of needs. It's not just the geek that uses MAT and VI and or EMATs. Well, so we need to find out what the needs of our users are. Since we have such a broad spectrum of users, each group of user has a different need, yes. And since we are the universal OS, we want to fulfill all those needs, not just one group, but all of them. So we still need the stable distribution, we still need to release and to have security updates, but we also need a better desktop. We need people to have a distribution that's easy to install and easy to use and that is translated to other languages. I think the people from the Debian installer have achieved the easy to install part, but the other parts are not yet there. It's not so easy to use, there are many things that are not so well done, many things that are not translated, those are the problems that we have, right? So those are the needs that we are not yet fulfilling. So why are we failing? Why are we failing to fulfill all the users need? First of all, as I mentioned previously, a lot of us don't use the software end users want, like we use much instead of evolution or we use VI instead of open office or whatever. So we don't care if open office is slow because we don't use it, right? So as we don't use it, we can't see the bugs and we don't feel like fixing them because they don't affect that, that's one of the problems. Another one of the problems as I see it is that those applications as they are end user applications are like second class citizens in our archive. Like libraries are much more important when their release is coming and we have to take packages away from the testing distribution. If it's a library, you think it like five times. If it's an end user application, you say, well, how many users have it in popcorn? Well, 30 or 40, it's okay, we can't remove it. And we are forgetting that not everyone is using popcorn and that even if it's only a small group of people, we are taking that application away. If it were a library, it would be different. I think that's a problem. Well, other problem related to internationalization is the fact that we all speak English. Maybe with more accent, maybe with less accent, but if we are here, it's because we speak English. To be a devian developer, you have to go through the end end process which is completely in English. So you have to speak English, better or worse, but you have to speak it. And then you don't mind if sometimes a dialogue comes up and it's in English. Well, you understand it, it's okay. There are people who don't understand a single word of English. And to those people, those dialogues in English are puzzling and are a potential problem because they might select the wrong option and do something wrong in their computer. And the last point is that we don't really care. It's not like nobody cares, but there's a lot of people that don't really care about the users, don't give a damn about them. So that's a problem too. So, to fix this, we need to define which goals we want to work on, right? We can do everything at once, we can fix all the problems at the same time, we need to define goals and work on those. This is a list that I selected. It doesn't mean it has to be like this, but I think it's important to decide which goals to work on and do it. And then we can go on with other goals, but keep it in mind and keep putting goals. Well, one of the goals, it's what already Christian said on the Debian Instauri talk, to have complete internalization of the whole Debian system. And of all the languages to cover the whole map, to have the whole map in red, do not leave a single country out because a country that does not have Debian translated to its language, it's a country that won't be using Debian, right? And we want it for the whole world. Well, another thing that I think it's important, and I've seen it on the list, that other people think it's something to work on for the next release, is to optimize boot time and hardware discovery. There are a lot of people that care about this, like people who use dual boot systems and they really complain about how slow the booting of Demian is. Other distributions would much, much faster. I don't know why, I don't have the technical skills to fix it, but I think it's important to know that it's not the same if your system boots up in two minutes that if it boots up in one or in half a minute, right? It's not really the same thing. I mean, for a person that has 100, 200, 300 days of uptime, it doesn't matter. But for a person that is switching the operating system two or three times a day, it matters. So I think it's something to change. And I think that there are quite some number of people who agree. Another point from my point of view is to simplify package management because everyone needs to do some package management on their computer. And even synaptic, which is quite nice, is still quite difficult to use for the complete clueless person. So I would say we need something like task cell but ported to the graphical interface, right? Something like the person can say, please upgrade my GNOME environment. And that's it. And the GNOME environment gets upgraded. Something that's stupid, right? We won't use it because it's not for us. It's for the end users. But we still need it so that people can upgrade their GNOME environment and not stay with the one they installed two years ago, right? Well, the fourth goal is to improve general speed and reliability. I think we have to work on that. It's not that important but still, it's quite frustrating when someone tells you that, yeah, Linux is fine but Windows is much faster. And it's true. I mean, if you use VI, it's not. But if you use GNOME on the same hardware, the proprietary software works much faster. So, well, I don't know. It's an argument that I have no reply to. I mean, yes, it's free software but the person still wants the proprietary software because it's faster. Well, then the next step is how to achieve these goals. The most important point for me is to set global goals. Not one person will achieve all the things that I said, all the things that you want to achieve for Edge or for H plus one. We need to set a global goal. Like, for example, optimize boot time. And everyone that works in a package that is related to booting has to work on optimizing boot time, say for six months or something, right? Set a global goal and everyone works with that goal. Then we achieve that goal, we pass on to another one. But we need to set global goals. Working independently, we are not going to achieve these global things. Well, and the third point, it's more important even. In both more people. In both more people because we can't translate to all the languages in the world. We can't assure all the graphical programs work perfectly because we don't use them. So we need people that use the graphical programs. We need translator for all the languages. We need people that care about the users. Remember the point that said we don't care. Well, we need people that do care. If we don't care, we need people that do care to help us achieve this. Well, I know that involving more people is like a sensitive subject, so I've thought of some ways of involving more people. The first way is translations, yeah? Translations are the key to world domination. We need to translate to the whole languages in the world. How to do that? Well, the first thing is that you, as package maintainers, can get translations for your packages. Even if it's upstream, right? You can still help upstream translate. You could go now, get your PO files and ask on the translations groups that Debian has for each language, for Spanish, for Portuguese, for Sherman, and for all the other languages. We have translation groups. You could go as a package maintainer and say, please, do translate this PO file to your language. They probably do it in very, very short time because it's not that much work for most programs, for most programs. And you say, well, this is upstream work because it's not my responsibility to have the upstream PO file translated, but still we are working to make the best distribution so we can do some upstream work. So I'd say this is an important step that can be done by anyone and you could go after we finish this talk and do it. Get your packages, see which translations are not up to date and get them up to date. Well, the second step is to pay more attention to the localization bugs. This is one thing that many translators have complained about, that when they submit a localization bug, it sits on the VTS for months and months and months because it's not important because it doesn't require or it's not worth a new upload just because of one localization bug. This is false. We need to give more importance to the localization bugs. We need to fix them as soon as possible to have all the packages translated to as many languages as soon as possible. And the third point, I think it's important but I still don't know how to do it, is to unify the whole internalization work. We have people working on map pages, we have people working on Dev Confiles, on DI translation, on the web page, on the Deviant Weekly news translation. All that work is done separately. I think that in many times it's a waste of effort that we could show in those groups, I mean for language, right? And automate, they are showed so that it's easier. Also what Christian said about making it as easy as possible for people who don't have the technical skills to do an SVN and whatever, do it as easy as possible and as automated and centralized as possible so that no work is lost. Then, other thing is to fix bugs. On the release for search, we only cared about RC bugs, right? And if a program had a graphical interface problem, that was not RC. Even if the user is really annoyed about the problem, it's not an RC bug. So it goes and fix and search is filled with many, many bugs of graphical interface. Why is that? Because we don't have the time to fix so many bugs. And most of them are upstream bugs, so it's even more difficult to fix them because we need to know the bad stream. Well, my proposal is to make it more appealing for people to fix those bugs. For people who are outside Deviant, we don't need Deviant developers to fix the bugs. Anyone can read the code, fix it and provide a patch. So, my idea would be, first of all, to add some new tags to the BTS, like what's the language, if it's Python, Perl, C or whatever, and how easy or difficult it is to fix this bug, if it's trivial, if you need to be a guru or something. And some other levels like that so that the bugs can be classified. And people can search for the bugs that they want to fix and they appear more appealing to them to fix them. Then have something like this week's bugs or today's bugs or something like that, advertising the bugs that need help so that people can go to that list and say, well, I want to fix a bug. Let's see which are the bugs that need fixing today. And after that, publish the name of those who fix the bugs. Like, in the same thing, right? If you have the list of the bugs that need fixing this week, then publish the list of the people that fixed more bugs last week. I think that giving more visibility to bug fixing will make more people that are not Deviant developers help us in fixing the bugs, right? We can't fix all these bugs, there are too many. But if we get more people to help us, we could do it. What? And I think that the key to all of this is teamwork. I want every project in Ilios. I think it's a bit too much, but I still want it. I think Ilios is awesome. It's great that we have it and we have to use it more. I think that almost every package needs to be command-tained because it's better when you are with a team. When you have someone else that can tell you a better way to do things. And in this way, we can incorporate non-Debian developers in the packaging much better than what we are doing today. If we have a team to maintain a certain package, say, for example, evolution, and in that team, we have a couple of Deviant developers and a group of six, seven or whatever non-Debian developers who are all helping maintain the package. The package is still uploaded and checked by the Deviant developers, but it's a place where the non-Debian developers can work. Like, they have access to that package, right? They don't need access to the whole archive or they don't need to go to the whole new maintainer process just for one package. They can collaborate in that package and what they do is still worth. They don't need to be a Deviant developer. Well, and this is my conclusion. If we want it, we can do it. It's just a matter of will, of what we want and what we can do. We want to make the universal OS. We want to take over the world and we can do it. We just have to set the goal and do it. And for this, we really need to involve more people. That's it, questions now. Thanks, Marge, for your nice talk. I think you said a lot of valuable things what we as Debian can do to involve more people to get our bugs fixed as well. And I really want to say, localization was even now for the release of such, not something which I said well, they might or might not, but actually we accepted localization fixes until up to the very last minute for such, which, well, because they are so important. But I have one question to you. It's the very beginning of the slides. Where the first slide was, our priorities, our users, and the free software. But now you spoke mostly about more technical things like how involve more people, how to get better translations. So are there other things that we need to change? Do we need to change our development model? Do we need, for example, a recent change of the Debian Free Software Guidelines? Did we already cross a bad line? No, I think I said it when I started. I think Debian is awesome on how it deals with free software. Hey. Okay. I think Debian is really doing very well on working on free software. I totally agree or almost completely agree on what is being done. I don't feel there's a need to talk about it. I think it's just being done so perfectly well that I don't need to speak about it. It's not like I say, hey, our priorities are only our users. No, I'm just saying what's missing. So my question was on one of the slides you had, I think about needing more bug tags. More tags for the bug tracking system to make it easier to track language stuff. Can you go into some more detail about which ones and we can add them? Yes, well, those are the ones that I think are more interesting, like which language is the package? I think that it is probably a package tag that should be added to the package itself to say if it's Python, Perl, C or C++. And the other important tag for me is how difficult the bug is. The tags I've thought for that are easy, trivial, interesting, tedious because there are some tedious bugs and guru level or something like that. Those are the tags I've thought but maybe someone can think some more. So earlier you mentioned that one possible way to solve all these problems would be to set goals universally across the distribution. Do you have any ideas on how we might be able to do that? Who should be coming up with these goals and pushing them out? I think it's probably the release team responsibility to set the release goal, but I'm not sure. Yes, one of the things I wanted to pick up on and spotlight a little bit is you talked about the problem of the fact that we don't always use the software that we tell our users to use. And I had a really intriguing experience with this in Stuttgart at the GWADAC conference a few weeks ago because I recently, as those of you who've been looking over my shoulder have realized, have been trying to use evolution. Emphasis on the word trying. And when I was at GWADAC, there was a presentation by JDub and various other things that were talked about about this idea of 10 by 10, trying to get 10% of the desktops by 2010 and so forth. And more or less in the process of that presentation, there was some comment about how cool it was to have evolution now in the main code base and all that. And so when I was talking to Nat Friedman with various other people standing around, I said, out of curiosity, show of hands, how many of you use evolution? None of them. And I said, okay, fine. So me, one of your poor, silly users trying to use this stuff, let me tell you what I think. And it led to a very interesting conversation. I don't know if any of them will actually go home and try using evolution or not, but this is a point that I think we have to take very seriously. If we are building things like standard environments and we're not using them, if we are giving people higher priority choices in our multiplicity of different editors and mail clients and all these things and we don't actually use the ones that we're putting at the highest priorities, we are really setting ourselves and our users up for real problems. Yes, I completely agree. I actually use evolution. I know how much it sucks. I've been trying to help with the package, but it's quite difficult because the evolution maintainer is not very responsive. Yeah, that too. You said in the very beginning that Devin is supposed to be for everyone, the five-year-old, the housewife, the government agent, the grandmother, are you sure? Yeah. Thank you. I'm sure that it's supposed to be to everyone. I realize that it's not like that right now. That's why we have Devin and the readers covering those points, but I think that Devin should be for everyone. I really think so. Two points that you mentioned in your presentations which really attracted my attention when I really liked them. One was about using Alliot more. I was thinking, and I think this is a point that came out recently, was it yesterday, I think, in the community gathering of Fubuntu people that was mentioned that, couldn't it be that using Alliot in any sort of space of sandbox where people can collaborate could be integrated as a part of the NM process? People that actually participate in some teams on Alliot could basically get what they've done there added as, for instance, an example of their skill set. That I think would be quite productive. Yes. I think it could be nice to replace the, have a package in the repository clause by have worked in Alliot in a package clause. Right? It doesn't only prove that you know how to work in a package, it also proves that you know how to work in a team. Exactly. The other item that attracted my attention was about NMUs and co-maintenance in general. And I don't know if anybody's ever noticed on the package tracking page for package that have a high priority. You sometimes run into messages that say, this package has a priority standard of hire. You should find a co-maintenor. Could we have the powers that BND been replaced that showed with the most? So the packages that have priority standard of hire don't remain with never ending list of bugs that accumulates because only one person maintains a package or two and they both happen to be neglecting their package or not having time to maintain them. Eric, that power has been delegated to the package policy committee. So that's in the hands of Andreas Barth and Manoj Srivastava and Matt Zimmerman. So. Would anyone of them care to comment? There's a documented procedure for making policy amendments. So I urge you to do it. But having delegated that power, I can't very well now undeligated. Well, technically I can. I could can them all and then do it and then reappoint them, but that wouldn't be a very nice thing to do. Finding a team for standards or hire packages, I guess it's easy for everyone because of our open bug tracking system to browse through the, there's no one holding it back to browse through the bug tracking system of those packages with only one maintainer neglecting it and sending patches in. And in maybe not an official way, team commanding it, but also contributing to the package. Yes, I was saying that sending in patches doesn't guarantee that any of them will be merged and that there are in fact packages with lots of patch being submitted and not being integrated and no efforts being, I mean, Marga gave the example of translation patches not being paid attention for. I can say that there is a few crucial packages to Debian right now that are in desperate need of attention and that have in some case seen patches submitted without any reaction for over two weeks, for instance. So I mean, yes, I could go through the PTS and see which package seemed to only have one or two maintainer or seemed to haven't fixed bugs, but that doesn't mean that the maintainer has to react to them or will. And that to me is a big problem, I think. You want me to repeat that, Mediel? Okay. He said, you realize that base was frozen for a long time before Sarge was released. And how long ago was Sarge released now? I mean, release has already happened. We're back to the development phase and still those bugs are not being responded to. I think that's a quite interesting discussion, but not really concerned to the topic. Perhaps we should leave it till after we finish it. So here was a question and then Ganna and Peter. And here, yeah. Yeah, sorry, Hal. Well, I don't really have a question, but I rather want to share my experience regarding constellations. I mean, there is interestingly enough, there's a lot of users out there who really want to contribute to translations. But I think the main blocker are two. First, they don't really have a clue of how to do that because there's nobody, and no really obvious hint on any webpage. And the second one is you can't really expect that they take the eye and the profile and translate that. So we really need to agree to a common standard platform where we can coordinate those translations. I mean, one of those great efforts has been Rosetta. I don't know how many people here know Rosetta or have even tried it. I mean, I tried it once and it was quite... That is what translations should really look like. It's make really easy, there's internal checks and so on. And just for the fun of it, I put the part file of one of my own packages, P-mount into it, which is not really the first thing you would expect to be translated because it's rather backend and nobody really cares about the translations. But still I was really surprised how much contributor translations I really got. So maybe you should just try that out and it doesn't need to be Rosetta, but at least there should be a discussion going on on how to centralize those efforts. They're really good and easy to use interface. I had a question about translation localization stuff. I agree that having translation and support for all languages is very important. Do you have any ideas on how to handle bug reports, for example, in people speaking languages that the maintainer don't speak? Yeah, we talked about this on the last DevConf. It's not easy to implement, but I think that the better solution for this, it's sort of proxying the bugs. Like you send the bug to someone who speaks your languages and also speaks English. You have a little interaction with this someone so that the bug report is really well done and after this interaction, the person sends the bug report in English to the package itself. It's a bit difficult because it requires a lot of manpower. It's not something automatic, but up to now it's the best solution I've seen for the bugs. I think it's important to have the VTS support as a language is and as I said, up to now that's the better solution and if we don't have anything better, I think we should go for it. I agree with basically everything you've said, but there's one point that's also a bit dangerous. We have to center our efforts in our users, but thinking that our users are desktop users is also too limited. We cannot just focus on them and forget all the others. I think if we go see by numbers, for example, well, yes, we have lots of people using servers. Now we will start having each time more and more people using Debian for appliances and then there are the desktop users. It's not that we can take care of one aspect, leaving the others behind. If you see how the, well, I've been around only, I've been using only since Potato, but if you take each of the releases, at least I have known the quality for the end user has really gone up. And even though, yes, what you said is completely true, there are very large gaps in the user experience. Well, I wouldn't want to devote too much attention to only one of the aspects. One of the things that make this distribution so rich is that there are people who care only about other things. I mean, we are not Fedora, fortunately. Right, I thought I had mentioned this. It's not the idea to focus only on desktop, yeah? We are still the universal OS, we also want CIS admins and programmers and geeks to be glad with our distribution. My point is that we are leaving desktop users like at the end of the queue and we are not really caring about their needs. So that's why I emphasize so much. It's not like I pretend that everyone should work on desktop and leave everything else out. No, we are doing very well on the stable distribution, the servers, that works quite, quite well. So I encourage everyone to keep working on that as we have been doing and also to make the desktop better. Yes, I'd agree with that. And I think surely there's a reason why our market share in servers is better than our market share in desktop use. What occurs to me about that question is that we could probably do better at improving the communication channels between average and geeky users and the maintainers of packages. One thing that occurs to me is that it would be interesting to find out what about a bug report causes the maintainer of a package to not act quickly on that bug compared to other bugs and whether there's an issue of communication there that if someone hasn't communicated effectively what the problem was or if there's some other thing, because it's an issue that the maintainer simply thinks is unimportant, maybe translation or anything else, it would be interesting to find out what makes a bug unworthy in the eyes of maintainers because then maybe we can do something to change that. And the other thing is that I think that if my parents were using Debian, which they don't because I think it would be a bit challenging and I'd have to spend far too much time sorting that out, they would have a lot of trouble submitting a bug report if they had a problem. I think we could do very well to make it much easier for average, ungeeky users to communicate with Debian. And one of the things that seems obvious to me is a web interface for submitting bugs. But I think there are other things we could do. I think we're setting a technical bar, which is high enough that the people who are not very experienced users can't even get as far as telling us what they would like us to do because they don't have that level of expertise. Yeah, we have bug-buddy, well, we don't. It's done by the GNOME people. Actually, when, currently, when a GNOME program crashes, it pops up bug-buddy and bug-buddy sends the bug report to GNOME. I think that's a mistake. I think we should send the bug report to Debian, right? And not directly to GNOME because many times, the problem is related to something in Debian, like some other library version or whatever, and sending it to GNOME directly sort of triggers a problem. Yep. Yeah, a few comments and observation from my experience. I do have a parent, a couple of parents running Debian. I installed their machines two Christmas ago, and I remotely administrated over the net. And we've experienced the woody to-search upgrade. It was not pretty. All the desktop icons on the KDE panel stopped working. I think two of them kept running and the rest was broken because the KDE team moved the desktop files. The application changed behavior and quite a few things was very confusing to my poor parents. So we are not doing a very good job in the desktop area. From my other effort in the School Linux project, we know that the menus in Debian are horribly confusing. And even if the structure is bad, the menu entries as well is not really explaining what the program is doing. So we need to improve there as well. As for why do some bugs stay unfixed? I can only speak for myself. I have way too many packages with way too many bugs, and I do way too many things to improve the state of free software, and it's just a lack of time. If you're lucky and you submit a bug when I'm actually checking for bugs, I will pick it up immediately and fix it. If not, it will go into BTS and I will forget about it and maybe remember it in two or six months time. So that's just my problem. I lack the time to do a proper job with all the bugs. I do try to keep track of all the release critical bugs to make sure my packages are without release critical bugs, but there are just too many bugs and too few of me. So we do need to improve. And I just a comment, I really believe that Debian is for everyone. I'm painfully aware that some people do not want Debian to be for everyone. They don't believe it's supposed to be for everyone, and they will not do so much work to make it available for everyone. This is a community discussion. We'll have to just go through and find out what we'll do about. Just be sure that there are at least some of us that believe it should be for everyone, and we are trying very hard to make sure it is for everyone. So even if there are some vocal, well, I don't know if there is the minority or the majority, but there are some vocal people on the list claiming that Debian is not supposed to be releasing distributions for the common people, and I believe they are wrong. So. Okay, we don't have more time. So this talk, the idea of this talk was to rethink some things about Debian. I think it has triggered quite a rethought about the distribution, so that was quite successful. If you have any more concerns, I'm not a Debian guru or anything like that. We should just keep talking about this but outside the auditorium.