17:00:32 #startmeeting 17:00:32 Meeting started Thu Dec 3 17:00:32 2009 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:42 #topic Roll call! 17:00:44 * stickster 17:00:46 * notting is here 17:01:10 * mdomsch 17:01:57 * jwb is here but getting nachos quickly 17:02:06 * poelcat 17:02:23 We seem to be missing spot, dgilmore, caillon 17:02:36 I pinged all three, but let's go ahead anyway. It's a very full day for everyone, I'm sure 17:02:43 #topic Board -- open floor 17:03:45 Speaking of FUDCon, I had one thing to interject... I wanted to publicly and loudly thank Mel Chua (mchua), Steven Parrish (SMParrish) and Chris Tyler (ctyler) for their help with FUDCon planning and execution 17:03:58 hear hear 17:04:01 +100 17:04:01 I am not exaggerating when I say, I have grave doubts as to whether FUDCon could have happened without them. 17:04:30 We are planning a FUDCon post-mortem meeting for the Thursday *after* FUDCon, at the regular time (2100 UTC in #fudcon-planning) 17:04:46 to look at things that went well vs. not well, and potential improvements. 17:05:19 The plan is to make FUDCon planning work through more of the community effort we try to use everywhere else in Fedora. 17:05:39 It's definitely been a huge help this time. 17:05:45 17:06:09 #info Many thanks to mchua, SMParrish, ctyler for FUDCon planning and execution assistance! 17:06:24 * stickster yields and waits 30 sec for other topics 17:06:27 do we have additional sponsors (for lack of a better word) like seneca lined up for future fudcons, or a process for finding them? 17:07:15 notting: I think that's a fine topic for the post-mortem. Short answer is that we started this time by asking community people to step up with offers of finding appropriate locations and space that would help us use our shoestring budget wisely. 17:07:38 So while we don't have anything lined up yet for December 2010, it's not too early to start looking. 17:07:45 We would like to do it someplace warmer. :-) 17:07:53 mdomsch: Any chance that you could help if we moved to Austin? 17:08:14 * stickster totally just put mdomsch on the spot -- don't feel you have to answer right now! 17:08:31 stickster, I could definitely help. I've been unable to get sponsorship funding though. 17:08:48 mdomsch: A free location is our biggest savings. 17:09:20 yeah. I'm watching the new TexasLinuxFest group trying to organize an event for next Spring, and they're having trouble locating a suitalbe venue for a reasonable cost 17:09:53 Monetary sponsorship helps us bring in more people, or have a bigger event. But the facilities are a huge cost defrayed, if we find someplace free like a university or corporate location. 17:09:53 mdomsch: no extra conference/meeting rooms at work? ;-) 17:10:06 if you recall the fudcon in Raleigh where we were in the RH office all day one day; I could do something like that at Dell, but we don't have big auditoriums or even classroom-sized rooms easily available. 17:10:28 rooms for 16-20 people are the norm 17:10:47 which makes our campus non-optimal for such 17:10:52 mdomsch: *nod... well, certainly we can discuss this further, there might be a way to make things work between a hotel banquet room and meeting rooms elsewhere 17:11:11 When you fill enough hotel rooms, often you can get a meeting space for free, especially if it's only for a limited time or a single day 17:11:33 mdomsch: If you're free, you have an open invitation to come to the #fudcon-planning post-mortem next Thursday 17:11:46 I'll do my best do do so 17:11:53 In any case, we can look at details later. There may be other community members interested in proposing a location too. 17:12:02 indeed 17:12:38 sorry I'm late guys 17:12:38 * stickster waits for 30 sec for AOB 17:13:12 #info FUDCon post-mortem: IRC Freenode, #fudcon-planning 2009-12-10 UTC 2100 17:13:42 If there's nothing else, we can move to Q&A then. 17:14:11 stickster, have many people taken you up on the offer to renew their Trademark License Agreement under the latest terms? 17:14:43 mdomsch: I'm sadly delinquent in finishing that task. I am planning to do a bunch of mass email over FUDCon to address that. 17:15:09 stickster, planning to get work done during FUDCon? /me thinks it unlikely. :-) 17:15:14 But I will certainly make a note of the general uptake for people who want to move from the old one to the new one 17:15:18 mdomsch: There's always the plane! 17:16:24 #action stickster to mail TLA holders and potential holders with updated agreement info ASAP 17:16:38 I saw your election plan note - that makes sense to me 17:16:53 Ah, thanks mdomsch -- my FUDCon filter was still in place 17:16:59 Let's talk about that briefly for everyone's sake 17:17:07 #topic Election schedule extension 17:17:11 and I am very greatful to inode0 for coordinating elections this round 17:17:26 #link https://www.redhat.com/archives/fedora-advisory-board/2009-December/msg00014.html 17:17:28 mdomsch: indeed, he's been doing a good job 17:17:36 +2 17:18:31 Because Infrastructure is moving some equipment the weekend of 2009-12-12, we want to make absolutely sure we have minimal impact on people's ability to vote in elections 17:18:42 I talked with mmcgrath, G, and inode0 this morning and we arrived at what we think is a suitable plan 17:18:50 See link above for details, but the essential pieces are: 17:19:04 1. Starting voting early, 2009-12-05 17:19:30 2. In the event of a >8 hour outage (which mmcgrath believes is unlikely) we will add a day to the end as well 17:19:43 seems reasonable 17:19:50 2a. In the event of any additional days of outage, we'll add another additional day to the end 17:20:00 for each day of outage, another day of voting will be added. 17:20:46 3. G (Nigel Jones) is preparing a change to the elections app that will allow a logged-in voter to review their previously made vote, to ensure that there is no effect on the ballots in the unlikely event of an outage 17:21:20 4. mmcgrath is going to blog to planet about the move; G and I will blog about the election changes. Additional surrounding blogs are appreciated too. 17:21:23 17:21:48 5. EVERYONE VOTE! 17:21:58 * stickster hears the voice of Michael Palin saying, "Are there any objections to my li'l scheme of MARCHING UP AND DOWN THE SQUARE?" 17:22:11 mmcgrath: Right on! 17:22:56 AOB? 17:23:13 agenda overboard? :-) 17:23:38 i'm ready for q&a 17:23:47 No objections, let's move on then :-) 17:23:51 #topic Community Q&A! 17:24:03 * mmcgrath has A's give me some Q's! 17:24:41 I've got P's and Q's, minding both! 17:25:22 (sorry, an earlier meeting ran late) 17:25:46 caillon: No problem. The log's being captured by our pal zodbot and will be posted shortly. Mostly informational thus far. 17:25:48 * dgilmore was looking into some koji issues and got distracted. sorry for my lateness 17:27:24 rbergeron: Go ahead! 17:27:36 * rbergeron waves 17:27:52 so my question basically revolves around whether or not there are specific, laid out goals for f13. 17:27:52 For those of you who don't know rbergeron, she is one of our primary Marketing team contributors 17:28:06 i realize we have a mission statement 17:28:16 rbergeron, if you are tying it to a distro release, wouldn't those be defined by the Feature process? 17:28:28 rbergeron: Do you mean goals for the Fedora 13 distribution, or goals for the Fedora Project that we want to reach during the Fedora 13 cycle? 17:28:30 but do we try and take that mission statement and develop that into specific things we want to improve on in each erlease 17:28:57 stickster: well, both, i suppose. 17:28:57 #topic Marketing & F13 17:29:03 i mean obviously there are goals like 17:29:10 "we want to get this out by this date." 17:29:19 "and get rid of bugs, etc." 17:29:34 I have personal goals for F13 but on the board side I'm kind of just waiting to see how Oxf13's new rawhide proposal works out. 17:29:35 if you're talking about previous things like the core/extras merge, or 'having spins available', i don't know that we really have those sorts of goals for f13 17:30:01 if you mean things like "Better Bluetooth support" or "Improved Telephony", then those normally come in via Features 17:30:04 but from the marketing team perspective: if there are goals that the distro is working on, or that we'er trying to reach as a community ni terms of process, it would be awesome to be able to highlight the process in blog posts, perss releases, in-depth profiles, etc. 17:30:04 The distribution goals are to some extent lined up with the feature list, as jwb mentioned, but there are also surrounding "how it's built" goals... the No Frozen Rawhide piece for instance. 17:30:06 as mmcgrath says, there are goals for changes in the development process. but from a marketing standpoint, i don't think users care there 17:30:13 rbergeron: great original question... something I"ve been think about for a long time 17:30:33 * poelcat thinks we have to think beyond the "feature process" as being our "planning" for a new release 17:30:51 Another would be clarifying our release criteria 17:31:04 the feature process is definitely a good way to organize what individual people are working on 17:31:18 but i wonder what it would look like to coordinate and plan at a larger level 17:31:30 coordinate and plan what? 17:31:32 There's the target audience discussion, with spins tailored to such; and specific activities to reach such 17:31:32 as an example 17:31:47 jwb: what the overall release will look like and what we want it to be 17:31:50 rbergeron: we have the feature list. but i dont know of any at the moment that are as big or noteworthy as core/extras merger or having spins. 17:32:20 poelcat, that is a pretty nebulous comment. i'm still not following 17:32:24 another distro i've heard of spends a whole week doing planning the next release 17:32:26 target spins - say, netbooks, and EC2 AMIs 17:32:35 i chatted with mchua a bit earlier about doing marketing goals (seeing if i was insane... she's a lovely sounding board) about takign a swag at it and organizing the marketing goals around the four f's. so that will be going out to mktg-list as an email, but I wanted to make sure that i wasn't missing some big higher-level of goal setting. 17:32:57 as i told her... i have no problems with tryign to build a road, i jsut want to make sure nobody else has said where the road needs to go or what we should be building it out of :) 17:33:02 with some consolidated effort around those targeted spins to provide the best possible experience 17:33:18 poelcat: I think there's often a tradeoff between the amount of labor you can devote to polish vs. deep technical features, the latter of which has typically been Fedora's strong point. 17:33:44 stickster: it might also be our weak point though wrt bugginess. 17:33:45 Hi all. Just managed to reach a place with internet here in India. :/ 17:33:47 I'm interested in increasing the number of people who are contributing to the polish part. 17:33:48 jwb: right now i think our releases are successful, but in kind of a mysterious way... lots of people and some concentrated groups (e.g. desktop) work on different functionality, but to my knowledge there is no overarching goal or coordination of those efforts 17:34:01 autoqa? 17:34:14 if there was, i'm wagering our releases could go from good to maybe amazing :) 17:34:16 that'll cross the whole distro 17:34:17 there's also the point that we really depend on our community to lead here, and we don't necessarily have the means to dictate what they work on 17:34:21 * mmcgrath created the dns entries for http://autoqa.fedoraproject.org/ just this morning :) 17:34:23 rbergeron: i know the desktop group is making plans to target a larger image size for the next release, and is holding discussions as to how to best utilize this 17:34:25 mdomsch, yeah... but marketing that? 17:34:30 mmcgrath, yea! 17:34:38 Well, AutoQA is no doubt very helpful, and I'm looking forward to seeing the progress report on that at FUDCon 17:34:42 * poelcat thinks there is a difference between 'leading' and 'dictating' 17:34:54 jwb, you market the result - better stability; fewer bugs in releases 17:35:05 poelcat, and if we want to make f??-updates be amazing too, then we need to look at the critical path regression suite and updates model definition stuff too 17:35:06 maybe even fewer updates as a result 17:35:06 mdomsch, which is an overriding goal every release... ;) 17:35:15 poelcat: yeah, and there's a difference between the community leading and the community doing. Sometimes it does feel like we have a lot of people doing. 17:35:26 and sometimes it feels like no one is doing :) 17:35:38 * poelcat doesn't want to discount for a second all the "doing"... it is amazing, it is great, keep doing it :) 17:35:54 poelcat, ok, but you want to direct the doing to specific things? 17:35:57 but could it be doubly great with a tiny bit more coordination? 17:36:01 i think people are happy to contribute in many ways, but holding up a sign saying "this way" never hurts. i've found that most people have more ideas than they have time, and if a little bit of direction is provided they may work on the "better bang for the buck" items. 17:36:08 jwb: me personally? 17:36:13 the board 17:36:19 I look at the polish on which some folks worked very hard toward the end of the cycle, and I thought to myself, what if we had interested community members finding additional weak spots and helping to develop (meaning sculpt the right answer, not necessarily code everything) the solutions? 17:36:20 jwb: I think he's less talking about making others do, and more about setting actual goals for the release 17:36:35 and seeing if we met those goals. Could be as simple as "don't slip this release" :) 17:36:47 well, we sort of did lead w.r.t. putting an official Do That stamp on NFR 17:36:48 jwb: i'm not thinking "coordinating" should be ______ person's job 17:36:52 mmcgrath, that's a goal every release 17:37:21 i'm thinking more broadly that if we did it might help us 17:37:32 who "we" is, etc. TBD 17:37:52 but I think rbergeron is onto something 17:38:09 i think it is humerous to read some of the press announcements about our releases 17:38:10 * rbergeron is holding a can of worms, which contains pandora's box 17:38:29 rbergeron, that's ok. it's fun :) 17:38:30 In the past, things like Spins, core+extras, etc. have all been "solutions to glaring problems" 17:38:44 Where's our next glaring problem? 17:38:48 For example, this release lots of virtualization stuff got done. We really pushed that in interviews and marketing. Was that something we planned just after F11 shipped? Or was that something we just noticed got done? 17:38:56 where it sounds like there was huge amount of deliberate decsision making and tradeoffs that went into deciding what we did for a particular release or what the themes were 17:39:07 we usually don't know what those are until we are feature complete :) 17:39:17 stickster: updates? 17:40:28 mmcgrath: i think thats all down to the feature process 17:40:32 mmcgrath: i thik it was the later 17:40:35 poelcat, well... personally that sounds like the Feature process is already doing exactly what we want in terms of coordination 17:40:37 notting: Could be, but that does fit into a larger idea of "How do we make your life on Fedora -- no matter who you are -- more pleasant and useful?" 17:40:55 stickster: the next glaring problem is CVS 17:40:56 We do have to remember that Fedora is, in a sense, an R&D lab 17:40:57 stickster, glaring holes: spins for netbooks and virtual environments (Fedora as a Guest) 17:41:14 stickster: but its not really something that users care about 17:41:30 dgilmore: our users don't care about CVS 17:41:32 R&D labs that are very successful tend to house some amount of experimentation, in addition to some planned projects 17:41:39 stickster: another things thats kinda glaring that will effect users is no forzen rawhide 17:41:42 dgilmore, there are much larger things than CVS 17:41:42 but, again, it's very hard for the board, with few directable resources, to say 'go do this' 17:41:56 dgilmore: i think that could be a good thing to fix internally, but it isn't something to trumpet about "what's great in Fedora 13" 17:42:15 jwb: depends on the point of view. but sure 17:42:20 notting: But we can certain shine a light in places and say, "This looks like a problem. How can we solve it? Who's interested in helping?". 17:42:21 notting, right 17:42:32 poelcat: right which is why i said users are not really effected 17:42:41 rbergeron: As you can see, these discussions take extra time over an IRC channel, and can get a bit wide-ranging. 17:42:56 * rbergeron nods 17:43:03 it's all good :) 17:43:29 maybe the answer to rbergeron's original question is "not really, at this time"? 17:43:30 stickster: sure. and as this discussion shows, we have different ideas on where that light should hshine 17:43:37 and good to get the seed planted. 17:43:52 dgilmore: sorry, missed that 17:43:58 notting: rbergeron: At FUDCon a lot of these seeds get watered, too. 17:44:16 poelcat: as i told mchua, i'll be sending out something of a proposal / idea to the marketing-list about it - if it goes well, maybe it will spread to other groups. 17:44:16 this would be a great FUDCon discussion 17:44:29 and if not - it never hurts to try :) 17:44:37 rbergeron: thanks for all the work you're doing there 17:44:53 :D 17:46:13 My overriding concerns for the next cycle are (1) that we find the right ways to focus efforts on a great Fedora distro while giving community members the room they need for their experiments in the Fedora R&D lab; and (2) giving our project a more pleasant, coherent appearance to match the changes we're trying to make under the hood for easier contribution. 17:46:43 stickster, project being the key word in #2, right? 17:46:50 (as opposed to distro) 17:47:41 jwb: Yes, although I certainly would like the distro also to be more pleasant and coherent... I'm less able to articulate how to improve that part, though. 17:48:42 I know that F12 *feels* better than F11 did, and I can point to things here and there that lend to my impression, but I can't draw a coherent picture about how to continue making that better. I'm hoping to see some results from Mo Duffy's usability tests that will help focus on some particulars. 17:49:10 Thanks for the conversation starter rbergeron! 17:49:14 We have another question 17:49:19 We can move on, but I think it is worth asking ourselves if we are missing something compared to the way Ubuntu plans their releases... I'm not advocating that we need to be them or follow them or that they do all the right things... just a question, "Are they gaining something from meeting for an entire week to plan each release in person and is there an aspect of that which would also be good for us?" 17:49:42 they're certainly gaining a larger travel expense account. 17:49:46 poelcat, comparing us to Ubuntu in this regard is a bit of a non-starter 17:49:59 you're already missing my point :) 17:50:10 just focus on the part in quotes :) 17:50:10 * mmcgrath agrees with poelcat. +1 to planning 17:50:23 poelcat, who is we, and how are they going to meet for a week? 17:50:39 that's not the point 17:50:41 poelcat, further, how are those people going to plan goals without resources to direct on fixing them? 17:50:41 to be less glib, i think if your plan is to focus on one particular usage case/market/etc., it probably does make sense to do that. if your raison d'etre is developer-driven chaos, then there's not much point 17:50:42 logistics aside, it's a fair question 17:50:44 jwb: Imagine we had an unlimited expense account. Then answer the question. 17:50:49 perhaps not everyone together for a week, but FAD's for individual teams. 17:50:53 * poelcat just trying to think out loud and brainstorm 17:50:57 forget the implementation details 17:51:04 I originally thought fudcons would be that kind of event; it's not, and that's fine for what it is. 17:51:17 mmcgrath: I'm not sure if FADs are the answer... the synergy *between* teams is often the key 17:51:20 mdomsch: yeah it's kind of a mix of both. 17:51:28 the hackfests are, with some extra structure, more of what they do 17:51:46 mdomsch: Right, what we could be talking about is a more comprehensive FUDCon 17:52:44 * poelcat doubts we can solve this today, just something I think we should mull over 17:52:52 stickster, I'd disagree. I think we have enough synergy between teams and less actual work from teams (hackfests/marathons). 17:52:52 Eliminating BarCamp, and instead a scheduled set of talks by teams, where everyone could attend and learn how we can better integrate into the whole 17:52:59 or beat me up in person on Saturday :) 17:53:01 we're too late to plan such an event for f13, but something we could do next summer if we start thinking now 17:53:07 in prep for f14 17:53:08 The few things we run a marathon for L10n engineering, it has worked extremely well. 17:53:30 poelcat: This is a great line of thought, maybe you can pitch a BarCamp talk about it on Saturday? 17:53:54 * stickster would like to get to a remaining question so as not to disenfranchise anyone 17:53:58 stickster: let me think about that 17:53:59 stickster, btw, thinking about an infinite expense budget isn't going to help me at all :) 17:54:06 it's kind of a matter of what we want the FUDCons to be. If we want them to be a meeting between fedora developers to plan the next release, that's not what they are now. 17:54:08 :-) 17:54:10 That's more of a FDCon :) 17:54:26 mmcgrath, indeed, it's far from what they are now. 17:54:44 mmcgrath: I had started musing to a few people last summer about whether we needed to separate out FUCon from FDCon 17:55:15 It's not zero-cost to do that, but that's a detail to tackle after we finish figuring out what we want to achieve, and how to do it. 17:55:32 EvilBob: Go ahead sir 17:55:33 * mmcgrath can't wait to get FUCon tshirts :) 17:55:41 Should we look at perhaps skipping a release in the future just to clean things up? I know there was a thread topic like this on the -devel list I did not read the thread however. We keep pushing the 6 month release schedule, could the extra time once in a while allow us to meet that 6 month timed release regularly? 17:55:43 oops, maybe we should rename that! 17:56:32 I am suggesting the F15 time frame or so. Can the Fedora Product and Project benefit from decompression if nothing more. 17:56:45 without more focus on what 'things' is, i would say no. i'd also point out that you can still fix things post GA as well as continue to fix them in rawhide at the same time 17:57:03 I'm not certain that solves a problem since our upstreams don't stop while we polish for an additional cycle. We end up with the same problems, only without a release in the middle. 17:57:19 * notting stops typing what he was, and just echoes stickster 17:57:25 But I do worry about contributor burnout. 17:57:25 * poelcat has a hard stop in 3 min for a concall 17:57:39 I was thinking beyond the software side, more to organization and processes. 17:58:13 I think those are things, especially in the non-software side, that we can tackle in the ~3 months before we get to Alpha. 17:58:26 We have to be comfortable with the idea of iteratively improving 17:58:36 And honest about what we can achieve in a given timeframe 17:59:00 If we set sights too high, disappointment can be a demotivator for people. If we set them too low, we don't take advantage of that time. 17:59:08 It would require planning and a list of goals I am sure 17:59:22 Yes, and that's something we empower leaders of each team to do 17:59:27 Robin asked what if one cycle was more engineering-focused, and one cycle was more polish/process -focused? 17:59:34 * dgilmore is with stickster 17:59:43 I think this fits my idea in a way 18:00:02 Then we could certainly fulfill the myth that Fedora-{even,odd} is awful and Fedora-{odd,even} isn't 18:00:07 LOL 18:00:16 how do we control that and what is engineering focused and polish/process focused? 18:00:31 poelcat: ack, feel free to drop if needed 18:00:39 poelcat: Thanks for your time, please consider that BarCamp session! 18:00:43 Very true, I feel I have had the response I hoped for, thank you guys. 18:00:59 polish in what sense? as stickster says, the upstreams don't stop. unless you make a project-wide distinction to ignore them for a cycle (in which case you're not working your polish upstream) 18:01:23 EvilBob: since we cant control what people work on. we cant just say make kde 4.3.3 betterer 18:01:24 * mdomsch hasn't heard the even/odd thing before 18:01:27 notting: Was that ducking? :-) 18:01:33 polish in what sense? as stickster says, the upstreams don't stop. unless you make a project-wide distinction to ignore them for a cycle (in which case you're not working your polish upstream) 18:01:33 mdomsch: neither have i 18:01:37 mdomsch, i have 18:01:38 mdomsch: Obviously you don't read the papers! ;-) 18:01:38 stickster: no, link dropped 18:01:55 The funny part is that if you ask a group of 100 people, 50 will say it one way, and 50 the other. 18:02:18 So I take that to mean that all Fedora releases {are great,need improvement} equally 18:02:25 Kidding. 18:02:36 dgilmore: Oh I agree, but perhaps we can make KDE 4.x more feature complete by getting more packages in and tested, again I was thinking more of how we do things not what we do. 18:02:38 stickster, 50/50 depending on which binary video driver is broken in that release? ;) 18:02:51 heh 18:02:52 jwb: Probably! 18:03:28 EvilBob: i think we are already doing that. 18:03:30 In any case, I'm not just dismissing the longer release cycle outright, but I'm saying that doing it once in a while seems ineffective. 18:03:43 every update is better than the one before it 18:03:54 dgilmore: yup, that is the answer I hoped for honestly 18:04:11 However, based on the experience we had in a longer release cycle, it doesn't seem like that helps either. 18:04:14 Thanks for the question EvilBob 18:04:27 Oops, I forgot to change the topic, sorry guys. 18:04:35 #topic Release cycle: see above ^^^ 18:05:10 * spot has to go to another meeting. Thanks guys. 18:05:15 Thanks spot 18:05:20 I'm going to call it, unless there are objections 18:05:24 in 15 18:05:32 10 18:05:37 5 18:05:40 3 18:05:41 2 18:05:42 1 18:05:44 #endmeeting