[03:25] hi jjesse [03:25] grin that was a late delay :) === michael_mac is now known as michaelramm [06:17] how long should bzr take to fetch the hardy docs? === nothlit_ is now known as nothlit [08:02] posingaspopular: the first time will take a while, unless you speed it up with one of the methods described on the Repository page [08:58] mdke: yes [09:06] hiya :) [09:06] popey: was looking for you to talk through that forum poll of yours rather than play email ping pong [09:06] hi [09:07] it was created after a discussion at UDS [09:07] did you see my last one? [09:07] just looking now [09:07] my goal was not to clarify the difference between w.u.c / h.u.c / h.u.c/c [09:08] it was merely to determine (finger in the air style) if people on the forums had some reason for not putting how-tos on the wiki [09:08] ah, so it's about help [09:08] the discussion we had at UDS was around getting the how-tos in a pristine state (Jonos suggestion) [09:08] why do you say "wiki.ubuntu.com"? [09:08] it sounded to me that it's about the development wiki [09:09] because we were talking about how-tos that were under development [09:09] ah, there may be a misunderstanding here [09:09] well, i didn't want to make the question overly long and complex [09:09] i suspect that may be the case, yes [09:09] wiki.ubuntu.com isn't for howtos that are under development... it's for material relating to the development of Ubuntu. All help goes on h.u.c [09:09] heh [09:09] (regardless of how evolved it is) [09:10] well I have been using ubuntu for years and _I_ didn't know that [09:10] so that's definately highlighted an issue [09:10] ok, so you could amend the poll to point at the help wiki :) [09:10] but seriously, this issue with forum howtos has been discussed to death in the past, you'll find countless threads about it [09:10] i also note that nobody else in the room knew that either [09:11] this isn't my puppy [09:11] i was merely taking part in a discussion at UDS [09:11] ah, I'm picking on you because you are the only one with the ability to clarify the poll :) [09:11] and the poll was just used as a general way of adding to the discussion [09:11] sure [09:12] anyhow, we're well aware of this issue about the distinction, we have specs about it [09:12] ok [09:12] ideas definitely welcome on how to improve things - ImproveWebsiteStructure is the spec [09:13] but as for the forum, we have this https://help.ubuntu.com/community/forum. Anything more has proved simply impossibile - I've spent so many hours discussing this one and there is unlikely to be any convergence. I can find the threads if you're interested but a search should turn them up [09:14] the idea behind the discussion at UDS was basically "some of us would take forum how tos and tag them as 'golden' which would then be made read only" [09:14] however, once jono found out two things this was somewhat deflated:- [09:14] 1) There are very few how-tos on the forums [09:15] 2) The ones that are there are riddled with crack like "sudo rm -fr *" and "sudo su" [09:15] (the first ones I found had those in) [09:15] my assertion was that they should be moved to the wiki so they can be cleaned up, but that met with much opposition [09:16] it's currently the case [09:16] (as per the community/forum link above) [09:17] I suspect there is quite a lot of crack on the help wiki too, don't forget [09:18] well sure, but anyone can edit that when they find it [09:18] btw I'm quite surprised no one at UDS knew about the distinction, I agree that there are confusing aspects, but for those contributing a lot, it's described in the first paragraph of the front page [09:18] you can't edit a forum post, but you can add to the zillions of comments [09:18] popey: very true. That's the advantage of moving it [09:19] i will clarify with the guys what we have discussed, thanks mdke [09:20] I think I'll email jono to discuss, we might be able to drive that spec out of its current hibernation [09:21] i'm happy to hear that there is interest around :) [09:21] popey: who else do you think might be interested? [09:22] will cc you on the mail so you find out :) [09:22] thanks [09:23] the spec is quite controversial since it includes renaming wiki.ubuntu.com, so wide interest will help :) [09:23] :) [09:24] popey: one more page of interest is https://wiki.ubuntu.com/DocumentationTeam/IndependentDocEfforts, slightly related [09:26] sent [09:26] thanks a lot [09:27] good, Mike [09:35] :) [15:29] Question: on the Wiki, is there a way to NOT have a link added to the page when it is added automatically? [15:30] A buddy of mine in our LoCo has an IRC handle of Pr0nStrGeek and when I add that to the wiki, it adds a link...I don't want a link there. [15:41] New bug: #160213 in ubuntu-doc "Broken link:http://doc.gwos.org/index.php/Understanding_fstab" [Undecided,New] https://launchpad.net/bugs/160213 [15:52] michaelramm: you could make it link to the persons page on launchpad? [15:54] michaelramm: however you can just use two backticks around a wikiname to prevent it being a link [15:55] ` being a backtick [16:03] popey: thanks, I don't know if they have set up their LP page yet [20:30] hola all [20:37] hiya LaserJock [20:38] mdke, question - are you more involved with the ubuntu or kubuntu documentation? [20:39] dappermuis: me personally? [20:39] mdke: yes [20:39] I only work on Ubuntu documentation [20:39] mdke: interesting thread on the wiki [20:39] nixternal is the main man for kubuntu, if you're interested in that side of things [20:40] LaserJock: yep [20:40] mdke, yes, i have been in contact with nixternal in the past - i don't have much time on my hands to get things done though :/ [20:40] I know that feeling [20:40] dappermuis: are you following me around? :p [20:41] nixternal: lol, just observing [20:41] wanna discuss some things with you though [20:41] renaming help.u.c is a really bad idea [20:41] mainly related to jucato's blog post [20:41] LaserJock: the spec is about renaming wiki.u.c rather than help [20:41] nixternal: yo, how you doin'? [20:42] yo yo [20:42] mdke: right, although teams.u.c is a bad idea too [20:42] what's up homeskillet <- mdke actually looked that word up and it is a real word, kind of :) [20:42] LaserJock: I like dev myself [20:43] dappermuis: oh man, not Jucato :) [20:43] nixternal, lol - his post was relevant though. it was something i had been thinking about for quite a while, though more specifically the docs aspect of things [20:45] if you have a better idea on the docs, then I am all ears! [20:47] oooh, when did the kubuntu wiki get the makeover? that was one thing which was really getting to me before [20:48] mdke: I was thinking devel. I think perhaps dev. might sound like it's only for devs [20:48] LaserJock: very good point. [20:49] tbh I have no feel for how likely it would be to get this change past the dev team without huge outcry [20:49] if the spec is well written enough, you never know, I suppose [20:49] tbh I don't think the name matters [20:49] what matters is the content [20:50] you can call it thisisforspecanddevelopmentwork.u.c and people won't care [20:50] do you have more ideas about how to make the distinction? [20:50] i do think people notice urls, myself [20:50] theming/branding [20:50] devwiki.ubuntu.com [20:51] yes, they will notice URLs that they can distinguish between [20:51] yes, hence the need to match the url with the aim of the site [20:55] well the old name will have to be left as an alias anyway, how big can be kicked? [20:55] how big a fuss [20:55] sure, it would be redirected [20:56] but people don't like change to the status quo. Anyone LaserJock is right, themeing is important too [20:57] anyway* [20:58] hehe [20:59] mdke: well, what I'm saying is, can people really distinguish between a dev wiki and a help wiki? [21:00] I'm saying that you can have the perfect URLs, but if people don't have the info to judge which one they want to us then it's no help [21:00] And the url helps give that information [21:00] no [21:01] what I'm saying is that people can perfectly have the information [21:01] and still not put it in the right place [21:01] windows.com vs. ubuntu.com provides a lot of context for what might be on those pages. [21:01] bah [21:01] that's not what I'm saying [21:01] I'm saying that what we need to give users is information to judge where to look/contribute [21:02] and you can't get that out of a URL [21:02] I can. dev.ubuntu.com and help.ubuntu.com give me two very different impressions [21:02] LaserJock: it's a question of degree between what you and somerville32 are saying [21:02] and without knowing knowing help.ubuntu.com exists, I might even look there (and thats actually how I found it). [21:02] the basic information can be given by the url; enough to bring a massive improvement [21:03] but obviously it's not enough, we need to do more as well [21:03] hello [21:04] hi jjesse [21:04] hello matt missed you at UDS [21:04] cos I wasn't there [21:04] :p [21:04] i know, i meant you were missed [21:04] just ribbing [21:05] it would be fun to go to one of those [21:05] lots of doc team related discussion [21:05] * mdke nods [21:05] bettween the server guys and the training people [21:06] as a new user of Ubuntu, I would never start looking for help in dev.ubuntu.com [21:06] michaelramm: that's good :) [21:07] I would *assume* that was the more technical side that I did not have a care to look at [21:07] * michaelramm catching up on the email flury today [21:07] * jjesse is having problems w/ his email and once again resumes to kicking things [21:07] Unless dev means help in some foreign language, than I think it'll be a good move. I just question how much it is needed because I've never heard people complain before. [21:07] i like teams.u.c but would assume that was another pointer to LoCos [21:08] LoCo pages would be there too [21:08] whats' the topic? [21:08] somerville32: it's a massive problem. As popey pointed out, even people like himself and jono weren't aware of the distinction [21:08] contribute and community are good, IMHO [21:08] jjesse: wiki:ImproveWebsiteStructure [21:08] erm, what's the package which has the kdevelop docs? [21:08] mdke, You're right. I didn't think like that. [21:08] michaelramm: too long [21:08] oh the spec [21:09] mdke: too long, but right on target [21:09] teams.ubuntu.com sound good to me [21:09] michaelramm: yes, that's what the spec says too :) [21:09] once you get there, you will remember it [21:09] i know [21:09] right now when I need to go to wiki.u.c, i type wik and scroll down the list of my recent visits [21:10] most of my visits are to my loco page, but I can quickly get to another page, or ANY page on wiki.ubuntu.com very quickly [21:11] ubw:WikiPage for w.u.c and ubh:WikiPage for h.u.c/community [21:11] * nixternal hugs konqueror [21:11] but it is uncomfortable to type long urls [21:11] There is a recent visits? [21:11] nixternal: whoosh, that's awesome [21:11] somerville32: in your browser history [21:11] mdke: for you [21:11] maybe not for all [21:12] somerville32: what mske said [21:12] mdke* [21:12] michaelramm: well I count myself as quite a good typer, but it still takes me longer to write "community" than it does to write "dev" [21:12] gg:search_term to google it, lp:app to search for a project on LP, and so on, and I can create as many as I want...dunno if you can do that with FF or similar, but it is sweet to have [21:12] nixternal, you can [21:12] very cool [21:12] ooh [21:12] somerville32: do tell [21:12] mdke: sure, but once you have built your browser history, you will only need to type com, and scroll down [21:12] because I know people who are dying for it [21:13] I know you can make FF understand help:/ urls for our documentation [21:13] michaelramm: I'm not talking about browsers, I'm talking about writing urls in other contexts, like when writing links in emails, blog posts, bug reports etc [21:13] nixternal, It has something to do with bookmarks [21:13] mdke: also remember "Who is the target audience?" [21:14] devwiki for dev stuff, and docwiki for doc stuff? [21:14] michaelramm: for the development wiki, it's people who write a lot of emails and bug reports :D [21:15] dev wiki = current wiki.u.c? [21:15] yes michaelramm [21:15] yes [21:15] I do more reading e-mails than writing myself, lol [21:15] evening mdke [21:15] hiya popey [21:15] I have roughly 4k pending [21:15] heh [21:15] my boss has around 10,000 unread emails at any one time. I like to keep mine in single figures if possible [21:15] ok, then why is all of the LoCo stuff housed there? OR what kind of dev are we talking about? [21:16] technical ubuntu development or ubuntu community development? [21:16] michaelramm: development in the broadest possible sense [21:16] another one would be server.ubuntu.com where the server team would dev there stuff and help for the server team would go there [21:16] there was some discussion at UDS at creating a server.ubuntu.com [21:16] developing how-tos ;) ? [21:16] jjesse: ouch [21:16] * mdke slaps popey [21:17] :) [21:17] mdke: well didn't know what exactly the address would be but something similar to that [21:17] I like teams.wiki.com [21:17] jjesse: if every team goes and starts their own website we're going to have chaos, divergence, and general nightmares [21:17] * somerville32 agrees. [21:17] mdke: wth does your boss do that he has 10,000 unread emails? that would drive me up a wall [21:18] had a similar issue with the education side of things [21:18] And why does the server team need their own wiki? :/ [21:18] I cry when I have 300 [21:18] mdke: i agree and understand [21:18] nixternal, How do you manage that?! [21:18] nixternal: yeah. He has people who read em for him I guess [21:18] I get like a million ubuntu e-mails a day [21:18] with my eyes closed [21:18] somerville32: the discussion per my email to the list is they are looking for more control ove r the server docs [21:18] nixternal: For firefox in the bookmark just put %s where you want the search term to be put. [21:18] there seems to be a the need for a higher standard in server related help [21:18] Inbox Zero by Merlin Mann...bouz...it will do wonders for you [21:18] jjesse: I think the concern is misplaced, but I will respond on the list. And anyway there are loads of ways to address it [21:18] dsas: rock on! is that in our documentation? if not, I suggest we get it in there under "tricks and tips" or whatever [21:19] higher standard!? [21:19] as if there is this random doc that tells you how to setup a server and it crashes and causes problems who do you blame? [21:19] thats a bit cheeky [21:19] popey: well "standard" is not the right term [21:19] blame mdke! I am tired of being blamed :) [21:19] jjesse: you blame the absence of quality assurance in the wiki [21:19] see? everything comes down to these two specs [21:19] every team would like more, higher quality docs [21:20] I think that help.u.c's front page needs a big fat uplift [21:20] EVERYTHING!!! mwaaaa [21:20] mdke: you know who might be a good one to talk to about wiki qa...mako [21:20] nixternal: yes, true [21:20] he might have some ideas from wikipedia [21:20] mdke: i agree but if i'm at an enterprise that installs ubuntu and follows a document i want to know there is a higher quality or some qa going int o the docs [21:20] jjesse: that's just what I said... [21:20] nixternal: Oh, and you have to specify a 'keyword' to use, I doubt it's in the Ubuntu docs. [21:20] jjesse, Only an idiot would follow a wiki document in an enterprise setting :P [21:20] jjesse: and that is something we need to work on..we are a bunch of volunteers, and wiki qa isn't the funnest job, although there are people who love to do it [21:21] * mdke nods at everyone [21:21] somerville32: i agree that only an idiot would follow a guide like that but it might/ or may have already happend [21:21] * jjesse nods at nixternal [21:21] I can guarantee it has happened [21:21] I don't think we've had this much discussion in this chatroom for awhile :P [21:21] heh, that wasn't off-topic at least [21:21] its nice we should have it more often [21:21] jjesse: tbh, I think everything is covered by the HelpWikiQualityAssurance spec, but if it isn't, I'd be interested to hear. [21:21] no doubt, I feel like we are accomplishing something here [21:22] mdke: i would agree that i think it is covered by that spec [21:22] it would be good to get the server team involved with that [21:23] I don't like teams.u.c [21:23] hey all, I don't think the wiki naming question is covered in the spec. [21:23] i dont either [21:23] maybe there is someone there who can get to grips with the moin code [21:23] mdke: well i'm now on the server team :) [21:23] I think it could even be worse than wiki. [21:23] after all the time i spent at UDS w/ them [21:23] also sommer is a part of the server team [21:23] sommer: huh? [21:23] which spec, and which question? [21:24] sorry the HelpWikiQualityAssurance one [21:24] or is that part covered by another spec? [21:24] sommer: right, it's a separate spec. See my email [21:24] ImproveWebsiteStructure [21:24] has anybody looked at how other distro's handle this sort of thing? [21:24] gah, distros [21:25] gotcha thanks [21:25] LaserJock: so far I have noticed them all just using one wiki/domain [21:25] LaserJock: or indeed any project - library.gnome.org / live.gnome.org [21:25] I think other distros suck when it comes to help/wiki facilities [21:25] I had a hard time finding stuff with Suse [21:26] I have a hard time with any of them because I have gotten so used to moin...fedora's is nice though [21:26] mdke: don't even mention gnome ;-) what aweful URLs [21:26] we should definitely check em out [21:26] I don't think GNOME have end-user documentation on l.g.o [21:27] dsas: I believe it's the target if not [21:27] it seems from the email threads that everyone agrees what the issues are, but I guess I'm fuzzy on the next steps are to impliment the specs? [21:27] brb restarting [21:27] I actually think we need to look at the broader picture [21:27] jjesse, You restart a linux box? [21:27] somerville32: currently in windows, restarting to linux :) [21:27] :O [21:28] look at what we want to provide and where, keeping in mind the technical and resource limitations we have [21:28] jjesse, The whip will be waiting for you on your return. [21:28] Well, we have unlimited subdomains so I think we're good there [21:28] ? [21:28] LaserJock: go on [21:29] well [21:29] it seems like forever we've wanted to merge system and wiki documentation [21:29] but it's technically very difficult [21:29] we've had that QualityAssurance spec around forever as well [21:29] well, I'm not so sure... [21:30] I think the merge is a one-time only thing [21:30] how will we deliver system documentation? [21:30] ditch yelp and ship a copy of the wiki? [21:31] rather than sync regularly each release, I think it's more realistic to import our current system documents to the wiki, and then let the wiki magic take its course. We'll then continue to maintain the system docs separately as now with an eye on what changes are being made to the wiki pages [21:31] mdke: I totally second that approach [21:31] Wait. We want to abandon static release docs? [21:32] mdke: that doesn't sound very good to me honestly [21:32] somerville32: that's my idea, subject to whatever subtle access control we can implemet for the most reliable documents on the wiki [21:32] my thinking is that the docbook versions are a subset of the corresponding wiki page, is that what you're getting at? [21:32] so we're gonna have to constantly worry about diff between system docs and wiki docs [21:33] I don't see why we need to have the system docs editable via a wiki? It is a lower denominator too. [21:33] I personally think the doc team doesn't have the resources to manage different systems very well [21:33] Plus, now that we use bzr, it is easy for people to contribute. [21:33] somerville32: heh, I don't think bzr has changed anything [21:34] LaserJock, bzr allows for distributed development. [21:34] we've had a tonne of people join up via documentors hungering for tasks, keeping an eye on the wiki docs and merging them should be a good mentoring task? [21:34] somerville32: and that helps why? [21:34] somerville32: that's not quite my idea. The system docs would continue to be maintained as now. The only question is how to make them available online, if at all [21:34] LaserJock, Different teams can work, with revision control easily, on different aspects. [21:34] somerville32: if anything I think bzr has made the barrier to contribution higher [21:34] LaserJock, How so? [21:35] bzr is slow and confusing for people [21:35] LaserJock: you're very pessimistic today [21:35] sorry :( [21:35] maybe it's one of those days [21:36] bzr is ok. I don't think it's changed our workflow at all. [21:36] no, if you use bzr as svn it's fine [21:36] but I don't think you can make the claim that distributed revision control is suddenly going to make contribution easier [21:36] Access control is simpler and lp integration is very nice [21:36] I agree [21:37] somerville32: that I can agree on [21:37] we're not using a distributed model, so it's not changed contribution at all [21:38] Bzr is inherently distributed. [21:39] mdke: you can't control whether it is or not [21:39] well, I don't look at it like that [21:39] in any case, bzr is beside the point :-) [21:39] our team is using a centralised model with bzr, the packages are hosted in a central place, that's the end of it :) [21:40] I'm using it decentralised ;-) [21:40] I could put a branch anywhere I like [21:40] I'm just saying you can't keep people from using it in a decentralised way [21:41] I hope people do. That way the server team can work on docs by themselves and then merge it in later. [21:41] No need to become ubuntu-doc members and give them direct access [21:41] I think it's going to be very difficult to merge [21:42] as I'm guessing it'll become an unrelated branch [21:42] bzr is magical [21:42] pfft [21:42] you can also quickly screw up your repo too ;-) [21:43] I wonder if lp is smart enough to use a repo [21:43] ok, back to what we were talking about [21:43] Which was what again? [21:43] I think maintaining both docbook and wiki versions of documentation is really difficult [21:44] confusion between h.u.c.and h.u.c/c [21:44] I agree with LaserJock [21:44] well, IMO there shouldn't be any confusion [21:44] h.u.c should be a wiki [21:44] ok, I am new to the doc stuff...but this is confusing in itself: [21:44] LaserJock: why would you put branches everywhere you like, when you are a team member and the team pages tell you not to? [21:44] "The documentation wiki at [WWW] help.ubuntu.com is where the bulk of the Ubuntu community documentation is kept. Anyone can edit the wiki, which makes it an ideal place to start contributing." [21:45] Maybe have a script that exports the a stable bzr branch, compiles it to html, and place it on h.u.c? [21:45] mdke: because maybe I want to do some testing or profreeding before commiting to the team repo [21:45] from the DocTeam page [21:45] LaserJock, somervill32: I'd have to disagree, if you look at https://help.ubuntu.com/7.04/server/C/postfix.html and https://help.ubuntu.com/community/Postfix [21:46] LaserJock: right, so you'll commit to the team repo eventually [21:46] the content is basically the same and the formatting closely matches [21:46] mdke: I doubt I'd ever do it but there nothing that prevents me is the point [21:46] sommer: but they can easily go out of sync and then you end up with problems [21:46] wow that took loonger then i thought :) [21:46] LaserJock: ok. Back to the main point, your solution is to have a separate website with system documentation? [21:46] wife came home :) [21:47] LaserJock: sure, but the system docs are only update per release... should have time to update them I'd think [21:47] sommer: doubtful and that alone causes confusion [21:47] mdke: not exactly [21:47] so where do you put them? [21:48] LaserJock: I guess I'm not clear on why? [21:48] instead of the wiki being a subdir of help.u.c why not make the static docs a subdir of help.u.c [21:48] sommer: if the same thing occurs in multiple place people get confused [21:48] especially when the don't say the same thing [21:49] LaserJock: I don't think it's impossible to simply import the static docs to wiki pages. If the technical side gets hard we can simple try dumping html in the wiki page, after all. That way we can eliminate overlap by having a wiki page on the same subject as a system doc page [21:49] mdke: so help.u.c is a wiki, then have say a GutsySystemDocs page that links to the static docs [21:49] I think people might be confused when the help that they had confidence in suddenly starts changing. [21:49] somerville32: ? [21:49] somerville32: dude [21:50] I don't think people know the difference [21:50] somerville32: isn't that where the quality assurance comes in? [21:50] that's like saying that I'd be confused if my plumber turns up on time tomorrow, instead of being late like he always is [21:50] it's true, but who cares? [21:50] people just Google stuff and click on whatever comes up [21:50] or whatever is posted on the forums [21:51] I think there needs to be official documentation and community documentation. [21:51] I doubt most people have a sense of confidence on *anything* that on the web [21:51] somerville32: why? [21:51] somerville32: it's all community [21:51] Ubuntu is used in the corporate environment and don't want to refer to a wiki which just anyone can contribute to. [21:51] LaserJock: its not viewd as the same documentation/same community [21:51] somerville32: that's their problem ;-) [21:51] i would argue somerville32's point [21:51] somerville32: you need to understand that "official" means nothing unless we actually make it so. There are plenty of wiki pages that are more reliable than the system docs [21:51] as sommer is saying, that's where the quality assurance comes in [21:52] mdke, I don't think that changes anything. The quality of that page could become compromised at anytime. [21:52] if you can give people an accurate idea of how reliable a page is, rather than just labelling them "official" and "not official", then we're winning [21:52] mdke, Do you read the e-mail sent out for every edit? [21:52] mdke: thanks, I'm also looking at the issue almost exclusively from the server doc viewpoing. [21:52] which at this point are pretty out of date [21:53] sommer: and which the sever team talked about updating [21:53] esxpecially as the server guide is currently two releases old [21:53] sommer: We can still do SRU for the official docs [21:53] QA for docs can still continue after a release. [21:53] But we need something solid for documents. Wiki is way too fluid. [21:53] somerville32: they can also be improved. I don't read the commit messages either. Anyway, the point is that the system docs can easily contain errors now, and wiki pages can be more reliable now [21:53] somerville32: fluidity is the point [21:54]