16:00:03 <stickster> #startmeeting Fedora Board
16:00:09 <zodbot> Meeting started Thu Apr  1 16:00:03 2010 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:19 <stickster> #meetingname Fedora Board
16:00:20 <zodbot> The meeting name has been set to 'fedora_board'
16:00:26 <stickster> #topic Roll call
16:00:32 * stickster 
16:00:41 * mmcgrath 
16:00:49 * poelcat 
16:00:56 * mdomsch 
16:01:57 * stickster should have used the .pingall command, just found out about it last night!
16:02:14 * spot burps
16:02:23 <stickster> classy :-D
16:02:49 <stickster> I see dgilmore jwb caillon also in channel
16:03:07 <stickster> ctyler will return in a moment
16:03:09 <jwb> here, yeah
16:03:22 <stickster> I pinged walters as well -- he has a meeting right before this IRL that sometimes runs a few minutes over.
16:03:56 <stickster> Let's go ahead and get started
16:04:11 <stickster> #topic F13 cancellation
16:04:18 <stickster> I'm sure everybody knows about the F13 Beta slip by one week
16:04:28 <stickster> After a talk with QA this morning we've decided just to forego F13 altogether.
16:04:46 <mdomsch> stickster, it was bad luck anyhow
16:04:47 <stickster> The number 13 isn't very well liked in a lot of places worldwide, so it seems safer to just wait another six months and release F14 instead.
16:05:09 <jwb> and we're going to hold a "Top Gun" event for F14
16:05:24 <stickster> Triskaidekaphobia is no laughing matter
16:05:38 <stickster> jwb: Talk to me Goose!
16:06:09 <jwb> it's like FUDCon, only if you don't pass the trials you get kicked out of Fedora for not being in the target audience anymore
16:06:19 <mdomsch> stickster, will updates for F14 have to get pushed into bodhi starting now then?
16:06:31 <jwb> mdomsch, nah.  launchpad
16:07:00 <caillon> mdomsch, that's up to FESCo :)
16:07:33 <stickster> #agreed One April Fool's joke is more than sufficient for one Board meeting :-)
16:07:48 <stickster> Shall we move on?
16:08:11 <caillon> stickster, walters can be our second ;-)
16:08:30 <walters> for a duel?
16:08:47 * walters really wishes irc didn't suck and kept channel history
16:09:30 <mdomsch> moving on...
16:09:31 <spot> walters: it does if you use a bounce, like miau. ;)
16:09:37 <stickster> walters: http://meetbot.fedoraproject.org/fedora-board-meeting/2010-04-01/fedora_board.2010-04-01-16.00.log.txt
16:09:46 <stickster> #topic SWG output check
16:09:52 <stickster> #link https://fedoraproject.org/wiki/User:Pfrields/Desktop_user_experience_designers
16:10:35 <stickster> This is a page that I worked on with the other SWG members to answer one of the questions the Board was asked to answer
16:11:37 <spot> wow, thats a lot of tap dancing with words.
16:11:54 <spot> the fact that the Fedora Design group is not mentioned once is very... suspicious.
16:11:55 <stickster> The SWG presented it in our notes on Monday, to address the question of how the UX in Fedora is defined and what happens if another SIG disagrees
16:13:00 <poelcat> spot: I don't think it was written with a conspiracy in mind :)
16:13:29 <spot> poelcat: no, but given the past contention issues between the Desktop group and the Fedora Design team...
16:13:34 <stickster> Right now, what happens is that interested people on the Fedora Design team and from all over the project meet on desktop@ list when it comes to questions of user interaction in those components
16:13:55 <spot> i would hope that document is not an attempt to alter the prior stated responsibilities of the Fedora Design team
16:14:00 <stickster> Mo Duffy and Nicu Buculei, for example, are both on that list
16:14:09 <dgilmore> stickster: desktop@is the wrong forum  it should be devel@
16:14:14 <stickster> That certainly wasn't the intent
16:14:22 <mdomsch> no, I think it just describes current practices and rationale for such
16:14:30 <spot> stickster: given the lack of mention, it could easily be interpreted that way
16:14:54 <poelcat> spot: what would you add to avoid misinterpretation?
16:14:55 <spot> i would like to see the role of Fedora Design documented along with that
16:15:03 <stickster> spot: Point well taken. So tell me how you would like to see the page changed to make it something you'd like better
16:15:34 * ctyler arrives in office, quickly scans scrollback & catches breath
16:15:42 <spot> I think if their role and responsibilities were documented there, it would make it clear that the Desktop SIG is not intended (or planning) to step on it
16:16:01 <spot> especially given that there is a section titled "Who makes designs?"
16:16:29 <mmcgrath> spot: I guess I see the design team as very tied to Fedora, whereas the Desktop Team is very tied to Gnome.
16:16:32 <mmcgrath> is that innacurate?
16:17:04 <walters> yes
16:17:05 <spot> mmcgrath: i wouldn't necessarily draw that conclusion, i doubt the Desktop Team would say that their designs are limited to GNOME
16:17:16 <walters> (yes, it's inaccurate)
16:17:18 <stickster> mmcgrath: I think it's s/Gnome/GNOME, freedesktop.org, and other upstreams/
16:17:44 <mdomsch> the example of choosing tomboy vs gnote wasn't really design-related though, or even UX, but really technical - 'look at all the mono packages we don't need to put on the livecd'
16:17:48 <stickster> And also a decided eye toward the Fedora model of upstream collaboration -- i.e. a two way exchange upstream and downstream.
16:17:56 * poelcat is there a common understanding that "Desktop Team" ==  "Desktop SIG" or are these two different groups?
16:18:01 <walters> mdomsch: that is true
16:18:11 <spot> Nor am i saying that the Desktop SIG should not be involved in the design aspects of Fedora, but rather that we should mention that the Fedora Design group is ultimately responsible for the overall design of Fedora
16:18:14 <stickster> poelcat: They are two different things, but related, which I tried to spell out in the page
16:18:45 <mmcgrath> spot: perhaps I'm just not close enough to know, where could I see a Desktop Team design?
16:18:45 <stickster> I feel like my role as a contributor allows me to be part of the Fedora Desktop SIG, but I'm not on the Red Hat Desktop team of course
16:18:47 <poelcat> stickster: oh, i thouht that part got removed
16:19:22 <mmcgrath> or a design team design for that matter.
16:19:30 <spot> There is a difference between "we pick which packages go into the Desktop Spin" and "we choose the look and feel for a particular release"
16:19:51 <spot> and yeah, there is a gray area in there, but we've previously established that the Design Group is responsible for the latter.
16:20:00 <caillon> poelcat, there are people who actively participate in the Desktop SIG that aren't employed by RHT even, so not sure it's actually an accurate statement
16:20:20 <stickster> mmcgrath: http://blogs.gnome.org/mccann/2010/02/06/action-pack/ for example
16:20:39 <walters> in fact, having those kinds of people is the *entire reason* we participate in Fedora
16:21:08 <stickster> spot: Right -- and I think the page is lacking there. We need to mention the work that the Design team does for every release, that's a bad oversight.
16:21:11 <mmcgrath> stickster: isn't this a gnome/upstream thing though?  not fedora specific?
16:21:41 <jwb> the page seems backwards
16:22:01 <stickster> mmcgrath: I don't see how discerning those is helpful -- unless Fedora starts deciding to depart broadly from how upstreams work
16:22:10 <jwb> i'd move the Discussion section above the Answers section
16:22:16 <spot> jwb: agreed
16:22:22 <stickster> jwb: noted, thanks!
16:22:27 <mmcgrath> stickster: because we do it witheveryone else?
16:22:41 <spot> I also think that page could be improved by restructuring it to make it clear what the Desktop SIG and the Design Group are responsible for
16:22:43 <poelcat> caillon: how do you define "Desktop Team" ?
16:22:55 <mdomsch> It's also important to point out, somewhere, that other desktop SIGs (KDE, XFCE, LXDE, ...) do define their own UX to a large extent, independent of the Desktop SIG's choices for the default offering.
16:22:58 <stickster> mmcgrath: I'm not sure I understand, can you restate?
16:23:04 <spot> mdomsch: +1
16:23:06 <stickster> I thought we stay close to upstreams generally in Fedora.
16:23:38 <mmcgrath> but close to upstream and upstream are different.
16:23:48 <stickster> mdomsch: s/Desktop SIG/Desktop and Design/ given previous comments from Spot, but yes
16:23:57 <caillon> more accurate would be we influence upstream
16:24:06 <mdomsch> stickster, agreed
16:24:08 <caillon> and actively participate
16:24:11 <mmcgrath> caillon: except that's not true in desktop's case... they are upstream.
16:24:17 * spot is all for Fedora to be "designed" as opposed to "haphazardly slapped together and shipped", but I don't want to inadvertently start up old flame wars, or confuse people as to their responsibilities
16:24:44 <walters> mmcgrath: contribute significantly to upstream, just like all teams in Fedora should for key infrastructure components
16:24:46 <caillon> mmcgrath, in many cases, but not all.
16:24:57 <stickster> spot: Agreed -- that was not the intent, and leaving out Design here was an oversight... partly because I read input from Fedora Design members on the desktop@ list fairly regulary
16:25:00 <stickster> *regularly
16:25:05 <mmcgrath> caillon: "but not all" as in there's other people that work on Gnome that aren't in Fedora?
16:25:19 <walters> mmcgrath: yes, a lot
16:25:20 <caillon> um, yes!
16:25:44 <mmcgrath> Yeah, but that's different then saying that our desktop team isn't gnome upstream.
16:25:58 <mmcgrath> comparing the desktop team's interaction with upstream is different then the kde teams interaction with upstream.
16:26:05 <mmcgrath> but we pretend for some reason that difference isn't there.
16:26:33 <ctyler> mmcgrath: different in a qualitative, not quantitative way?
16:26:39 <mmcgrath> both
16:26:40 <jwb> mmcgrath, i don't think we do.  we called out the Desktop team's interaction with upstream as a reason it's the default spin
16:26:46 <mmcgrath> actually lets move on.  I stopped caring around 12:21
16:26:58 <caillon> i'm not sure i follow.  we don't say that the kernel upstream == fedora kernel developers.
16:27:01 <mmcgrath> if I'm in the clear minority lets move on.
16:27:13 <mmcgrath> caillon: we're not talking about user experience for the kernel.
16:28:08 <stickster> Certainly we've got people in the Fedora Desktop SIG who are paid to do 100% coding in upstream projects
16:28:14 <stickster> mmcgrath: Is that the distinction you're getting at?
16:28:26 <mmcgrath> the distinction I'm getting at is... lets move on.
16:28:36 <mmcgrath> really, no foolin.
16:29:06 * spot would be interested in seeing a revised version of that document which addresses my points
16:29:09 <mmcgrath> spending several minutes talking about one board member who has a dissenting opinion is foolish.
16:29:14 <spot> (at a future board meeting, of course)
16:29:16 <mmcgrath> s/about/to/
16:29:17 <stickster> spot: I'm going to take that action
16:30:03 <stickster> #action stickster to take input from this meeting to revise page for Board review
16:30:31 <stickster> OK, in deference to mmcgrath and our community members' Q&A we can move on
16:31:15 <stickster> #topic Q&A
16:32:31 * stickster looks to #fedora-board-questions for some questions
16:34:25 <stickster> inode0: go ahead sir
16:34:26 <inode0> Does the current board still have hope to wrap up the major bits in the questions it has been dealing with for a while about Fedora's audience?
16:34:45 <mdomsch> yes
16:34:51 * spot sure hopes so
16:34:59 <stickster> inode0: Good question. Yes, we are well on our way to that point
16:35:10 <stickster> https://fedoraproject.org/wiki/Unfinished_Board_issues shows our progress to date
16:36:24 <stickster> There are only a couple of the questions left at this point. The strategic working group (SWG) started so that we could handle tough discussions in an additional meeting without making it difficult for the Board to get its other business done
16:36:40 <stickster> Once that work is finished, the plan is to disband the SWG.
16:37:06 <stickster> Given our pace, I'm guessing we'll be done before elections, which is fine timing.
16:37:25 <stickster> inode0: Does that answer your question?
16:37:49 <inode0> Good to hear, I know there have been lots of frustrations and wrapping before elections would be great all around.
16:37:52 <poelcat> https://fedoraproject.org/wiki/User:Poelstra/What_is_a_target_audience captures the remaining discussion
16:38:16 <inode0> thanks for the update
16:38:17 * poelcat has high hopes of wrapping up SWG by end of April
16:38:27 <stickster> inode0: Thanks for the question!
16:38:27 <poelcat> May at the latest
16:38:46 <stickster> jjmcd_: You had a question, go ahead sir
16:38:54 <jjmcd_> Each release alpha, beta, GA we seem to slip
16:38:57 <jjmcd_> Are we reviewing the fairly routine schedule slippages to try to identify why we are always surprised?
16:39:17 <jjmcd_> Scheduling seem to be improving but we don't seem to quite get there
16:39:31 <stickster> Good question jjmcd_ -- although I think "surprised" may not be the precise word
16:39:35 <jwb> that's more a question for FESCo and rel-eng i think.  but i don't think i'd call them surprising
16:39:37 <stickster> "disappointed," some of us for sure :-)
16:40:00 <mmcgrath> poelcat: just curious, do we track the reasons for slipping over time?
16:40:19 <stickster> A *lot* of people have put work into not only creating schedules for our various teams, including poelcat, rel-eng and QA team members specifically on the distro
16:40:20 <walters> poelcat: i sent you a /msg btw
16:40:20 <dgilmore> jjmcd_: releng and qa are working to make the chance of slipages less
16:40:47 <mmcgrath> I will say they've gotten better about predicting whether or not a slip will happen.  It's not like they don't know what is going on.
16:40:50 <poelcat> mmcgrath: not very detailed
16:40:54 <stickster> and also into having a well-defined set of criteria to determine what can make us slip, and precisely what remedies to take hwen it happens.
16:40:58 <mmcgrath> I think it's just complex / difficult problems that probably take longer then expected.
16:41:08 <dgilmore> jjmcd_: however at the fast pace of change we have some critical things take longer to stabalise and setlle down than we allow for or would hope
16:41:24 <dgilmore> jjmcd_: we could be less agressive but then we are not fedora
16:41:41 <poelcat> mmcgrath: only in the past few releases have I been diligent about tracking planned vs. actual
16:41:45 <jjmcd_> Yes, but if we pay attention to history then perhaps we can buy aggressive at a lower price
16:41:50 <poelcat> mmcgrath: next step would be to track specific reasons
16:41:57 <jjmcd_> exactly
16:42:36 <stickster> Each time we produce a schedule, we do look at the previous releases to see where tuning that we've done has either worked or not worked. And we can probably improve the level of detail at which we examine those reasons.
16:42:53 <jwb> pretty sure you could do bugzilla mining and find the reasons for slip for each milestone
16:43:05 <jwb> there's tracker blocker bugs.  just see which bugs were open on the planned date
16:43:09 <poelcat> mmcgrath: the other part is consistently following a methodology and experimenting less
16:43:13 <stickster> jwb: Sometimes yes, sometimes no. I think we need to look wider than that, probably.
16:43:16 <jwb> also, read the go/nogo emails
16:43:54 * mdomsch prefers to slip than to ship something that is seriously broken, even at alpha/beta times
16:44:11 * spot wonders if this wouldn't all be made easier if we just adopted Ubuntu's release schedule so we could leverage all their upstream contri.... oh sorry, i can't even do that on April Fools Day
16:44:30 <mmcgrath> mdomsch: Nummi!
16:44:33 <stickster> I read adamw's blog entry and one of the problems he noted was the time squeeze on QA for testing for Beta. Recall that we slipped Alpha by one week and didn't echo that down the rest of the schedule. So one thing we might want to consider is whether echoing the slip is really required to give QA that time..
16:44:37 <ctyler> mdomsch: agreed, but if the slips keep recurring, then there's a procedure or schedule issue
16:45:03 <jwb> ctyler, i disagree
16:45:07 * stickster is just picking out one detail among many -- it's a discussion worth having, but not necessarily a simple answer that just makes our future schedules magically work in every case.
16:45:09 <jwb> it's not that cut and dry
16:45:24 <mmcgrath> stickster: well, i think after the first slip they kind of sit down real quick and say "Can we recover and make up the time?"
16:45:27 <jjmcd_> ctyler, if each slip is different maybe not, but if there is a pattern then we can address it
16:45:51 <dgilmore> In the past we said we wanted the agressiveness. and we felt that if we took a less agressive schedule we wouldnt fix the issues because people will always wait until the last minute
16:45:53 * stickster seems to recall back in the FC6, F7 days that our slips would pretty much happen at the very end of the process, week by week without a lot of warning.
16:45:56 <mmcgrath> but now that I think of it I can only think of that happening once (I happened to be at that meeting) I don't know if that's SOP or not.
16:46:00 <mdomsch> it's a good question - and I don't know if there's a pattern; I suspect there are showstopper bugs in different areas each time.
16:46:02 <ctyler> right, even if that pattern is "something is always going wrong between these two scheduled events, they are too close together"
16:46:16 <stickster> Nowadays we do a much better job of detecting risk of slip earlier, and then making plans for it by echoing it down into the schedule.
16:46:19 <poelcat> mmcgrath:  in fedora we have never "make up time" it is scheduling myth for most projects
16:46:48 <mmcgrath> poelcat: then perhaps we should talk to releng and QA and say that any slip is a total sip, the echo thing stickster mentioned from adamw's blog.
16:46:50 * poelcat notes we are probably verring off topic
16:46:52 <mmcgrath> err total slip
16:47:10 <poelcat> mmcgrath: that was the policy until they made a last minute change at alpha
16:47:20 <mmcgrath> ah, i didn't realize that
16:48:13 <stickster> jjmcd_: So to answer your question, the answer is yes, we do review that problem, and will continue to do it -- and should be able to improve the level of detail as we look at the reasons for any slip
16:48:45 <jjmcd_> Thanks guys, good stuff
16:48:48 <stickster> I believe we have at least a QA-level post mortem for the release and rel-eng generally participates there
16:49:06 <stickster> It's a public meeting like others and we encourage people to listen or pitch in as desired.
16:49:25 <poelcat> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle explains our approach
16:49:34 <stickster> Thanks poelcat
16:49:52 <stickster> rsewill: You had a question?
16:49:55 <stickster> Go ahead sir!
16:51:40 <rsewill> My question is jumbled, probably bad, will try to summarize, think got an answer, Looking at https://fedoraproject.org/wiki/User:Poelstra/What_is_a_target_audience, got concerned about the diagram.  Have sister who is computer illiterate, friend who uses Mac, another friend who can install Linux...was wondering about line indicating who Fedora is for (below line people would have more difficulty using Fedora)...but do we te
16:51:40 <rsewill> ll them that (bad idea?, or get questions on mailing list?)  My question is confusing.
16:52:11 <stickster> rsewill: Ah, thanks for the question.
16:52:15 <spot> Yes. Your question is confusing. :)
16:52:15 <mmcgrath> rsewill: my understanding is we'd exclude your sister.
16:52:24 <mmcgrath> well, not exclude.
16:52:27 <walters> rsewill: that's a very good question and concern; I think there is a lot of people dissatisfied with the triange as currently shown, and we plan to revise it.
16:52:27 <mmcgrath> but not target either.
16:52:27 <stickster> That diagram is actually just a draft we did, and we've already found problems with it.
16:52:40 * mmcgrath likes the triangle
16:52:51 * dgilmore doesnt like the triangle
16:52:53 <mdomsch> right, not target
16:53:42 <stickster> One of the problems with the triangle that, until we got some design input, we didn't realize was that it gives the impression of status -- i.e. if you're not at the top, you're a "plebe" or somehow it's a judgment on value
16:53:54 <caillon> rsewill, personally, i think it should be for all of them (and if it's not, we should get to that point)
16:54:08 <dgilmore> rsewill: people bellow that line probably should be told make sure you have someone handy who is above it to help you.
16:54:10 <stickster> I'm working on a revision for that diagram that doesn't suffer from some of those types of problem.
16:54:29 <mdomsch> caillon, in time, yes. "take and use this today for everything" - no.
16:55:01 <walters> it is definitely inaccurate in saying we don't design for them, because we ship major upstreams who clearly do, like Firefox and GNOEM
16:55:08 <mmcgrath> caillon: :(
16:55:30 <ctyler> The purpose is not to "tell people to go away", but rather "this is who we're aiming at". Anyone, above or below the line, is welcome to use Fedora, but given the choice of something that works for people in one category or the other, we'll choose the solution that works best  those in the target group.
16:55:41 <ctyler> for*
16:56:05 <walters> well we should pick this up at the next SWG
16:56:33 <walters> so i think the current answer for rsewill is "the diagram is not final"
16:56:44 <caillon> right
16:57:21 <stickster> *nod
16:57:25 <stickster> Thanks for the question rsewill
16:57:55 <stickster> There was a general question about packaging but that appears to have been answered in the other channel by attendees
16:58:12 <stickster> Oh, there's another question beyond that
16:58:19 <stickster> plarsen: You had a question about training
16:58:36 <stickster> (disclosure: plarsen is in my local LUG and I believe we discussed this the other day)
16:58:47 <plarsen> Yes - I was at FOSE 2010 this year. We had a lot of people at the booth who knew "unix" but didn't know Linux and wanted some kind of introduction to Linux
16:59:00 <plarsen> We talked about creating small inexpensive classes or videos ....
16:59:08 <plarsen> I wondered if Fedora had any similar efforts?
16:59:19 <plarsen> We did stickster :)
17:00:06 <stickster> So there are two things to note here as background that will help make context around the answer
17:00:26 <plarsen> It would be simple topics such as controlling the desktop setup, setting up email/network etc.
17:01:17 <ctyler> There is the Fedora classroom initiative: http://fedoraproject.org/wiki/Communicate/IRC/Classroom
17:01:18 <stickster> 1. Fedora is a community run distribution, which means the things that we create come from our community members. A number of Red Hat employees are community members, and they typically work on the things that are important to their teams strategically in Red Hat. Fedora is kind of a community R&D lab in this regard.
17:01:33 <stickster> So anyone in the community can help produce things like that.
17:01:48 <stickster> 2. (ctyler stole some of my thunder, good on you ctyler!)
17:01:55 <ctyler> (sorry!)
17:02:02 <stickster> Not at all!
17:02:41 <stickster> The Fedora Classroom allows experienced people to teach skills to others. However, we do realize that, as it's IRC based, it may not be the ideal learning environment for everyone.
17:03:02 <plarsen> stickster: you stole my thunder there :) I was about to say that IRC may not be the best channel
17:03:15 <ctyler> There are also things such as the user sessions at FUDCon. We experimented with expanding these at the last event, with mixed success: some sessions were quite well attended, some were not.
17:04:08 <stickster> So there's some context. The rest of the answer is, over the last many years Red Hat's Global Learning Services has created a lot of fantastic training. That training forms a curriculum for Red Hat Certified Technician (RHCT), RHCE (Engineer), RHCSS (Security Specialist), and so on all the way to RHCA (Architect).
17:04:33 <stickster> That training costs a lot of resources to keep up to date even for a product with a long stable lifecycle like RHEL.
17:04:53 <stickster> For Fedora you can imagine it being an order of magnitude higher. I created a couple of my own in previous jobs, and... wow.
17:05:58 <stickster> But there is some discussion happening about finding particular pieces of other content created for training purposes, and building a community effort around that -- and it could well provide the type of training you mention, plarsen
17:06:04 <stickster> So there's the whole answer
17:06:09 <plarsen> stickster: It's important to understand they weren't looking for comprehensive training. Just introductionary
17:06:13 <stickster> Yup.
17:06:35 <stickster> Specifically I'm talking about introductory type training.
17:07:00 <stickster> Stay tuned about that -- there's nothing I can point you to now but hopefully that won't be the case for long
17:07:08 <stickster> Thanks for the question plarsen!
17:07:35 <stickster> I think we're out of questions in the queue next door
17:08:37 <stickster> OK, that's the bell for today then!
17:08:46 <stickster> Thanks to everyone who came, listened, asked questions, helped out.
17:08:54 <stickster> Have a wonderful weekend everyone!
17:08:59 <stickster> #endmeeting