From 2013-08-14 meeting:
AGREED: FESCo would like to move forward with exploring concrete ways of implementing the tiered model roughly laid out in http://mattdm.org/fedora/next and would like the Board to let us know if they object to that general direction (+7,0) (nirik, 18:12:10) AGREED: send to the board the idea of fedora producing 'products' and allow fesco to work on a detailed proposal around those and what might be in them, etc. (+7,0) (nirik, 18:43:03)
The board meeting the next way was generally positive as well, so here's a draft of a more formal proposal:
https://fedoraproject.org/wiki/Fedora.next/boardproposal
As noted at the top of the page, this is currently a first draft and needs more work.
Working on draft at https://fedoraproject.org/wiki/Fedora.next/boardproposal
Ok, so let's start the dance. Basically, I agree with most of the proposition, but yet, I do have a few questions/remarks :
since we will have 3 different target products, I think that websites, doc and marketing team would also be quite impacted. I assume each product will have a website, release notes, etc. Like QA, they are important for the product, and like QA, I am sure they do not have too much volunteers at the moment. So it would make sense to treat those team like we treat QA in the draft, maybe as a 2nd step. Maybe for some of them, this would mean there is no increase in term of work needed, but I would prefer to have it explicitly said. IE, do we expect to have a team for website for each product, or do everything in the same team, same for doc, marketing, etc.
on having 3 products, I am not sure up to what point the branding would be the same. I am not a marketing specialist, but if current Fedora do have a reputation of not being suitable for server, maybe we need to address that by having a different name/brand ? I am sure that trademark fall under board duty, not sure about branding. Would this be under the working group mandate and things that need to be done ?
Despites having read again the whole thread, I am still uncomfortable on the last part of the summary, about rings 2 and less stringent requirements.
Replying to [comment:6 misc]:
This is a good observation. I'll update the draft taking these groups into account.
Additionally it occurs to me that while we specifically say that someone from FESCo must be on each working group, it would also be good to make sure that qa, docs, web, marketing, and releng have representation, through either a member from each of those groups on each team or at least someone designated as a liaison. (Either an existing member or someone new committed to the role.)
I think this is something the working groups should come up with for approval from the board. The general branding strategy for all three products needs to be coordinated.
Is it the summary you're uncomfortable with, or the concept itself? What would it take to ease that discomfort?
The concept, or rather, what I imagine it could mean in practice. I mostly assume this would be around packages, but maybe I am wrong. And so, to me, the requirements around packaging are part of what make Fedora be a good distribution, like the Debian guidelines and the fact they are applied everywhere is what make Debian being Debian. So while I am not against exploring, I fear this would make the distribution less consistent, and I am not sure how Fesco would ratify different requirement of what they created before.
But as I try to explain what make me a bit uncomfortable, I realize that I can also simply join the working group and participate to make sure we avoid something I would see detrimental for the project, so I guess I can wait for now.
/me Just updating this ticket with what was discussed at last week's meeting: homework for FESCo members was to read the proposal
We'll want to start discussing it at this week's meeting.
About the "point of contact" for teams - it's definitely what we want, we already lack resources (and it's pretty hard to release even now, when we have everything in one place). It should work more as having one QA, one docs etc. team and delegate persons from respective groups to join this "main" teams, to help with doing stuff, setting policies etc.; we can't afford not cooperate on this field. Even for real own governance for every single product it's going to be a bit too much - you can see how many people are interested in to serve current bodies (and yeah, there was FKDESCo for a few weeks ;-).
I'm really trying to make sure all teams cooperate together so we still need this highlevel overview on top of it and I'm definitely willing to help setting it up. Actually one of the ideas of current planning process is to off load as much stuff to SIGs, so we are almost there! (that was something I really wanted in the process) and allow cooperation between teams - development, QA, marketing. So adding flexibility to the way how we make things also leads to more responsibility, and even stricter highlevel governance, planning, tracking, so we don't fall apart ;-).
In summary, these are my two main concerns - resources (I hate this word sometimes ;-) and making sure we still fit together at some (high) level.
I realize this is late :( Still, hopefully better than trying to use 60-char lines in IRC.
Replying to [comment:10 jreznik]:
About the "point of contact" for teams - it's definitely what we want, we already lack resources (and it's pretty hard to release even now, when we have everything in one place). It should work more as having one QA, one docs etc. team and delegate persons from respective groups to join this "main" teams, to help with doing stuff, setting policies etc.; we can't afford not cooperate on this field.
I think I agree with you, but am a little unclear on your terms and which direction you see this going. Do you mean to ask for existing QA team members to join the product groups, or other way around, where each product group has a new member that they add to the QA team? (To me, both are good, as long as someone sees that communication as their area of responsibility and lives up to it.)
So, in this proposal, where do non primary products live? Is there anything like spins or a place to create a process for them?
Might make it clear that FESCo reserves the right to overrule the working groups (but hopes to not do so).
Some of the groups in next steps may have to wait on others. ie, releng may not be able to provide information until a set of deliverables is determined by the other working groups. Might note that FESCo should coordinate this effort and try and keep everyone communicating.
So two of the concerns I raised at the board meeting were related to the particular three products in the proposal.
Where did these come from? How were they selected? While they seem reasonable (at least to some people) on the face of it they also seem arbitrary. Over the coming years I expect other products will seem equally reasonable and I am not very happy with the suggestion for how any potential new products will move into the Fedora product suite. Following the example of promotion to a primary architecture in many cases would translate into years of lost opportunity while others grab new markets.
Agility at the Fedora product level is something I would love to see defined. Agility on the fringe of the core products is wonderful and is one of the things I like about the proposal overall. But agility at the project product level I think is what would really pay big dividends in the future.
Replying to [comment:11 mitr]:
I realize this is late :( Still, hopefully better than trying to use 60-char lines in IRC. The "3 distinct operating systems" wording worries me. Do we really want the 3 product to diverge that much?
We want them to diverge as much as they need to but no more. (In the same sense as "simple as possible, but no simpler").
If the longer server lifecycle is not a part of the proposal, let's not make it a part of the proposal. (I'd rather have working updates than a long enough lifecycle, for example.)
Okay. Dropped.
Overall, the proposal is getting rather process-heavy. It's starting to seem as if actual development could only start in ... 12-18 months?
Since you made this comment, we reworded the section on deliverables to be more aggressive. I agree that we don't want it to be dragged down in endless process.
[several comments related to this skipped]
An alternative that would allow us to start actually working on the PRDs right now: Keep the existing shared release cadence (until a WG actually asks for a change) Pre-seed WGs with subsets of FESCo members (+ invite others to self-nominate possibly?) Use the spins process for product delivery
+1 to all of these except I think that the spins process is an implementation detail that doesn't belong in the proposal here.
Replying to [comment:13 kevin]:
I hope that the tools and process developed to support this also make it easier to make "secondary" products. I would certainly be sad if Fedora lost Xfce. If you have thoughts for how that should fit into the proposal here, I'd love to hear them. (I would like these things to be more product-like than spins currently are, too -- more like http://xubuntu.org/, but probably also more closely aligned (eg. could have fedora url).
I think that subcommittee of FESCo implies that, but if you have an idea for better / more clear wording, I'll be happy to take it.
Yes, definitely. (Change made to fesco responsibilities)
Replying to [comment:14 inode0]:
So two of the concerns I raised at the board meeting were related to the particular three products in the proposal. Where did these come from? How were they selected? While they seem reasonable (at least to some people) on the face of it they also seem arbitrary. Over the coming years I expect other products will seem equally reasonable and I am not very happy with the suggestion for how any potential new products will move into the Fedora product suite. Following the example of promotion to a primary architecture in many cases would translate into years of lost opportunity while others grab new markets.
Stephen Gallagher proposed the three-product idea initially, and it was refined through discussion at Flock and afterwards in FESCo discussions and through this conversation. The specific products cover areas we think Fedora both can and needs to succeed, and where we have an expectation that there are actually people ready to work on them.
I guess I just disagree that the secondary -> primary promotion mechanism is too slow and heavyweight, at least as it has applied to Arm. (Overall, actually, this proposal should make that more lightweight.)
I think we need to allow that, while also having places to focus our resources to the extent that we have the power to do so. (Either by inspiration or by asking our sponsor; both of those things are hard to do without a target.)
Replying to [comment:17 mattdm]:
Replying to [comment:14 inode0]: So two of the concerns I raised at the board meeting were related to the particular three products in the proposal. Where did these come from? How were they selected? While they seem reasonable (at least to some people) on the face of it they also seem arbitrary. Over the coming years I expect other products will seem equally reasonable and I am not very happy with the suggestion for how any potential new products will move into the Fedora product suite. Following the example of promotion to a primary architecture in many cases would translate into years of lost opportunity while others grab new markets. Stephen Gallagher proposed the three-product idea initially, and it was refined through discussion at Flock and afterwards in FESCo discussions and through this conversation. The specific products cover areas we think Fedora both can and needs to succeed, and where we have an expectation that there are actually people ready to work on them. I guess I just disagree that the secondary -> primary promotion mechanism is too slow and heavyweight, at least as it has applied to Arm. (Overall, actually, this proposal should make that more lightweight.)
OK. We can disagree on this but there really isn't any way to directly compare architecture promotion with dubbing something an official product of the Fedora Project.
So for some perspective I'll add that I think a cloud product years ago would have been appropriate. What is it taking for us to get a cloud product? A complete overhaul of the way we do things it seems. I don't want the next new product to either have to wait 5 years too long or to recreate everything about how we do things to get into the mix.
With a suite of products it also seems rather obvious to me that some products will not pan out as hoped for and there should be a reasonable way to cut our losses and move ahead with or without a replacement rather than continuing to sink resources into a product that isn't paying enough dividends.
This stuff I don't think is that important to me to have included in this proposal. FESCo and/or the Board can probably reasonably deal with it but I would like some thought somewhere to happen about how we might deal with it 2 or 3 years out. Perhaps you can take this as just me thinking out loud.
Agility at the Fedora product level is something I would love to see defined. Agility on the fringe of the core products is wonderful and is one of the things I like about the proposal overall. But agility at the project product level I think is what would really pay big dividends in the future. I think we need to allow that, while also having places to focus our resources to the extent that we have the power to do so. (Either by inspiration or by asking our sponsor; both of those things are hard to do without a target.)
We can agree on this. I just hope to be nimble about adjusting the product suite as circumstances change in the future. I have no objection at all to beginning with some desktop/workstation, server, and cloud product to focus everyone's attention on.
Some thoughts:
Perhaps we need another group to shepard 'ring 1' ? Ie, the current collection of packages we have that meet guidelines, etc. This group could also handle things that wish to create products (that are not primary) from that collection. I suppose the other alternative would be to just have this be part of the "Environments & Software Stacks Working Group", but that seems like overloading them with different things.
How about replacing the wording around the three products with: "we propose these three initial products" clearly implying that other things can come along and be moved into our target products. Then add a "The Board can create a new target product" (Or FESCo I guess, but a new target implies to me new direction or goals that are more a Board issue.
Replying to [comment:18 inode0]:
If a promise outside of the proposal that we intend to reasonably deal with it is sufficient, I'm very happy to go with that.
So, at this point, I think that most of the concerns raised have been addressed, with the notable exception of secondary products and a process for that. If we can agree that that will be taken care of outside of this proposal, I think this is basically ready to go. There are two approaches we can take:
Replying to [comment:19 kevin]:
Isn't that mostly existing FPC + FESCo?
I could go either way on this. I don't think the last part is required but I'm open to spelling it out. The first part certainly softens the focus, and I'm more in favor of stronger focus -- but if the board prefers it that way, okay.
At board meeting today, board had a couple of changes:
And they want to vote given that. So, I'm closing this and opening a board ticket.
Board ticket https://fedorahosted.org/board/ticket/163
followup from board ticket 163, the board is unanimously in favor of moving forward with draft proposal.
Replying to [comment:26 rdieter]:
Thanks Rex and all the rest of the Fedora Board.
I'm going to close this ticket and open a new one for the next step -- working group call for volunteers.
Login to comment on this ticket.