17:00:39 <ke4qqq> #startmeeting
17:00:39 <cs-meeting> Meeting started Wed Nov 14 17:00:39 2012 UTC. The chair is ke4qqq. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:39 <cs-meeting> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:55 <ke4qqq> #chair bhaisaab chipc edison_cs iswc jzb noe techpubs u-ichi
17:00:55 <cs-meeting> Current chairs: bhaisaab chipc edison_cs iswc jzb ke4qqq noe techpubs u-ichi
17:01:17 <chipc> hi all
17:01:26 <ke4qqq> ok - I like being contrarian, so we'll go in reverse order today - u-ichi have anything for the group?
17:02:29 <ke4qqq> ok - hearing nothing - techpubs you are up
17:03:07 <techpubs> ok
17:04:02 <techpubs> I am working on an estimate of total tech pubs outstanding requests, and the effort required to fulfill them
17:04:49 <techpubs> This to include not just doc bugs filed, but new docs and other improvements from the field & all interested parties
17:05:33 <chipc> probably a ton of work outstanding
17:05:51 <techpubs> Well, there are about 275 doc bugs, alone
17:06:14 <techpubs> A significant backlog caused by having only one writer on the project for years
17:06:14 <jzb> techpubs: huh?
17:06:17 <ke4qqq> I only see 38 open
17:06:18 <chipc> I assume that means in the bugs.cs.o list still?
17:06:31 <techpubs> Yes, please do count the bugs that were filed pre-apache donation
17:06:37 <techpubs> Most or all of those would apply in the Apache world.
17:06:41 <jzb> techpubs: there's a problem with that
17:06:46 <ke4qqq> they need to move to i.a.o
17:06:48 <jzb> techpubs: we're not working out of that bug tracker any more
17:06:53 <techpubs> Yes, yes I know
17:07:17 <techpubs> It's a lot of work to manually port 240 bugs from one base to another, and what I heard was: port them as you work on them, not en masse
17:07:32 <techpubs> Is that not correct?
17:07:47 <chipc> that was the agreement, yes
17:07:47 <ke4qqq> so two potential issues
17:07:57 <ke4qqq> 1. bugs.cs.o is going away at some point
17:07:59 <ke4qqq> and
17:08:12 <ke4qqq> 2. it means you get no help on the stuff there, as it's not visible to anyone else
17:08:24 <ke4qqq> or rather no one is looking there
17:08:41 <techpubs> Might not be looking there by habit, but it's certainly visible to all
17:08:54 <ke4qqq> for the moment, but bugs.cs.o is going away
17:08:59 <techpubs> I had two questions, basically, about this topic as a whole
17:09:08 <techpubs> Number 1:
17:09:10 <techpubs> I created a wiki page called "Suggestion Box" a little while ago, but not many new suggestions have been added to it
17:10:14 <techpubs> Is there another better mechanism for sounding people out in a worldwide community rather than announcing this wiki on list. Seems like a docs-specific IRC or ... suggestions?
17:10:35 <ke4qqq> why a suggestion box instead of a filing a ticket in the bug tracker.
17:10:38 <jzb> what's the suggestion box for?
17:10:58 <techpubs> OK, most people think a doc bug is for a typo or some other error
17:11:16 <techpubs> We had a long "wish list" of larger-scale requests, like "could you please make the API Reference better"
17:11:17 <chipc> jira items can be wish list things, improvements, bugs, tasks, whatever
17:11:50 <techpubs> People were not filing Jira items for these larger-scale requests, though. So I put them in a wiki for safe-keeping...
17:12:00 <jzb> I'd ask for a Jira ticket to be more specific than "make API docs better" but…
17:12:05 <jzb> most of this should go in Jira
17:12:08 <techpubs> Anyhow, this is just a question of record-keeping, I don't mind about where the ideas are stored...
17:12:26 <chipc> I think jira needs to be the system of record for specific items
17:12:34 <chipc> discussions belong on the dev list
17:12:43 <techpubs> The question is more about how to be sure we have elicited all the good suggestions, before we make the level of effort estimate, and get volunteers to do the actual work.
17:12:56 <jzb> techpubs: that's really not how open source works
17:13:03 <jzb> you do it as you go.
17:13:11 <jzb> you'll never elicit all the good suggestions
17:13:31 <ke4qqq> yes - volunteers work on what they want to work on - the rest doesn't
17:13:32 <jzb> judging by the Jira tickets and the suggestion page on the wiki, there's plenty of work to be done
17:13:34 <ke4qqq> happen at all
17:13:47 <techpubs> To rephrase then: To be sure most people are aware they are invited to make such suggestions;
17:14:05 <techpubs> And to try to get some sense of organization
17:14:33 <ke4qqq> it's also well nigh impossible to calculate other folks available time and throughput when you don't directly employ/manage them.
17:14:39 <techpubs> I know it's not top-down, but there's no reason it has to be chaos either
17:15:19 <techpubs> If I were a volunteer, I'd appreciate seeing the available projects with some notation like "We think this would take about 10 days of your time" vs. "25 days"
17:15:35 <ke4qqq> it's not chaos - it's the bazaar - people who want to get things done, get them done. it's self-electing responsibility.
17:15:35 <chipc> techpubs: suggestion then… how about you consider organizing what you know to be needed into "sprints", and ask for help in each sprint by specifying specific areas that each would cover
17:16:01 <chipc> if it gets folks to help, then awesome
17:16:03 <ke4qqq> the time involved completely depends on the 'volunteer' - what may be 5 minutes for jzb might be 5 days for me.
17:16:14 <techpubs> Yes, we did that with our XML conversion sprint, with fairly good participation
17:16:19 <techpubs> Ok, maybe I should move on to my second question
17:16:24 <jzb> the other way to ensure a bug gets fixed, if it's crucial is file a blocker bug
17:16:40 <jzb> if the community agrees it must be fixed for a release, then you'll see more participation
17:16:49 <jzb> (eg. the docs and the last release)
17:17:26 <jzb> but if it doesn't rise to that level, then chipc's sprint idea might be a good way to go.
17:17:40 <techpubs> Yes, that's exactly how a lot of crucial tasks get neglected, actually. Everyone is focused just on the next release.
17:18:02 <techpubs> I am hearing sprints are the way to go for extra-release-specific wans.
17:18:05 <techpubs> er, wants.
17:18:09 <jzb> yes
17:18:11 <techpubs> That's very useful, thank you.
17:18:15 <chipc> so then the potential solution is to elevate the focus, and be specific, given your knowledge
17:18:55 <techpubs> chipc: that's nicely put
17:19:22 <ke4qqq> yes - long term you want to grow the folks writing documentation - docs become part of the release cycle and it becomes a constant stream of people working on it as part of the project - because everything (including docs) is released at 'release'
17:19:58 <iswc> techpubs: fwiw, when kdamage and I put a request out there to the community for community written documentation about topics users found confusing, hard to understand, or not covered well we got zero responses but we field virtually the same questions in IRC on a regular basis
17:20:23 <jzb> iswc: when you field those questions does anybody put the answers anywhere other than IRC?
17:20:35 <ke4qqq> iswc: please file bugs then (and supply patches if you are feeling froggy)
17:20:36 <chipc> iswc - you guys would be great contributors to the official docs
17:20:45 <ke4qqq> chipc: agreed!
17:20:57 <jzb> +1
17:21:10 <iswc> jzb: kdamage and I have been putting them into a larger document.. most of them aren't really specific items about CS but that people have a hard time getting their hands around all of the terminology and how things tie together
17:21:22 <jzb> iswc: I've been working with kdamage a bit to try to get him contributing to docs w/patches, etc.
17:21:28 <jzb> iswc: happy to do the same w/you.
17:21:43 <jzb> iswc: where's the document?
17:22:32 <iswc> jzb: sounds good, we have some presentation stuff we have been working on for vegas as well as something more encompassing but there's a WIP of what we started a while ago that I'll get the link for in a sec
17:23:53 <iswc> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Example+Configurations & https://cwiki.apache.org/confluence/display/CLOUDSTACK/2012/09/13/A-CS+Post+Install+Architecture
17:24:24 <jzb> iswc: wow
17:24:47 <iswc> the CS Post Install is the collaborative document, the example host layout just really seems to help people their first time through because it provides examples and pictures to give people something to relate their install to
17:25:15 <chipc> iswc - you should work with techpubs to add this stuff to the formal docs!
17:25:18 <jzb> You guys are doing some great work
17:25:27 <ke4qqq> wow indeed
17:25:28 <iswc> chipc: happy to, I just wasn't sure how
17:26:00 <ke4qqq> that is a problem. - where did you look for figuring out how to contribute to docs?
17:26:53 <iswc> I sort of didn't... it originally started out as an effort to be helpful and then took on a life of its own and I wasn't really sure how it would tie into the current documentation since most of what's there is more of a "how to" and not really conceptual/design oriented
17:27:14 <techpubs> Most of what's in iswc's doc, at a glance, is already covered in the Admin Guide under "projects," "domains," etc. but we don't have the pretty diagrams
17:27:43 <iswc> techpubs: yeah, what's there was based on what was in the guide along with some of our own experiences
17:27:49 <techpubs> I like some of iswc's wording, too. Some of those admin guide sections were written by the early Cloudstack engineers 2+ years ago, in a big rush.
17:28:59 <techpubs> iswc: there is a "Doc Contributor's Guide" on the wiki, in case you need a pointer
17:29:08 <iswc> techpubs: not to detract from anything you guys had on the schedule but as an example in the admin guide for 3.0.5 where private gateways are mentioned it's a few sentences for something that actually has some pretty huge reprecussions (in a good way)
17:29:19 <iswc> techpubs: thanks, I'll check it out today
17:29:59 <ke4qqq> iswc: don't hesitate to ask us on IRC if that is unclear - you and kdamage have tons of real-world experience that we'd love to make use of.
17:30:09 <techpubs> Yes, getting good conceptual info and more meat on the bones is going to be an awesome outcome, I hope, of having >1 writer. Actually, we added writer #2 just before donation. I don't mean to overlook her!
17:31:01 <iswc> techpubs: awesome, and I know kdamage and I are going to continue to work on what we're doing which is to try and relate CS to some real-world installations and examples to make it easier for people to adopt and shorten the learning curve
17:31:17 <jzb> techpubs: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Documentation+Team+Status+Dashboard
17:31:28 <jzb> is this still being kept up?
17:31:40 <jzb> I think we would do better to keep track of Jira tickets / jobs by release.
17:31:42 * ke4qqq notes we are 30 minutes in
17:31:46 <jzb> ouch
17:31:53 * iswc goes to listening mode
17:31:57 <techpubs> Well, luckily, I have now forgotten my 2nd question
17:31:59 <jzb> perhaps we need to have a separate docs meeting?
17:32:10 <jzb> actually, there's no perhaps. I think we probably do.
17:32:13 <ke4qqq> jzb: perhaps - something to discuss on list
17:32:21 <jzb> K
17:32:27 <techpubs> jzb: I haven't updated the status dashboard lately, no.
17:32:38 <ke4qqq> noe: anything for us?
17:33:08 <ke4qqq> hearing nothing....mozg you are up
17:33:21 <mozg> yes, I am up
17:33:27 <mozg> listening to the discussion
17:33:50 <mozg> nothing to contribute yet
17:34:14 <ke4qqq> ok - thanks for coming - skipping myself as I am still catching up from 2 weeks of travel - jzb what do you have for us
17:34:38 <jzb> So - I'm going to RM the 4.0.x bug fix releases.
17:34:52 <chipc> applauds
17:34:57 <ke4qqq> woot!
17:35:01 <jzb> I need to get started on that - I'm pretty much buried with conference stuff today but will get started on that by end of the week.
17:35:07 <ke4qqq> timeline yet?
17:35:08 * jzb takes a bow
17:35:21 <jzb> ke4qqq: timeline for… the release date?
17:35:33 <jzb> I think we said on list mid-December
17:35:46 <jzb> so I'll put out a timeline that gives us a vote shortly after the conference.
17:36:14 <ke4qqq> sounds good
17:36:18 <ke4qqq> anything else for us?
17:36:21 <chipc> jzb: and the other difficult part will be getting some order (see Alex's email) around using Jira to decide what to pull
17:37:23 <jzb> Yeah. Being the first one out, we are going to have a lot of decisions to make about what goes in to the release and the process.
17:37:26 <jzb> It'll be fun
17:37:39 <jzb> otherwise - that's it for me right now.
17:37:48 <ke4qqq> awesome
17:38:00 <ke4qqq> iswc: what do you have for us?
17:39:22 <ke4qqq> taking silence as nothing - Gwyden have anything for us?
17:40:52 <ke4qqq> edison_cs: anything for us
17:41:21 <edison_cs> no
17:41:33 <techpubs> ke4qqq: I remembered my 2nd question, if we get time
17:41:38 <ke4qqq> cs-meeting and cloudbot have nothing for us - chipc ?
17:41:38 <cs-meeting> ke4qqq: Error: "and" is not a valid command.
17:41:39 <ke4qqq> ok
17:42:06 <chipc> well - looking for agreement on the latest 4.1 schedule proposal (thanks ke4qqq)
17:42:30 <chipc> but given none, I'll assume lazy concensus and start sending reminders at critical points
17:42:40 <ke4qqq> sounds good!
17:42:40 <chipc> that's all I've got
17:42:50 <ke4qqq> bhaisaab: around? have anything for us?
17:43:48 <ke4qqq> archetech2: anything for us?
17:43:52 <archetech2> I 2nd the call for a doc only meeting whenever possible thats all for now
17:44:08 <ke4qqq> awesome
17:44:24 <ke4qqq> techpubs: go ahead with second question
17:44:36 <techpubs> does jzb nominate himself to put out the request for a doc meeting? (that's not the 2nd question) Or shall I do so?
17:45:06 <techpubs> 2nd question is: Given this backlog of 275 bugs, and ke4qq's comment earlier "people do what they want, the rest doesn't get done"...
17:45:42 <techpubs> I think we do make sure certain things get done by making them high-priority bugs. By what process, then, will we decide which of the 275 are critical?
17:45:43 <jzb> #action jzb put out request for docs meeting.
17:45:54 <techpubs> sitting down and reading 275 bugs with a group of people via IRC sounds challenging.
17:46:09 <jzb> techpubs: that would be challenging
17:46:10 <techpubs> jzb: thanks
17:46:21 <jzb> techpubs: so how do we normally decide on severity?
17:46:26 <jzb> for other bugs
17:46:29 <chipc> techpubs: well, anyone can enter them / edit them
17:46:33 <jzb> that's how we should do it :-0
17:46:35 <jzb> er,
17:46:44 <chipc> if someone disagrees with the severity, they edit it
17:46:55 <chipc> and if there is confusion, then folks discuss in the bug or on the list
17:47:07 <iswc> I think that's probably a good first thing to do is qualify what's there now and prioritize the workload
17:47:08 <ke4qqq> so the 'expectation' I'd have is that it's set - and someone (RM?) is actively triaging
17:47:16 <techpubs> There is no one who's actively looking at these bugs, though, looking to set the severity or mark them "definitely fix for 4.1"
17:47:29 <jzb> on the 275 bugs is it possible to get an export that we could easily cherry pick the ones that need to come over to Jira?
17:47:42 <ke4qqq> techpubs: the RM should be
17:47:52 * ke4qqq looks over at chipc
17:48:11 <chipc> hmmm… except I have a workload concern personally
17:48:21 <techpubs> Well, there are thousands of legacy engineering bugs over on bugs.cs.o, also. I think you're right to be concerned about your workload!
17:48:41 <chipc> I'd suggest that the migration from bugs.cs.o, in general, needs to be done by CTX folks with the background
17:48:45 <ke4qqq> are you concerned about the workload of triaging or of being 4.1 RM?
17:48:56 <chipc> triage - more than willing to drive 4.1
17:49:08 <jzb> do we have "owners" for the components?
17:49:09 <chipc> specifically, triage of the cs.o bugs
17:49:17 <jzb> I think they ought to be the ones triaging bugs per release initially
17:49:22 <jzb> RM being final authority
17:49:32 <techpubs> I would be the one to do the initial triage on the doc bugs, then
17:49:38 <ke4qqq> ahhh I was referring to ongoing bugs - but nothing should stop anyone else from triaging initially
17:49:42 <jzb> sorry - not final authority, but ykwim
17:51:24 <chipc> I know how to solve the migration in an internal dev team world… but it's harder in this world
17:51:31 <techpubs> I think we have this question answered, actually: CTX folks triage their own old bugs, manually port any gold nuggets over to the Apache Jira, alert the RM to include them in upcoming release
17:51:38 <chipc> right
17:51:58 <techpubs> I asked because of the group nature of the Apache side
17:52:11 <techpubs> Thought maybe we had to have an open forum discussion to decide on all those bugs
17:52:22 <chipc> it's a place for people to do what they think is right first and foremost
17:52:27 <ke4qqq> yes
17:52:30 <chipc> and bug updates do hit the list
17:53:21 <ke4qqq> ok - anything else - we are at 53 minutes in.
17:53:33 <techpubs> I am done
17:53:43 <ke4qqq> anyone else?
17:54:09 <ke4qqq> hearing nothing I thank you for attending - will post meeting minutes shortly.
17:54:14 <ke4qqq> #endmeeting