18:00:08 <jwb> #startmeeting Fedora Board Meeting
18:00:08 <zodbot> Meeting started Thu Aug 22 18:00:08 2013 UTC.  The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:21 <misc> hi
18:00:37 <jwb> #chair rbergeron mjg59 misc Sparks
18:00:37 <zodbot> Current chairs: Sparks jwb misc mjg59 rbergeron
18:00:38 <rdieter> yo
18:00:42 <jwb> #chair rdieter
18:00:42 <zodbot> Current chairs: Sparks jwb misc mjg59 rbergeron rdieter
18:00:53 <jwb> #chair mhayden
18:00:53 <zodbot> Current chairs: Sparks jwb mhayden misc mjg59 rbergeron rdieter
18:00:54 * inode0 waves
18:00:58 <jwb> #chair inode0
18:00:58 <zodbot> Current chairs: Sparks inode0 jwb mhayden misc mjg59 rbergeron rdieter
18:01:07 * mhayden shuffles a chair over
18:01:32 <jwb> mjg59 sends his regrets today.  he'll be away from a computer during the meeting
18:01:57 <jwb> anyone heard from ghomls?
18:02:05 <misc> nope
18:02:38 <misc> but he was active on irc 2h ago
18:02:45 <misc> so not on PTO
18:02:56 <jwb> we'll wait a minute or two.  rbergeron hasn't spoken up yet either
18:03:28 * inode0 pinged both in #fedora-advisory-board
18:03:43 <jwb> i was unaware that even existed
18:03:50 * mhayden didn't know either, jwb
18:03:58 <jwb> so many channels
18:04:10 <mhayden> at least we're channeling our efforts
18:04:18 <jwb> #info #fedora-advisory-board is a thing!  join in the fun.
18:04:50 <rdieter> its mentioned on http://fedoraproject.org/wiki/Board , fwiw
18:05:02 <mattdm> /join #fedora-board-public
18:05:10 <rdieter> essentially the irc equivalent of https://lists.fedoraproject.org/mailman/listinfo/advisory-board
18:05:23 <jwb> rdieter, who reads the wiki pages? :)
18:05:27 <inode0> with fewer flamefests
18:05:42 <rdieter> jwb: truth
18:05:49 <jwb> inode0, i dunno.  advisory-board@ has been pretty quiet the past few months
18:05:59 <rbergeron> okay.
18:06:09 <rbergeron> praise the lord, I now have internets. sorry
18:06:14 <rdieter> we can probably help fix that problem of not enough flames
18:06:22 <jwb> all hail our leader!
18:06:28 <rbergeron> rdieter: /me bequeaths you with a flamethrower
18:06:28 <jwb> ok, let's get rolling
18:06:37 <rdieter> woo
18:06:43 <jwb> #topic Target audience & alignment with anticipated future directions
18:06:49 <rbergeron> jwb: gholms may also be late, he is exchanging his telephono.
18:06:55 <jwb> this is the only thing on the agenda today
18:07:13 <mattdm> i am here to talk about it if you like
18:07:13 <jwb> as far as i know, we're still waiting on a concrete proposal from FESCo on the Fedora.next thing
18:07:33 <mattdm> there is a draft proposal at https://fedoraproject.org/wiki/Fedora.next/boardproposal
18:07:47 <jwb> draft as in "not ready for submission to the board"?
18:07:49 <mattdm> this combines fedora.next ideas with target product idea
18:07:57 <rbergeron> okay, and mjg59 is out, and the desire for his presence for this conversation was expressed in the last meeting.
18:08:00 <rbergeron> but.
18:08:10 <sgallagh> jwb: Draft as in "good enough for the board to tell us if they need anything more from it to vote"
18:08:13 <inode0> yeah, we tried
18:08:31 <misc> #info draft proposal on https://fedoraproject.org/wiki/Fedora.next/boardproposal
18:08:48 <jwb> rbergeron, i believe he's aware we're talking about it.  i don't realistically see us making firm decisions today, so it should be fine for him to review later
18:08:56 <rbergeron> jwb: ack
18:09:06 <misc> sgallagh: just to make sure, vote from FESCO ?
18:09:07 <jwb> sgallagh, mattdm: was this sent out previously and i just missed it?
18:09:25 <mattdm> jwb no it was not
18:09:35 <mattdm> so i am not expecting you to have seen it :)
18:09:43 <rbergeron> mattdm: it doesn't highly influence the approval ability - but for transparency-ish-ness it might be useful to link your slides or video presentation to this wiki page
18:09:52 <sgallagh> misc: It was developed with FESCo input, so I'm reasonably comfortable with it
18:09:56 <mattdm> rbergeron will do
18:10:02 <jwb> mattdm, whew
18:10:09 <misc> #info draft is proposed for first review, to know if FESCO can vote on it or if Board need something else
18:10:15 <mattdm> jwb right. :) it _was_ mentioned in the fesco minutes
18:10:37 <mattdm> misc: there is definitely some board-level stuff in here
18:10:43 <sgallagh> misc: I don't think FESCo needs to vote on this at this time
18:10:50 <sgallagh> This is a board-level question
18:10:51 <inode0> So one concern that has been mentioned before is the Workstation product target shift? Any additional comments on how you see that working?
18:11:02 <misc> sgallagh: ok so let me #undo :)
18:11:04 <misc> #undo
18:11:04 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2848c290>
18:11:28 * misc wonder if someone could 1 day fix meetbot to show a better thing than a "pointer"
18:11:29 <sgallagh> If this is approved, the wiki page describes actions that FESCo will need to take (and vote on)
18:12:16 <sgallagh> inode0: Could you rephrase the question? It's a bit vague.
18:12:25 <jwb> #action nirik to fix meetbot ;)
18:12:40 <nirik> Patches welcome. ;)
18:12:47 <misc> nirik: challenge accepted
18:12:57 <inode0> The target audience you describe for workstation is not the current target audience for the default offering.
18:13:00 <nirik> misc: :)
18:13:06 <jwb> #undo
18:13:06 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x27887ed0>
18:13:27 <sgallagh> inode0: That is correct. The current target audience for the default offering is so vague as to be useless.
18:13:31 <inode0> Will the same people produce the Workstation product? Will other people? Has this been discussed with the desktop "team?"
18:13:58 <sgallagh> inode0: I have spoken with mclasen about it, yes. His team *will* be heavily involved.
18:14:19 * rbergeron agrees with the "workstation" vs. "default offering" differences in target audience; mostly curious about if it will change the decision-making process about what is on desktop, included, etc.
18:14:33 <rbergeron> and how that interacts with other spins such as kde, etc.
18:14:46 <inode0> Ok, there is just concern that we could cause a harmful fracture if we don't handle this part with care I think. At least from my perspective.
18:14:46 <jwb> i'm thinking it's mostly going to change the target audience
18:14:56 <misc> sgallagh: what about people outside the RH desktop team ? ( either non desktop,, or non RH ) ?
18:14:56 <jwb> as in, we'll have 3 newly defined ones
18:14:59 <rdieter> each working group probably ought to have some say in tweaking their "Target" and "Purpose" anyway
18:15:36 <sgallagh> misc: Each of the working groups will have their own opportunity to design their own charter and governance
18:15:48 <jwb> i feel at a disadvantage not having read this yet.  i'm going to try and read it quickly
18:15:50 <sgallagh> Subject to FESCo and Board in ways described on the Wiki
18:16:20 <mattdm> rdieter Yes, proposal is for first deliverable for each working group will be more detailed proposal for target and purpose for board to review/approve
18:16:30 <misc> sgallagh: i as more speaking of the initial discussion, ie, you discussed with more than mclasen ?
18:16:40 <sgallagh> rdieter: The proposal includes directives aimed at working with rel-eng to build product-creation tools that should be usable for other desktops that want to create spins
18:16:48 <sgallagh> Hopefully in a much more sane manner than the current approach
18:17:29 <rdieter> sgallagh: i think i'm falling in love
18:17:30 <rbergeron> so one thing I anticipate in reading this - release engineering and QA - they will need resources to retool - is their ability to get / even have bandwidth to plan for what resources are needed a blocker on fesco approving anything?
18:17:51 <sgallagh> misc: I've approached some members of other desktop families as well, but I'll admit to having spent less time with them than with GNOME, if only due because of less access to them
18:17:59 <rbergeron> i just do'nt want this to turn into "I can't commit so we're all going to not move"
18:18:25 <mattdm> rbergeron we will make sure that they have time and other resources.
18:18:33 <sgallagh> rbergeron: Part of the proposal includes a requirement for those two groups to provide a document specifying their needs
18:18:40 <jwb> mattdm, that is a pretty nebulous statemetn
18:18:45 <misc> sgallagh: in fact, i am more concerned about making sure the discussion is outside RH, even if i agree with the current focus on the workstation
18:18:46 <jwb> and it doesn't answer rbergeron's question
18:19:08 <mattdm> jwb fair enough. let me be more specific...
18:19:08 <sgallagh> misc: I understand. I'm hopeful that improved tooling will make this less of a hassle.
18:19:26 <rbergeron> are we going to make working groups to help those teams come up with plans?
18:19:38 <sgallagh> I.e. we may be able to enable downstream spins in a similar manner to how Kubuntu and Xubuntu work, without them necessarily being blockers to the core Fedora offerings.
18:19:49 <Viking-Ice> so why should the desktop team be heavily involved with "workstation
18:19:52 <rbergeron> because I do'nt think the answer is "expand # of humans" so much as "rethink how we build, test, automate" - which doesn't seem to be something that will scale well
18:19:52 <Viking-Ice> !
18:19:55 <mattdm> we will definitely work with the fedora release timeline to allow retooling room for teams that need it
18:19:56 <Viking-Ice> mean "
18:20:01 <rbergeron> if we are stlil having qa, releng, in individual silos.
18:20:08 <sgallagh> rbergeron: Yes, those plans should be coordinated with the Product Working Groups
18:20:13 <rbergeron> not that i am totally in devops/puppetconf land.
18:20:23 <jwb> rbergeron, nor do those groups have _time_ to do that now
18:21:08 <rbergeron> jwb: yes, precisely. Mostly I guess I am wondering - if the board approves this - then ... fesco? then rel-eng and qa have to make plans? or ... present plans, incorporate plans into higher-level plan, then fesco approves?
18:21:49 <mattdm> _and_ I've been assured that red hat is willing to put money where my mouth is to help with actual number of humans where we can show that it's part of a solid plan
18:21:52 <sgallagh> rbergeron: Please read https://fedoraproject.org/wiki/Fedora.next/boardproposal#Post-Approval_Responsibilities
18:21:57 <inode0> Viking-Ice: it would simply be their choice. I just want to know they are aware, interested, involved somehow now thinking about the possibility of going in a different direction.
18:22:04 <sgallagh> I was trying to describe the answer to that specific question
18:22:27 <jwb> rbergeron, to be honest, i think doing this is going to require the board and/or fesco declaring the release this happens in takes significantly more time.  then it will be gathering the requirements and plans and actually basing the schedule on taht
18:22:35 <jwb> i don't see any way of doing it otherwise
18:22:49 <rbergeron> Because basically: while I utterly approve and encourage this new way of thinking - we are essentially talking about making many more things all first class. which either means we have to triple or quadruple the workforce, or abstract some things away by re-thinking our tooling to match the flexibility that we want fedora to have.
18:22:50 <mattdm> +1 jwb
18:22:59 <sgallagh> Yes, if we're going to make a fundamental shift like this, we may need to accept a longer cycle
18:23:03 <sgallagh> s/may/will/ (most likely)
18:23:16 * tflink assumes that the part of "multiple sets of relase criteria" isn't set in stone? - emphasis on _multiple sets_
18:23:19 <sgallagh> Not necessarily permanently longer, but at least for the course-correction
18:23:37 <jwb> mattdm, on your # of humans point, it is reassuring that the main sponsor is willing to do so, but i would sincerely hope we make significant effort in finding community people invested in making this happen
18:23:40 * Sparks is here
18:23:47 <mhayden> the longer cycle would be a must... and might give us a little bit of an ability to test a semi-permanent longer cycle
18:23:59 <sgallagh> tflink: I'd be expecting it to be one primary set with specifics for each product
18:23:59 <rbergeron> sgallagh: yes, i see that. so "timeline for developing first release" seems to hinge on "qa/releng plans to fix anything / do tooling changes / etc." - if that is going to take a while, the schedule / timeline for delivery is affected.
18:24:04 <mattdm> jwb Yes. Hopeing that this makes it easier for new people to plug in, too.
18:24:07 <rbergeron> hi sparks!
18:24:35 <mattdm> some of the time dgilmore is requesting for releng is specifically to build up documentation and community
18:24:46 <jwb> hm
18:24:51 <Sparks> rbergeron: Sorry for my tardiness
18:24:59 <misc> #info each working group (cloud, server, workstation) will be have its own charter and governance
18:25:34 <mattdm> and _must_ have such a charter and governence
18:25:35 <Viking-Ice> inode0, it's seems to me based on sgallagh response it has been made clear who will dictate what will be in the "workstation" proposal in fact i'm a bit worried that it has already been decide who will do what in what ring in the community from within Red Hat
18:25:51 <jwb> misc, mattdm, still under the purview of fesco and the board, surely
18:25:58 <jwb> otherwise, you will have mass chaos
18:25:59 <Viking-Ice> this ring proposal is doomed to cause more friction
18:26:16 <rbergeron> sparks: no worries. glad to see you :)
18:26:19 <sgallagh> jwb: Yes, part of the proposal requires at least one FESCo member on the working group governance
18:26:31 <mattdm> jwb absolutely. i just don't want to dictate "must have 9 members with such and such terms"
18:26:56 <mattdm> Viking-Ice Could you elaborate on what has been made clear?
18:27:15 * inode0 thinks Viking-Ice is reading too much into what sgallagh said
18:27:21 <misc> #info governance /charter still need board/Fesco supervision, current proposal is to have at least 1 FESCO member in the group governance
18:27:36 <jwb> #info working groups will still be under the guidance of FESCo and the Board
18:27:37 <jwb> #undo
18:27:37 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x27e72e90>
18:27:43 <jwb> #info in the proposal, working groups will still be under the guidance of FESCo and the Board
18:27:52 <jwb> misc, heh
18:27:59 <jwb> #undo
18:27:59 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x27d86ad0>
18:28:08 <jwb> i think that should clear it up in the minutes now
18:28:44 <mattdm> if you all think it's easier/better to have consistent structures for each working group, I don't have a strong attachment to that -- I just suspect it will work better.
18:29:14 * jwb is still reading two things at once
18:29:16 <inode0> personally I prefer self-organization to the greatest extent possible
18:29:29 <mattdm> inode0 exactly
18:30:43 * rbergeron wonders if tflink's earlier question was answered or not?
18:30:51 <sgallagh> rbergeron: Which question?
18:31:00 <tflink> rbergeron: the important part was, I think
18:31:03 <rbergeron> "11:23  * tflink assumes that the part of "multiple sets of relase criteria"  isn't set in stone? - emphasis on _multiple sets_
18:31:11 <misc> 20:23:56|  sgallagh> tflink: I'd be expecting it to be one primary set with specifics for each product
18:31:17 <rbergeron> AH, OKAY
18:31:18 <rbergeron> oops
18:31:18 <misc> rbergeron: it seems it was :)
18:31:32 <rbergeron> okay
18:31:36 <tflink> the thought of maintaining and keeping in mind multiple sets of different release criteria is rather intimidating to say the least
18:31:43 <misc> I am more curious about the software stcks part
18:31:43 <mattdm> having a common core is also intended to reduce qa overload
18:31:44 <inode0> I'd like some idea of how new products might come into existence so we don't later find ourselves not so agile. Sorry if I just missed that somewhere.
18:31:49 <jwb> can someone elaborate on "Base Design Working Group" ?
18:31:56 <jwb> is that ring0/ring1?
18:32:05 * rbergeron has another question re: "the second deliverable should be a timeline for developing the first releas eof the product" - that's for "each individual product"
18:32:09 <rbergeron> or one timeline for everything?
18:32:19 <misc> jwb: I assume ring1, as i think ring0 is the minimal root ?
18:32:22 <mattdm> jwb yes. i will make a note to flesh that out.
18:32:24 <misc> (well, ring0+1)
18:32:27 <sgallagh> rbergeron: individual
18:32:45 <rbergeron> individual release schedules?
18:32:49 <sgallagh> We're leaving open the *option* of separate delivery cycles, but not bound to it
18:32:58 <jwb> mattdm, while not really a Board item, i'm curious how conflict resolution between products/working groups will work
18:33:13 <sgallagh> If the proposals all come in with roughly the same estimates, then naturally we'll keep them together
18:33:24 <sgallagh> If they're enormously divergent, we'll address that then
18:33:31 <jwb> mattdm, e.g. cloud wants a tiny kernel.  workstation wants a kernel with everything.  discuss (and produce a result that doesn't involve multiple kernels)
18:33:50 <jwb> mattdm, not to be answered here, but perhaps something on conflict resolution in the proposal
18:33:51 <Viking-Ice> rbergeron, that actually is the way forward ( individual release schedules ) at least for anything on top of the core/baseOS I would sasy
18:33:54 <Viking-Ice> mean say
18:33:57 <rbergeron> sgallagh, mattdm: docs, l10n - feedback from them?
18:34:03 <mattdm> jwb FESCo will be the arbitrator in general. Also individual packagers (as people doing the work) still get some input.
18:34:11 <jwb> some
18:34:15 <jwb> interesting.
18:34:27 <mattdm> sorry that was supposed to be in humorous tone of voice
18:34:28 <rbergeron> Viking-Ice: yeah, i just worry about the prospect of putting QA into a constant cycle of "always stuck in blocker meetings" - or "two separate sets of blocker meetings at the same time"
18:34:31 <jwb> ah
18:35:01 * jsmith suggests <humor> and <sarcasm> tags may be helpful
18:35:19 <sgallagh> rbergeron: docs and l10n are oversights. But you're right, we'll need input from them
18:35:20 <mattdm> individual packagers remain essential. if we need something that the individual packagers can't provide we either need to find the resources so it is possible or back off the suggestion
18:35:43 <jwb> mattdm, that's a great answer
18:36:20 <Sparks> sgallagh: I suspect that Docs will need more input and more developers to maintain the variety of documentation that will need to be written.
18:36:39 <Sparks> sgallagh: At least more input.
18:36:45 <sgallagh> More input certainly
18:36:48 <Viking-Ice> rbergeron, QA will be focusing on just the base/coreOS ( or just the cloud/server/workstation/ bits ) the rest would have to be handled by the sub-communities surrounding each spin/product by themselves and we QA and Releng be there more for assistance/guidance then any other work. Atleast that's how I see it
18:37:04 <sgallagh> I think the set of documentation they're writing will be largely the same, just split up differently
18:37:13 <rbergeron> sgallagh: basically - it's ... just like rel-eng/qa - docs/marketing/l10n, etc. -
18:37:14 <Sparks> sgallagh: Having offset releases might actually help with documentation.
18:37:17 <Sparks> sgallagh: +1
18:37:20 <sgallagh> Viking-Ice: That's how I envisioned it as well
18:37:26 <rbergeron> yes, what you just said - things just split up differently, etc.
18:37:41 <mattdm> in some cases, the rings proposal may mean that we can avoid conflict where there would have been before (again, if someone is willing to do what's necessary to maintain things in parallel)
18:37:50 <rbergeron> but there might be interesting ways to migrate that stuff together, similarly, around all the different teams, without ... causing triple-work. :)
18:38:20 <rbergeron> Viking-Ice: I agree - I still just wonder if that means cloud/server/workstation == 3 things instead of just one, if we are talking about those three tihngs being on different schedules.
18:38:55 <rbergeron> "just the base" is not quite the same as "just cloud/server/workstation" - unless it's *just the base* for all three of those things (aka base/core/whatever)
18:39:11 <Sparks> rbergeron: It is possible that they could be on the same schedule but we wouldn't need to delay all the bits if there was a blocker on one of those things.
18:39:35 <sgallagh> Sparks: The catch there is how the next schedule would happen
18:39:47 <jwb> i'm not sure that sends a great message from a marketing perspective either
18:39:47 <Sparks> sgallagh: dartboard?
18:39:50 <sgallagh> Do the ones that delay on this release get less time for the next one?
18:39:52 <mattdm> lol Sparks
18:40:01 <rbergeron> what are the responsibilities "if approved by board" for environment / softare stacks working group from a "deliverables" perspective?
18:40:04 <jwb> "Fedora 21 is released!  Oh, except Server!  Later!"
18:40:31 <rbergeron> jwb: my concern is more that we make *too much noise* that eventually drowns itself out
18:40:39 <jwb> seems like bullshit
18:40:41 <Sparks> sorry...  <sarcasm>dartboard?</sarcasm>
18:41:00 <rbergeron> sparks: :)
18:41:10 <mattdm> If the release cycles are separate, we probably need to think about separate release numbering
18:41:13 <Viking-Ice> I would say the bits that make up the core/baseOS will be on fixed the rest is on top of that is kinda irrelevant from my pov
18:41:18 <jwb> i think we can be subtle in trumpeting the newness of 3 products.  but i do think it's important those 3 be released at the same time
18:41:20 <inode0> Things at least need to be on reliable and fairly predictable schedules that can be planned around.
18:41:22 <Sparks> jwb: Fedora 21 for Workstations is released.
18:41:22 <Sparks> jwb: Seems like it becomes a bit wordy.
18:41:22 <mattdm> I'd like to try maintaining coordinated releases at least at first
18:41:33 <jwb> Sparks, exactly what i want to avoid.
18:41:38 <inode0> Often the release it all at once model is easiest for scheduling.
18:41:43 <misc> we could try to ask for 3 differents name for the 3 differents products
18:41:46 <Sparks> Would we even *need* to number them?
18:42:07 <mattdm> Sparks are you suggesting... colors?
18:42:18 <misc> so at least, the server product could not need a FAQ about why it is different from the older Fedora
18:42:19 <jwb> i'm guessing he means rolling release
18:42:23 <jwb> which...
18:42:25 <Sparks> mattdm: Or Greek Gods or something.  I don't know.  Alpha, Bravo, Charlie...
18:42:31 <jwb> oh god
18:42:34 <Viking-Ice> mattdm, it's probably best to approach this to have everything on the same release schedule and leave the option open to opt out from that
18:42:44 <sgallagh> jwb: *rimshot*
18:42:58 <Sparks> jwb: Well...  I don't really mean to go down that road... that's a completely different discussion all together.
18:43:13 <sgallagh> Viking-Ice: I can agree with that
18:43:17 <rbergeron> I am reasonably okay with all of this - I think it's a good idea - My only concern is that the proposal is largely focused on "must have 3 new things" but no focus on "to do this well we *really really* need to rethink how we Build Things.
18:43:17 <Sparks> Perhaps it would be up to the individual teams that are designing these bits?
18:43:43 <sgallagh> rbergeron: Well, part of the proposal involves gathering that information
18:44:10 <sgallagh> but that's Work, and without the Board's backing, we wouldn't want to waste anyone's time
18:44:19 * inode0 is still curious about how a fourth thing gets in the game
18:44:36 <mattdm> ah! i knew there was something else to respond to
18:44:38 <Sparks> rbergeron: I don't really understand the need to define the three things.  I could easily see four... or two.
18:44:39 <sgallagh> I don't want to send adamw and dgilmore off designing a plan if the Board is going to scrap the project.
18:44:55 <mattdm> inode0 I think it basically works like secondary arches do now.
18:45:39 <rbergeron> sgallagh: well, adamw is going on long vacation realsoonnow :)
18:45:48 <Viking-Ice> rbergeron, agreed I'm a bit worried we are trying to do to many things at ones so I recommend that we should just start small as in to get the core/baseOS bits sorted out then move to for example the cloud bits from there to server and finally workstation
18:45:51 <mattdm> Overall, I hope that the approach for this makes it easier (or is at least as easy as it is now) to make things out of fedora which are not the main thing.
18:45:56 <sgallagh> inode0: I want us to build the tooling so that other projects can grow up around the Fedora Project, without necessarily directing its development. I'm kind of looking at the Ubuntu model here where they provide the tooling to create Kubuntu and Xubuntu and Edubuntu, but they're not core pieces and carry their own schedules
18:46:18 <jwb> #idea The Board reviews the proposal, comes up with a list of questions/suggestions (if any) and provides FESCo feedback before the next FESCo meeting
18:46:20 <Sparks> Viking-Ice: +1
18:46:21 <sgallagh> rbergeron: Are you having Adam killed?
18:46:23 <rbergeron> sgallagh: kind of ike we have spins vs. remixes now...
18:46:27 <rbergeron> sgallagh: that would be idiotic
18:46:30 <inode0> sgallagh: yes, but I'm asking about something we do want to be a new core product of Fedora
18:46:49 <misc> jwb: +1
18:47:00 <rbergeron> sgallagh: i mean, who would i drink martinis with while playing poker :)
18:47:07 <inode0> while the initial group of products seems very reasonable it is also in some sense completely arbitrary
18:47:11 <rbergeron> inode0: ie, what is the board's benchmark / process for elevating something else?
18:47:13 <jwb> i would further allow that if there are no questions/suggestions, we simply vote and let FESCo know
18:47:36 <mattdm> inode0 If it becomes popular, we do the same thing we're doing with arm -- shift to building it as primary, and then when it's demonstrably ready to be there, we put it with the rest
18:48:20 <Sparks> jwb: +1
18:48:23 <sgallagh> inode0: I'm comfortable with addressing that when it comes up, rather than trying to bog it down in process up front
18:48:36 <inode0> ok, is the cloud product popular now? :)
18:48:43 <sgallagh> inode0: Extremely
18:48:48 <rbergeron> sgallagh, mattdm: so - to be clear - the expectation, if we approve this proposal, is -- everyone runs with it? or will this come back to the board once all of the plans detailed in "post-approval responsibilities"
18:48:52 <Viking-Ice> btw the server stuff will be equally hot potato as the workstation one since you have equal or more choices there which is why I'm a bit afraid this proposal is doomed to cause friction
18:48:54 <rbergeron> are sorted out?
18:48:57 <jwb> rbergeron, inode0, rdieter, mhayden, i made a proposal above in case you didn't see it
18:49:09 <sgallagh> rbergeron: There are portions of the proposal that mandate additional Board ratification
18:49:15 <mattdm> rbergeron "everyone runs with it"?
18:49:15 <rdieter> jwb: ah, consider me +1
18:49:21 <inode0> sgallagh: yeah, I don't want to bog it down, but I want some thought about it or we still don't have an agile system - we have a 3 product system rather than a 1 product system.
18:49:26 <mhayden> jwb: sorry, got dragged away, but i'm fully +1
18:49:35 <rbergeron> mattdm: by "runs with it" i mean "goes through the list of post-approval things"
18:50:04 <mattdm> rbergeron then, yes.
18:50:08 <sgallagh> rbergeron: The list of post-approval things involves planning and submitting detailed requirements, so yes
18:50:22 <mattdm> if we need to add in more post-appoval things let's do that.
18:50:42 <rbergeron> jwb: yes, i saw, i just want to make sure I am clear on "what this vote means"
18:51:03 <jwb> rbergeron, sure
18:51:50 <Viking-Ice> inode0, the fundamental problem is that we as in the whole project still have a "product" and while we do then there better be a rock solid procedure for how to actually get something to be in those products because interested parties will want to try to push their stuff on it ( as history has already taught us )
18:52:03 <rdieter> so, next FESCo meeting is... when exactly?
18:52:11 <jwb> rdieter, next wed
18:52:12 <mattdm> rdieter next wed
18:52:19 <sgallagh> rdieter: Wednesday at this same time
18:52:29 <inode0> jwb: that is fine with me
18:52:34 <jwb> we have 6 days.  4 working days.  surely we can come to agreement before then :)
18:52:37 <mattdm> i think it might be next wednesday
18:53:33 <jwb> so gholms and mjg59 aren't here.  i won't speak for either, but i'm fairly sure mjg59 would be OK with review and communicate over the next few days
18:53:35 * rbergeron is +1 on proposal - i may have a few further questions
18:53:40 <inode0> and thanks mattdm and sgallagh - I really appreciate what you guys are doing here
18:53:47 <jwb> particularly since they haven't been able to participate today
18:53:59 <mattdm> inode0 thanks!
18:53:59 * rbergeron thanks you guys for coming as well
18:54:07 <jwb> we should note that we don't have to wait until the meeting to send FESCo questions too
18:54:14 <jwb> EMAILZ
18:54:19 <mattdm> right in fact the sooner we get the questionz the better.
18:54:27 <rbergeron> jwb: yes, and i'm sure gholms has some cloudy/releng thoughts since ... he kind of does those tihngs in eucaland
18:54:52 <rbergeron> jwb: maybe a ticket for fesco where we can collect questions?
18:54:57 <rbergeron> though that's hard from a trac perspective
18:55:11 <jwb> rbergeron, not that hard.  just CC all of fesco
18:55:20 <sgallagh> We have a ticket, one moment
18:55:28 <jwb> or use theirs, since it's open
18:55:41 <mattdm> https://fedorahosted.org/fesco/ticket/1158
18:56:29 <jwb> #info The Board will review the proposal and communicate any questions/suggestions to FESCo by the next FESCo meeting, if not before.  Questions are preferred ASAP
18:56:48 <jwb> is everyone OK with collecting questions in the FESCo ticket mattdm just pointed to?
18:57:06 <rbergeron> yes, let's do that
18:57:21 <Sparks> sounds good to me
18:57:42 <misc> ok
18:57:43 <inode0> yes
18:57:46 <jwb> #link https://fedorahosted.org/fesco/ticket/1158
18:57:56 <jwb> bam.  look at us, making progress and stuff
18:58:05 <mattdm> yay
18:58:17 <jwb> we're approaching the hour now.  anything on this or anything else?
18:58:26 <jwb> as noted at the start, we have nothing else on the agenda
18:58:28 * rbergeron adds herself to CC in fesco ticket - does anyone else want me to add them while in here
18:58:32 <mhayden> always freaks me out to see "priority: major"
18:58:35 <Sparks> rbergeron: me
18:58:37 <inode0> rbergeron: sure
18:58:54 <jwb> i'll be making a comment there shortly, so i'll add myself
18:58:54 <rbergeron> jwb: i have to bail - i am on booth duty and in my room with the only internet :\
18:58:55 <mhayden> rbergeron: me as well
18:58:55 <Sparks> mhayden: Does that mean you are responsible for all those?
18:59:04 <mhayden> Sparks: haha, my brain thinks so initially
18:59:13 <Sparks> mhayden: WORKSFORME
18:59:59 <jwb> rbergeron, ok, no problem.
19:00:05 <jwb> i think we're wrapping up anyway
19:00:18 <rbergeron> jwb: are you on minutes duty?
19:00:21 <jwb> srue!
19:00:24 <jwb> er, sure
19:00:26 <rbergeron> <3 thanks
19:00:37 <jwb> #topic open floor
19:00:39 * rbergeron will type from phone when back downstairs if possible
19:00:41 * inode0 thanks Viking-Ice for contributing here and elsewhere too before we close
19:00:48 <jwb> ok, a few minutes for open floor
19:00:53 <rbergeron> inode0: +1
19:01:01 <sgallagh> Thank you everyone for your valuable feedback
19:01:03 <Sparks> !
19:01:11 <jwb> go ahead Sparks
19:01:26 <Sparks> Last year I brought to the Board an idea to recognize contributor's contributions to the Project.
19:01:47 <Sparks> I want to thank the people of the Badges project for doing just that.  Excellent work.
19:01:50 <Sparks> EOF
19:02:26 <misc> !
19:03:01 <jwb> Sparks, indeed
19:03:02 <jwb> go ahead misc
19:03:19 <sgallagh> badges++
19:03:33 <Sparks> badgers++
19:03:34 <misc> well, we didn't announce the Fedora 20 voting , afaik
19:03:40 <jwb> #info The Board wishes to thank the people working on Fedora Badges for their excellent efforts at contributor recognition
19:03:56 <jwb> misc, oh!  yes :\
19:04:07 <inode0> I noticed I only knew about it via a blog post
19:04:18 <jwb> misc, it was sent out on blogs and G+ but i saw no email announce
19:04:30 <jwb> does anyone want to send one?
19:04:41 <Sparks> We should
19:04:47 <jwb> Sparks, volunteering?
19:04:49 <Sparks> per the *new* policy
19:05:08 <Sparks> I'll send one out if someone will point me to the blog post so I can get the relevent information.
19:05:24 <jwb> inode0, do you have the link to the blog handy?
19:05:46 <Sparks> jwb: Which reminds me, I do have something else once we clear this up.
19:05:51 <jwb> Sparks, https://plus.google.com/112917221531140868607/posts/HvoxWvvDDpv is the G+ link
19:06:03 <inode0> looking ...
19:06:17 <jwb> #action Sparks to send F20 Naming vote announce email
19:06:35 <Sparks> jwb: That's somewhat lacking in information.  "Oh look, there's an election for something..."
19:06:47 <jwb> Sparks, that's literally all i saw.
19:07:11 <Sparks> ya
19:07:12 <jwb> also, i'm not sure what *new* policy you're referring to?
19:07:54 <Sparks> We also seem to be a bit out of schedule for this one:  Community vote on final name: June 08 - June 15
19:07:58 <Sparks> ^^^ From the wiki page
19:08:05 <inode0> http://www.fedoraproject.ro/vot-nume-f20
19:08:10 * abadger1999 notes if the board wants the voting extended, just ping me after the meeting
19:08:40 <misc> jwb: the one about "sending email on enough list"
19:08:49 <Sparks> abadger1999: Yeah, it seems that it ending tomorrow might be bad if we're just going to announce it today
19:09:00 <jwb> abadger1999, yes...
19:09:06 <jwb> misc, ah, ok
19:09:10 <abadger1999> Sparks: <nod>  yeah -- just ping me after the meeting with a new end date.
19:09:11 <Viking-Ice> inode0, well I do no more or less then anyone in the community so let's extend that thanks to everybody participating in the project ;)
19:09:14 <Sparks> Should we extend it a week?
19:09:15 * abadger1999 in two other meetings right now.
19:09:32 <rdieter> Sparks: +1 to +1 week
19:09:39 <jwb> Sparks, yes, that seems reasonable
19:09:51 <Sparks> #idea Extend the Release Name voting one week
19:09:54 <jwb> +1
19:10:12 <misc> +1
19:10:24 <inode0> +1
19:10:25 <rdieter> +1 (again, for the record)
19:10:29 <Sparks> :0
19:10:31 <Sparks> :)
19:10:38 <jwb> mhayden, ?
19:10:52 <Sparks> Okay, I'll ask abadger1999 after his meeting about making that happen and I'll send out the announcement.
19:11:19 <jwb> #info F20 Release Name Voting will be extended by 1 week
19:11:34 <misc> #action Sparks contact abadger1999 to extend and send the announce
19:11:39 <jwb> ok Sparks, you said you had another thing?
19:12:54 <Sparks> I talked with rbergeron about this a couple of weeks ago about all of our policies and procedures that the Board has on the wiki.
19:13:28 <Sparks> Like all successful wikis, Fedora has managed to cram as much information into ours as possible making it virtually impossible to find anything you might want to know.
19:13:36 <Sparks> So I propose this:
19:14:30 <Sparks> #idea We make a "Policies and Procedures" guide for the Board that is marked up in DocBook and published similarly as our other official Guides to make it easier for people to find out how we get things done.
19:14:54 <Sparks> The upside is that we can easily translate it and we become more transparent.
19:15:07 <mhayden> jwb: sorry, my desk is like a revolving door today, i'm +1 on extending the voting
19:15:14 <jwb> mhayden, cool thx
19:15:23 <misc> Sparks: policies for Board, or policy for more than board ?
19:15:26 <Sparks> The downside is that unless we have someone that is DocBook literate (like me) on the Board we'll have to enlist someone from Docs to do the updates.
19:15:36 <jwb> Sparks, and remove all the content from the wiki?
19:15:47 * rdieter doesnt think looking here is hard, http://fedoraproject.org/wiki/Category:Board
19:15:49 <mjg59> Hey, sorry for missing earlier stuff
19:15:53 <Sparks> misc: Well, I'm specifically looking at things that affect us.  Like the voting announcements and such
19:15:58 <mjg59> I'll catch up on backscroll
19:16:19 <Sparks> misc: I mean, there isn't a whole lot of rules and such for us but it would be good, IMO, to make it more accessible.
19:16:34 <jwb> mjg59, no worries.  quick summary: the board is going to review https://fedoraproject.org/wiki/Fedora.next/boardproposal and get back to FESCo before the next fesco meeting.  questions to be asked in https://fedorahosted.org/fesco/ticket/1158
19:16:46 <misc> Sparks: yup, indeed, but I think packaging policy would benefit from being in git :p ( but not our duty or decision )
19:17:29 <jwb> Sparks, i guess i have no idea where teh processed docbook output would live.  docs.fedoraproject.org?
19:17:31 <abadger1999> eh, from experience with infra moving sops out of the wiki... I don't know that that's a good idea.  For packaging, I've been thinking that making use of categories might be better.
19:17:34 <Sparks> jwb: And the stuff on the wiki would be removed, perhaps with a note pointing to the new document.
19:17:44 <Sparks> misc: We can make that happen.
19:17:48 <Sparks> jwb: Yes
19:18:03 <Sparks> jwb: We can have our own section on docs.fp.o where our stuff would live.
19:18:31 <misc> Sparks: we can discuss after the meeting, i prefer to keep meeting short when i am not paid to be present :p
19:18:50 <jwb> Sparks, maybe open a ticket in trac and discuss there?
19:19:02 <Sparks> abadger1999: When things are in categories on the wiki it does certainly help with organization.  The problem becomes searching for the information.  Who knows what categories exist to look for.
19:19:12 <jwb> i'm not majorly for or against it either way i guess
19:19:17 <Sparks> jwb: Sure, I can do that.
19:19:24 <abadger1999> Sparks: Make categories more integral to the flow.
19:19:35 <jwb> abadger1999, that assumes there is a flow ;)
19:19:39 <abadger1999> Sparks: front page of the group is a category page.
19:19:43 <abadger1999> things like that.
19:19:46 <Sparks> abadger1999: Agreed.  As long as the categories are linked together in some fashion and people know where to go looking.
19:20:17 * rdieter is unconvinced so far.  problems not significant, proposed solution doesnt solve all problems, and has disadvantages (editing is harder)
19:20:22 <Sparks> abadger1999: But not all groups use their category page as their front page.  Of course that's a different beast all together, though.
19:20:31 <abadger1999> Sparks: yep that's the thing -- categories are the only thing in mediawiki that have the hierarchical metaphor built in... so basing around anything else i nthe wiki is very prone to chaos.
19:20:42 <Sparks> agreed
19:20:43 <inode0> people can't ever find documentation they need no matter where it is located - isn't that some universal law of nature or something?
19:20:52 <abadger1999> Sparks: Right.  That's ppart of what neesd to be changed.
19:20:52 <jwb> inode0, mostly
19:21:02 <Sparks> Pretty much.  I can only find things in git repos on my laptop.
19:21:27 <abadger1999> Sparks: the thing I've seen in infra's move to git is that the problem isn't the wiki.  The problem is "gardening" (as quaid put it).
19:21:35 <jwb> #action Sparks to open Board trac ticket to discuss documenation strategy of Board policies and proceedures (wiki vs. docbook)
19:21:39 <abadger1999> There need to be people who update the old docs.
19:21:46 <Sparks> abadger1999: I didn't want to get into how the wiki is actually working as I figured ianweller would come in and school us all.
19:22:01 <ianweller> wiki? working?
19:22:03 <ianweller> i mean, hi
19:22:21 <abadger1999> Putting them into a git repo made that harder for infra rather than better.  I have a feeling that putting board policy into docbook will be even worse than the infra setup.
19:22:45 <Sparks> abadger1999: I've found that it made things easier for Docs
19:22:47 <jwb> clearly we need webapps for everything.  buttons to click.  massive amounts of JS to make it pretty.  OPENSHIFTSTACKSOURCE and all that
19:22:58 <Sparks> jwb: +1
19:23:11 * Sparks doesn't trust anything that doesn't have buttons
19:23:16 <abadger1999> Sparks: Yeah -- but as you said -- the docs people are able to read and write docbook... whereas the board doesn't make that a mandatory skill.
19:23:20 <Sparks> Okay, I'll open up a ticket and we can discuss there.
19:23:25 <jwb> ok, not to cut things off prematurely, but we should probably close the meeting down soon if there are no other topics
19:23:34 <abadger1999> Sparks: unless you said that docs guys will take over that maintainance and I missed it?
19:23:35 <jwb> abadger1999, docbook is not hard.
19:23:40 <Sparks> abadger1999: I did
19:23:44 <jwb> it's plaintext
19:23:50 <abadger1999> Sparks: ah okay.  Test it out and see then.
19:23:51 * jsmith can help with DocBook stuff too
19:23:55 <abadger1999> jwb: uhmm...
19:23:57 <abadger1999> hah !
19:23:58 <jwb> once the main formating is there, editing is easy
19:24:08 <Sparks> I believe randomuser said he'd help as well
19:24:35 <abadger1999> jwb: You can't fool me mister, I've written docbook before ;-)
19:24:39 * Sparks wonders if there is a Badge for stirring up trouble in a meeting.
19:24:52 <jwb> ok, anything else for open floor?
19:25:04 <sgallagh> Sparks: I'm pretty sure that's the "Chaired a meeting" badge...
19:25:08 <Sparks> I received an awesome F19 thank you t-shirt.
19:25:09 <inode0> you are just getting badges for docbook things aren't you?
19:25:23 * quaid agrees that docbook is too high a barrier
19:25:26 <jsmith> inode0: <sarcasm>There are badges for DocBook work?</sarcasm>
19:25:35 <Sparks> inode0: Used more than twenty DocBook markups in a guide.
19:25:36 <quaid> and recall that I was the one who fought using the wiki instead of docbook, but I changed my mind :)
19:25:37 <sgallagh> "Secretary General"
19:25:47 <rdieter> badge for mentioning the word 'docbook' more than X times in a meeting
19:26:02 <jsmith> rdieter: Scary :-p
19:26:17 <jwb> meeting will end in 4 <undefinded units of time>
19:26:26 <jwb> undefined even
19:27:02 <rdieter> jwb wins my quote of the day award
19:27:04 <quaid> anything more than "click edit, edit, save" is going to lose huge % of contributors - so if we had a web-based editor that hid all the docbook markup, maybe that would work
19:27:28 <Sparks> quaid: We aren't looking to have a lot of contributors for this particular project
19:27:41 <jwb> quaid, the number of contributors is strictly capped at 9.
19:27:42 <Sparks> quaid: Just one or two
19:27:55 <Sparks> jwb: End this thing!
19:27:58 <jwb> #endmeeting