=== maskie [~maskie@196-30-109-1.uudial.uunet.co.za] has joined #ubuntu-meeting === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-meeting === HiddenWolf [~hidden@136.121.dynamic.phpg.net] has joined #ubuntu-meeting === Simira [~simira@56.80-202-210.nextgentel.com] has joined #ubuntu-meeting === froud [~froud@ndn-165-147-115.telkomadsl.co.za] has joined #ubuntu-meeting === Burgundavia [~corey@24.68.134.11] has joined #ubuntu-meeting === mpt [mpt@210-55-179-107.dialup.xtra.co.nz] has joined #ubuntu-meeting === mpt [mpt@210-55-179-107.dialup.xtra.co.nz] has left #ubuntu-meeting [] [12:59] time [12:59] froud, another hour [12:59] ;) [01:00] its 11 UTC [01:00] nah [01:00] yah [01:00] Current UTC (or GMT/Zulu)-time used: Sunday, April 17, 2005 at 11:00:21 === jsgotangco [DaWorm@81-nas1.dial-pool.digitelone.com] has joined #ubuntu-meeting === trickie [~trickie@203-173-47-188.dyn.iinet.net.au] has joined #ubuntu-meeting === mpt [mpt@210-55-179-107.dialup.xtra.co.nz] has joined #ubuntu-meeting [01:59] ok [01:59] who is the chair [02:00] mary organised the meeting [02:00] yep, is Mary here [02:00] not yet [02:00] ok [02:00] I am now logging === mdke points at boglot :) [02:01] hey, take a look at this idea: [02:01] http://img107.echo.cx/my.php?image=help2ui6ja.png [02:02] Burgundavia: nice suggestion [02:02] by default, it woudl show common things [02:02] and when they searched, it would reorder itself [02:02] very simple ui [02:02] would beagle be part of breezy [02:03] jsgotangco, that is the plan [02:03] but this would be a standalone app [02:03] I just used beagle as a look example [02:03] Gnome only [02:04] is the backend desktop neutral [02:04] someone could right a qt frontend [02:04] it is daemon and frontend === froud thinks we should take this back to channel until mary arrives [02:04] we might as well talk here [02:05] not sure everyone else not docteam is interested [02:05] and it would be better to capture it under our weblog etc [02:05] true [02:05] ok [02:05] am going to flood #ubuntu-doc with this talk === hypatia [~mary@adsl-66-203.swiftdsl.com.au] has joined #ubuntu-meeting [02:08] ok hypatia will you lead? [02:08] yeah sure. [02:08] gimme 2 minutes [02:09] game [02:10] OK, doc team meeting as per https://www.ubuntulinux.org/wiki/DocteamNextIRCMeeting [02:10] who's here? [02:10] present [02:10] me [02:10] ! [02:10] yeppers [02:10] tadaaa [02:11] me [02:12] yay. [02:12] So, agenda item #1. [02:12] Better communication between Documentation Team and Development Team [02:12] we got good feedback from mdz on this [02:12] As I recall, this came up after the late addition of new spatial behaviour to nautilus. [02:12] 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] ie way to late to document and translate the documentation. [02:13] he mentioned that the dev team is willing to create an artwork freeze [02:13] such freezes should be well planned though [02:13] so we have 2 issues here [02:13] and incorporate our feedback into freezes in general [02:13] 1. artwork [02:13] 2. features [02:13] But is artwork a real problem? [02:13] no its not [02:13] feature are a problem [02:14] why not a real problem? [02:14] artwork is a professional issue [02:14] froud: the concern was screenshots looking exactly like a default desktop. [02:14] its a shame if our screenshots look unprofessional [02:14] I agree that features are more of a problem. [02:14] ie. our quickguide looks like crap because it does not look like hoary [02:14] but artwork is easily fixable [02:14] so we want to recapture all screen shots every release? [02:14] i think so yes [02:14] froud, if the artwork changes, then yes [02:14] but features that make what we say in the docs is wrong is worse than inconsistent artwork [02:14] we can always say that we're using a pre=release version [02:14] but I would also like the doc screenshots to mirror a default desktop perfectly if possible. [02:14] trickie, agreed [02:15] that is lot sof overhead [02:15] which would mean no late artwork changes. [02:15] "Objects in mirror may be newer than they appear." [02:15] so when do we want the artwork freeze to be? [02:15] the screenshots shouldn't take too long to recapture, given a reasonable freeze [02:15] chaps in i18n are gonna scream [02:15] for the quickguide it shouldn't be too bad [02:15] froud, i don't think so, they just do the words [02:15] other docs it becomes an issue [02:16] especially to what were planning on [02:16] the visual stuff [02:16] remember we have captures for each language [02:16] anyway, the point is, when do we want the artwork to freeze? [02:16] froud, yeah but we will have to do them all [02:16] in each language [02:16] afaics [02:16] perhaps we can capture without the window [02:16] well if we are going to have consistent artwork across langauges the freeze will have to be before string freeze [02:17] trickie, can it not be at the same time> [02:17] do we have a definite time line at the moment for breezy [02:17] maybe we can refer to that [02:17] Burgundavia, yeah you are... same thing [02:17] jsgotangco, no they will define it at UDU [02:17] hence this meeting [02:17] ok, when is our breezy string freeze? [02:18] breezy is october 2005, around the same time as warty [02:18] Burgundavia, they are reworking their plans at UDU, that is why mdz wanted our feedback [02:18] so that it could be put into the equation [02:18] how many weeks before release was our string freeze this time? [02:18] mdke: that is point 2 [02:18] froud, they are the same [02:18] we are still on point1 [02:18] are they [02:18] no [02:19] 1 is comms [02:19] well if we're talking about time needed for freezing, this is point 2 [02:19] I think the first one was also about creating some relationships between the doc team and the developers [02:19] yeah. [02:19] point 1 is communication. [02:19] let's get that out of the way. [02:19] lets focus on that then [02:19] have we decided on a date or at least a 'weeks before' timeframe? [02:19] we have established flow and coms with i18n processes [02:19] Burgundavia, can we leave that until we come onto point 2? [02:20] sure [02:20] for devels we need interaction [02:20] so, re point 1, trickie has agreed to try and interface a bit with the devel team. [02:20] we need note of updates [02:20] in terms of communication, we can't do much more than encourage them to let us know when major changes occur [02:20] 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] trickie: can you summarise your plans again? [02:20] 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] I agree with mdz [02:21] mdke: but if we have people reading devel out of interest anyway, then they can help fill us in as a bonus. [02:21] I currently am subscribed to ubuntu-devel and breezy-changes [02:21] we need a single point [02:21] I agree that it would be a huge load *just* for this task,. [02:21] froud: a single point of what? [02:21] mabye a weekly report perhaps? [02:21] we need an rss feed [02:22] an rss feed of what? [02:22] probably easier to just forward a summary of each issue to the doc list [02:22] froud: I'm sorry, I'm not following. [02:22] Burgundavia, ++ [02:22] Burgundavia, +1 === daven [~davesheep@83.148.133.161.adsl.griffin.net.uk] has joined #ubuntu-meeting [02:22] as it happens, like [02:22] devs need to comm in a way that we get automatically and without much overhead to them or us [02:23] 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] froud: but what exactly do they need to communicate? [02:23] a weekly summary wouldn't be that much to them imo [02:23] froud: is there any (semi-)automatic way to determine docs relevant changes. [02:23] 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] like decisions made, changes made [02:23] I mean, above the beezy-changes list. [02:23] breezy-changes [02:24] where is it [02:24] 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] hypatia, not really [02:24] we need to feed off what is pertinentto us [02:24] froud: breezy changes is at http://lists.ubuntu.com/mailman/listinfo/breezy-changes [02:24] froud: but it is very high volume. [02:25] hypatia: I alrwady get a huge amount of mail [02:25] hypatia, froud breezy changes is the actual package change logs [02:25] 800 a day [02:25] Burgundavia: I know. [02:25] 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] I think we need a person to filter the devel list [02:25] we need to filter [02:25] I think monitoring breezy-changes is more than one person could do reliably [02:25] and then we need a devel to tell us when changes are made [02:25] Burgundavia, +1 [02:26] +1 [02:26] So do we want developers to be familiar with documentation of the packages they maintain? [02:26] so long as those persons are always there and consistant at doing it [02:26] or even ubuntu-specific documentation [02:26] have they even read our hoary docs [02:27] jsgotangco: I know some have in parts. [02:27] I see 2 levels [02:27] it would be nice if they did [02:27] 1. Desktops [02:27] 2 apps [02:27] I don't think it's reasonable to expect them to read the entire set of docs. [02:27] then we'd have to keep 2 changelogs [02:27] which is annoying [02:27] Another way to do it would be to have a QA effort for the docs [02:27] Go through them and check that the instructions still work [02:27] Treenaks, that would be too formalised i think [02:28] mpt, there is already going to be a dev qa, right after string freeze [02:28] right, a qa is a good idea. [02:28] mpt: how about proofreading by people who know a thing about writing style? [02:28] and then we freeze for translation. [02:28] Treenaks: I volunteer for that :-) [02:28] I think it might be easier, if right before string freeze, everybody tests the docs [02:28] I think we are underestimating the size ofthe problem and we are not looking to reduce the overhead [02:29] have a week set aside for that [02:29] instead we are increasing it [02:29] mpt: but one problem is convincing the dev team to stop making changes after the docs freeze. [02:29] yes [02:29] hypatia, the feature freeze should cover most of this [02:30] 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] so, to recap. [02:30] hypatia: we are a small team withmuch to do [02:30] the more admin the kless gets written [02:30] i also think the overhead being talked about is too much [02:30] there wasn't that much that came out wrong [02:30] froud: the latter then. [02:31] froud: do you think that present interaction with the doc team is adequate> [02:31] 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] I would like to find ways to automate as much possible [02:31] i don't think that is too much overhead, IF some people already follow that list for fun/other reasons [02:31] mdke, yeah i think monitoring is good also [02:31] froud: do you presently have any such ways to suggest? [02:32] froud, you can't automate communication [02:32] right, recapping. [02:32] introducing extra QA is not [02:32] Presently, suggestions are: [02:32] In part you can [02:32] 1. That we have monitoring of the development mailing list [02:32] we can do little bits of QA before committing instead of doing one whole QA session before freeze [02:32] 2. That the development team make an effort to inform us of documentation relevant changes. [02:33] 3. That the QA process be improved (somehow) [02:33] 1. +1 [02:33] why don't we delay the qa process, and discuss on the list [02:33] 2. How [02:33] the rest is good [02:33] 1,2, ++ [02:33] froud, I think the best we can do is ask them to do their best [02:33] 2. supposes they will [02:33] Burgundavia: I think a changed QA procedure will take at least another thread to nut out, don't worry about that. [02:34] I suppose they will not in most cases [02:34] Alright... [02:34] Imagine for a moment the best of all possible worlds. [02:34] froud, we can review in a month or two and give feedback [02:34] What would "notification from the devel team of changes" look like? [02:34] 2. i only expect mdz at the moment but hopefully it will improve [02:34] hypatia, a post to the list [02:34] saying what changed [02:34] an alert perhaps [02:34] mostly the thing we need notice of is UI changes [02:34] is there a list of all planned features/changes, that they could indicate a possible externals impact? [02:35] 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] daven, more will come out of UDU [02:35] sorry this is to loose for me, I think devels should create bugzilla's for documentation changes [02:35] froud, ugh, too much overhead [02:35] that's a good idea froud. [02:36] Burgundavia: who for, them or you> [02:36] the devels use bug trackers heavily [02:36] hypatia, both [02:36] the devels hate bugzilla [02:36] that is why they are developing malone [02:36] they can just use the current bugzilla perhaps [02:36] why don't we jump on malone? [02:36] So then we must be part of their bug system [02:36] Burgundavia: well, in a "best of all possible worlds" discussion you can ignore the overhead for them for the moment. [02:36] I dont care which [02:36] Burgundavia: what's the overhead for you? [02:37] hypatia, I find bugzilla to be very clunky and hard to navigate and organize info [02:37] hypatia, and very very rigid [02:37] Malone is hard to navigate too [02:37] you want every developer to consider what change to a package impacts on documentation in whatever slight way, and document that? [02:37] but I'm working on it [02:37] :-) [02:37] i think that is excessive [02:37] but they use it! [02:37] mpt, malone is being developed [02:37] Burgundavia: mpt is on the launchpad team... [02:38] Changes should have check boxes [02:38] hypatia, I know that [02:38] hypatia, sorry, that sounded rude [02:38] 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] if the doc checkbox is selected we get updates [02:38] anyway, the major changes we need are UI changes [02:38] Burgundavia: tis OK [02:38] froud, add doc-team CC? [02:38] yes [02:38] tight [02:38] not get lost [02:38] broadcast via our list [02:38] clear [02:39] trackable [02:39] I say we go for malone as our stuff is not that critical and malone is going to get better [02:39] OK, so from my 1, 2 and 3... [02:39] little overhead [02:39] inline to devel [02:39] "1. monitoring of devel list" seems to be pretty popular [02:39] mpt, malone "feels nicer" to use [02:39] integrated [02:39] 1. can do but not reliable [02:40] 1. can do but same... not consistently [02:40] hypatia: I would like o see processes integrated and sustainable [02:40] "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] 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] +1 [02:40] 2. Malone sounds good, and if we could get something like the checkbox froud talked about that would be better [02:40] bugzilla doesn't really track new features [02:40] "3. That the QA process be improved" is considered a big job and is deferred to the mailing list. [02:41] mdke: OK, that seems fair. [02:41] +1 [02:41] So 2a "Devel team to inform documentation team of updates after freeze" [02:41] 2. Devel team to notify of changes primarily to the UI of programs [02:41] "made after freeze" [02:41] hmmm why is that it is their software creation in the first place [02:41] before freeze is nice too [02:42] Burgundavia, it may be nice, but its our job to monitor that, not theirs IMO [02:42] at anytime [02:42] I don't think we should limit ourselves to after freeze [02:42] create a habit [02:42] 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] if suddenly you intro a new thing mid way they will not do it [02:42] id prefer notification anytime that impacts the whole docs [02:42] Well, how about we take that to mdz and ask which is feasible: [02:42] daven, i'm not sure it is that simple, but then again I'm not a developer [02:42] daven,froud, I think you overestimate the usage of bugzilla by the devs [02:42] after freeze only, after freeze and before where possible, always. [02:43] Burgundavia: what do they use [02:43] they use their heads [02:43] froud, most of the stuff comes down from gnome [02:43] and UPSTREAM [02:43] Burgundavia: we need to be in their process and cycle [02:43] I think the devels use bugzilla for bugs. [02:43] froud, and the team is very small [02:43] 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] all major system changes come from upstream [02:43] froud, there heads and #canonical I would guess [02:43] For features and planning they use the wiki/the mailing list/irc. [02:43] s/there/their [02:43] The "Masters of the Universe" are currently using Malone, the rest using Bugzilla. [02:44] OK, so are we ready to wrap up point 1? [02:44] hypatia, yes [02:44] ok by me [02:44] i think we should, this meeting was called for point #2 mainly, due to the urgency of doing it before UDU [02:44] but we also need to deal with point #3 before UDU [02:44] 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] right. [02:45] OK, point 2. [02:45] +1 [02:45] sounds good [02:45] worksforme [02:45] there's actually 2 subpoints, so let's deal with them in order. [02:45] point 2a. [02:45] a list of items that affect documentation [02:46] artwork, UI changes of other kinds [02:46] can be added to teamstuff in svn [02:46] any other ideas? [02:47] think we will have to think on this list [02:47] yeah. [02:47] ok [02:47] but let's do what we can with those suggestions. [02:47] what is 2b? [02:47] 2b is the amount of time necessary for us to adapt to late changes in the things listed in 2a [02:47] Burgundavia: if one of these areas (artwork etc) changes, how long does updating the docs take? [02:47] so, let's start with artwork. [02:48] hypatia, if the artwork changed, like hoary, we would need new screenshots [02:48] taking screenshots on en and i18n [02:48] we can obviate the artwork problem [02:48] i18n is a concern [02:48] dont capture window frame [02:48] screenshots without window frames [02:48] the major issue I see here is sabdfl [02:48] nah [02:48] Burgundavia: with the artwork, or with timing in general? [02:48] but he recognizes the problem [02:48] we have a natural conflict here [02:49] he wants to keep the artwork until the last sec, so as not to spoil the party, which is natural [02:49] but we need it to document it [02:49] Burgundavia: just dont capture artwork [02:49] Burgundavia, not sure about that [02:49] Burgundavia, there was a time limit set for artwork, but it was late [02:49] froud, huh? [02:49] who thinks that screenshots without window frames is desirable? IMO it might be a shame to lose them. [02:49] but it may have more powerful advantages [02:49] On screen captures dont capture the frame [02:49] ick [02:50] I assume artwork is an integral part of the "Applications" menu though? [02:50] ie the icons... [02:50] I think most people wouln't understand [02:50] we dont use icons [02:50] and anyway, the artwork changes are deeper than that [02:50] explain [02:50] selection boxes [02:51] my question is [02:51] anything that could be themed, was [02:51] can a user use the instruction to accomplish a task [02:51] that takes precedence [02:51] Window titles can be important for that [02:51] I don;t see how truncated screenshots are going to help? [02:52] i think at the technical meeting mdz was perfectly happy to put in place a system where the artwork is frozen beforehand [02:52] mpt: if important include [02:52] ("Is this the right window, or not?") [02:52] yeah [02:52] we should at least put this forward at UDU, if sabfdl overrules it, then we can talk about solutions [02:52] if not dont [02:52] then we have inconsistent docs [02:52] and that looks even worse [02:52] mpt: intructions should be action reaction [02:52] do this [02:52] that is opened [02:53] no need for screencapt [02:53] much easier to explain with a screencap, but we digress [02:53] we are discussing artwork freeze dates [02:53] indeed we do digress. [02:53] Images need to be used sparingly [02:53] hmm in a stylish way, we'll have inconsistent screenshots [02:53] If they are going to include an artwork freeze then we should not take SS till then, otherwise we have option [02:53]