[03:34] <Simira> Kamion: ping?
[07:51] <HostingGeek> tooo many meetings
[11:08] <froud> nhla lets do this thing
[11:08] <froud> enrico: you lead
[11:09] <enrico> are we all there?
[11:09] <froud> here
[11:09] <trickie> here
[11:10] <jeffsch> here
[11:10] <froud> what's first topic enrico 
[11:10] <drasko> hi all... 
[11:11] <enrico> Good.
[11:11] <enrico> Good morning/afternoon/evening/night, ladies and gentlemen
[11:11] <Burgundavia> hello
[11:12] <enrico> Welcome to the third Ubuntu Docteam Meeting
[11:12] <enrico> I'm loosely leading the session, and I'll post minutes to the mailing list and in the wiki
[11:13] <enrico> We have three main topics in the agenda:
[11:13] <enrico> 1) Clarification of recent events
[11:13] <enrico> 2) Releasing Hoary
[11:13] <enrico> 3) Post Hoary
[11:14] <trickie> i posted the first topic on the wiki, because i was not understanding what was going on very recentyl in regards to the team
[11:14] <enrico> We can start with the first one, just quickly I'd say: we seem to have reached harmony, and I don't want to shake it too much :)
[11:14] <froud> basically Burgundavia and I kissed and made up
[11:15] <Burgundavia> right
[11:15] <trickie> love is in the air...
[11:15] <Burgundavia> well I am single
[11:15] <trickie> ha ha ha
[11:15] <enrico> I have a personal take on the event, though
[11:15] <froud> however as general we need some guidelines to contributions at various dev stages
[11:16] <froud> prose are not code
[11:16] <enrico> froud: yes.  We've been needing some freeze, or half-freeze, for quite a while
[11:16] <jeffsch> phases like: planning, writing, editing, release?
[11:16] <froud> jeffsch: yes
[11:17] <froud> we have used @status in the docs
[11:17] <froud> if people want I can change them
[11:17] <enrico> I mean, the idea of phases
[11:17] <enrico> I'd just remove the "planning" phase
[11:17] <froud> normally we use outline, first draft, second draft, camera ready
[11:17] <enrico> It seems to me like the analogue of the "work in progess" icon on webpages
[11:18] <enrico> Sometimes it helps to make it so that either a work starts, or it isn't there.  "planning" phases tend to sit there forever
[11:18] <froud> outlining is a plan
[11:18] <enrico> froud: ah, ok
[11:18] <froud> see it as a skeleton
[11:18] <trickie> thats how i see it
[11:19] <froud> from outline we can derive status docs
[11:19] <froud> and allocate work between us
[11:19] <froud> after each decides on a section we prepare first draft
[11:19] <froud> collectively
[11:20] <froud> then we switch sections as we go to second draft
[11:20] <froud> each checks and edits the other
[11:20] <froud> after second draft we do technical review
[11:20] <froud> at which point major edit should be limited to
[11:21] <froud> technical error, punctuation, spelling grammar
[11:21] <froud> opinions
[11:21] <enrico> You need a tightly coupled team to for the switching sections part to be successful
[11:22] <trickie> i agree, using those phases and limiting edits in certian phases will certainly increase our productivity
[11:22] <jeffsch> big changes near a release are not good: one thing gets fixed, and two get broken. it is normal for that to happen
[11:22] <froud> enrico: what do you suggest
[11:22] <enrico> But I think the limiting edits to "technical error, punctuation, spelling grammar" is a good step
[11:23] <enrico> I mean, a step to make at some point
[11:23] <trickie> if someone sees something they would like to change (majorly) but it is already in final draft, then they should line it up for the next release
[11:23] <froud> yes, in each release the docs should go through the same phases
[11:23] <froud> over the course of several releases
[11:23] <enrico> From what froud said, I'd keep at least the freeze-like phase, and apply it to the QuickGuide now
[11:23] <froud> quality and quanity is built
[11:24] <froud> over time and provided that the whole OS does not change, stability is created
[11:24] <enrico> froud: yes.  I'm curious to see what the QuickGuide will have become by Grumpy or Perky
[11:24] <trickie> I am not sure how smoothly the switching sections bit will be either... but it will only be easier as participation grows
[11:25] <froud> yes, Quick Guide is the platform to build on
[11:25] <enrico> .oO(I guess people will have noticed that I'm a shameless fan of the quickguide)
[11:25] <froud> trickie: the switching happens on nodes
[11:25] <froud> some nodes move faster than others
[11:26] <froud> basically the @status shows the stage a node is at
[11:26] <trickie> yes agreed on that, whether every node gets to go through the whole process or not is what i meant
[11:26] <froud> so status="first-draft"
[11:26] <froud> the main problem I see is the interaction with the technical review
[11:27] <froud> it's not such a problem with quick guide
[11:27] <froud> but for user and admin guides it will be
[11:27] <froud> we need devs to do the technical reviews
[11:27] <trickie> yes, we will have to probably include developers
[11:27] <froud> and to save them time
[11:27] <trickie> yes
[11:27] <froud> we have to give specific reference to what they should check
[11:28] <Burgundavia> a dev read over might be a good thing at certain point
[11:28] <enrico> I like the idea, but I'm still wondering if it applies to the more caotic nature of our project
[11:28] <Burgundavia> catch things like the sudo error
[11:28] <enrico> I was however liking the idea of phases
[11:28] <froud> Burgundavia: yes :-)
[11:28] <enrico> How about:
[11:28] <trickie> yes i found dev feedback for the release notes was good, but because i asked for general review and comments it came in over a few weeks
[11:28] <enrico> 1) "Wiki mode": everyone adds contents everywhere, even comments
[11:29] <enrico> 2) "Style mode": people pull the contents of a section together in a nicely readable way, giving them a narration and a consistent meaning and style
[11:29] <enrico> 3) "Review mode": as froud was saying
[11:30] <froud> I was thinking devs do svn up we give them xpath
[11:30] <trickie> great idea
[11:30] <froud> they check the node and add <!--comments--> or make direct edit
[11:30] <enrico> uh, and of course:
[11:30] <enrico> 4) Ready for release
[11:31] <froud> they make patch
[11:31] <enrico> Being a Debian Developer, I sometimes forget that there are releases :-)
[11:31] <Mithrandir> enrico :)
[11:31] <trickie> a patch would be good, because if they have content they would like to see, or a change to existing content, they don't usually have time to phrase it as the rest of the doc
[11:32] <froud> there are also more devs that writers
[11:32] <froud> patches are easier to control
[11:32] <trickie> agreed
[11:33] <enrico> second point is: Releasing Hoary
[11:33] <Burgundavia> have we had a dev do a technical check of the docs?
[11:33] <enrico> can we safely conclude that the QuickGuide is in "review" phase as defined above by froud ?
[11:34] <trickie> enrico, have you heard anything about whether the .pot file i sent you for the quickguide was asustiable for the translators?
[11:34] <enrico> "edit should be limited to technical error, punctuation, spelling grammar"
[11:34] <enrico> trickie: good question.  I'm checking ubuntu-translators
[11:34] <ogra> froud, we are watching you
[11:35] <Burgundavia> I was about to say that
[11:35] <trickie> froud, maybe we should ask em?
[11:35] <trickie> ha ha ha
[11:35] <froud> you think they can see but not hear?
[11:35] <trickie> dunno, never can tell with those devs
[11:35] <trickie> :)
[11:36] <ogra> lol
[11:36] <enrico> trickie: I sent the potfile you gave me to Carlos Pereillo, but I still haven't heard back
[11:36] <froud> ogra: how can we notify devs in an orderly manner
[11:36] <enrico> Hello Liz!
[11:36] <mdz> Jeff Waugh (jdub) is already starting to review the docs
[11:36] <trickie> enrico, no probs!
[11:36] <Mithrandir> froud: bribery with beer always works.
[11:36] <Liz> hi enrico
[11:36] <Liz> morning all
[11:36] <mdz> but he probably needs some prodding
[11:36] <ogra> froud: you can drop by in #ubuntu-motu and call for help
[11:37] <trickie> mdz, ok, i'll warm up the taser
[11:37] <Liz> jeff lives on caffeine
[11:37] <froud> ogra: and are the devs ok with the process outlined above?
[11:37] <froud> I mean svn co, xpath etc
[11:37] <drasko> froud, how to know that?
[11:38] <ogra> froud: i think so, but you guys must keep in mind tha time is getting shorter for us as well with the nearig release time
[11:38] <froud> drasko: how to know what?
[11:38] <froud> ogra: that's why we giv eyou xpath
[11:38] <froud> you get just the nodes you must check
[11:38] <froud> not the whole doc
[11:38] <enrico> tricky thing is, the more we approach release, the more we need reviews from the devels
[11:38] <enrico> however
[11:39] <enrico> the more we approach release, the more we have to do without the devels
[11:39] <ogra> yup
[11:39] <enrico> froud: what for, xpath?
[11:39] <froud> xpath makes a query
[11:39] <drasko> froud, nevermind... I was wondering about devs. But ogra has been explanatory
[11:39] <froud> in xml
[11:39] <enrico> the good news is that if we write something wrong, we can always blame the devels who didn't check
[11:39] <Burgundavia> we probably only need one dev checkover, at the beginning of stage 3
[11:40] <enrico> (redirecting blame is an ancient italian art :)
[11:40] <Burgundavia> after that, there is not supposed to be any new stuff going in
[11:40] <ogra> enrico: its german too :)
[11:40] <drasko> enrico, gree
[11:40] <drasko> a
[11:40] <trickie> it would be nice to have something on the web, that wraps the current doc previews, and allows the devs to leave comments there?? comments??
[11:41] <trickie> then they don't have to svn co
[11:41] <enrico> Burgundavia: just say that you were short of sleep :)
[11:41] <trickie> dunno just a spur of the moment thought
[11:41] <Burgundavia> I am always short of sleep
[11:41] <enrico> trickie: oh, it'd be nice
[11:41] <froud> ogra: example. please check
[11:41] <froud> /book[1] /chapter[3] /sect1[5] /sect2[2] /sect3[1]  - id="qg-openoffice-ooow" status="complete"	quickguide.xml	file:/home/sean/projects/ubuntu/trunk/quickguide/quickguide.xml	1728:0
[11:41] <froud> /book[1] /chapter[3] /sect1[5] /sect2[2] /sect3[2]  - id="qg-openoffice-oooc" status="complete"	quickguide.xml	file:/home/sean/projects/ubuntu/trunk/quickguide/quickguide.xml	1737:0
[11:41] <froud> /book[1] /chapter[3] /sect1[5] /sect2[2] /sect3[3]  - id="qg-openoffice-oooi" status="complete"	quickguide.xml	file:/home/sean/projects/ubuntu/trunk/quickguide/quickguide.xml	1746:0
[11:41] <enrico> but there's no really good framework for annotating webpages afaik
[11:41] <enrico> everyone would like that, though
[11:42] <trickie> enrico, ok no prob
[11:42] <Burgundavia> what about just a post to ubuntu-doc?
[11:42] <enrico> froud: it's not trivial to generate those xpaths
[11:42] <froud> well it is. just //sect3
[11:42] <trickie> enrico, it could be done by script based on status
[11:42] <froud> and you get the above
[11:43] <enrico> froud: what do you mean with //sect3?
[11:43] <froud> xpath starts with //
[11:43] <trickie> enrico, that gets all sect3's
[11:43] <froud> you want all sect3
[11:43] <dholbach> froud: not always
[11:43] <enrico> Ah, ok, sure
[11:43] <dholbach> froud: you can also start with / - it depends
[11:44] <froud> you can also make it specific to a section //sect3[2] 
[11:44] <froud> will only show
[11:44] <enrico> froud: ah, ok, you didn't get me
[11:44] <dholbach> trickie: for the script you could use   xmllint --path
[11:44] <froud> we already use xmllint in the validation
[11:44] <trickie> well when we generate the status reports for each doc, we can also generate the xpaths for all sections marked with a certain status
[11:44] <froud> .sh
[11:44] <enrico> I mean, I know xpath: what I meant is that there's no trivial methods to make them (say, clicking to some text and getting the xpath query to it)
[11:45] <dholbach> (although i'm not aware of what you're trying to do=
[11:45] <enrico> and there's no easy way to open up the document and jump to a given xpath
[11:45] <trickie> dholbach, thanks, exactly what i was thinking
[11:45] <froud> I think treebeard does that
[11:45] <enrico> treebeard?
[11:45] <froud> but it is java and I know how you love java
[11:46] <enrico> it's not in apt-cache search, so it doesn't exist :)
[11:46] <froud> http://treebeard.sourceforge.net/
[11:46] <froud> then you must suffer :-0
[11:46] <enrico> However, the problem here is to point a specific section to the devels
[11:46] <ogra> enrico: it does only mean that nobody pointed MOTU at it yet ;)
[11:47] <ogra> treebeard ^
[11:47] <enrico> ogra: well, right.  I've no familiar with that MOTU device, but it seems powerful
[11:47] <trickie> i reckon generating the xpaths when we build status reports is fine for now
[11:47] <froud> ok
[11:47] <ogra> enrico: the Masters of the Universe ;)
[11:47] <enrico> trickie: how do the devels get the text from the xpath, then?
[11:47] <froud> xpath returns the nodes and the values
[11:48] <enrico> froud: right, but that's not the best format for reading
[11:48] <enrico> Aren't there, say, HTML anchors?
[11:48] <froud> they can see it in the xml
[11:48] <froud> they should hav ethe xml src right
[11:48] <enrico> Like, making an HTML anchored link from the status page to the corresponding point in the real document?
[11:48] <froud> enrico: xml is sans presentation
[11:49] <froud> xpath takes you to the spot
[11:49] <enrico> Well, if the devels are happy with xpath queries, then I'm fine
[11:49] <enrico> however, I fear it'd end up that they'd have to figure out how to get the text out of that, and would slip reviewing lower in their overful TODO-list
[11:50] <trickie> wel we could also generate the HTML links in the status report
[11:50] <enrico> at least, that's what my instinct tells me to do when I have my devel hat on :(
[11:50] <enrico> Right.  To pull that all together
[11:50] <enrico> I'd say: ask the devels for review
[11:51] <enrico> if you find some who want xpath, give them xpath
[11:51] <enrico> else, give them "street directions": "go to the title "Fooish bar", turn right, follow the path until the big tree, then go down a section and it's after the third comma: you can't be wrong"
[11:52] <enrico> It all boils down to negotiating the preferred way with the other endpoint of the conversation
[11:52] <ogra> yeah, with gps navigation :)
[11:52] <froud> +1
[11:52] <Burgundavia> and I say any sort of dev feedback is good feedback
[11:52] <froud> +1
[11:52] <enrico> depending on who this other endpoint is every time
[11:52] <trickie> agreed
[11:52] <Mithrandir> enrico: I'm not following the doc stuff closely, but are all docs in XML files?
[11:53] <enrico> Mithrandir: yes
[11:53] <froud> those in svn are
[11:53] <enrico> Mithrandir: DocBook XML
[11:53] <ogra> Mithrandir: yelp compatibility :)
[11:53] <enrico> So, we have a QuickGuide to submit to the devels for review.  jdub's on it already, but he should be pinged
[11:53] <Mithrandir> enrico: ok.  DocBook just makes me want to stab myself with a spoon or something.
[11:53] <enrico> people, meet Mithrandir 
[11:53] <trickie> hi
[11:54] <enrico> Mithrandir is more of a Kernel guy than a documentation guy :)
[11:54] <Mithrandir> enrico: I don't do kernel stuff.  toolchain and low-level stuff is fine, though.
[11:54] <enrico> Ok, he's a GCC hacker
[11:54] <froud> Mithrandir: you will do just fine then
[11:55] <Mithrandir> I guess so. (:
[11:55] <enrico> Rusty said he became a kernel hacker because he couldn't understand what gcc hackers were talking about
[11:55] <froud> b'sides you dont have to do the docbook stuff, just check the text :-)
[11:55] <Mithrandir> gcc is simple.
[11:55] <enrico> Mithrandir: right.  I can't even read to the end of the manpage :)
[11:55] <enrico> well, I can, but not everyday
[11:55] <Mithrandir> froud: most of my stuff doesn't really have any docs per se, it's porting work, but I guess I'll manage.
[11:55] <Mithrandir> enrico: the source is easier to understand.
[11:56] <Burgundavia> back to releasing hoary
[11:56] <froud> yes
[11:56] <froud> +1
[11:56] <enrico> Burgundavia: yes
[11:56] <Burgundavia> so we need a dev to check our stuff
[11:56] <Burgundavia> what else?
[11:56] <enrico> jdub's on it, so we're fine (provided we ping him)
[11:56] <froud> http://bugzilla.gnome.org/show_bug.cgi?id=170074
[11:56] <froud> the xref problem
[11:56] <Burgundavia> ah yes
[11:57] <froud> can one of the devs please fix this in yelp
[11:57] <Burgundavia> now that 2.10 is out, can that be fixed for 2.10.1?
[11:57] <enrico> mdz: that is Yelp needing fixing
[11:57] <Burgundavia> doc team is yelping at you mdz
[11:58] <enrico> Is there a way to open a bugzilla item on ubuntu linked to that bugzilla item on Gnome?
[11:58] <Burgundavia> if that can't be fixed, where do we go from there?
[11:58] <Burgundavia> enrico: you can just list it in the bug comments
[11:58] <enrico> Burgundavia: ok
[11:58] <Burgundavia> seb128 does that
[11:58] <enrico> We can report that as a bug for Yelp, then give it to seb
[11:59] <enrico> however, that report is not that easy to understand
[11:59] <Burgundavia> a screenshot and code might be helpful
[11:59] <Burgundavia> I will do that
[11:59] <enrico> Burgundavia: that's great"
[11:59] <enrico> Burgundavia: that's great!
[11:59] <froud> https://bugzilla.ubuntu.com/show_bug.cgi?id=6899
[12:00] <froud> the scrollkeeper/omf problem
[12:00] <froud> how to get ubuntu in top level of yelp
[12:00] <enrico> jdub was trying to figure it out
[12:01] <enrico> however (guess?) we need to ping him :)
[12:01] <froud> If those tow bugs can be closed then the docs are good for go after tech review