 Our last bof of today's Debian.org related track, we are going to have the wiki bof here in the small round room and Paul, why is this going to hold that bof with us together to discuss the wiki related issues Okay, so just first of all a quick what happened in the past year We've a where's sledge gone Yeah, so we added a couple of new people to the wiki admin team sledge and Ashish who isn't here and didn't really do much We upgraded the wiki to squeeze which was great and lots of fun We also have the new theme on the wiki which Is the same as the Debian website theme Yeah So we need more people working in the team For a start we need someone to be maintaining more and more in the software that we use on the Debian wiki It's currently maintained by Jonas Medgar, but it needs a new maintainer because he's got lots of packages And he doesn't maintain it that well. There's one security bug in squeeze at the moment It's a cross site scripting thing that probably needs fixing so It's reported Someone needs to maintain the package Any volunteers silence, okay So is anyone else interested in getting involved with the admin side of things? that basically involves spammers oh Okay, so we need more people watching recent changes for spammers and deleting the spam It's reasonably well done at the moment by people who already do that, but it would be good to have more people to help So one thing I would like some input on is how to How to get People who are deleting spam to report those spammers to the wiki admin team who would then ban the spammers Currently we just watch the recent changes and manually do it So if anyone has any ideas about that, that'd be great Any one I Actually had the issue of people spamming my my own wiki. I don't use the same software I use PM wiki, but one thing that solved it was a capture and then I had no no boats boats Editing the wiki Just an idea So for the dev in wiki we want to have as low a barrier To entry as possible So maybe a capture isn't possible for the dev in wiki We discussed this before and decided it was best not to have one So one of the things that we need to do within wiki admin is have some way of coordinating between the people who are banning spammers and so that They don't waste time banning spammers already banned so If anyone has any thoughts, maybe someone wants to hack the wiki theme to Indicate if a username is already banned. Is anyone here know Python and would be interested in Editing the theme. I guess that's a no So we do have a few users who are active I mean no Paul and I are as he says what basically watching recent changes hands up anyone else here who's helping out with that No, I guess not So what we have at the moment is There's a there's us too. There's about four or five. I think other users who will go through and delete the spam pages But then we still end up having to go through later. We have a script which will Ban the spam spam username will give various bits and pieces of information so we can possibly so we can track the IP address so we can send Spam reports to be honest There's very little point on the spam reports because most of the time they clearly come they're coming from scattered DSL or cable accounts all over the world, you know, it's the usual botnet type of activity It's a difficult problem, of course to Keep a low barrier for entry for people putting wheel information in while keep keeping the spammers out Yeah One thing that I suggested to Paul I mean feel free to comment is it we might want to actually stop people creating new accounts without being approved by a wiki admin I'm worried again that we'll just stop wheel users contributing any thoughts two things. First of all, I think I would Go first with this captcha before requiring approval of users I think captcha is a much lower barrier And I can't remember the second thing right now I use icky wicky for my blog and I know one of the things that has for comments is running through a spam check filter and Having so the administrator needs to approve anything that appears to that it might be spam Before it actually appears on the So if we already require users to register an account before they can click edit, right? So we need to show them one single captcha At the step of registering a new account That already exists and this captcha could be from recapture.net which can be audible also. So it's not really something that Hurts people with low eyesight or no eyesight So apparently it's an Reasonably accessible solution that only needs to be applied once on the account creation not upon every edit So it seems useful to me. It's it's still the same barrier to entry. It's the same procedure just a little bit longer Under saying that Blasen suggested We are already having some I think five seconds delay when I were at least when I currently save the page it takes for me some five to ten seconds till I get the page redisplayed adding Whatever a kind of spam checker in there will just more slow slow down that process I'm not sure if that will help on the other hand They're adding something like claim AV for getting Justice the gestion adding some sort of Whatever filter to do with the with the common things that usually Pop up on the wiki page might help do not know another idea as well is that I also have it on on PM wiki is that Spammers would most of the time try to push links to their own websites So one thing that does work is to approve new URLs by domains like We approve Obviously dbn.org and dbn.net and if we have something external Then we would have some somebody to approve that specific domain name Which ends up in yahoo Oh, yeah, who pages and then would be all white listed as well No explicitly not for that kind of thing of you know We're expecting links to other technical sites whether it's debbie and whether it's other Linux distros or whatever those will be easy I've forgotten about what else I was gonna say now I mean no what the problem we're seeing with spam In fact, we have had a load of things of like the essay writing links and all that kind of bollocks in the past We're now seeing lots and lots of Spam pages being added which are clearly being put in to kill Bayesian statistics, you know, we're seeing links for How to get your swimming pool cleaned in Australia or you know stupid things like that About the only feature that I can see the only common pattern I can see is that typically in those pages there will be four or five identical links to the same other page We could pick that as a pattern and of course, we'll get fine the next one and the next one I think that actually setting up the capture for new accounts is a good thing I mean would it would anybody agree? Would they really disagree? fine, we'll do that and We can move on to adding extra checks on page save later on But obviously I said we already are seeing very slow page saves. I have no idea why it's not like the wiki Takes a huge amount of load, but I've seen But In any suggestions gratefully received I treat I tried to debunk that once and it was obviously not missing battery of a of a rate controller and it's not anything Related to the hard disks. It's Seems to be something in within the software which is slowing down wiki-debian.org while writing Things to the to the hot disk Yeah, so it's been a while since I edited the Debbie and wiki and I'm not too familiar with the solutions within Moin Moin world, but I can talk about some solutions that have been used with media wiki and Wikipedia in particular If you'd like Please do so There's Edit filter system where you can Set up rules with regular expressions to do certain actions and certain types of edits There's also URL blacklist For specific URLs that show up And that that list is public for wikipedia So you could potentially if there was such an option for Moin Moin you could dynamically pull the blacklist that's used on wikipedia every so often and Block those same URLs on the Debbie and wiki There's There's page protection at various levels So you can Have a page semi-protected or fully protected if it's semi-protected then it can be edited by users that have been auto-confirmed And it fits fully protected then it can only be edited by Admin Auto-confirmed means it's configurable But usually it means something like you've made at least four edits and you've been around 20 or so days or something. I think we have some sort of ACLs within the wiki Just Quite a few as only a few pages using those ACLs at the moment like the entry page for example Yeah, and there's one or two Pages that have had people disputing the content and Someone reverts it and reverts it and reverts it So we've had to use that in some cases, but that's not something It might not be something that would work for spammers I'm not sure Also the the wikipedia cluster has integration with at least one RBL I don't know if you have that currently. I don't think we do There is so what one thing that You can do with editing links or adding new links or Any kind of edit filter match you can have a captcha just for that and not necessarily for every edit Or you can have a captcha just for people that are not auto-confirmed Sounds like you want to sign up for wiki admin or coding on Moin Moin Okay, so maybe we should move on from spam because we could spend the whole day on it So Some Has anyone got some features they would like to see added to the wiki two things that I'm looking at Adding one is bug status port for launchpad so you can so that you can hover the bugs And get a title whether it's closed or not We have this for the debbin bug If you if you go debbin bug colon And then the bug number So that's one thing that I wanted to add soon Does anyone got any other feature ideas? I guess not So the next topic that I wanted to talk about was merging wiki.debin.org into wiki wiki.debconf.org into wiki.debin.org I Would like to probe I would like to work on that but I'm unable to attend the related Bof at the end of this week. So if someone could go there and suggest it, that'd be great Merging debconf wiki which uses media wiki into Into this one No, I mean if media wiki is deployed at Wikipedia, it's surely it's more scalable than what we have perhaps Yeah, I Been doing some spanning claim cleanup for the debconf wiki and I like a lot like a better Lex, I like very wiki. So last I heard Something like 85% of all wikipedia hits including logged in users are cash hits and That Includes all logged in users getting cash misses all the time. So Most content being served to anonymous users is straight from squid not hitting PHP at all Okay, we don't have any front-facing Proxy at the moment for the debin wiki. It's just straight into mine As far as I know, I think I don't think we have a performance issue while reading Yeah, we do have a performance issue while saving wiki pages, but not while reading. I tried that once And we ended up with something like you can do 250 300 similar 10 years Requests on the wiki and the wiki doesn't get any sort of slower and the machine loads still stays at the same level so the reason to Do such a merge would be that there's only one wiki. You don't need to maintain multiple wikis Yeah I'm not sure whether it's a good idea or not, but that's one idea that I had Is there any more on that topic well if you end in the in if in the end we end up with maintaining less hardware and Less services, I think it's a it's a good idea on the other hand Perhaps someone from the debcon for our team could also comment on If that is a thing which is wanted or if that should just be on separate infrastructure Well, I can comment on my personal opinion for that we'll have this this topic more or Optimizing or improving the debcon for org Infrastructure with the debbie in a bit We have a separate buff for this about the whole topic The relationship between debbie in and debcon which we had last year in New York, which is the continuation of the topic That is on the last day of debcon I don't know the time at the moment, but there will be a topic and I will have better More opinion from the team My personal opinion is that I am annoyed by switching between moin moin and media wiki syntax and I would like to fix that part how we Implement it on different hardware different wikis. I don't know but it seems sensible to have one wiki and different namespaces there anything else Okay, so the last two topics The re-licensing the wiki currently has no license at all except for a few pages that people have said are GPL or whatever So that's currently stalled because the person who was working on it has gone missing in action or it really busy So if someone wants to take up that that'd be great Anna Would you like to volunteer? For the re-licensing the wiki It is more and more yes for what is worse on people was preferring Wiki media wiki. I prefer my mind. I totally was thinking that when Horger said that he preferred having a single wiki With my mind having an instance we can have to separate wikis So what you probably know that It's used when you have made the question I don't know if you are mentioning merging the This con wiki inside the day and wiki or just having both then together Even if they are in separate instance So the idea would be to convert all of the debconf wiki pages into more and more in format and merge them in With the complete history. Yeah, okay. I was thinking more. I was having both in the same server Oh that could also be possible, but My idea was to merge the content in a one-site So with the re-licensing stuff It needs someone to care about it at the moment We don't have any clear copyright for the whole wiki or even for most pages or and When this when the wiki became official it wasn't We didn't have any permission to copy those pages into the dev-in servers or Anything like that. So it's kind of problematic and it's similar to the issues with the website But it means that We can't necessarily copy content from the wiki to Packages or whatever so the plan for that was to choose a license Franklin chose the creative commons CC by SA or CC by For various reasons you can look it up on the wiki reliance relicensing web page wiki page and so the idea is to then contact everybody who's contributed to the wiki because we have all the email addresses from when people signed up and then Contact everyone who's edited the wiki and Get permission and delete the pages that people haven't given permission for Comments to that. Yep. I don't I wouldn't like to have the wiki but I have default license a CC by SA CC by I would be fine I think it was CC by and the other thing is in Debbie and Edo we use the Screamlink and they've been either we use the PDF export the dog book export from Moin Moin to maintain the our documentation which is GPL license, which is find the license of the pages But the dog book export from Moin Moin Is degrading? So as the upgrade to squeeze was done now It's still kept keep working But Moin Moin I think is upstream thinking of removing the functionality because they don't have a maintainer for that Mm-hmm, and that is becoming really a problem for us if that happens I Don't know if media wiki has better dog pot dog book export so That brings us kind of to icky wicky Last year Some people proposed that they've been wiki was switched to icky wiki. No one did anything since then so Anyone wants to think about looking at it That'd be great If you are a non-deb in developer I can give you a page dump of all the pages and the revision history and whatever and you can Work on converting it to icky wiki there are some Features that we rely on like the bug status links. We have to make sure that these things work and the dog book output But if we switch to icky wiki, then you could probably Use icky wiki to generate your documentation and the other advantage of icky wiki is that translators can use their usual Translation workflow instead of Manually creating pages and keeping them in sync, which is what they currently do So is anyone interest hands up if you want deb into switch to icky wiki Hands up if you do not want if you want deb into not switch to icky wiki Hands up if you want to make it don't care Okay So Anna, could you and I've forgotten your name Mentioned why you don't want us to use icky wiki First of all, I like moi moi. I use it in another project. So for me, it's easy to handle. I Think it's a bit more and I think it's a lot of more new be friendly than icky wiki. I think icky wiki Usability very difficult from time to time. There is people using icky wiki that That are using there in in their blocks and when I want to comment is a pain. I don't I haven't used it like little very little icky wiki and No, it's better. No, it's better. Mon moin That's the reason I'd love icky wiki for once for the translation support with PO files And the ability to edit pages we are get so I don't have to use the web interface at all So that's why I would really be very happy if we would switch to icky wiki I think the usability issues in the web GUI can be improved. That's a matter of improving icky wiki There is a deviant package called edit moin That is what I usually use that you don't need to to use the web browser for editing a moin moin edition. I Don't know if what you need but for me works very well. I want to write it directly from my mind but so the other thing about get is that Moin moin 2 they're planning to add different back ends and I think some of those include VCS back ends Which would be interesting? But that's a long way off. I Think plus run for icky wiki because I think it's much more Much more intended for technical persons like Debian There are many processes like gith and and others that said can be Well-integrated and if it's a well set up icing the commenting end and similar issues can be avoided because it's very customizable at least icing so what one other thing about icky wiki and Moin is what Wiki format Do people prefer currently moin has its own syntax with version 2 it's going towards a format called creole Which is supposed to be an inter wiki interchangeable format. I'm not sure how that's going, but so That's one thing to think about as well And icky wiki uses markdown by default, but it has multiple out inputs Yes, I'm using icky wiki and it is very well maintained by joy hess so And it does not use PHP so So that Is a good point for avoiding various security holes that have been found in PHP code To be not saying it's in moin moin, but to be fair pretty much all wikis have had Security problems in the past including icky wiki and moin moin and whatever else Of course the big issue is if we do switch to another wiki engine is just physically finding the manpower to do it Unless we actually have a lot of volunteer effort. I can't I just can't see it happening at all I mean exactly the people who are who has pushed suggesting icky wiki Are you actually prepared to help us do it or would you just like it if somebody else did? Exactly, I personally don't have time to do such a project I imagine it will be quite a lot of work, especially since the format needs to change probably Yeah, absolutely, and I've done a move Before in the past several times from one bit of wiki software to another quite it's a pain Yeah, I'd be happy to do it for the Debbie and either name sub name space on the Debbie and wiki to move to icky wiki So if you want to try that all Debbie and developers have access to the wiki host So you can log in and the pages are in flash serve flash wiki. I wouldn't want If you want to try it but somebody else, but I want to do the work if the move has been done Okay So if anyone wants to try it if you're a dev-in developer you can log into the server and look at the pages and copy them out or whatever If you're not a dev-in developer, I can provide a table dump of the whole thing if you want it's about 700 meg I think total I Would need to dig up. I don't do not know Yeah I think that's the size of the last one that I gave to the people who proposed icky wiki last year and didn't do anything So we have a couple of minutes left any other thing else I I have one more idea with the migration thing that I saw somewhere else With the migration with wikis that they Start the new wiki and There was no real migration with the content as as you mentioned and there were two parallel sites Which we should really avoid? Yeah, I think that's kind of interesting because it ties in with one way to do the relicensing stuff You could Check each page my opponent is is avoid if possible avoid if possible. Yeah, I definitely agree there But it does tie in with the relicensing. You could check each page one at a time and copy them as they Approved what could be done as if the one wiki is giving a four or four you could Dynamically redirect to the other wiki and drive if you find it there, but that's Not the best way to set up sure Okay, I guess we're out of time no I Want one minute Just checking on the IRC channel We do have a couple of questions Or suggestions we can whitelist wiki accounts which have contributed wiki entries and we're fine I guess obviously that's for the anti-spam and then only check accounts which aren't in that whitelist and Also the same guy asking can we add login via open ID? I don't know if you were on this morning's DSA talk We were speaking about having some sort of Sign-on possibility At least for the Debian developers. I do not know if that could also be done for let's say alias So you could use have use your alias account for that Do not know if you want to do open idea for that. I Believe the wiki software supports open ID, but it's a policy question Yeah, we should enable it not sure but definitely single sign-on would be a lovely thing to have yes, definitely Yeah, I'll help. I'll happily work with you on that But if any any last comments from anybody else Okay before everyone leaves There were