[18:52] godbyk, you around for a question or two ? [22:27] KI7MT: I'm here now. [22:31] godbyk, I got what I needed I think, talked with knome .. was having trouble with local repos and working on multiple fixes as things. Seems the only way I can do that is to have separate branches in a none shared local repo. [22:32] KI7MT: Ah, okay. Yeah, that's the only way I've found to deal with it, too. [22:33] (I often wish we used git instead of bzr for that reason. But perhaps I'm just missing an obvious feature of bzr that would help.) [22:33] Yeah, I created a bit of a mess with ubuntu-docs .. sent up on MP .. was merged, then did a second MP, then an unrelated bux fix, used > bundle and well made a mess .. lol .. [22:34] Heh.. yeah, I've been there. :) [22:34] I end up checking out a new branch for each MP and each bug fix and dealing with them one by one. [22:34] Otherwise I'm not sure how to keep it all straight. [22:34] I wouldn't be an issue if the repo wasn't Distributed + gatekeeper, but I can see why they want it controlled. [22:34] * godbyk should learn how to use bzr better. [22:35] For the manual, anyone on the team can directly commit to our repository. We don't bother with MPs generally. [22:35] So far it hasn't been much of a problem. [22:35] Im now using a branch .. then cp -R to say ubuntu-docs-lp12345 and work it that way. [22:35] We'll occasionally have someone that commits something that breaks the build. [22:36] But it's usually a quick and simple fix. [22:36] That's what I end up doing, too. [22:37] I had to pull my second MP and adn the fix into their repsective repos, but think it's all sorted. The docs say to setup a shared repo .. but that's leads to torubles. [22:38] Allot of these fixes are a line or two of text, so can do several fixes per day. [22:39] Hows progress on the 14.04 manual going? saw some email traffic on translations. [22:40] In the next couple weeks I'm going to start putting out calls for volunteers again. [22:41] We usually don't begin writing too early as we have to wait for things to actually land in Ubuntu before we can document them. [22:41] Is there a task list of to do's somwhere? [22:41] Not really. We usually assign authors and editors to particular chapters/sections of the manual. [22:42] After they're finished, we then proofread the entire manual. [22:42] Have you looked at an applicaiton called asciidoc ? [22:44] I think I've seen that one before. [22:44] I've looked at pandoc, too. [22:44] It has a LaTex backend: http://www.methods.co.nz/asciidoc/#X1 docbook well supported as is Mallard. [22:45] Most of the convert-to-LaTeX apps I've seen do a fair job, but not really as good as we can do by just using LaTeX directly. [22:46] There's a slight learning curve when people start working on the manual, but I don't think it's too bad these days. [22:46] For me it's kinda frustraighting . all the docs seem to use different tools. Kinda rough for new folks to come in and help out .. I think the authors and editors approach is pretty good though. [22:46] The LaTeX syntax we use is fairly limited at the moment, so you don't have to learn too much. [22:46] Yeah that is a problem sometimes. [22:47] I don't mind having to learn a new markup language and tools as long as they're well-documented. [22:47] And the docs project isn't documented nearly as well as I think it should be. [22:47] I'm hoping we can continue to work on that going forward. [22:47] Thats just it, relevant examples is hard to find, then how that markup is to used used on a project, or lack of templates [22:48] I think ubuntu-manual is pretty good, the styles guide explains allot. [22:49] For the manual project we went to quite a bit of effort to make it easy for people to work on our project. [22:49] So what's the key freeze point for the manual, Feature Freeze? [22:50] Well, the final deadline is to publish the manual the same day that Ubuntu 14.04 is released. [22:51] We try to have all the editing done at the beginning of that week (so I have a couple days to do any last-minute tidying up). [22:51] You have a definitive list of topics as well yes? [22:51] And going back from there we try to give the editors and authors as much time as we can. [22:51] Yeah, kind of. [22:51] We've been sticking with the current chapter/section outline, but we can change that if need be. [22:51] If we think we need to add another topic or remove one or shuffle things about, etc. [22:52] Nothing is really set in stone, but it serves as a guideline. [22:53] I find looking through the Ubuntu-QA app testing list a good template regarding docu some apps have their own help, some done, wehre does one draw the line in the sand so to speak :-)mentation needs, but [22:53] *some dont .. .. [22:53] Yeah, I don't know how that works. [22:54] I think some app developers write their own documentation and others don't. [22:54] that's odd. mentaton need, but got added.. no idea how that happened ..lol [22:54] For the Ubuntu system (desktop) docs, we inherit the docs from GNOME and then tweak that documentation to account for differences between Unity and GNOME. [22:54] (The differences are becoming more and more pronounced it seems.) [22:55] From a user stand point, where do they go fist .. app help, system help, external docs .. it's all kinda crazy. [22:55] Yeah, it is. [22:55] And I don't know what users *actually* do... I'd love to find out, though. [22:55] I don't know if anyone reads the system documentation on their desktop (e.g., open the Dash and run the Help program). [22:55] Yeah, that's would be an interesting set of data for sure. [22:55] I don't know if they visit help.ubuntu.com.. [22:55] Or if they visit wiki.ubuntu.com... [22:56] or if they just ask Google and go where it leads. [22:56] Hopefully some of them read the Ubuntu Manual, too. ;-) [22:56] Im actually confused on that one myself .. in IRC I try to send people to help.ubuntu.com.. was tols the wiki is more or less for developers .. then there's askubuntu.com .. LOL .. [22:56] *told [22:57] Yeah, I forgot about askubuntu.com. [22:57] Myself, I tend to just Google things. [22:57] I send folsk that say, "Im new to Linux, where to I start", or I need some general how too for ubuntu etc to the ubuntu-manual. [22:58] If they ask for a specific topic .. how to I do x,y,z .. then usually help.ubuntu.com .. unless I can't find an up to date one, wheich that needs allot of work too. [22:59] I think that's a good way to go. [22:59] For the manual, we write it when a novice Ubuntu user in mind. [22:59] It's geared toward new Ubuntu users. [22:59] my typing is horrible today .. Im on an HP Mini right now, fingers bigger than the keys .. lol .. [22:59] Gah, I hate small keyboards! [23:00] ditto .. [23:00] Or laptops with a touch pad right where it should NOT be .. lol .. like 99% of them are. [23:01] Yes! My laptop has a touchpad that my wrist keeps hitting and so the cursor moves and I start typing elsewhere in the document. [23:01] is there a repo specifically for gnome-docs ? I keep seeing allot of reference to that on the ubuntu-docs stuff. [23:02] Yeah, they have a git repository. One sec and I'll dig up the link. [23:02] On the ubuntu-docs task list, says we need to check ubuntu-docs against gnome-docs .. [23:03] https://git.gnome.org/browse/gnome-user-docs/ [23:03] lol .. and of course, it's Git and bugzilla :-) [23:04] Yeah. We have to diff the GNOME docs (keeping in mind that Ubuntu may be using an older version of GNOME than the latest and also that the GNOME docs themselves may be out of date for that version) and the Ubuntu docs. [23:04] Then update the Ubuntu docs accordingly. [23:04] v.s. bzr and launchpad [23:04] But it's not a process we can automate. We have to have humans looking at the diffs and deciding what to keep and what not to. [23:04] That explains why Im seeing allot of gnome .page file things .. [23:05] authors and such [23:05] they have a nice styles guide also. [23:06] That's what we need for ubuntu-docs Help [23:06] They gnome-docs moved over to Mallard didnt' they? [23:07] Yeah, the gnome-docs use Mallard. And that's why ubuntu-docs switched to Mallard, too. [23:07] from a first glance perspective, seems a fare bit easier than DocBook [23:08] Yeah, there are a lot fewer tags. [23:08] Mallard was also designed specifically for this type of documentation. [23:08] So it's not designed to produce books or any random document type you can think of. [23:08] It's specifically for documentation. [23:08] It looks nice, we jst need to develop a more focused Styles guide foe Help Docs. [23:09] and get rid of all the DocBook stuff .. except for server docs, but then again, why not move them over to mallard too. [23:10] I'd like to see nice documentation for writing Ubuntu system docs (desktop) using Mallard, too. Something like the Ubuntu Manual style guide would be great. [23:11] Yes, it's definately needed. The gnome guys have a pretty good handle on this. [23:12] Like, they have a whole page on License usage. [23:12] yeah [23:13] They have their own IRC also .. :-) [23:13] web-based though, not a fan of that. [23:15] You can probably still connect to it through an IRC client. [23:15] A lot of people just use web clients, though. [23:15] I was gonna go look .. probably a different server. [23:15] Web-Client kinda hard to do on a server :-) .. well a non DE server at lease .. IRSSI be my buddy .. lol [23:18] I've thought about switching to irssi but haven't taken the plunge yet. I'm still using xchat. [23:18] dont know if you seen this, pretty nice: https://developer.gnome.org/gdp-style-guide/stable/ [23:18] Yeah. And the Ubuntu docs style guide reference that GNOME docs style guide. [23:18] I use both .. server irssi .. DE xchat .. irssi is realyl powerful, but has a learnign curve. [23:19] One of the things I'd like to do for Ubuntu it work with the docs teams and the Ubuntu designers/developers to come up with a list of canonical names and spellings (and capitalizations) of all the various UI elements so we can ensure consistency. [23:19] Right now those things are somewhat inconsistent. [23:19] well .. maybe that's what we need to do if Unity is the way of the future .. [23:20] I agree .. and I think the docs teams whould all work form the same styles guide .. and adjsut contest based on platform. [23:21] *docs teams should .. .. [23:21] contest.. lol .. adjust content. [23:21] Like the use of Dash .. if it's in Dash .. point users to go through Dash to get to it .. not, click this, click that. [23:22] Yeah. [23:22] and for DE .. terminal should be avoided .. I like the terminal .. I can't work without it, but, Unity uses Dash, not the term. [23:24] And workflows .. that would be great, like: https://wiki.gnome.org/DocumentationProject/StatusTracking [23:25] I asked about status tags .. and ubuntu-docs Help .. they not being used. [23:26] Yeah, I was a bit wary about the terminal-based instructions for disabling the guest account for that reason. [23:26] And this Shaun McCance is like gnome docs super man, his name is everywhere. [23:26] But since I'm unaware of a GUI way of doing it, I let it go. [23:27] Yeah, Shaun is the guy who wrote/designed/invented Mallard, too. [23:30] :-) that explains why he's all over the mallard questions I had :-) [23:34] re Guest .. I've seen that done allot in the field / real world use. The server guys are terminal guru's .. README's are wthe way of life there. [23:36] gnome uses Git too :-)