Fedora Board Meeting 27 August 2010

The meeting today was a public meeting on IRC (#fedora-board-meeting on freenode) and lasted 1 hous. We continued to follow the new meeting format we introduced during the last IRC. The next meeting will be at the same time next Friday, and will be held over the phone.
By the way, I missed last week’s phone meeting, so I didn’t blog it (I was getting fitted for my wedding dress. 🙂 ) The minutes from that meeting are available, so check ’em out if you are curious.

Log Links

• Minutes (html)
• Minutes (text)
• Log

Introduction

• inode0 thanked spot and others for their tireless work on the Sun RPC-licensed code relicensing, and many attending chimed in with their words of thanks.
• mizmo mentioned sgallagher’s proposal to advisory-board-list. jsmith said we’ll discuss it further when we have a draft vision statement.

Question 1: Decentralized Technical Direction?

Are we disperse and unfocused on technical direction?

skvidal: “Fedora doesn’t have any one group/person who oversees technical direction or sets goals. Do you think that means we end up being disperse and less focused?”
Matt Domsch disagreed with the initial assertion – “that is FESCo’s (Fedora Engineering Steering Committee) role,” he said, and Spot agreed.
Jared agreed as well, “I may have a naive understanding, but I personally think FESCo should take that the lead in the technical direction and decision making role.” Jared continued, “One of the things that I’d like to discuss with FESCo is whether or not *they* think they have that role.”

With no authority to direct developer resources, are we doomed to unfocused development?

Following up, Seth asked, “FESCo has no authority or any developer resources to direct. So they can sing and dance all they want, but without any capacity to DO anything. If that’s the case, then is Fedora as an organization doomed to unfocused development?”
“Last time I looked, the only one here who can direct other people’s work on a day-to-day basis is Spot,” Matt pointed out.
Spot offered, “I’m not necessarily against figuring out if there is a way to put some of Red Hat’s devel resources at FESCo’s disposal.”
Jared stated that he was “open to proposals on how you think we can get more traction within FESCo.”
Continuing with another follow-up, Seth noted, “Spot sadly cannot direct the Desktop Team folks, as far as I know, to focus goals for Fedora, or to defocus things which are non-goals. It seems without that, we’re at the whim of whatever someone happens to be working on. and whether or not it can qualify as a ‘feature.'”
Matt responded, “Spot can’t direct me either, but clearly having a manager isn’t a prerequisite to being a contributor who gets things done.”
“I see most work/change being driven by individual developers, groups/sigs, etc. that’s where the fun happens,” Rex responded.
“But if you work on renovating ‘foo’,” Seth replied, “and foo is something everyone uses – you can deeply impact the distro.”
Spot replied, “I don’t think it is impossible for FESCo to have some say in where paid Fedora development happens, whether it is desktop or not.”
“As a board, we set the overall vision for Fedora,” Jared said. “But we depend *very heavily* on individuals to do the heavy lifting. FESCo should take a role in making the technical decisions regarding features, major changes, etc. In general, that means that we are sometimes dispersed and not working in unison.”
Matt added, “FESCo does get to approve major changes, or NAK them if they so choose.”

Can FESco stop commits?

“So, in short,” Seth said, “If there is an organization or sig who can direct developers and they have influence over important pkgs, then they win, defacto. It can’t stop their committing, not without a fistfight. I mean, FESCo couldn’t stop the KDE commits. It still can’t. If someone has commit access to a package, FESCo can’t stop them.”
Colin replied, “It should be able to, at least if there’s rough consensus they’re screwing things up, especially if it’s part of core.”
Rex added, “FESCo (or whoever) can impose sanctions, if required, for those not playing nice.”
“Well, yes,” was Matt’s reply, “but if push comes to shove, FESCo could restrict someone’s commit access if they were making commits that directly conflicted with FESCo’s direction. FESCo could also have rel-eng untag builds.”
Caillon responded, “I do think a FESCo-like thing should eventually be able to help direct, but if we want to be able to do that, we need to make Fedora more about coding and less about packaging. I think also we need to decide to ship a product that everyone can get behind, not just poop out something every 6 months because its time.” A couple of folks noted that “poop” was probably not the best choice of words, despite an earlier remark regarding burritos.
Jared tried to clarify Seth’s concern: “Are you arguing that FESCo should be able to override them? Or that FESCo is powerless? I’m not sure I follow your train of thought.”
“Exactly,” Seth replied. “Either FESCo has to have authority, or they are powerless. Those are the two choices.”
“Are you willing to write a proposal for the Board to consider that picks one of those two sides and runs with it?” asked Jared.
Seth answered, “I don’t think a proposal is possible without buy-in from various management inside Red Hat to enforce FESCo guidelines internally.”
“Well, we need to do that,” said Colin.
“I didn’t think there are sides to pick (really?),” said Rex, “it should be obvious that FESCo has the power to enforce the policies/rules it makes.”
Seth replied to Rex, “It is not obvious to me at all, and I was onFESCo for long enough to see that.”
“Ok, let’s make it happen then,” replied Rex. “What’s in the way?”
Caillon noted that the question had overrun the 8-minute limit, and Jared encouraged Seth to continue the conversation on the advisory-board mailing list. Jared concluded the discussion with, “It’s clear there are a lot of mixed feelings about FESCo in general, and we’d like to try to come to a resolution of some sort.”

Question 2: Funding and organizationof Fedora Activity Days

inode0: “Speaking of resources, as Red Hat Community Architecture funds are more and more spent to support development through FADs (Fedora Activity Days) does it make sense to have some group make those decisions? Perhaps FESCo for some of those funds?”
Matt asked, “Let FESCo spend the CommArch money and plan FADs to further its goals, so it doesn’t feel as powerless?”
Jared pointed out that FADs are primarily organized through FAMSCo, and inode0 asked, “Is the right way?”
“Some FADs have been organized around development topics,” Matt said. “It could be organized any group that wants a FAD, and within the budget constraints.”
“This isn’t just about turning them down or funding them,” said inode0, “it is also about encouraging them where they are beneficial.”
Matt suggested, “FESCo can propose FADs to further its goals.”
“FESCo could maybe just take a more active role in doing that,” inode0 agreed, “regardless of the funding source.” Mizmo and Jared also agreed.

Question 3: FESCo and Enforcement

notting: “With regards to FESCo becoming more of an enforcing body… Historically, there’s been a reluctance to … suggest … to contributors that their energies are better focused elsewhere. If the Board would like FESCo to be a more enforcing body, does that mean they are OK with taking a stronger stance in this area?”
“Gee, we’re really grateful that you’ve electrified the toilet seat,” joked Spot, “but maybe that’s not what we need right now.”
“Yes,” Matt responded, “Otherwise, what does setting direction mean?”
Colin said, “I don’t see how it’s any different from rough consensus of a project’s maintainers not allowing bad code in.”
“I think we agree that if FESCo is going to make technical decisions, it needs to be able to say no,” said Jared. “We might disagree about the exact details, but in general, the answer to your question is yes.”
Mizmo agreed, “From a user experience perspective I think its more important to say no then yes.”

FESCo and the Board working Together

“To add onto that,” asked mmcgrath, “does the Board think FESCo should be making “should” decisions as well as the “can” decisions they’re making now? FESCo seems to be a policy and approval body right now, it doesn’t seem to be focused on what Fedora should be. It’s just making engineering decisions. so Fedora’s been engineered, not designed. Does the board think they should be pushing FESCo to step in more into the design of what Fedora should be?”
“Hmm,” said Colin, “I wouldn’t say ‘design,’ but ‘technical direction,’ probably.”
“And I wouldn’t use the word ‘pushed,’ either,” Jared added. “I don’t think it’s as much about ‘pushing’ as it is ‘working together.’ I think FESCo should work together with the Board to make sure they share the same vision for Fedora, and then work together to realize that vision.” He continued, “Right now, the Board is working on their vision statement. When done, we expect to consult with FESCo to get things lined up behind said vision.”
Mizmo agreed, “I kinda think the Board and FESCo should design fedora together as a product with the Board setting the vision and FESCo determining how to best make it happen technically. Having the vision will help define the major problems – what’s a problem in the context of one vision might be a positive in another.”
“I would agree with “technical direction” as being a responsibility of FESCo,” said Spot. He noted he would love to see FESCo and the Board say “these are some big problems that we’re going to rally the community to solve.”
Matt added, “We’ve already started to do just that… There’s a back-and-forth on what the Board really means by the stable updates policy, for example.”

Should & Must & No

“‘Should’ and ‘must’ are two dangerous words to say to a volunteer,” said inode0. “Be careful using them in their direction.”
“Careful, I agree,” chimed in Matt. “But we shouldn’t be scared to use them too.”
Jared asked, “What would the RFCs look like without “shall” and “must” and “should”? We obviously need to be considerate (and even compassionate?), but we must also draw some boundaries.”
Jon responded, “I sort of think that they have to be used. And, as mizmo so eloequently put it, the word “no”.”
“I think 37signals says something like ‘say no to a feature request the first three times, consider yes the 4th time.'” Mizmo added.
Jared added, “Or, at a minimum, ask “Why?” until you get to the root of the problem, like a famous car manufacturer used to do.”

Question 4: Target User

skvidal: “What’s our target again? I was looking for it in the wiki and I couldn’t find it.”
“There’s a wiki page, but i can’t find it either!” said Mizmo.
skvidal replied, “Maybe it shouldn’t be QUITE so hard to find?”
Mizmo provided a link to it: http://lwn.net/Articles/358865/, still unable to find it on the wiki. Nirik was able to find it on the wiki: https://fedoraproject.org/wiki/User_base. A summary of the target user for Fedora is as follows:

We found four defining characteristics that we believe best describe the Fedora distribution’s target audience, someone who:

1. is voluntarily switching to Linux
2. is familiar with computers, but is not necessarily a hacker or developer
3. is likely to collaborate in some fashion when something’s wrong with Fedora
4. wants to use Fedora for general productivity, either using desktop applications or a Web browser.

skvidal said, “So we’ve precluded servers from the target. That’s fine, I just wanted to confirm it.”
“Primarily due to the lifecycle that doesn’t tend to match server deployments,” said Matt.