 We can maybe just have a summary of what happened over the last year and then what we want to focus for the next period and if we have some questions, so yeah, we can have a look. So we've been through the migration of the wiki to Moa Moa 1.7. We could clean up in many spaces, we have implemented many features from Moa. We had some discussion about the anti-spam. We now have a Git repository. We should very soon have a Git repository. What's supposed to be soon, but so soon. So all the files are available. This one? This one has a problem? Okay. You heard? I don't know. Yes? Okay. You're right. Okay. So it's about the Git repository. After dinner I'll be working with Stephen Graham to get the Git repository working on the server and possibly get it mirrored to Alioth automatically and setting up the bug stats thing as well, probably. Okay. That's good news. So we can more easily implement features of Moa Moa so we can... Because it was... It's not easy for... I mean, many people, many contributors to the wiki are not Debian developers and it's useful to have access to the configuration files so people can... Is it fine for you? Yeah. Okay. And people have access to the configuration file and maybe set up some stuff and make some tests. For instance, one is someone who is doing some translation to Spanish and he's probably going to investigate some problem with search engine so that's going to be useful. So we'll come to that later but if some people want to implement Starsheet for the new them, that's useful to have. So lots of work on the settings of the wiki which we have implemented many small features of the wiki. What we have... What the main task we have which is pending is basically the license issue. We also have basically a few feedbacks for the request for command to the ascent. Okay. Should I summarize or what was the status? Out of all the pages of Debian wiki, how many have a non-clear status regarding the license? I don't have figures regarding the number of pages which have a license. I know that Debian references which is something like 15 pages have license, Debian do have license, that's 100 pages and for the remaining basically we don't have licenses which makes that most of the wiki don't have license. Come on. I'm not a regular wiki user but on editing, is there any warning displayed to the user regarding the license? We haven't... It's an option which we can set up so people when they commit a change, they have whichever text we want when saying typically which would say read this license page. We haven't set it up yet because we have not chosen officially the license. So for those on my RC, you can check the wiki page for which... The web page for which I send the link. It's a tool to measure... You probably know it. To identify the page which have license issue, it's sorted by the popularity of the page. Currently there's a progress bar on the right of the side of the page. It's only my own contribution and some technical modification. The URL is www.klabs.be slash wiki dash stats. I'm just reposting it in case someone... So the idea was to, based on this list, identify which was the main contributor of the website of the wiki and identify which page are really useful, which page we might want to duplicate at some stage and we want to make sure we fix this license. Maybe for the page which have very low page rank, if the license remain, issue remain, maybe we can just drop it at some point. And in any stage with this tool we will know who committed what. So if some people come to us and say we don't want to license our stuff, we'll be able to actually remove the contribution from the wiki if we want. How do you evaluate the free-ness column? The free-ness is basically... I take all the contribution of the page for each contribution. I count basically the number of words which are added by this contribution. And if the contribution was made by someone who has re-licensed his work, it's considered free. So maybe for Flash Player page, it happened to have contributed 14% of the page. Oh, yes, you missed me. So the idea was to get people to just sign up on the wiki page and say, free license by work and also to put a banner on the wiki and say, from now on every new contribution is made under license, which is to be chosen. Regarding license, I've sent on the IRC, I've pointed a link to an email I sent a while ago. Has there been much feedback on the WWW list about the license change? No, it was meant to be the first part and to get feedback from internal. We had some discussion together, Paul and I. We can go to the thread model. Andre Popescu, I hope we say it this way. Pointed that there was a mistake in my email regarding a license. A feature of the license I've chosen, which was improperly worded. Samu was about GPL, I'll confirm that exactly. Yeah, so basically he said that his own page was GPL, so it's not an issue. My point of view was really that it would be interesting to have a license which is also used by Samu as a wiki to be able to easily match. Which contents from? Get share content to collaborate. Actually, I've never replied to you because at the moment I was not very available, but I've completely reached your proposal. So I looked at my old IRC logs. So I think, for example, there have been huge efforts on release notes to get approval of contributors for getting the provided contents under GPL. Who I am, one of the web team, I don't have a clear understanding on the license status on the website either. But I think that we shouldn't spend so much effort in deciding which is the best suited license. Because if you move to a specific license, as soon as it is DFHG, you will be able to move contents from the website to the wiki or some other documentation. But that's why maybe some specific licenses you mentioned. I don't remember. I remember that some of them, you thought that providing source code was not necessary. I think that, well, most of the people will just agree to provide contents under the GPL. So unless using GPL brings some constraints on the wiki, I think that, well, just got GPL. Maybe I have a naive point of view, but I don't know what your reaction to... I'll talk about GPL, I'll talk about PSD. The GPL informs you to distribute the source code. And clearly when you talk about wiki page, there is a kind of source which is the wiki markup. I think it's an issue to having to distribute the GPL license each time you distribute some documentation. The other thing is to distribute the source code with a page along the content. And the other thing is for GPL, you have a license statement which is quite big. You can just put a page somewhere on the wiki with a GPL. The problem is when you get some information outside from the wiki and you put it somewhere else, you need to keep you to preserve the license and you still have to apply the license. That's one thing, I mean, just a different point of view. If we try to compare with the package, well, the license is present at most of the C5s. If we want to make it easy to reuse the content of the license, because the wiki is often used to get people to contribute to any kind of file, for instance, for the release notes on the wiki page, we have a page named New in Lendi where anyone can just come and put some information which are later reused in the release notes. And there are some other examples. And that's probably a good time to speak about PSD, which precisely would allow to reuse the content in any page without problem. You want to say something about it? I was quite interested in using CC Creative Commons, a Sherlock license, because Wikipedia has switched to this license and Ubuntu is using this license too. If we use a license which is more liberal than those wiki, it means they will be able to use our content, but we won't be able to get some of their content in our pages. Or, I mean, if we do it, we will have to keep those licensed, so it means over time we will have to keep track of, oh, this page is GPS, this page is Creative Commons share, this one is PSD and we can share this one. We can move content from here to here, but not from here to there, and so it can become a nightmare. Maybe we can send a request. Oh, okay. So the proposal currently is really about Sherlock-like license. Maybe we should... Do you think that we should rewrite this email in a more open way and ask the Dubian developers what they think about it? I think using them in project for some wider feedback might be a good idea. Let's see what they think about which license people would prefer in general. We have... There was some figure in my emails, actually, by the way. If we... On the whole, there has been approximately 3,500 contributors, and 10 of them met based on my tools, which has some biases, but more or less, 10 contributors provided 23% of the words as I count them. This was 70 contributors contributed 50% of the content. About 450 contributors contributed 80% of the content. The remaining contributors basically have a problem. No. And then we have 2,000 contributors. Okay, so then we have 2,000 contributors which contributed 90% of the wiki, and the remaining contributors just basically contributed so few content, something like less than 25 words, which means they don't really... I mean, it's not really a problem. It's some kind of... What we can consider this is fair use of the contribution and... Another naive question. So, since you have... Well, do you plan to contact every wiki contributor using the registered email address, if any, or do you... You will plan to do it in a passive way, waiting for the next... Well, do you fear users to be harassed by such an email or I don't know? I think it's quite sensible to email everyone just to push it quicker. I don't think it's harassment to receive a one-time mail for relicensing the wiki content. I know the website people are going to have to do something similar to contact everyone for their website license. Yeah, I think... If we can get many contributors to just relicense their work, we know we have relicense quite an amount of... And also the benefits is that we will have told our users, our contributors that from now on their contribution is going to be entered in your license. So that's probably a nice way to go. So for this to summarize, maybe we get something more open, a proposal which is more open and request for comment on the BN project mailing list. And then we carry on by asking users to relicense their page as a contribution. If needed, we will just remove the contribution as requested by users. So there's a few more pages to be written about precisely how we... What's the new license and how people understand, but that's not the big issue. I don't know which topic you want to discuss during this buff. I have a few amount. One thing I've started and I think would be interesting is generally to turn the Wiki into a front page where it's really... Which is really focused on getting people to contribute. Anyway, I mean, people don't... Maybe we can try to get some statistic, but I don't believe people come to the Wiki and then use the built-in engine to say, tell me about how do I use this or what. I don't think people come to the front page and click on links and actually click on the links to navigate until, oh, yeah, I have my Wiki page about how my wife at Cardi supported. I believe most people come through Google. So the front page is really more about people who come to our website and say, what's on this website? What kind of useful information can I find? And that's probably a good place to get people to contribute and have a minor place where some places were just keeping up to date and say, oh, this is happening in Derby and this is happening on the Wiki. I know what's your opinion on the front page and what you would lack in it. To be honest, I don't really visit the Wiki front page at all. I usually use the search to find stuff if I'm looking for something on the Wiki. Yeah, me too. I mean, having links and organized front page where you can try to orient people to get to... But since we don't really have documentation, I think this page, as it is, which, I mean, by visiting this page, most users probably believe that they're going to find a lot of documentation on the Wiki, whereas the documentation are more inside the package and that's where we want people to contribute. And what we find in the Wiki is more something like how-to's and which, again, people find through Google. Maybe more. I know what you think about it. Especially, I mean, if you're very involved in the website, who would you think to differentiate the two pages? So you mean two pages between the Wiki one and the website one? Yeah. Well, honestly, I don't really know. And I think the question on which content is to be on the website, which content has to be on the Wiki is not an easy question. And what would be interesting is to have some statistics about maybe some pages, some Wiki pages that are not more or less stable in the time with an high popularity. Maybe some such pages may have their place on the website. I don't know. The Wiki pages may be as well seen as a way to, well, as a first place in order to stabilize the content of documentation before making it official. I don't have a clear idea about all this question, but you can guess that it's not clear for me. Maybe it's something we can also post later on the BN project and say, I think maybe we can, if we get a new, if the BN gets a new design for the website, we can try to coordinate and have a new, not just a new design, but actually... Well, even without a new design, I hope that will be the case. Well, we have to have a clear idea of which are the contents, you already mentioned it, which contents are specific to Debian, because we know that many of them are not specific to Debian. That's why some Debian people get documentation from Ubuntu Wiki and the reverse as well. Which content do you really want and has its place on Debian Wiki or website? I think that we should avoid as much as possible rewriting documentation that already maybe appears on upstream project pages. I think that's not the role of Debian to rewrite documentation when there is a specific documentation written by maybe GNOME people or Linux wireless people and so on. Maybe identify such pages, keep only the Debian specific part of it. And I see that for some static pages that are... Well, a copy of static pages on the Wiki. Maybe even, I don't know if it is implemented in the Wiki, I guess so, but even send an HTTP redirect or some reload HTTP or JavaScript, something to tell the user such official information. The reference source for such documentation is the website. It's a bit round off my days. It's more or less. What we try to do actually in Debian Wiki is to have some kind of placeholder so people just don't come again and again with a page about Debian Laney or what is Debian stable and get people just... The reference is... There are still some content which should be migrated, I think, to the website. It just needs someone to do it. I think there's one part of the Wiki which is very interesting. It's the Debian team's part which really is not accessible when people get to the front page. That's probably the part of the Wiki which should be the most accessible and really placed in a way so people really find it easily. And maybe as a risk of duplicating some existing content, having some page to explain to contributors that they can contribute to Debian easily. They can contribute to Debian easily. And maybe also tell them that they shouldn't expect people to come and explain they just have to come and actually do the job. Either want to contribute to the website or a package and come and do it. And then again using the team's page to explain to them how to do it. Here is a pointer to the resource to contribute to Debian Perl Group. And we're thinking again about having a clear status of which content is to be published by Debian means. So either a website or Wiki or maybe one day one unique site. So I see that from the front page, so pages are somehow sorted by if it targets developers, your users, administrators and so on. Do you have a tree view of the Wiki somewhere? No. What you see here is really the top of the tree. It's not so structured anyway. Trying to structure the tree of the Wiki looks like chasing a running target. That's maybe raised another question. Do you think that is a tree structure still up to date now that all people talk with tags and so on? I don't know. I wonder because I know that for example in the website some pages are maybe sometimes duplicated because you get installers from Debian installer, sometimes you get it from slash distrib. Do you already maybe moved some pages because the tree was not that clear in the Wiki and you notice that did you ever move pages in order to have a clearer name space and tree in the Wiki? Usually the Wiki is... People tend to create just one name for the Wiki and have a rather flat structure in the Wiki. When there are sub-directories, it's really because it's inside. People really want to group together some stuff like Debian installer or Debian live have their own tree. The problem is then because it's flat people tend to create a page with a name which strikes a man. About the tags, one of the features of Moin is categories. For each page you can add X amount of categories and then each category has a web page that lists all the pages that are in that category. That's one thing we hope that the website doesn't seem to have. Also, there was some talk about... I don't know if... For the front page, I don't know who should be involved in this to have a new organization on the front page. Descending what we put on the front page is probably going to be a tricky game. I had it roughed somewhere with a few contributions. We probably want to just keep it on the WNW-WWM list and see if people have ideas. And also what's the message that we want to have on the website from page and which message. Which important topic we want to have on the wiki homepage. Some previous people who submitted a website... Well, front page mockups already spotted quite very well. So it's get it, so download. You don't have to download, contribute documentation about Debian maybe. I think maybe... Yes, maybe for both the website, the front page and wiki front page maybe there are already too many information maybe. I think the website has had an even longer than life. Sorry? I think the life of the website... Even works here. The website is ten years old, the wiki is... What I say, the website is probably fifteen years old. There's quite some stuff on it. What are those... You have some topics you want to discuss. Do you have something like ten minutes left? One thing I'd like to discuss is maybe increasing the size of the wiki admin team. Because currently it's me and Helen, Helix who is not really doing anything. So do you think any of the WWW people would be interested? So I can talk for me. Well, basically we are... Well, I think we will be free in the... At least in the WWW group. So there is Ronda, Matt and me. I mean for the people that are most present. Well, I don't know if I will have all the free time to do all the stuff I have to do. But I can join you and I think it's better to... Well, for both of the team to have a better idea of what... How does the concurrent system works. So it can only improve both of wiki and website to merge a bit the teams. So yes, I have a volunteer for that. I think maybe I should document some of the setup on the server so that the WWW people would be able to help out more easily and maybe a list of different tasks that we do all the time like blocking spammers and blocking their IP addresses and deleting all the stuff that they leave behind. We can also probably try to get some people, the most active contributors to have a contribution, the largest and the topic of interest you currently have. We have some people who are very interested in translating. Some people are very interested in some specific hardware support. Did you speak to Simon? No, I haven't. I wanted to do it with you. Is he here at DevCon? No, unfortunately he couldn't come. For example, I was just on the website to do list and that let me think that part of the website may be either completely automated or maybe you should use the wiki as input. For example, there are pages about Debian consultants. So for the moment that's mailed to a specific address which is consultant.debian.org. People give some information about their activity, the name and so on. And that's for the moment it's still a manual copy past into the WMA.datafile which is compiled on the website and so on. So either for such, for example, for such a use, I guess that maybe I think that a wiki page may be better or maybe using a wiki template to force people to match the data structures and use this wiki template to automatically feed the website or something like that. But I must admit that I am quite a newbie in the wiki so how to do template and so on. I don't know but you will tell me how. Yeah, it's reading. And the same ways or I think that such a page could be moved or even removed from the website. That's Debian users page. Yeah, adding people manually maybe. It's the same. I think a list of consultants is useful for Debian users and that's one of the reasons why it's on the website is because people need support and when they're willing to pay for it they go to the website to find out which people they can go to for that. So my point is, as for other content, use the wiki only as an input point and move it to the website once we are sure that it's correctly structured. And you got all the information. That makes sense. What about internationalization? So it has been discussed evenly during the last ITN sessions. I guess you can tell more about that than me. So we're still having some discussion. Rasmus Gard, which is a Debian developer, has a wiki based on Iki wiki in which he is managing the translation of the pages through PO files, PO system. As you know it's probably interesting to have formal translation to ensure consistency of the translated page. We have different needs and wikipedia which really wants to have each language to evolve its way. So it will also fix all the problems we have of content negotiation, of broken links, Iki wiki seems... I mean, I've investigated a bit one year ago and it really seems that all wiki seems to work like Wikipedia. So, well, I think we just have to wait until the next version of Iki wiki which is supposed to implement those tools. And if some translators are really interested in using Iki wiki we can have a look further if we can still have all the features we want. So you're saying we might think about moving to Iki wiki for the wiki? I'm just saying that we should investigate if it actually handles internationalisation properly and then maybe, yes, it could be sensible. Well, actually, the reason why we are a bit conservative on dbn www is that most of wikis don't have any internationalisation support as the dbn website has. So, and the other question is about putting arbitrary... using arbitrary output of scripts to put data on a wiki or in a Iki wiki session. I don't have any idea how that works or that may work so the point of keeping our WML setup it's because we have tons of perl scripts that generates, well, a resume of pages, for example, that generates some figures, some tables, well, many things so I think that some wiki feature can handle, can replace some perl scripts. I know that, for example, well, from Eros, for example, we dynamically fetch figures of archive size from FTP master and, well, I just wonder how that can be handled in the wiki. Do you have some dynamic, well, kind of dynamic data fetched by the wiki or...? Currently, no. But there's some way to do it, for instance. I can't remember his name, but there's a wiki page which is named something like Debian Topic or Debian Develop Topic, Debian Topic, I think, which is updated by an external page. So, it's possible to push the data in and the nice thing to do it this way is that we can track history of this page and also we don't have to tweak the wiki to push the data inside. But if the data change every six hours, like the archive, you cannot just keep the history of... You don't want and it's probably not worth. Otherwise, most wiki have some macros which could implement dynamic data. With wiki, you can implement plug-ins in Perl so you can just have a string saying look up X and the plug-in will go and do whatever you want to do. That would be quite... I think it would be quite nice to have... If we consider the fact that at some point we might want to share wiki page with other distribution, it would be nice if the wiki is there was some kind of way to say, okay, in our wiki we are defining some variables. Actually, those kind of variables exist in Woma. But we declare some variables which we then use in the wiki page. That could be used to replace Debian with MMPs, Maemo, whatever, Ubuntu. That could be used to replace the name of the distribution. It could be used to provide some figures like the one we were talking about. That's probably a long-term goal. I think we're over. I'm not sure there's someone just after us so we probably have a few minutes left if we want. About statistics of the wiki, so you have the page wrong, but does it give you something about... Okay, it's... And that's the number of it's during the wiki life or... Okay? The page you are looking is a page about statistics. It's... The wiki don't hold data for the whole life. The way the statistics are generated, not on this page, on the main wiki pages is by analyzing the log of the wiki. So inside the wiki, if you ask for the statistic of a page or a statistic on anything, it's going to analyze the current log. So the 1-1-1, on the apache logs? The 1-1-1 logs. So basically we have one month. We probably want to rotate the logs every month, so that's something we should do. I'll have my script, which... At the moment we're not rotating the logs, so we probably should fix that some point. So you have lots of history, but it takes ages to have your statistic. We can... Did you say you have a script to rotate the log? Yeah, I haven't tested much in real life, but I tested it with... by simulating a growing file and then... Because we can't just rotate the log, because if you just rotate the log, you only have history maybe like one week after. You lose your statistic if you just rotate the log. So what you want to do is something ugly, which you move the whole week, there's log files, and then just get half of it and put it temporarily and something. You just wait one week to get your statistic. That could be an option, but it's sometimes useful to have some statistic of a page. So I've written a script to do an ugly log rotation, and it seems reliable. Log rotate is great as well. Yeah, but... So we have statistic... Maybe we could set up a statistic from a regular stat... Maybe we could have some regular statistics engine by some regular web stats, by analyzing the Apache log. Currently, I don't think I have access to the Apache log, but maybe I can talk to DSA and get that changed. Or we can ask them to implement... to install AWU stats or... I don't know what they use usually. I think AWU stats doesn't have a very good history of security, so probably not good to use that. Yeah, it could be in our standard public, but if we don't want... maybe we just don't have it public. I'll ask Steven Graham about it tonight. See what he says. Maybe they have some sort of standard thing. Do they have something for the website? No, and we should as well... So we should... Well, we don't have proper statistics about the website, and now that even the website is... the website load is spread over GeoDNS and so on, it's even harder to get statistics. But I think that, for example, the same way that you identified in the wiki, the very low page rank pages, we should do the same on the website so that we can get rid of maybe hidden pages, or just pages that are maybe 10 years old and that have never been modified. For example, I remember that there is some slash distrips, slash floppy. There is still an URL... Valid for me. ...direct in order to get... to allow people to download the CD version, but I think that keeping links operationally is a good thing, but that you don't make... keeping the system alive harder or so. Yeah, and there's probably some obsolete content somewhere, which maybe the page says, you can install Dubian using floppies. Oh, can you? Okay, so we have some statistics in the wiki about mainly some... about one single page who often it has been visited over the last days, and another page about the overall wiki, which are the most... where all the page visited are honked by number of visit. But it's very basic. It doesn't count the page which weren't visited. It doesn't give a clue about the keyword that was used to reach the wiki. We don't have statistics about... So we have to go to Apache analysis and... Yeah, and we have all the history of Apache. And that's true as well to get the same tool for both websites and wiki. That's easier to maintain. Easier to compare as well. To know if maybe one of... for the same content replicated on wiki and website, which is more famous. That's the problem. The statistics of the wiki are actually not... not tremendous because it's really one page. The number of pages is not so high and among all the pages, we just usually keep the history if we don't discard pages usually. So there are a few active pages out of the few thousand we have. And since DDs really make sure everything works, we should not need wiki pages. What do you... You spoke about an active page that you don't remove as far as I understood. What do you do when... if there are some active pages containing just crop information that maybe, well, just gives bad advices to users? We tend to kill bad advices. Bad advices or everything which is not... I mean, the way you would do it, the Debian way. Any page which tries to document how to install manually something is usually considered. Yeah, it's not really the right way to do it for Debian and if you want to install it manually, AppStream probably has some documentation on how to do it. I don't know your feeling. But how... Practically, what do you do? You put a banner on top of the page which says this is not the Debian way to refer to page B or I don't know if you... I think we either just replace the content or delete the page or put a notice up would work too. But one of those things... It's really dependent. I mean, sometimes it's the only way you can do it. Currently, there's one software... I can't remember which one. VMware or something like that. I mean, no, that's VMware. One package, one product which is not packaged for Debian but still it can be useful and it's proprietary software but it's so... Okay, so do we... Don't document it at all and just let our user alone or do we try to do something? It's difficult sometimes to... But if it's packaged, I mean it doesn't have to be... We don't have to explain how to install it manually. It doesn't make sense. But usually that's our policy. 11 plus 10. 10 plus 8. Okay, so we try to focus on the... Finishing the licensing. For the license, we ask Debian project for feedback. You're setting up the Git repository. By the way, for the Git Depot well, since Git is distributed that it's still easy to get a contribution for the people but why not all your project? Just a question like that. At the moment there's a mirror of the Git repository on Collab Mate. So if you're a DD or a member of the project you can just push to there and from the server we can pull and look at the changes and apply them if they're useful. We can get that on the front page. Okay, that's the summary on the main list and we'll fill up. If we can solve the license in the next few months that would be great. The highest quality we can achieve on this is better but just still do it and have it fixed. Thanks. I don't know if you had any questions. No. I know some people want to do. Just watch. Don't hesitate to be part of the web team as well. Yes. You're right. It's true that I have sent a few patches but yeah just enough to say I have sent some patches. For example fast but for example there are some well specific Wiki layout CSS layout for maybe a specific paragraph to tell that's running and well since I don't know if it is the ones provided by the photo if they have been customized. It's a new feature in the latest release of MAMA Because I think if we want to have a more common graphical view of the graphical chat Is it graphical chat? How you say in English if you want to have a consistent graphical identity identity that's maybe a good idea to copy past the CSS for more and more or use some CSS for more and more to the website in order to have maybe something more consistent. I think that's something when we will have to have the new CSS for a new term I really hope that we can choose a new term for the website just something nice and useful and then yes just maybe try to use the same features like the warnings and stuff like that I think it's really a nice feature that was added if you're okay I would be more feel like having these conversions of the appearance and to get it pending until we have the CSS for the websites I'll probably work on this actually on the CSS I don't know who else is going to do it otherwise Thanks