This is part three of a series based on talks in February at DevConf in the Czech Republic. You should start with Part I, ”Why?”, particularly if your first response on reading this is to… ask why. That part covers the background and outlines some problems we are trying to solve. Part II, “What’s Happening?” talks about accepted proposals (and connects them back to “why”, again). This week, governance structure, current status, and some big-picture ideas. Then, next time, the panel discussion, and finally, Q&A after that.
As before, you can watch the video on YouTube, but there are a few reasons you might want to read this instead. First, videos are hard to skim or search. Second, time moves on and this contains
a few many updates (which I have marked with Update, so if that’s all you care about they will be easy to find). And finally, I made some embarrassing typos on the slides, which I have fixed. You can see those slides on my web site, starting with slide 18. This portion only covers three slides, but also a full third of the time: I talk a lot. (And, there’s quite a lot of new material.)
The Video, Further Continued
(For this article, we start at 22 minutes, 18 seconds in.)
This is the governance structure we’ve set up for the distinct Fedora products and the different “rings”. (Make sure you’re familiar with Part II of this series or this will all be very confusing!)
I come from a personal background where decisions are made in consensus communities after a lot of talking, and so maybe I have a predisposition for that. In any case, that’s how the new Working Groups are set up — we created five new committees, which has some people putting their palms to their faces and muttering More governance? Is that really going to help? But, I think it really will, and here’s why.
The idea for this structure came out of my work in Fedora’s Cloud SIG. If you’re not familiar with the idea of SIGs in Fedora, basically, a SIG is a very lightweight construct where you say “I want to have a Special Interest Group”, you make a wiki page for it, and maybe you request a mailing list for it, maybe you don’t — and there, you have a SIG. This is a great, flexible structure for doing open source. EPEL (the Extra Packages for Enterprise Linux repository, an immensely popular Fedora subproject) went from having a formal board and so on to being a SIG, because it works pretty well for a lot of things.
But, a SIG can easily drift out of maintenance because it’s easy for no one to feel real responsibility for it. In Fedora Cloud, it ended up with me doing almost all of the consistent work… I’d call for volunteers to do things, and people would show up and help (and make very significant contributions), but then they’d drift out again, and I think people never really felt where they could fit in to the ownership.
So, the idea for the Working Groups was to have committed, active groups, where we called for volunteers, got nominations, and assembled the people with voting responsibility, where there are voting-type decisions to be made. The groups will have regular meetings (or at least, regular communication), and these people have signed up for some accountability — but that doesn’t mean the greater SIG that is associated with that area is gone. We still welcome everyone to participate, it’s just that these people know their names are on the line for it. And, if you want to talk to someone who is invested in that way, you can easily know who they are. You can talk to those people, and you know what the framework is. (Update For the curious, the membership for these Working Groups can be found in the project wiki: Cloud, Server, Workstation, Environments & Stacks, Base Design.)
The idea is really to make more people feel empowered, not to introduce more bureaucracy. And, as Fedora continues to get bigger, some of the things that FESCo currently does can be delegated. FESCo meetings won’t be four hours every week, because many of the technical decisions can be offloaded to these working groups, so it’s a structure that’s set up for growth.
SIGs are still a thing, and the other sub-projects and teams in Fedora — the Fedora Packaging Committee, Design, Quality Assurance) — those are all still here. Exactly what their role is, how they fit into the project… that may change a little, but it’s going to change as part of a community collaboration. No one is saying that we are disbanding anything, and we still value all of these contributions and the groups all have an important part to play in Fedora.next.
Update Fedora QA “community monkey” Adam Williamson wrote a nice blog post reflecting on Fedora.next as an additive process, and since I think it’s dead-on and articulates some things I had been thinking but not saying very well, I highly recommend it as extra follow-up reading. (You didn’t expect homework, I know. Don’t worry; it’s short.)
Update It’s two months later, so quite a bit in this section has progressed from what’s in the video: much of what was future tense is now past and present.
We started with this: each of the product working groups produced something we called a “PRD”. That’s a kind of business term — a PRD is “Product Requirements Document“, and since we don’t actually have any products that we’re going to in any way sell, it’s not quite as formal all that. But we did want to make them a little more deliberate and structured than we ever have before. Basically, each is a description of what we are planning to do with Fedora Cloud, with Fedora Server, and Fedora Workstation.
At the time of the talk, these planning documents had been approved by FESCo but had not yet been reviewed by the Fedora Project Board. Update They’ve now been approved by both bodies. This is important because, obviously, this is all a big strategic shift, and those of us involved in the planning wanted to make sure we followed the proper process and have affirmation that we’re going the right way. (And along these lines, the KDE-based “Fedora Plasma” proposal is still waiting on Board discussion; I’ll include more on that as it develops.)
You can see these documents for each working group on the Fedora Project wiki.
For the next step, each group discussed the practical changes that their product will actually mean for the next Fedora release, Fedora 21 (due out this fall, sometime around Halloween). In the future, it may be that the different products each have an independent release schedule, but we decided to keep them in sync now, because changing too many things at once is dangerous, especially when (if you’ll remember back to the beginning of the talk) Fedora has gotten pretty awesome at putting regular releases every almost six months. For the same reason, what you see in F21 won’t necessarily be the grand realization of each vision — but we’ll have meaningful progress.
Then, these change ideas were broken down into Change Proposals, with a capital C. These are part of the Fedora Release Planning Process, which is a whole talk or article on its own, but in short, these proposals are our way of coordinating development across the project. Each is reviewed and approved (or, sometimes, rejected) by FESCo, and that’s what we’re in the process of going through right now, with coordination from fearless Fedora Feature Wrangler Jaroslav Řezník.
The accepted Change Proposals (including those from other parts of the project) form the roadmap for Fedora 21. It’s not all set yet, but the overall picture is becoming a lot more clear as proposals go from vague handwaving to actual plans for things to build, code to write, processes to reengineer — and as we get commitments from project members who are excited to do those things.
(If you’re inspired by any of this, or inspired to do something which I haven’t even mentioned, Fedora has a lot of room to get involved. You can easily join Fedora if you’re not a contributor already, and if you are but aren’t quite sure where to help, talk to me or anyone else involved in the project in an area that interests you. We’ll hook you up.)
But Wait, There’s More!
So, those things — the products, the Environments & Stacks and Base Design rings — are, so far, the most visible, obvious changes that make up Fedora.next. But there are more things which I like to include under this umbrella. Not everything has to have this brand, of course, but, in a way, everything that’s in the future decade of Fedora is what we’re talking about when we say “Fedora.next”. It’s not specific little ideas, but the big direction setting. So, these are some other areas which I think are important to where we need to go.
We really have very little of this in Fedora Quality Assurance and Release Engineering, and in order to deliver three separate products, and in order to address any needs beyond those products, we really need to step it up.
And, we are. The QA team is working on a system called Taskotron, to do automated testing, both for packages and distribution-wide. This is based around Buildbot, an open source Continuous Integration framework, but with features beyond that and integration into our environment. The QA team asked for extra time to work on this, and that’s part of why Fedora 21 has a longer-than-usual development cycle.
Also, Fedora Release Engineer Dennis Gilmore gave a talk at DevConf on Building an Agile Fedora Release Engineering, where he covers change related to Fedora.next, and puts out a call for people interested in contributing. I encouraged people to attend that talk in February, and if missed it but are interested, I encourage you to watch the video now and contact the Rel-Eng team to get involved. A lot of what’s currently done by hand needs to be made more automatic, and there are many areas which could use optimization in order to better handle Fedora’s growth.
HyperKitty and the Fedora “front page”
Fedora has some communication issues — each part works fairly well, but we have a lot of separate areas which we don’t always communicate across. And the Fedora devel mailing list has always had a lot of noise, making it hard to pick out the signal. HyperKitty is a web-based interface to our mailing lists. Again, it’s additive. It doesn’t take the mailing lists away, but it lets you interface with them in a modern way. If you like the old way, cool — still there. But if you want something more, this is not just prettier but enables features that we can’t do with mailing lists.
Designer Máirín Duffy gave a talk about HyperKitty at LibrePlanet 2014, and you can see the slides for that (with video hopefully coming soon. There is also a staging instance online. Be aware that it’s running on underpowered hardware and is only periodically synced with content from the the real lists, so don’t set your expectations too high, but you should be able to get feel for what it will be like.
I also have this idea which Fedora Engineering development ninja Ralph Bean dubbed “Fedora Front Page”. It’s basically an aggregator of everything that’s important in Fedora right now, a kind of stream of content that’s currently important across the project and specifically information that’s of interest to you as a Fedora contributor or active user. Right now, if you go to http://fedoraproject.org/, it’s a very pretty front page, but Fedora contributors probably never look at it, and Fedora users might visit it a few times, think “oh, this is a nice brochure”, but never look again. It was designed to be a brochure site, and it really does that well, but I think we need something that is more of an active center. The Internet, these days, is of course centered around the web, so we should move our active center out of being mailing lists and IRC onto a web site.
Update The Fedora Design team and Fedora Websites have picked this up. I’ve covered it a bit in my Five Things in Fedora This Week posts, but the best place to learn more is Máirín’s blog — see A proposal for Fedora’s website (considering Fedora.next). She and Fedora Designer Ryan Lerch call this part the “community hub”. I’m excited — this is going to be really useful.
COPRs, Fedora “Ugly”, and EPIC
You’ve probably heard of COPRs by now. Basically, this is personal package repos that anyone can create, with a very low barrier to entry.
Update This is in production now. The website is at http://copr.fedoraproject.org/ (and I guess we are spelling it “Copr”, with no s and fewer capitals). There’s actually a nice introductory blog post over on Red Hat’s developer blog — see An Introduction to COPRs, and since this whole article series is nominally a recap of DevConf, you should also watch developer Miroslav Suchý’s DevConf talk.
The next thing is “Fedora Ugly” — an idea that came up at DevConf. It’s a way for software to move from Copr towards the main Fedora distribution, where packages are integrated together in a way that Coprs aren’t, but yet not having to climb the high wall that is getting into Fedora distribution proper. So this is a practical way we can do that thing I was talking about, where we have packages that aren’t pretty, but we still include them in Fedora the project and make them better while they are part of Fedora — rather than saying “you can’t play with us until you are perfect”, which is really our current approach.
Update This, too, is happening. As you’ll see from the question and answer section later, people weren’t really fond of the “Ugly” name, and the Environments & Stacks Working Group settled on “Playground”. Their initial plan is up for wider discussion now, and the official Playground Repository Change Proposal will go through FESCo review as explained above.
And, “EPIC”. This is an idea from Fedora Project Leader Robyn Bergeron for a repo that fits between EPEL’s 10-year RHEL-matching lifespan and Fedora’s fast moving cycle. That’s Extra Packages for Infrastructure and Cloud — of course, mostly to make a cool name. Update And this one is championed by Fedora project member and long-time EPEL contributor Stephen Smoogen — if you’re interested, vote for his “EPEL.next” talk for this summer’s Flock to Fedora conference. (And I hope it’s not too gauche to at least suggest that if you’ve read this far in the series, you might be interested in voting for some of the other Fedora.next proposals as well.)
Next… an easy, quick docs site. Fedora’s project wiki is a tool that’s used for a whole bunch of different things — a lot of it is process documentation, a lot is guidelines for Fedora developers, a lot is active pages used in actual workflow. Mixed in with that there’s some user documentation, but if you want to find user documentation about Fedora, good luck finding it with a search. Someone basically has to point you at it. And then if you click on some link and go out of that maintained part of the wiki, you are in crazy-land and could easily land on anyting: outdated information from six years ago, or worse. It’s a big mess, and it’s really so bad that’s a barrier to even getting started in contributing, so I think we need something new that’s clearly separate.
The other side of this is the Fedora Docs project (http://docs.fedoraproject.org/ — this is excellent, almost book-level documentation. It’s very high-quality, but it’s also created through a relatively heavyweight release process, so if you want to contribute to the documentation in that way, you’re kind of committing to a joining a whole subproject that has its own processes and culture — and there’s nothing wrong with that, and everyone who does that is awesome, but, if you just wanted to throw up a quick HOWTO, Fedora isn’t really equipped to accommodate that.
The Fedora Docs people are aware of this, and have ideas for making this better, so if you have suggestions, you can talk to me, but even better talk to them about helping. Update Yet another thing which is moving forward. Docs team lead Pete Travis has a blog post about a recent activity day focused on new contributors, and the Fedora Cookbook came out of that. Read more at Pete Travis: Open Books, and watch for more about it in Fedora Magazine soon.
Watch for Part IV In Two Weeks
Next week I will be at Red Hat Summit (at the Fedora booth, of course, and wandering around DevNation), so while there is a chance I’ll have the next installment ready, I don’t want to promise and then not deliver. So, let’s say the next week. I’ll cover the Working Group summary presentations, and the week after that, questions and answers (from both this talk and from the panel discussion).
And I’m going to find some more pictures. Without the slides to break things up, this is getting a bit text heavy. Sorry about that.
As before, let’s continue this conversation in comments and replies, and in addition to responding, I’ll distill that into a final Q&A post at the end of this series (separate from the summary of the questions at the conference).