[12:59] <froud> time
[12:59] <mdke> froud, another hour
[12:59] <mdke> ;)
[01:00] <mdke> its 11 UTC
[01:00] <froud> nah
[01:00] <mdke> yah
[01:00] <mdke> Current UTC (or GMT/Zulu)-time used: Sunday, April 17, 2005 at 11:00:21
[01:59] <jsgotangco> ok
[01:59] <froud> who is the chair
[02:00] <mdke> mary organised the meeting
[02:00] <froud> yep, is Mary here
[02:00] <mdke> not yet
[02:00] <froud> ok
[02:00] <froud> I am now logging
[02:01] <Burgundavia> hey, take a look at this idea:
[02:01] <Burgundavia> http://img107.echo.cx/my.php?image=help2ui6ja.png
[02:02] <froud> Burgundavia: nice suggestion
[02:02] <Burgundavia> by default, it woudl show common things
[02:02] <Burgundavia> and when they searched, it would reorder itself
[02:02] <Burgundavia> very simple ui
[02:02] <jsgotangco> would beagle be part of breezy
[02:03] <Burgundavia> jsgotangco, that is the plan
[02:03] <Burgundavia> but this would be a standalone app
[02:03] <Burgundavia> I just used beagle as a look example
[02:03] <froud> Gnome only
[02:04] <froud> is the backend desktop neutral
[02:04] <Burgundavia> someone could right a qt frontend
[02:04] <Burgundavia> it is daemon and frontend
[02:04] <Burgundavia> we might as well talk here
[02:05] <froud> not sure everyone else not docteam is interested
[02:05] <froud> and it would be better to capture it under our weblog etc
[02:05] <Burgundavia> true
[02:05] <jsgotangco> ok
[02:05] <Burgundavia> am going to flood #ubuntu-doc with this talk
[02:08] <mdke> ok hypatia will you lead?
[02:08] <hypatia> yeah sure.
[02:08] <hypatia> gimme 2 minutes
[02:09] <jsgotangco> game
[02:10] <hypatia> OK, doc team meeting as per https://www.ubuntulinux.org/wiki/DocteamNextIRCMeeting
[02:10] <hypatia> who's here?
[02:10] <trickie> present
[02:10] <mdke> me
[02:10] <froud> !
[02:10] <Burgundavia> yeppers
[02:10] <jsgotangco> tadaaa
[02:11] <mpt> me
[02:12] <hypatia> yay.
[02:12] <hypatia> So, agenda item #1.
[02:12] <hypatia> Better communication between Documentation Team and Development Team
[02:12] <Burgundavia> we got good feedback from mdz on this
[02:12] <hypatia> As I recall, this came up after the late addition of new spatial behaviour to nautilus.
[02:12] <trickie> Yes... i had a bit to say about that... but unfortunately haven't had a chance to do any of what i said  i would
[02:13] <hypatia> ie way to late to document and translate the documentation.
[02:13] <Burgundavia> he mentioned that the dev team is willing to create an artwork freeze
[02:13] <jsgotangco> such freezes should be well planned though
[02:13] <Burgundavia> so we have 2 issues here
[02:13] <mdke> and incorporate our feedback into freezes in general
[02:13] <Burgundavia> 1. artwork
[02:13] <Burgundavia> 2. features
[02:13] <froud> But is artwork a real problem?
[02:13] <jsgotangco> no its not
[02:13] <froud> feature are a problem
[02:14] <mdke> why not a real problem?
[02:14] <Burgundavia> artwork is a professional issue
[02:14] <hypatia> froud: the concern was screenshots looking exactly like a default desktop.
[02:14] <mdke> its a shame if our screenshots look unprofessional
[02:14] <hypatia> I agree that features are more of a problem.
[02:14] <Burgundavia> ie. our quickguide looks like crap because it does not look like hoary
[02:14] <Burgundavia> but artwork is easily fixable
[02:14] <froud> so we want to recapture all screen shots every release?
[02:14] <mdke> i think so yes
[02:14] <Burgundavia> froud, if the artwork changes, then yes
[02:14] <trickie> but features that make what we say in the docs is wrong is worse than inconsistent artwork
[02:14] <jsgotangco> we can always say that we're using a pre=release version
[02:14] <hypatia> but I would also like the doc screenshots to mirror a default desktop perfectly if possible.
[02:14] <mdke> trickie, agreed
[02:15] <froud> that is lot sof overhead
[02:15] <hypatia> which would mean no late artwork changes.
[02:15] <mpt> "Objects in mirror may be newer than they appear."
[02:15] <Burgundavia> so when do we want the artwork freeze to be?
[02:15] <mdke> the screenshots shouldn't take too long to recapture, given a reasonable freeze
[02:15] <froud> chaps in i18n are gonna scream
[02:15] <Burgundavia> for the quickguide it shouldn't be too bad
[02:15] <mdke> froud, i don't think so, they just do the words
[02:15] <Burgundavia> other docs it becomes an issue
[02:16] <jsgotangco> especially to what were planning on
[02:16] <jsgotangco> the visual stuff
[02:16] <froud> remember we have captures for each language
[02:16] <Burgundavia> anyway, the point is, when do we want the artwork to freeze?
[02:16] <mdke> froud, yeah but we will have to do them all
[02:16] <froud> in each language
[02:16] <mdke> afaics
[02:16] <froud> perhaps we can capture without the window
[02:16] <trickie> well if we are going to have consistent artwork across langauges the freeze will have to be before string freeze
[02:17] <Burgundavia> trickie, can it not be at the same time>
[02:17] <jsgotangco> do we have a definite time line at the moment for breezy
[02:17] <jsgotangco> maybe we can refer to that
[02:17] <trickie> Burgundavia, yeah you are... same thing
[02:17] <mdke> jsgotangco, no they will define it at UDU
[02:17] <mdke> hence this meeting
[02:17] <Burgundavia> ok, when is our breezy string freeze?
[02:18] <Burgundavia> breezy is october 2005, around the same time as warty
[02:18] <mdke> Burgundavia, they are reworking their plans at UDU, that is why mdz wanted our feedback
[02:18] <mdke> so that it could be put into the equation
[02:18] <Burgundavia> how many weeks before release was our string freeze this time?
[02:18] <froud> mdke: that is point 2
[02:18] <mdke> froud, they are the same
[02:18] <froud> we are still on point1
[02:18] <froud> are they
[02:18] <trickie> no
[02:19] <froud> 1 is comms
[02:19] <mdke> well if we're talking about time needed for freezing, this is point 2
[02:19] <trickie> I think the first one was also about creating some relationships between the doc team and the developers
[02:19] <hypatia> yeah.
[02:19] <hypatia> point 1 is communication.
[02:19] <hypatia> let's get that out of the way.
[02:19] <mdke> lets focus on that then
[02:19] <Burgundavia> have we decided on a date or at least a 'weeks before' timeframe?
[02:19] <froud> we have established flow and coms with i18n processes
[02:19] <mdke> Burgundavia, can we leave that until we come onto point 2?
[02:20] <Burgundavia> sure
[02:20] <froud> for devels we need interaction
[02:20] <hypatia> so, re point 1, trickie has agreed to try and interface a bit with the devel team.
[02:20] <froud> we need note of updates
[02:20] <mdke> in terms of communication, we can't do much more than encourage them to let us know when major changes occur
[02:20] <trickie> We were talking last week about having someone from doc team hangin out on the dev list trying to catch features that impact on docs
[02:20] <hypatia> trickie: can you summarise your plans again?
[02:20] <mdke> mdz mentioned at the Technical board meeting that he thought it was unfeasible to monitor the whole devel list just for issues which will be fairly rare
[02:21] <froud> I agree with mdz
[02:21] <hypatia> mdke: but if we have people reading devel out of interest anyway, then they can help fill us in as a bonus.
[02:21] <Burgundavia> I currently am subscribed to ubuntu-devel and breezy-changes
[02:21] <froud> we need a single point
[02:21] <hypatia> I agree that it would be a huge load *just* for this task,.
[02:21] <hypatia> froud: a single point of what?
[02:21] <jsgotangco> mabye a weekly report perhaps?
[02:21] <froud> we need an rss feed
[02:22] <hypatia> an rss feed of what?
[02:22] <Burgundavia> probably easier to just forward a summary of each issue to the doc list
[02:22] <hypatia> froud: I'm sorry, I'm not following.
[02:22] <mdke> Burgundavia, ++
[02:22] <trickie> Burgundavia, +1
[02:22] <Burgundavia> as it happens, like
[02:22] <froud> devs need to comm in a way that we get automatically and without much overhead to them or us
[02:23] <mdke> also mdz mentioned that he would bear in mind the fact that the docteam should be informed if a change obviously affects the docs
[02:23] <hypatia> froud: but what exactly do they need to communicate?
[02:23] <jsgotangco> a weekly summary wouldn't be that much to them imo
[02:23] <hypatia> froud: is there any (semi-)automatic way to determine docs relevant changes.
[02:23] <trickie> we also need to make a formal introduction to the dev teams identifying what our concerns were last release and maybe some examples
[02:23] <froud> like decisions made, changes made
[02:23] <hypatia> I mean, above the beezy-changes list.
[02:23] <hypatia> breezy-changes
[02:24] <froud> where is it
[02:24] <mdke> jsgotangco, the thing about a formal weekly summary is that most stuff in the devel list is not relevant to our work, its only just occasionally
[02:24] <Burgundavia> hypatia, not really
[02:24] <froud> we need to feed off what is pertinentto us
[02:24] <hypatia> froud: breezy changes is at http://lists.ubuntu.com/mailman/listinfo/breezy-changes
[02:24] <hypatia> froud: but it is very high volume.
[02:25] <froud> hypatia: I alrwady get a huge amount of mail
[02:25] <Burgundavia> hypatia, froud breezy changes is the actual package change logs
[02:25] <froud> 800 a day
[02:25] <hypatia> Burgundavia: I know.
[02:25] <hypatia> Burgundavia: I'm trying to get froud to explain where the "only stuff that is relevant to us" is going to come from.
[02:25] <Burgundavia> I think we need a person to filter the devel list
[02:25] <froud> we need to filter
[02:25] <trickie> I think monitoring breezy-changes is more than one person could do reliably
[02:25] <Burgundavia> and then we need a devel to tell us when changes are made
[02:25] <mdke> Burgundavia, +1
[02:26] <jsgotangco> +1
[02:26] <hypatia> So do we want developers to be familiar with documentation of the packages they maintain?
[02:26] <froud> so long as those persons are always there and consistant at doing it 
[02:26] <trickie> or even ubuntu-specific documentation
[02:26] <jsgotangco> have they even read our hoary docs
[02:27] <hypatia> jsgotangco: I know some have in parts.
[02:27] <froud> I see  2 levels
[02:27] <mdke> it would be nice if they did
[02:27] <froud> 1. Desktops
[02:27] <froud> 2 apps
[02:27] <hypatia> I don't think it's reasonable to expect them to read the entire set of docs.
[02:27] <Treenaks> then we'd have to keep 2 changelogs
[02:27] <Treenaks> which is annoying
[02:27] <mpt> Another way to do it would be to have a QA effort for the docs
[02:27] <mpt> Go through them and check that the instructions still work
[02:27] <mdke> Treenaks, that would be too formalised i think
[02:28] <Burgundavia> mpt, there is already going to be a dev qa, right after string freeze
[02:28] <hypatia> right, a qa is a good idea.
[02:28] <Treenaks> mpt: how about proofreading by people who know a thing about writing style?
[02:28] <hypatia> and then we freeze for translation.
[02:28] <mpt> Treenaks: I volunteer for that :-)
[02:28] <Burgundavia> I think it might be easier, if right before string freeze, everybody tests the docs
[02:28] <froud> I think we are underestimating the size ofthe problem and we are not looking to reduce the overhead
[02:29] <Burgundavia> have a week set aside for that
[02:29] <froud> instead we are increasing it
[02:29] <hypatia> mpt: but one problem is convincing the dev team to stop making changes after the docs freeze.
[02:29] <mpt> yes
[02:29] <Burgundavia> hypatia, the feature freeze should cover most of this
[02:30] <hypatia> froud: I don't understand whether you're suggesting anything or simply saying "all suggestions so far are too much work and will fail"
[02:30] <hypatia> so, to recap.
[02:30] <froud> hypatia: we are a small team withmuch to do
[02:30] <froud> the more admin the kless gets written
[02:30] <trickie> i also think the overhead being talked about is too much
[02:30] <trickie> there wasn't that much that came out wrong 
[02:30] <hypatia> froud: the latter then.
[02:31] <hypatia> froud: do you think that present interaction with the doc team is adequate>
[02:31] <mdke> all that is being suggested is that some of us monitor the devel list, and that the devels (as mdz has already undertaken) will contact us when there are major changes which may affect the documentation
[02:31] <froud> I would like to find ways to automate as much possible
[02:31] <mdke> i don't think that is too much overhead, IF some people already follow that list for fun/other reasons
[02:31] <trickie> mdke, yeah i think monitoring is good also
[02:31] <hypatia> froud: do you presently have any such ways to suggest?
[02:32] <mdke> froud, you can't automate communication
[02:32] <hypatia> right, recapping.
[02:32] <trickie> introducing extra QA is not
[02:32] <hypatia> Presently, suggestions are:
[02:32] <froud> In part you can
[02:32] <hypatia> 1. That we have monitoring of the development mailing list
[02:32] <jsgotangco> we can do little bits of QA before committing instead of doing one whole QA session before freeze
[02:32] <hypatia> 2. That the development team make an effort to inform us of documentation relevant changes.
[02:33] <hypatia> 3. That the QA process be improved (somehow)
[02:33] <froud> 1. +1
[02:33] <Burgundavia> why don't we delay the qa process, and discuss on the list
[02:33] <froud> 2. How
[02:33] <Burgundavia> the rest is good
[02:33] <mdke> 1,2, ++
[02:33] <Burgundavia> froud, I think the best we can do is ask them to do their best
[02:33] <froud> 2. supposes they will
[02:33] <hypatia> Burgundavia: I think a changed QA procedure will take at least another thread to nut out, don't worry about that.
[02:34] <froud> I suppose they will not in most cases
[02:34] <hypatia> Alright...
[02:34] <hypatia> Imagine for a moment the best of all possible worlds.
[02:34] <Burgundavia> froud, we can review in a month or two and give feedback
[02:34] <hypatia> What would "notification from the devel team of changes" look like?
[02:34] <jsgotangco> 2. i only expect mdz at the moment but hopefully it will improve
[02:34] <Burgundavia> hypatia,  a post to the list
[02:34] <Burgundavia> saying what changed
[02:34] <jsgotangco> an alert perhaps
[02:34] <Burgundavia> mostly the thing we need notice of is UI changes
[02:34] <daven> is there a list of all planned features/changes, that they could indicate a possible externals impact?
[02:35] <hypatia> daven: I doubt it. A lot of user visible changes come from the new GNOME release, and their feature freeze is kinda the same time as Ubuntu's.
[02:35] <Burgundavia> daven, more will come out of UDU
[02:35] <froud> sorry this is to loose for me, I think devels should create bugzilla's for documentation changes
[02:35] <Burgundavia> froud, ugh, too much overhead
[02:35] <hypatia> that's a good idea froud.
[02:36] <hypatia> Burgundavia: who for, them or you>
[02:36] <froud> the devels use bug trackers heavily
[02:36] <Burgundavia> hypatia, both
[02:36] <Burgundavia> the devels hate bugzilla
[02:36] <Burgundavia> that is why they are developing malone
[02:36] <jsgotangco> they can just use the current bugzilla perhaps
[02:36] <Burgundavia> why don't we jump on malone?
[02:36] <froud> So then we must be part of their bug system
[02:36] <hypatia> Burgundavia: well, in a "best of all possible worlds" discussion you can ignore the overhead for them for the moment.
[02:36] <froud> I dont care which
[02:36] <hypatia> Burgundavia: what's the overhead for you?
[02:37] <Burgundavia> hypatia, I find bugzilla to be very clunky and hard to navigate and organize info
[02:37] <Burgundavia> hypatia, and very very rigid
[02:37] <mpt> Malone is hard to navigate too
[02:37] <mdke> you want every developer to consider what change to a package impacts on documentation in whatever slight way, and document that?
[02:37] <mpt> but I'm working on it
[02:37] <mpt> :-)
[02:37] <mdke> i think that is excessive
[02:37] <jsgotangco> but they use it!
[02:37] <Burgundavia> mpt, malone is being developed
[02:37] <hypatia> Burgundavia: mpt is on the launchpad team...
[02:38] <froud> Changes should have check boxes
[02:38] <Burgundavia> hypatia, I know that
[02:38] <Burgundavia> hypatia, sorry, that sounded rude
[02:38] <mdke> it is our job to pick up on changes in programs and document them, all we need is a reasonable time before release that changes are not made, and LATE changes are communicated
[02:38] <froud> if the doc checkbox is selected we get updates
[02:38] <Burgundavia> anyway, the major changes we need are UI changes
[02:38] <hypatia> Burgundavia: tis OK
[02:38] <Burgundavia> froud, add doc-team CC?
[02:38] <froud> yes
[02:38] <froud> tight
[02:38] <froud> not get lost
[02:38] <froud> broadcast via our list
[02:38] <froud> clear
[02:39] <froud> trackable
[02:39] <Burgundavia> I say we go for malone as our stuff is not that critical and malone is going to get better
[02:39] <hypatia> OK, so from my 1, 2 and 3...
[02:39] <froud> little overhead
[02:39] <froud> inline to devel
[02:39] <hypatia> "1. monitoring of devel list" seems to be pretty popular
[02:39] <Burgundavia> mpt, malone "feels nicer" to use
[02:39] <froud> integrated
[02:39] <froud> 1. can do but not reliable
[02:40] <trickie> 1. can do but same... not consistently
[02:40] <froud> hypatia: I would like o see processes integrated and sustainable
[02:40] <hypatia> "2. Devel team to inform documentation team of updates" is not so popular, may be too much overhead. There's also some dispute over whether using Bugzilla is good or not.
[02:40] <mdke> guys I think this is getting carried away: developers have no duty to communicate to us changes made before freeze: this is our job to follow the devel os: its changes AFTER freeze which need to be communicated to us
[02:40] <froud> +1
[02:40] <trickie> 2. Malone sounds good, and if we could get something like the checkbox froud talked about that would be better
[02:40] <Burgundavia> bugzilla doesn't really track new features
[02:40] <hypatia> "3. That the QA process be improved" is considered a big job and is deferred to the mailing list.
[02:41] <hypatia> mdke: OK, that seems fair.
[02:41] <froud> +1
[02:41] <hypatia> So 2a "Devel team to inform documentation team of updates after freeze"
[02:41] <Burgundavia> 2. Devel team to notify of changes primarily to the UI of programs
[02:41] <mdke> "made after freeze"
[02:41] <jsgotangco> hmmm why is that it is their software creation in the first place
[02:41] <Burgundavia> before freeze is nice too
[02:42] <mdke> Burgundavia, it may be nice, but its our job to monitor that, not theirs IMO
[02:42] <froud> at anytime
[02:42] <Burgundavia> I don't think we should limit ourselves to after freeze
[02:42] <froud> create a habit
[02:42] <daven> mdke: but surely if we can make it easy for them to tick a box and say "hey i think there's a doc impact on this", there's no reason not to?
[02:42] <froud> if suddenly you intro a new thing mid way they will not do it
[02:42] <jsgotangco> id prefer notification anytime that impacts the whole docs
[02:42] <hypatia> Well, how about we take that to mdz and ask which is feasible:
[02:42] <mdke> daven, i'm not sure it is that simple, but then again I'm not a developer
[02:42] <Burgundavia> daven,froud, I think you overestimate the usage of bugzilla by the devs
[02:42] <hypatia> after freeze only, after freeze and before where possible, always.
[02:43] <froud> Burgundavia: what do they use
[02:43] <mdke> they use their heads
[02:43] <Burgundavia> froud, most of the stuff comes down from gnome
[02:43] <mdke> and UPSTREAM
[02:43] <froud> Burgundavia: we need to be in their process and cycle
[02:43] <hypatia> I think the devels use bugzilla for bugs.
[02:43] <Burgundavia> froud, and the team is very small
[02:43] <daven> mdke: from personal experience i think you're right - where i work devs ignore the "docs hit" box... but i think that's just tradition :-s
[02:43] <mdke> all major system changes come from upstream
[02:43] <Burgundavia> froud, there heads and #canonical I would guess
[02:43] <hypatia> For features and planning they use the wiki/the mailing list/irc.
[02:43] <Burgundavia> s/there/their
[02:43] <mpt> The "Masters of the Universe" are currently using Malone, the rest using Bugzilla.
[02:44] <hypatia> OK, so are we ready to wrap up point 1?
[02:44] <Burgundavia> hypatia, yes
[02:44] <froud> ok by me
[02:44] <mdke> i think we should, this meeting was called for point #2 mainly, due to the urgency of doing it before UDU
[02:44] <mdke> but we also need to deal with point #3 before UDU
[02:44] <hypatia> Conclusions I drew were: better monitoring of devel is a good idea, better informing by devel would be nice but we still need to sort out mechanism and figure out to what extent devel can actually do this (mdz would be person to inform)
[02:45] <hypatia> right.
[02:45] <hypatia> OK, point 2.
[02:45] <froud> +1
[02:45] <jsgotangco> sounds good
[02:45] <Burgundavia> worksforme
[02:45] <hypatia> there's actually 2 subpoints, so let's deal with them in order.
[02:45] <hypatia> point 2a.
[02:45] <hypatia> a list of items that affect documentation
[02:46] <Burgundavia> artwork, UI changes of other kinds
[02:46] <froud> can be added to teamstuff in svn
[02:46] <hypatia> any other ideas?
[02:47] <froud> think we will have to think on this list
[02:47] <hypatia> yeah.
[02:47] <Burgundavia> ok
[02:47] <hypatia> but let's do what we can with those suggestions.
[02:47] <Burgundavia> what is 2b?
[02:47] <mdke> 2b is the amount of time necessary for us to adapt to late changes in the things listed in 2a
[02:47] <hypatia> Burgundavia: if one of these areas (artwork etc) changes, how long does updating the docs take?
[02:47] <hypatia> so, let's start with artwork.
[02:48] <Burgundavia> hypatia, if the artwork changed, like hoary, we would need new screenshots
[02:48] <jsgotangco> taking screenshots on en and i18n
[02:48] <froud> we can obviate the artwork problem
[02:48] <jsgotangco> i18n is a concern
[02:48] <froud> dont capture window frame
[02:48] <mdke> screenshots without window frames
[02:48] <Burgundavia> the major issue I see here is sabdfl
[02:48] <froud> nah
[02:48] <hypatia> Burgundavia: with the artwork, or with timing in general?
[02:48] <jsgotangco> but he recognizes the problem
[02:48] <Burgundavia> we have a natural conflict here
[02:49] <Burgundavia> he wants to keep the artwork until the last sec, so as not to spoil the party, which is natural
[02:49] <Burgundavia> but we need it to document it
[02:49] <froud> Burgundavia: just dont capture artwork
[02:49] <mdke> Burgundavia, not sure about that
[02:49] <mdke> Burgundavia, there was a time limit set for artwork, but it was late
[02:49] <Burgundavia> froud, huh?
[02:49] <mdke> who thinks that screenshots without window frames is desirable? IMO it might be a shame to lose them.
[02:49] <mdke> but it may have more powerful advantages
[02:49] <froud> On screen captures dont capture the frame
[02:49] <Burgundavia> ick
[02:50] <hypatia> I assume artwork is an integral part of the "Applications" menu though?
[02:50] <hypatia> ie the icons...
[02:50] <Burgundavia> I think most people wouln't understand
[02:50] <froud> we dont use icons
[02:50] <Burgundavia> and anyway, the artwork changes are deeper than that
[02:50] <froud> explain
[02:50] <Burgundavia> selection boxes
[02:51] <froud> my question is
[02:51] <Burgundavia> anything that could be themed, was
[02:51] <froud> can a user use the instruction to accomplish a task
[02:51] <froud> that takes precedence
[02:51] <mpt> Window titles can be important for that
[02:51] <Burgundavia> I don;t see how truncated screenshots are going to help?
[02:52] <mdke> i think at the technical meeting mdz was perfectly happy to put in place a system where the artwork is frozen beforehand
[02:52] <froud> mpt: if important include
[02:52] <mpt> ("Is this the right window, or not?")
[02:52] <mpt> yeah
[02:52] <mdke> we should at least put this forward at UDU, if sabfdl overrules it, then we can talk about solutions
[02:52] <froud> if not dont
[02:52] <Burgundavia> then we have inconsistent docs
[02:52] <Burgundavia> and that looks even worse
[02:52] <froud> mpt: intructions should be action reaction
[02:52] <froud> do this
[02:52] <froud> that is opened
[02:53] <froud> no need for screencapt
[02:53] <Burgundavia> much easier to explain with a screencap, but we digress
[02:53] <Burgundavia> we are discussing artwork freeze dates
[02:53] <hypatia> indeed we do digress.
[02:53] <froud> Images need to be used sparingly
[02:53] <jsgotangco> hmm in a stylish way, we'll have inconsistent screenshots
[02:53] <trickie> If they are going to include an artwork freeze then we should not take SS till then, otherwise we have option
[02:53] <hypatia> Let's proceed with the assumption for the moment that we won't have completely artwork free shots.
[02:54] <trickie> no option
[02:54] <Burgundavia> what was the freeze for hoary? the string freeze that is?
[02:54] <mdke> hypatia, +
[02:54] <hypatia> Let's assume we've already taken the screenshots.
[02:54] <hypatia> And then there's a major change in one of the interfaces.
[02:54] <mdke> we work on the basis that they have expressed a will to freeze the artwork earlier. The question is, how long will it take us
[02:54] <froud> if time permits then update them after artwork release
[02:54] <hypatia> How long does it take to fix up the shots?
[02:54] <froud> otherwise tuff
[02:54] <hypatia> That's the number that mdz has asked for.
[02:54] <froud> over 12 books
[02:55] <trickie> then we would need as much time as it takes to retake all the sreenshots * number of i18n shot
[02:55] <mdke> it depends on l18n: if we delegate them, then IMO no more than 2-3 weeks
[02:55] <froud> depends on the number of books and languages
[02:55] <hypatia> He's asking "if we make late changes, how long do you guys need to catch up?"
[02:55] <jsgotangco> hypatia depends on the docs but also consider i18n specific shots
[02:55] <mdke> i think we can delegate l18n specific shots to the locoteams
[02:55] <Burgundavia> I would ask for a month at least
[02:55] <jsgotangco> mdke +1
[02:55] <hypatia> jsgotangco: I know. mdz wants a conservative estimate, do you have any idea what it would be?
[02:55] <mdke> but if we do them ourselves, it will take longer
[02:55] <froud> loco teams can do it
[02:56] <trickie> One seems logical... at least until our doc base grows alot larger
[02:56] <jsgotangco> mdke true some i18n teams do subscribe to ubuntu-doc
[02:56] <trickie> one month ...sorry
[02:56] <mdke> I am happy to try and coordinate the locoteams to do this job
[02:56] <froud> but asking them to do it again just for color is not on
[02:56] <froud> which means that we can only release to loco teams after art freeze
[02:56] <trickie> i agree... one month lets us retake our shots and then hand over at the string freeze for translation
[02:57] <froud> which leave little time for translations
[02:57] <mdke> froud, that's the whole point of this discussion
[02:57] <froud> I know
[02:57] <Burgundavia> screenshots and translations can take place simultaneously
[02:57] <hypatia> right, so the answer for artwork seems to be about 1 month.
[02:57] <mdke> froud, and its not a question of translation, its just a question of taking the captures
[02:57] <froud> and why I am saying that the artwork is not the main issue
[02:57] <Burgundavia> they are not mutually exclusvie
[02:57] <hypatia> or rather, the answer for anything needing new shots is 1 month.
[02:57] <mdke> froud, but we are talking about the artwork
[02:57] <froud> no it is translation and screen capt
[02:57] <froud> Ok hold with me
[02:58] <hypatia> it is purely screen capture at the moment.
[02:58] <mdke> froud, translation of the documents is a separate issue and is OT imo
[02:58] <froud> we give a pot file
[02:58] <hypatia> we'll get to the translation in a minute.
[02:58] <froud> it may be way before art
[02:58] <froud> thenlater we come back and ask for capts
[02:58] <mdke> froud, yes
[02:58] <Burgundavia> froud, how do we give a pot file before string freeze?
[02:58] <hypatia> hang on.
[02:58] <froud> the translators will be doing other things by then
[02:59] <Burgundavia> froud, huh? what other things?
[02:59] <froud> other documents
[02:59] <froud> not ours
[03:00] <mdke> here's what I see. our string freeze -> our document translations -> (later stage) artwork freeze -> screenshot capture for both en and other languages
[03:00] <hypatia> OK, so then mdz's next question is "if we do something that requires a change to the writing in the docs (after the freeze), how long does it take to put the new info in?"
[03:00] <Burgundavia> why is string freeze before artwork freeze?
[03:00] <mdke> Burgundavia, because translating takes longer than snapping a few screenshots
[03:00] <Burgundavia> strings are probably easier to translate
[03:00] <Burgundavia> than taking screenshots
[03:01] <Burgundavia> and can be done anywhere
[03:01] <froud> yes they are
[03:01] <mdke> translating is a lot more time consuming that screenshots
[03:01] <Burgundavia> as where as screenshots require a default install of breezy
[03:01] <froud> to take a capture the person has to find the exact same screen
[03:01] <froud> to translate a string they type inline
[03:01] <mdke> i've tried both so trust me
[03:01] <mdke> anyway we are way OT
[03:01] <froud> taking captures takes time
[03:02] <hypatia> so, on topic now.
[03:02] <hypatia> what's the answer to mdz's question?
[03:02] <hypatia>  "if we do something that requires a change to the writing in the docs (after the freeze), how long does it take to put the new info in?"
[03:02] <froud> there can be none at this time
[03:02] <froud> mdz has asked those question too early
[03:03] <jsgotangco> we havent even seen breezy
[03:03] <mdke> its us that raised the question, not him
[03:03] <mdke> i think a month is reasonable for both things
[03:04] <trickie> agree... meaning if it is the last month it will cause some havoc possibly
[03:04] <hypatia> OK.
[03:04] <hypatia> Anything else for point 2?
[03:04] <Burgundavia> nope
[03:04] <jsgotangco> none at this moment for me
[03:05] <hypatia> ok, point 3.
[03:05] <hypatia> web portal.
[03:05] <Burgundavia> http://www.ubuntulinux.org/wiki/DocTeamWebPortal
[03:05] <Burgundavia> everybody read it?
[03:05] <trickie> at which point i have to bow out i am afraid
[03:05] <mdke> the main question here IMO is that 
[03:05] <trickie> sorry... see ya later
[03:05] <jsgotangco> i havent sorry
[03:05] <hypatia> trickie: good night.
[03:05] <froud> later
[03:05] <mdke> we need to ask sabdfl is he is willing to throw some devels at this question
[03:05] <hypatia> jsgotangco: it's very short, can you have a look?
[03:06] <mdke> hence it needs to be thrown into the melting point at UDU i think
[03:06] <jsgotangco> just finished ok im game
[03:06] <froud> well I have a Lnya working very well
[03:06] <hypatia> so, jeff waugh told me that we could follow up through him and he can tell us the next step in pushing the proposal through to Canonical to see if development could be funded.
[03:07] <mdke> hypatia, cool
[03:07] <froud> hypatia: the only question her eis how much development is needed
[03:07] <froud> and how long will it take
[03:07] <jsgotangco> if the whole system is good enough for them, there needs version control then for all the stuff to be done in the portal
[03:07] <Burgundavia> gah
[03:07] <mdke> froud, did you say that you had a working solution?
[03:07] <Burgundavia> anyway, anything I miss?
[03:07] <mdke> Burgundavia, i'll PM
[03:08] <froud> yeah
[03:08] <hypatia> froud: do you have any sense of the numbers at all?
[03:08] <Burgundavia> mdke, cheers
[03:08] <froud> not yet
[03:08] <froud> I tried Docbook Wiki and it was hopeless
[03:08] <froud> I tried Lenya and I am 90% there
[03:08] <mdke> can you describe how it works?
[03:09] <mdke> does it satisfy the points on that page?
[03:09] <froud> all we need is developers to extend the editors for structured authoring
[03:09] <froud> hypatia: I have no clue how much that will cost
[03:09] <mdke> given the problems we have on the wiki, we need a good way to enforce quality control
[03:09] <froud> covered
[03:09] <Burgundavia> mdke, rss watchlists
[03:10] <froud> covered
[03:10] <Burgundavia> mdke, the other issue is that there is going to be nothing but presentation docs in there
[03:10] <mdke> Burgundavia, that takes a certain amount of effort for lots of minor changes
[03:10] <hypatia> froud: it would probably take a couple of weeks to do a decent cost estimate unless someone who was already familiar with the code did it.
[03:10] <mdke> what are presentation docs?
[03:10] <Burgundavia> mdke, docs for the great unwashed
[03:10] <Burgundavia> not dev chatter
[03:10] <Burgundavia> and garbage like that
[03:11] <mdke> Burgundavia, yes i see
[03:11] <mdke> a doc appeared on the wiki the other day recommending users to delete files in /etc/init.d/
[03:11] <mdke> such as gdm
[03:11] <froud> Apache Lenya must also stand up against the security muster
[03:11] <Burgundavia> and it is java
[03:12] <froud> http://lenya.apache.org/index.html
[03:12] <froud> tomcat
[03:12] <froud> cocoon
[03:13] <jsgotangco> version control in wiki is good but access control is questionable for it may limit entry of prospective members
[03:13] <Burgundavia> anyway, mark didn't quote a price or a time frame, so lets throw this at him, and see what happens
[03:13] <mdke> we need something fairly concrete to throw at him
[03:13] <mdke> jsgotangco, agreed
[03:13] <hypatia> probably go through jeff.
[03:13] <Burgundavia> from extensive experience on WP, limit article creation to logged in people
[03:13] <Burgundavia> and let the anons play with the other stuff
[03:13] <froud> Burgundavia: I cant test if it will stand up to the pounding it will get
[03:13] <hypatia> he can probably doa reasonable job of deciding when it's concrete enough.
[03:14] <mdke> Burgundavia, problem is that logged in people regularly delete wiki pages
[03:14] <froud> I would like a sandbox system running at docteam.ubuntu.com
[03:14] <mdke> froud, +1
[03:14] <jsgotangco> nice idea
[03:14] <Burgundavia> mdke, limit that as well. The deleting thing is crap I have never seen at any other wiki
[03:14] <froud> Then let mark look at it and decide
[03:14] <mdke> Burgundavia, ok
[03:14] <Burgundavia> mdke, deleting should be a priv held by very few
[03:14] <froud> Dudes I must go to lnch with family. Cheers
[03:14] <mdke> froud, bye
[03:14] <Burgundavia> cya
[03:15] <jsgotangco> cya
[03:15] <daven> ttfn
[03:15] <Burgundavia> anything else?
[03:15] <Burgundavia> is 6am here and I need to sleep
[03:15] <mdke> that's it, but we need to compose one mail to mdz and one to jdub
[03:15] <Burgundavia> and one to the list about what we talked about
[03:15] <jsgotangco> hypatia are you going to UDU as well?
[03:15] <hypatia> jsgotangco: Monday only.
[03:16] <jsgotangco> right a holiday
[03:16] <hypatia> Burgundavia: I think that's about it.
[03:16] <Burgundavia> ok
[03:16] <Burgundavia> I need to crash
[03:16] <Burgundavia> good meeting
[03:16] <mdke> sweet dreams Burgundavia 
[03:16] <jsgotangco> hypatia recap at least?
[03:16] <hypatia> Burgundavia: and you and/or froud follow up the web portal with jeff waugh please?
[03:16] <hypatia> jsgotangco: of the meeting.
[03:16] <hypatia> OK
[03:16] <hypatia> so.
[03:17] <Burgundavia> hypatia, I will let froud, as I haven't played with it
[03:17] <hypatia> point 1:
[03:17] <hypatia> 1. Better communication between DocumentationTeam and Development Team
[03:17] <mdke> hypatia, on the list?
[03:17] <hypatia> mdke: I'll do it here now and on the list in the next 24 hours.
[03:17] <Burgundavia> morning/night/day all
[03:17] <mdke> cool
[03:17] <hypatia> mdke: you don't have to stay for the recap here :)
[03:17] <mdke> hypatia, i'll do the mail to mdz on point 2
[03:17] <hypatia> mdke: thanks.
[03:17] <mdke> hypatia, thank you
[03:17] <hypatia> We decided:
[03:18] <hypatia>  * having some of us monitoring the development list and keeping an eye out for relevant changes would be handy
[03:18] <hypatia>  * having developers inform us of relevant updates would be good to. The mechanism is yet to be decided, and the question of whether they'd do this only post-freeze or not should be defered to mdz
[03:19] <hypatia>  * an improved QA process /may/ be needed but deserves a lot more discussion
[03:19] <hypatia> Point 2:
[03:19] <hypatia> #
[03:19] <hypatia> Integration of DocumentationTeam needs into release freeze dates. MattZimmerman has asked for: 1) a list of items that we should be aware of which affect documentation (artwork? translations? desktop behaviour?), and 2) a conservative estimate of the time it would take to adjust for a change in one of those areas
[03:20] <hypatia>  * It was not clear whether i18n of screenshots or translation of text is more time consuming or difficult, and thus the order of string freeze and artwork freeze is unclear
[03:21] <hypatia>  * The consensus for time needed to integrate post-freeze changes was something on the order of a month.
[03:21] <hypatia> Point 3:
[03:21] <hypatia> Discussion of DocTeamWebPortal
[03:22] <hypatia> froud has liked Apache Lenya very much, and thinks that the addition of a structured editor would make it suitable for our needs
[03:22] <hypatia> development time needed is entirely unclear
[03:22] <hypatia> froud to follow up with canonical (???)
[03:23] <mpt> ok, bedtime for me
[03:23] <mpt> thanks hypatia
[03:23] <jsgotangco> it would be nicer if froud can do that before the 25th when all of canonical is there
[03:23] <hypatia> hmmm, can someone send me a log of the meeting?
[03:23] <mdke> sure
[03:23] <hypatia> I don't think I had xchat logging...
[03:24] <hypatia> mdke: ta
[03:24] <mdke> remind me of the addy
[03:24] <mdke> /msg
[03:24] <jsgotangco> we have boglot
[03:24] <hypatia> mpt: you're welcome, good night.
[03:24] <daven> http://irclog.workaround.org/
[03:24] <mdke> boglot is backwards tho ;)
[03:24] <hypatia> daven: thanks.
[03:24] <mdke> we also have: http://people.ubuntu.com/~fabbione/irclogs/
[03:24] <hypatia> ta
[03:24] <hypatia> I'm off, see you all around :)
[03:25] <hypatia> I'll post a summary to the list tomorrow.
[03:25] <jsgotangco> ok i guess this was a good meeting
[03:25] <jsgotangco> its only 9:30pm hehe
[03:25] <jsgotangco> ok
[03:25] <jsgotangco> thanks hypatia
[03:25] <hypatia> 11:30pm here :P