=== bradf_afk is now known as bradf_ === thunderstruck is now known as gnomefreak === asac_ is now known as asac === kirkland` is now known as kirkland [19:39] hello [19:39] the documentation team meeting is in 30 minutes rite? [19:50] saketh, in 10 now [19:56] huh? [19:56] oh [19:56] yeah [19:56] thanx [20:00] ok, this is the Documentation Team meeting [20:01] yup yup [20:01] it's going to be a lot of stuff to cover, so we're going to have a make an effort to keep the discussion nice and focused [20:01] yeah [20:01] before we being, for the record of the IRC chat, can you repost the link to the agenda [20:02] sure [20:02] I think we should use the MootBot to help facilitate that, and to collect meeting notes [20:02] huh? [20:02] ok [20:02] anyone object? [20:02] second [20:02] no objection [20:02] how use moobot? [20:02] second, no objection [20:02] saketh: don't worry, I'll explain [20:02] ok [20:02] tahnx [20:02] is MooBot documented? haha [20:03] #startmeeting [20:03] Meeting started at 14:03. The chair is mdke. [20:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [20:03] ok... [20:03] now... [20:03] how use? [20:03] so, I'll try and handle the topics and people can just discuss them normally [20:03] ok [20:03] got it [20:04] if someone wants to formally record an idea for the notes, please preface the statement with [IDEA] [20:04] ok [20:04] the meeting agenda is here: https://wiki.ubuntu.com/DocumentationTeam/MeetingAgenda [20:04] ok [20:05] Phil Bull may not be able to attend - he sends his apologies but he has been caught without irc access [20:05] ok [20:05] [TOPIC] Introduction of team members [20:05] New Topic: Introduction of team members [20:05] i gotta go do a chore for mom real quick [20:05] brb [20:05] let's find out who's here :) [20:06] I'm here. [20:06] Evening [20:06] I'm Matthew East, I tend to take care of the administrative side of the team's activities, such as uploading packages, translations and the website [20:06] ok i m bak [20:06] the wiki agenda calls for a brief introduction of what people do and their interests, so shoot :) [20:07] Hi, I'm Cody Somerville. I'm the Xubuntu Project Lead and also a member of the doc commit group. [20:07] John Haitas, new member to the ubuntu-doc mailing list. Aspiring member to the Documentation Team. [20:07] I'm Dougie Richardson, I predominantly work with Internet and Networking and a member of the commit group [20:07] I m saketh kasibatla the only person in here who is still in high school [20:08] btw i m new [20:08] I'm Kelvin Gardiner I'm new to the team and looking to help with the 9.10 install guide and new to Ubuntu docs [20:08] btw i wanna help with xubuntu docs [20:09] I"m Marc Kaplan and I'm on the Wiki Team, of which the levels were on I think for discussion later in the meeting....One of my central focuses is streamlining, organizing, updating/removing outdated info [20:09] I would like to contribute to areas in particular need of attention. I have bee working on WebKit, Chromium, MATLAB, Programming, and VMware [20:09] Hi Everyone. My name is Mike Matis. I run the IT Dept. of a very small college on the east coast of the US (Maine). I've used Ubuntu since Edgy. Started out with Mandrake, then Slackware in 2000. I joined to help with the new ubiquity help files - specifically the partitioner. [20:10] I have been using ubuntu since 2006 (Dapper) [20:10] mfitzhugh: just doing some brief introductions at the moment [20:10] ok i gotta go do more chores again... [20:10] srry [20:11] saketh, afk or brb would be sufficient [20:11] ok, let's move on to the first agenda item [20:11] Hi - i'm new to ubuntu, but am finding it a great way to combine interests in writing and tech. [20:11] [TOPIC] Decide about placement of documentation branches within Launchpad [20:11] New Topic: Decide about placement of documentation branches within Launchpad [20:12] I prepared a summary of this issue here: https://lists.ubuntu.com/archives/ubuntu-doc/2009-April/012733.html [20:12] ok [20:12] ok [20:12] srry [20:12] let's take a moment to review the link before proceeding....for those who have not had a chance to do so yet....if there are no objections... [20:12] yes, certainly [20:13] Has anyone got any strong feelings one way or the other? [20:14] i think that its pretty good rite now [20:14] as it is [20:14] I'm a fan of keeping like materials together [20:14] I have a slight preference for the single project scheme, for the reason I've expressed on the mailing list [20:14] but it took a while for me to figure out how to get the doc source... [20:14] but maybe thats just me [20:15] saketh: yes, you joined at a time where we have inconsistent placement of our docs; that's what we're working on at the moment [20:15] ok [20:15] Of the "pros" I don't see any significant advantage other than the second point [20:15] sorry to be a pain [20:15] this is not a discussion to differencite the docs of the different flavors, just the packages within the flavors, correct? [20:15] yup [20:16] technomensch: it's about where we store the documents of different flavours on Launchpad [20:16] How useful will point 2 of the Pros be? [20:16] afk [20:16] There is something to be said for simplicity, but good docs could make that a less important point. [20:16] Of the "cons" I don't agree with the divergence issue so that only leaves an increase in house keeping [20:17] Good "getting started" with the docs team I meant [20:18] I am not going to weigh in either way. I am too new to do so in an informed manner. [20:18] mfitzhugh: yes, the main problem is the lack of consistency at the moment, I'm sure that we can properly document either approach, as long as we pick one [20:18] it's essential that we pick one, IMO [20:18] cody-somerville: any thoughts on the summary I posted? [20:18] I certainly have some comments on the topic [20:19] I apologize for not being able to articulate a reply yet [20:19] I've been very busy with the recent release as well as with work. [20:19] However, IIRC, you said that you're open to the idea of trying the project group approach? [20:20] If thats the case, I'd very happy to help facilitate that. [20:20] no worries cody, even after all this time, i'm still trying to wrap my head around how launchpad works because I haven't had the time to sit and read through our documentation.... [20:20] Could someone provide some background as to why the current arrangement is a problem? [20:20] same here [20:20] Depends on what we consider the "current arrangement" [20:20] matt, for those new, a quick launchpad lesson might be in order [20:21] gracias [20:21] technomensch: did you read the first bit of my post on the mailing list? [20:21] 4th and 5th paragraphs [20:21] yes....I have it open in a window next to this chat session [20:22] does that not help? [20:22] does the current method have some sort of Version Control System? [20:22] cody-somerville: do you happen to know whether Launchpad will support branches on packages any time soon? [20:23] mdke, Its definitely in the work [20:23] presumably it's essential for the plans to host all Ubuntu source in bzr [20:23] It is [20:23] any idea of timescale? [20:23] Difficult to say when it comes to launchpad [20:23] Priorities get shifted frequently [20:24] so what u wanna decide about is to keep seperate projects for say ubuntu and kubuntu docs [20:24] vs [20:24] one project with different branches... [20:25] rite? [20:25] yes [20:25] Its a little bit more complicated than that [20:25] ok [20:25] But thats the basic premise [20:25] mhm [20:25] afk [20:25] I happen to disagree with that concept, but I can see why we would need to wait for branches to be available [20:25] cody-somerville: I've been looking at some group projects recently, and they strike me as rather disorganised - I'm not convinced they would improve the organisation of our branches at all [20:26] if you look at these pages: [20:26] https://code.launchpad.net/mozilla [20:26] The Launchpad paradigm is that each project (previously called product) is related to a distinct codebase [20:27] All of the features available to projects and all future features resolve around this paradigm [20:27] mhm [20:27] and [20:27] https://launchpad.net/bazaar/+milestones [20:27] you get the idea that things could get horrendously out of sync [20:27] I think that is a grave understatement [20:28] Those are some very messy examples [20:28] that's why I chose them [20:28] so the mozilla part of launchpad is what we want to be like? [20:28] But lets consider if all those projects were just one project [20:28] Would the situation be any different? [20:28] Those views would be the exact same regardless if we're one project or many [20:28] well, not the milestone page [20:29] it's messy like that because each project has got out of sync with its releases [20:29] mdke, We could prevent that by having an agreed set of milestones [20:29] mdke, Or asking launchpad to allow us to share milestones [20:29] I don't really buy the "This is how LP intends us to work", because really, LP intends group projects to be for separate projects with no shared code [20:29] we do share code, and in fact, we should share a lot more than we do [20:29] I've spoken with the launchpad team [20:30] It is their opinion IIRC that project groups would be exactly what we're looking for [20:30] does launchpad allow for webpages like a sourceforge page? [20:30] No [20:30] The biggest features that I'm looking to enable flavours to take advantage of are series [20:30] cody-somerville: it depends on how you define "what we're looking for" [20:31] Especially so with the Xubuntu docs unable to take advantage of the traditional translation support provided by soyuz+rosetta with the Xubuntu docs being in the universe component. [20:31] I still believe that centralizing the code is one step closer to centralizing the flavors, whether anyone see is it or not, and that is something I am in favor of. I know that's a discussion for another time, but it is something to consider.......cont'd [20:31] Centralizing the code really has nothing to do with having separate projects [20:31] imagine all of the docs together, and each flavor merely referrencing the need for that area. [20:32] Regardless of how we set this up, all branches will continue to be owned by the same team [20:32] cody-somerville: what's the reason that you used a different team as the project driver when you set up the xubuntu-docs project? [20:32] mdke, Let me take a look [20:32] keep in mind that the mozilla project is not an good exemplar on which to base a decision... i don't believe launchpad is the primary base for the mozilla project [20:33] pace_t_zulu: that project is used primarily for code developed by Ubuntu developers who work on Mozilla products for Ubuntu [20:33] Mozilla don't use it, you're right [20:34] correct me if i am wrong, but we are talking about making Launchpad the primary base for all Ubuntu documentation activity [20:34] it already is [20:34] we are talking about the docbook code used to make our actual documents, [20:34] it's just a technical structural point [20:34] the ones that come in the help for the distro and are available on help.ubuntu.com [20:34] mdke, I believe I set it to that team to simply affiliate that team with the project. Since we don't use advantage of bugs for the project, I don't think it affects any permissions or anything of the sort. With the same team being the maintainer, the core doc team retains the same rights and privileges. [20:35] * cody-somerville didn't type that very well. [20:35] mdke and cody, can you two possibly back-track and redefine that for the rest of us [20:35] apologies for my comments... like I said before, being new it is hard for me to appreciate the nuances of this discussion [20:35] Would setting the driver to the doc team again would alleviate the second con that mdke stated? [20:36] no, we'd still have to maintain the series separately [20:36] but it would make me happier :) [20:36] I have no problem changing that [20:36] so here's a proposal [20:36] is the driver the admin of the group of docs for that particular project? [20:36] technomensch, no [20:36] mdke: then we have a potential for compromise - does xubuntu need this change [20:37] cody-somerville: sorry that was meant for you, would this change improve xubuntu's processes [20:37] [IDEA] we try the separate project (with group project) approach for six months, and reevaluate the position after karmic is release. The setup and team management of the projects should be identical for each, and the releases and official branch structure should be identical [20:37] IDEA received: we try the separate project (with group project) approach for six months, and reevaluate the position after karmic is release. The setup and team management of the projects should be identical for each, and the releases and official branch structure should be identical [20:37] +1 [20:37] mdke, I think thats a great idea [20:37] +1 [20:38] If it doesn't work then by all means lets re-evaluate and change it back if we feel that to be best [20:38] +1 [20:38] so how does voting work on MootBot? [20:38] [AGREED] [20:38] for six months, I'm game to at least see it in action. I ebleive that all good ideas should at least be given a chance [20:38] +1 [20:38] +1 [20:38] DougieRichardson: this isn't a vote at the moment, but express your opinion anyway [20:38] +1 [20:38] :) [20:39] [AGREED] we try the separate project (with group project) approach for six months, and reevaluate the position after karmic is release. The setup and team management of the projects should be identical for each, and the releases and official branch structure should be identical [20:39] AGREED received: we try the separate project (with group project) approach for six months, and reevaluate the position after karmic is release. The setup and team management of the projects should be identical for each, and the releases and official branch structure should be identical [20:39] [ACTION] mdke and cody-somerville to follow up and make the changes in Launchpad [20:39] ACTION received: mdke and cody-somerville to follow up and make the changes in Launchpad [20:39] mdke: apologies for misuse of MootBot [20:39] pace_t_zulu: :) [20:39] w8 so what is this all about again? [20:39] Democracy in action - is almost worth missing a barbeque [20:39] to quote jed bartlett "what's next?" [20:39] we will post the meeting notes to the mailing list first, to see if anyone not present now has any objections [20:40] ok [20:40] the next agenda item [20:40] ok [20:40] [TOPIC] Clearer identification of tasks - please see the meeting agenda for detailed explanation of this topic [20:40] New Topic: Clearer identification of tasks - please see the meeting agenda for detailed explanation of this topic [20:41] Meeting Agenda: https://wiki.ubuntu.com/DocumentationTeam/MeetingAgenda [20:41] so this is about who fixes submitted bugs in the docs and the like rite? [20:41] thanks pace_t_zulu [20:41] Can we please include wiki tasks in this discussion? [20:41] mdke: you're welcome :) [20:41] or would that complicate matters? [20:41] technomensch: yes, let's discuss those too, although different considerations could apply so we'll talk about them shortly [20:42] the idea comes from the fact that the Tasks page for SystemDocumentation quickly gets out of date [20:42] [LINK] https://wiki.ubuntu.com/DocumentationTeam/MeetingAgenda [20:42] LINK received: https://wiki.ubuntu.com/DocumentationTeam/MeetingAgenda [20:42] and we find it difficult to keep up with it [20:42] if we use bugs exclusively to manage our tasks, I think that it will be better organised [20:42] [LINK] https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Tasks [20:42] LINK received: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Tasks [20:42] i guess [20:43] I propose the use of a tags and an explanatory page on the wiki [20:43] the bug list is quite disorganised, so we'll need to ... [20:43] second that [20:43] what DougieRichardson said :) [20:43] I agree that we should use bugs, however, I think that it could get messy on the mailing list..... [20:43] technomensch: go on [20:43] a lot of students ask for suitable bugs to start on so I propose a "low hanging fruit" one [20:43] for ppl like me... [20:44] technomensch: agree a small subset and adhere to them? [20:44] if each bug goes to the mailing list, not everyone would need it [20:44] DougieRichardson: second [20:44] Taggin makes great sense because you don't have to always update the wiki to add new starter bugs [20:44] and for more experienced ppl, the tougher bugs [20:44] I don't think we should outline all the possible bugs tags here and now [20:44] it will take a bit of time, so I'd suggest that we prepare them and then discuss on the mailing list [20:44] I think that if we have bugs, then we might want to consider a doc-bug list [20:44] technomensch: bugs don't go to the mailing list [20:45] they dont? [20:45] no [20:45] then where do they go? [20:45] btw i sent a bug fix 4 bug 358447 [20:45] to the people who subscribe to them [20:45] and it hasnt [20:45] been commited yet... [20:45] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/358447/+text) [20:46] brb phone [20:46] ok [20:46] saketh: can we stay on topic :-) [20:47] sorry [20:47] i m a bit hyper today [20:47] too much sugar [20:48] good to see you sommer [20:48] hey, sorry for being late [20:49] Hi sommer, my name is John Haitas. I am new here. [20:50] hi sommer [20:50] i m saketh [20:50] kasibatla [20:50] newbie extrordinaire [20:50] DougieRichardson: By tagging, do you essentially mean replacing the text on the tasks page with links to corresponding bugs in launchpad? [20:51] mmatis: could do, but at least a clear description of what to look for - so say you wanted a straight forward bug to start on the wiki page would point in the right direction [20:52] got it [20:53] DougieRichardson: so u mean that say i wanted a bug related to xubuntu, id look for a bug tagged xubuntu [20:53] saketh: there's already a link for that at the top of the current page [20:53] ok [20:54] sorry to be a pain [20:54] Can bugs in LP be marked as "good for new people" as gnome do on their tracker. [20:54] saketh: but if you wanted to know where to start out, new to the process then you could click say low hanging fruit and get a list of bugs that are relatively easy [20:54] oh yeah [20:55] kelvingardiner: that's what we're proposing [20:55] i get that... [20:55] we've always used the term "low hanging fruit" [20:55] ok [20:55] Okay, its been about an hour now. I'd like to suggest we start wrapping up and make plans for another meeting since there is lots to still discuss. [20:55] ok [20:56] so... how bout next sunday [20:56] next sunday is mothers day in the us [20:56] oh [20:56] i dont really pay attention to holidays [20:56] next weekend is not good for me either - I've other team meetings [20:56] even if they happen to be where i live... [20:56] ok... [20:56] it's too soon [20:56] how bout the week after then? [20:56] I'd like to cover at least another issue this evening if people can [20:57] I'd prefer to push on [20:57] +1 [20:57] when do u suggest? [20:57] I've moved stuff aside for this [20:57] As have I [20:57] ditto [20:57] when? [20:57] considering how long we've been trying to have this meeting....at least 6-8 months, if not longer, I think an hour isn't enough time [20:57] ok [20:58] thenn [20:58] i think we have a fair proposal for the point in hand anyway - devise a defined set of tags and apply them [20:58] i have about 2 hours free after aout 5 hours [20:59] yes [20:59] DougieRichardson: +1 [20:59] I think we're agreed on that one, lemme do something for the bot [20:59] +1 [20:59] DougieRichardson: +1 [20:59] mdke: may I? [20:59] +1 [20:59] DougieRichardson: it's limited to the person who started the meeting [20:59] ::zing::: [20:59] DougieRichardson: would you be prepared to have a go at the first draft of bug tags to use [21:00] mdke: Yes - I'm getting back in my box now ;-) [21:00] DougieRichardson: it's just a limitation of the bot [21:00] oh i got an idea [21:00] instead of tas [21:00] just rate each bug on a scale of 1 to 5 [21:00] 5 being most difficult [21:01] saketh:that's too subjective and all that would happen is people would use 1,3 and 5 IMHO [21:01] ok... [21:01] saketh: -1 [21:01] there are already priority to the bugs and we are adding tags on top of them [21:01] DougieRichardson: +1 [21:01] [ACTION] DougieRichardson to draw up list of bug tags to be used for identifying tasks, and to discuss on the list [21:01] ACTION received: DougieRichardson to draw up list of bug tags to be used for identifying tasks, and to discuss on the list [21:01] just wanted to throw out the idea... [21:01] DougieRichardson: is that ok? [21:01] mdke: yes [21:02] great [21:02] thanks [21:02] [TOPIC] Discussion of https://wiki.ubuntu.com/DocumentationTeam/Organization [21:02] New Topic: Discussion of https://wiki.ubuntu.com/DocumentationTeam/Organization [21:02] I'd really like to get this item sorted out so that we can clarify the group structure and have a clear picture for new people joining the team [21:02] do people have any specific thoughts on the page? [21:03] did you want to include the ability for submitting fixes in plain text into this discussion? [21:03] for the contributors [21:03] mdke: I agree that it is unclear, being one of these "new people" [21:04] isnt there a group for students also [21:04] technomensch: ideally I'd like to limit the discussion to the team structure, obviously that point is a good one too but separate [21:04] or is that gonna be done away with... [21:04] Happy with the proposed structure [21:04] The "join the Ubuntu Documentation Contributors team on Launchpad" link is broken [21:04] ok... [21:04] I assume we're essentially replacing the word student with contributer? [21:04] @dougie: I would hope so [21:04] mmatis: it's not created yet - the page is not yet finalised [21:05] DougieRichardson: that's the idea yes [21:05] I found having different names on LP a bit confusing at first. [21:05] I think if we break it up in this fashion, we should not only make a clear distinction of who is at which level.... [21:05] but also what their specialitiy is [21:06] OK then it seems concise to me - the contributers is open and the committers/wiki admin is not [21:06] I have been unable to join the team. [21:06] as in, who to go to for what [21:06] technomensch:+1 [21:06] how would one do about beconing a commiter from a contributer? [21:06] technomensch: +1 [21:06] saketh:that's the next item [21:06] oops [21:07] dougie: thanks [21:07] technomensch: +1 [21:07] saketh: it's explained on the page, I hope - that's the whole point of the page! [21:07] technomensch: +1 [21:08] technomensch: could you give an example of what you have in mind? You'd have in mind identifying individuals? [21:08] for example, earlier we were talking about cody and xubuntu....then there is sommer and the server guide......, etc.... [21:09] yes know that is their role as an ubuntu member [21:09] but not all new doc team members might not know where to find the data [21:09] so, contact people for each particular sub-project, basically? [21:09] I think that a question directed to the ML will get to the right person [21:09] I agree with DougieRichardson [21:09] might be a good start, that was one of the things I did when I modified /Teams [21:09] the other potential issue with identifying people in that way on the wiki is that things tend to get out of date quite quickly [21:10] I thought you meant that if someone was a Wiki Admin then that identifies them, say on IRC as the one to ask about a wiki issue [21:10] we have a lot of wiki pages :) [21:10] dougie: that too [21:10] yeah... [21:10] dougie: I was getting there [21:10] :) [21:10] so pointing to the Launchpad teams is probably the most easy to maintain solution [21:10] but I can see the advantage of documenting who is primarily involved in different parts of the project [21:11] so... different teams for different levels? [21:11] mdke, can that be maintained on launchpad as well? [21:11] technomensch: I can't immediately think of a way to do it [21:11] i don think so... [21:11] technomensch: also, I'd personally like to encourage people to mail the list [21:11] because that way, if sommer doesn't happen to be around for a server guide issue, someone else can answer [21:12] given the lack of a maintainable LP solution and the transience of the wiki, I vote to stay with the ML for this aspect of identifying [21:12] valid points [21:12] just an fyi there are other server team members on the doc list as well [21:12] sommer: sure thing [21:12] sorry sommer, it was just an example [21:13] we do need to give the other members the credit they deserve though [21:13] sommer: but you've done the most awesome work with the serverguide recently :) [21:13] ::applause::: [21:13] thanks :) [21:13]