Because Big Data is Big… according to my data.

That’s right, folks: The Fedora Big Data SIG is here. We’re going to do things. Things that I know that Very Smart People, just like YOU, dear reader, are quite possibly very interested in.

Which things? Oh, Big Data is such a murky term. In true Fedora fashion, we shall do things that people show up to actually do and get done.  Which means YOU can make things happen. Whatever those Big Data-related things might be. Packaging, use cases, feedback, education, this is your spot.

So now that you are TOTALLY psyched: Here’s what you need to do:

  • Join the mailing list.
  • Come hang out on IRC in #fedora-bigdata on freenode.
  • Come to the randomly-assigned-time FIRST MEETING on IRC, Thursday, March 7, at 17:00 UTC. I’ll be the assigned meeting-runner and excitement-gatherer. We’ll be in #fedora-meeting-1 (NOTE THE ONE). Bring ideas and questions and whatnot.
  • Check out the newly-minted Big Data SIG wiki page. And remember: It’s a wiki, be bold, and stuff.

See you all there (in that variety of locations)!

FUDCon: Lawrence printable travel sheet – USE THIS AND MAKE YOUR LIFE EASIER!

TL;DR version: Download your printable “get me to FUDCon” sheet. It will help you. Seriously.

For those reading on (and about to be sorely disappointed by my lack of spherical or cylindrical  puns):

I know many folks are prepping for their trips to FUDCon: Lawrence – with some people arriving today (Wednesday) and the majority arriving tomorrow (Thursday), it will be a busy time. Many folks are taking advantage of the provided shuttle service, others are renting cars, etc. If you need help en route – joining #fudcon-help on IRC should do the trick,  or #fedora-fudcon will be a good place to just hang out and keep in touch with others as they arrive.

For those staying at the Springhill Suites, we’ll have a booklet for you at check-in (and by “you” I mean, a pile at the front desk, and we have about 1 per person, so don’t go crazy making paper airplanes); and we’ll have more onsite at FUDCon at the registration desk / “Command Central” for those of you staying elsewhere, or just local. Please, please, please take some time to read through this booklet – it is filled with additional details beyond the printable sheet, has a fillable schedule you can use to jot down your planned attendance for barcamp sessions, info about FUDPub, and more.

In the meantime: We’d like to make sure you get to the hotel and event, and know when to be where, so we’ve made a handy-dandy printable sheet to help you do just that. It contains super-pertinent information like:

  • For those taking the arranged shuttles from Kansas City International (MCI) to the Springhill Suites, reminder info about timing, who to look for, etc.
  • Details about when FUDCon starts, and when to catch shuttles downstairs from the hotel, so that you don’t have to walk in the cold, bitter, piercing weather, uphill, both ways. Yes, I want you on the bus on time, and we can’t all take the last bus, so I’m counting on many of you to get downstairs around 8:00-8:15 for the ride over to campus.  So we don’t start late. FUDCon starts promptly at 9am.
  • We will have coffee, water, soda onsite at FUDCon; there is free breakfast at the Springhill Suites, so be sure to eat. :)
  • Emergency phone numbers. Protip: “All the bars are closed” is not an emergency. 

And many other fun snippets and details. But don’t take my word for it (well, you sort of are when you print it out, but you’ll just have to TRUST ME) – DOWNLOAD IT! And then PRINT IT OUT. (Don’t be like Robyn, and print something out, and subsequently leave it on your printer, and then leave. Seriously.) And make sure your friends going to FUDCon have heard about it as well.

See you all as you arrive today and tomorrow. I’m sure that you will all have your ruby red slippers on, hackfests thoroughly planned, barcamp sessions ready to pitch. Yes? :) (Also – if you haven’t put your proposed hackfests or planned barcamp pitches on the wiki yet – there is no time like now, now, now! – though you are welcome to still do so, or invent new ideas,  when you get to FUDCon. 

Go on, man. Have a cow. Fedora 18 (Spherical Cow) is here.

Hopefully by now most folks have “herd” the news: Fedora 18 has been officially released, and the Spherical Cow is in the vacuum of the intertubes.

<marketing interlude real quicklike>

If you haven’t read the announcement, I encourage you to take a moment to check it out. Or, take a moment to check out the Feature List for Fedora 18.  But don’t let me stop you if you’re already downloading and just moments away from full-blown F18 glory.

Though I will gently nudge you and recommend that you read the release notes, including details about installation and upgrading. We’ve got a lovely new installer, and a lovely new upgrade tool, so it’s definitely worth reading over. And, hey, checking out the list of common bugs in Fedora 18 is worth a gander as well.

</end marketing interlude>

Moooooving on:

I think I can succinctly, udderly (what, you thought I’d leave the puns behind as we moved beyond Beefy Miracle?) summarize this release event in just a few letters:


Yes, yes, I believe that pretty much covers it. 

No, really, in all seriousness: this release was a heroic undertaking. There are people, many, many people, for which the phrase “above and beyond” doesn’t even begin to cover the amounts of effort, sweat, bugzillas, biting-of-tongues, tears, praise, helpfulness, git-er-done-ness, and general awesomeness that I have seen in this release cycle.

The lovely press folks (hi!) who get me on the phone right around this time tend to, and already have, ask the following question: What did you, Robyn, learn from this release? Well, gee, where to begin? Sure, I can go on about hindsight being 20/20, things of that nature.  But the important thing is this: Even though I knew it inherently already, I discovered what an amazing band of people the folks in the Fedora Project community are.  We didn’t shy away from doing the Hard Things, we didn’t abandon ship in the face of adversity, we didn’t give up or cut corners on the things we believed absolutely needed to be done right, we didn’t waffle on our commitment to freedom, open source, to building a quality distribution for our users and contributors. 

As we’re now in the part of this blog known as “full-on-cheese-land” – I’ll add this following thought: We often talk about Fedora’s core values, aka four Foundations – Freedom, Friends, Features, First – and I’m so glad that what we release continues to embody those foundations, every release. We continue to be committed to freedom, to having cutting-edge features, to being a leader when it comes to introducing new technology.  But most of all: We stick together. We watch out for each other. We tell each other to go to sleep, we recognize good deeds, we help out when we can, where we can.

Or to paraphrase slightly (but only slightly, because I already feel dirty not properly quoting Lennon/McCartney): We get by with a little help from our friends.

FUDCon: Lawrence is coming this weekend. (More on that soon enough.) To more heavily modify the aforementioned lyrics (aagggggh): We get beer and a little fun with our friends. It will be a gathering of getting things done and celebrating the release all at the same time, I suspect, and I look forward to seeing how everyone else around the globe is celebrating the release of Fedora 18, both because it’s just awesome, and because we deserve to celebrate ourselves and our great work as well.

Board Meeting, & user survey thoughts.

Greetings, live from LinuxCon in Sandy Eggo.

Two things I want to talk about:

First up: Fedora Board Meetings.  We do a public IRC meeting every other week, on Wednesdays, at 18:30 UTC (11:30 pacific, 2:30pm eastern, or use a time converter that I’ve conveniently already preset with the time in this link.

These meetings are open to everyone. We set aside time at the beginning of every Board IRC meeting to take questions/concerns/comments/otherwise from folks who wish to join the meeting (we used to do this at the end, but it always seemed to fall into the “we ran out of time” situation). So consider this a friendly reminder, or an announcement for those who didn’t previously know, that you are welcome to join and observe, participate, etc. – sometimes we have no questions, and sometimes there is lively discussion.

If you’re not familiar with IRC yet, this page is a good place to start.  We meet in the #fedora-meeting channel on There is also a wiki page with some light information about meeting structure and protocol for Board meetings, which is useful to read as well.

Second: I wanted to type a bit about user surveys.  It’s an old board ticket, but has particular interest to me, and I’ll elaborate on why that is. :)

So way back in Ye Olden Days, I was a new person to the Fedora Marketing team.  One of the first things I was very interested in was the idea of market research – I’ll get to my interests there in a moment – and making a page about moving forward with some various aspects of research was, literally, the third thing I ever put on the Fedora wiki. The first two things were release name suggestions. That was September of 2009.  We embarked on the epic journey of Lime Survey packaging, and, well, eventually I got sidetracked by other things (FUDCon, becoming employed, etc.)

But the idea is still near and dear to my heart.  Before Red Hat, before the motherhood period of being a stay at home mom, before Intel, I worked at a industry analyst firm, cranking out reports on server, PC, PDA (yes, I just dated myself) usage, sales, dissection of usage by vertical markets and size of business, etc.  I find data fascinating.  And part of that job was surveying people for various things.

Why I think this type of thing is useful? A few reasons. From strictly a “how many” perspective, which was the bulk of my reporting at that point, it’s incredibly useful data to a variety of information-consumers; if i manufacture parts for a PC, it’s helpful to know that if I make, say, memory for laptops, that it is unlikely that I will sell 4 billion pieces of memory, if we generally assume 1 or 2 sticks per laptop, and worldwide sales of laptops are 150 million per year. You laugh, yes, but I have seen forecasts in my time that wound up equating to “45 set top boxes per man, woman, and child, sold in one year.” At Intel, I was on the data-consumer side of this, looking at new opportunities for specific chips, so looking at this type of data could help me establish how big a market was, vs. how much we were already selling into it, etc. And finding new markets altogether was always awesome.

From a more general usage survey perspective – which was more in line with size-of-business segmentation that I did – that type of information is useful to vendors for tailoring their needs to different types of markets, or identifying which ones they can serve the best.  For illustration: If businesses between 1 and 5 employees typically use cell phones to conduct business operations, because they don’t want to screw around with maintaining phone infrastructure, and businesses between 1000 and 5000 employees use some sort of PBX or VOIP stuff, and I am a vendor that is selling a magical pink unicorn that makes VOIP dead simple and lowers costs, I could tailor the targeting/marketing of the small businesses, because they don’t have existing solutions and because they struggle with barriers to implement, and target the enterprises differently (cost savings, etc).

Anyway. My point is this: I find it interesting, I find it gives useful information to people.

We’ve talked a lot in Fedora over the years about where we are going, what we are going to do, etc. It’s always controversial.  I think one of the key sticking points is this, and again, I love metaphorical illustrations, so: If you have a group of friends, and you want to go to dinner, you have to pick a place that works for everyone’s diet, you have to pick something within budget, etc. Lots of considerations.  You never, ever say, “Let’s go to dinner in Paris,” and assume that works.  Particularly if you are not close to Paris, if you don’t have a plane, and you only have a boat.  If you live in Paris, then that’s totally attainable.  When you go to dinner, you consider where you are starting from.

But we often lack any consensus, at least, in my humble, often-wrong opinion, about Where Fedora Is Today.  And in many discussions, I see a wide variety of assumptions about usage, and they have vast differences, like, oceans-apart, totally conflicting differences. Coming to agreement on how to solve a problem when there’s no common understanding of the underlying assumptions… well, that’s kind of like, making a map to dinner in Paris that only covers the last mile of walking, and doesn’t cover the “where we started from, and do we have a plane” type of stuff. I’ve probably mentioned about 40 times that I’m sort of into planning things, so I think this is a good first piece of that type of thing.

So. Still with me? Haha.

A few good things to note about user surveys:

  • Doing them consistently (ie: with the same questions or only slightly changing what you are assessing), on a yearly basis, can give you a good way to measure “things.” “Things” being – if you focus on addressing a certain area, for example – you can see if the work done made a measured difference in following years.
  • Much of it is about writing good, clear questions.  Unbiased questions, without a particular slant to them.
  • Be clear when working with folks to develop the survey about if you’re looking for opinions or actual data.  “What is your opinion of __________” is different from “what is your primary use of _______.”

I’m really thinking of the usage data points for this survey – how do you use Fedora, what applications do you typically use, what type of hardware (desktop/laptop), that type of thing. But I’m still rattling ideas around in my head – we’ll probably tackle this more fully in marketing-land, though it has been, as I mentioned, a board ticket for some time.  There’s also other ideas along the lines of doing strictly community-people surveying, but we shall see. And of course things like – tooling – figuring out a process for translations – figuring out how to get the word out to a lot of places that we’re doing surveying – etc.

Anyway: I think it’s an important thing to do. It helps to plan, prioritize, and give people new ideas about ways to contribute or places to improve things, and a way to measure improvements or progress (aka: mustard).  I’ll write more about what kinds of specific questions I’m thinking about and how people can get involved over the coming days.

And with that: I am off to keynotes and booth duty. :)

FUDCon, cerveza, playa, baño!

The four words I need to know to get by in Valencia, Venezuela, for the 2012 FUDCon in LATAM while being an english speaker. (The fifth word may be “poker,” we shall see tonight.) I’ve had a lovely time here thus far, though the internets have been somewhat unkind to me :) I’d go on and on about how lovely it is here, and how good it is to see everyone, but you all know that stuff anyway (all true!) so I’ll skip right ahead to the meat of this post:

FUDCon here is distinctly different from from how it works in North America, and even EMEA to some extent; I haven’t had the pleasure of attending a FUDCon in the APAC region yet, but I suspect it is somewhat similar.  Lots of people showing up to learn about Fedora; there are maybe 30 or so people here from various parts of South America who are Fedora contributors, all of whom contribute in varying parts of the Fedora Project, in different capacities.  Lots of sharing of knowledge – from the use of different applications, robotics hacking, graphic design, becoming a contributor.

We did get the opportunity today to have two solid chunks of time to gather the regional ambassadors and spend some time making plans around a few things, though we did see a few folks shuffle in and out to give presentations.  It comes down to a few things, and they’re things that I’d like to be seeing ambassadors in all regions think more about.

One of the items is planning for the next year to 1.5 years. First off: the budget for each fiscal year (our money year runs from March 1 – February 28) gets set around the December/January time-frame, maybe into February a bit.  So knowing what the needs are when that time comes helps us to get the money we need to continue to do outreach, FUDCons, etc.   The things I’m talking about planning, at least in this particular situation, are specific events where we’d like a Fedora presence.  There are a few things we need to know:

  • Event name/type of conference
  • When, where, how many attendees, does it have a booth fee
  • How many people needed to staff at a minimum; how much it will cost to get people there if they need sponsorship

The “we” here is the Ambassadors from the LATAM region – finding this out for each country, making sure that there is coverage, and then prioritizing what to go to. If there are events where we want to have a bigger presence, figure out what the plan is around that.  Figuring out what the needs will be for swag at the event.

The second major issue for ambassadors here is really logistics of shipping; some countries can’t ship to others, customs is a nightmare, and items need to be printed in various languages.  We talked today about the possibilities of just possibly having a hired person specializing in shipping, or outsourcing to a logistics company who can package and drop ship things as needed, having FADs where we can put together packages and bring them home, as well as simply coordinating what countries are best for production and shipping, finding out who their friendly neighbors are, and making sure there are volunteers to wrangle ordering, payment, shipping, etc.

LATAM has spent very small amounts of money in the past; part of this is cultural tendency, part of it is simply difficulty of payment (some places don’t have paypal, we can’t directly pay in some places, etc), some of it is simply lack of coordination, or someone saying, by God, GO FORTH AND DO THINGS, the money is there. So to those of you in LATAM, please: Make plans. Think big. Let’s think about where we can go, where we can reach the most people, in this region of the world where people are incredibly interested in open source and the opportunities it can provide them.

The logistics piece is going to take a number of people to investigate; planning out the event “wish list” for the next year or so should take less time, and I suggested that September 28 (about a month from now) be the goal date for having a complete list of events that could possibly be attended over the next year to year-and-a-half.  Alejandro Perez has a wiki page already for coordinating this, and a number of people volunteered to help push in weekly meetings and to work with other ambassadors in their more immediate regions to try and coordinate this list.  Remember: it’s a “wish list” – once the LATAM ambassadors have that as a starting point, it’s easier to narrow down the priorities, so don’t be afraid to throw your favorite event on the list.  From there, it’s easier to start thinking about swag needs, and when and where things are needed, which helps from the view of ordering things like media, shirts, stickers, and the like.  Which will put us at a good point come December, right as the budget planning for next year starts.  This is also when the planned EMEA FAD in Rheinfelden will be – a fair amount of that FAD is centered around planning the next year+ of events, swag, etc. I’m hoping that we’ll be in way better shape as far as planning and knowing our target budget for next year than we ever have been by this point.

Ambassadors worldwide have always done an excellent job of being responsible with the budget, carefully weighing the value of what we spend against the return on that money, ensuring that those attending events are contributing event reports and blog posts. But I have noticed that towards the end of the year – when we are getting lower on the amount in the bucket, we tend to slow down spending – mostly because of concern about “I don’t know what other people are planning” – and I know that in EMEA and NA, I have seen people say things like, “We’ve already spent plenty, and LATAM and APAC have hardly spent, but we don’t know what they have coming, either.”  So planning – not just in LATAM, but really, in all the regions – is one thing that can absolutely help each of these groups to know what is expected in terms of spending, and helps us to be more confident about decisions towards the end of the year; ideally, spending all the money is where we want to be at, so that we don’t wind up with a lower budget in the next year.

I do want folks in all the regions to start thinking bigger – and thinking outside their normal event types.  We’ve predominantly been attending traditional linux conferences, either of the community/homegrown type, or bigger-budget events.  But I think there is definitely value in getting Ambassadors – and even non-Ambassadors who are contributing in other areas of the project who want to share their domain knowledge (and honestly, I really do consider contributors, in any area of the project, who share with others to be Ambassadors, regardless of the formalities) – to events that are more specific to interests, roles, etc.  There are Ruby conferences, Python conferences, cloud conferences, etc. – and I’d like to see us think about how we can get some of our Ambassadors and/or people who specialize in an area where there is a conference (ie: get a python person to PyCon), to that conference.  Get them in a Fedora shirt. Encourage them to submit a proposal to present. If they want to be learning at the conference, and not necessarily sitting at a booth, make sure they can get at least a small package of media and stickers to be a walking booth, to some extent – so they can spread the brand and media and knowledge at least in presentations they attend, when they meet others.  Hopefully as we start seeing people do more planning for events in the future – we’ll see some diversity in these new areas, and maybe we’ll find that those places are just as good of locations to find new users or contributors, and possibly even better.

It seems to me – with my former program manager on – that thinking about the budget, and event and swag planning, is something that we could definitely be doing on a yearly (every other release) basis, to be coordinated with the time period when the budget gets set.  (That’s not a hint, Jaroslav, it’s just me thinking out loud and wondering if that would help Ambassadors. I promise.)

I look forward to seeing what the folks in LATAM come up with over the next month, and am hopeful that these kinds of efforts will enable them to do a wider variety of events in the future – and I definitely hope that other regions (I’m looking at you, APAC Ambassadors!) start thinking about doing similar planning; I encourage everyone to take a look at Alejandro’s wiki page as he shares that information, and see if something similar will work for you.

Early morning thoughts on release management in open source communities.

I occasionally have days where, when reading a mailing list, I want to stab my eyeballs out at what I am reading.  And then I realize that: Perhaps my thoughts might be better utilized if I make a blog post.  (Bonus: I won’t look like a totally angry troll!) And then, at 4am, as I lay in bed, the thoughts still seething in my head, I say, well, maybe I’ll do that now.

And thus, today, I bring you: My observations and advice on the utilization of time-based schedules in open source software communities.

Full disclosure: I used to do program management (ie: build the schedule, kindly and repeatedly ask people to comply) for Fedora.  I learned a lot in a relatively short period of time, thanks to the awesome people I work with.  I have no certifications in project management, I have never officially studied it or taken a course in such things, and quite frankly, I just might not actually know what the hell I’m talking about.  But I like to think I know a thing or two, or that I might at least give you, dear readers, something to ponder on as you work in your own projects.

First off: There are time-based schedules, and feature-based schedules, and those are pretty much the two models I see employed in community-land.  (Yeah, yeah, agile, blah blah blah, I’m not getting into that or its relationship to these methods right now.) Time-based means that you do releases on a predictable basis, you pick a date, and you STICK TO THAT DATE, come hell or high water.  Feature-based scheduling involves identifying a list of features, and working until those features are actually done, at which point… you release.  I am not going to dive into the latter method, at least today, but I will say this: “Features” tend to suffer from what is referred to as scope creep – what seemed like a small task in the beginning gets a little enhancement here, a little extra love there… basically, they can go on for some time without being *done* according to someone’s opinion.  Which means it could be a really long time between releases.  (And that may be okay for a lot of people, but you lose out on some of the benefits I’m going to talk about.)

The benefits of time-based schedules

There are many, but these are the two big ones in my mind:

  • Out with the old and in with the new. If you’re doing time-based schedules on a short enough release cycle – 4 to 6 months, even 8 months – you know that anything that doesn’t make it into this release, is only going to be one more release cycle away, and you know exactly how long that will be.  You also benefit from looking like you’re actually making progress; potential contributors can see that things are coming out the door, and not wonder if the community they are about to jump into is ever going to finish what they are doing. Users know when new stuff is expected, also good.
  • Predictability for the community. If I know that I generally contribute to one specific thing (or perhaps more), and I know when that contribution is expected, I am more likely to make that deadline.  There is never any question about when things need to happen.

But announcing that the release date is X and patches are welcomed is, well, not enough.  Particularly if the scope of the project is large, or you have a large number of contributors. Here are the basic pieces that I think are important:


  • Have dates by which features must be proposed and accepted.  I’m not going to tell you how to decide what gets in and out; that varies from community to community.  MAKE SURE that this list is prominently displayed.  This gives people a way to give feedback. Sometimes features collide; this can help to avoid that, or at least, to ensure that changes are well-coordinated for things that are really dependent upon each other.
  • Have a date by which all features must be complete. You can scale this as you want (must be close, another date for really done). And then be very clear about the fact that features will NOT BE INCLUDED if they are not finished. Why? There may be people in your community doing documentation, marketing, translations, making test plans, etc. People need to know when a good time is to start doing all of those things, without doing it for things that are going to get dropped; they also don’t want to get hailed the day before release because this brand new thing just landed and HEY, wouldya mind dropping everything and writing replete documentation at the last second? Not cool. Having a clear cut-off is important.
  • Track the actual progress of accepted features. Make feature owners/contributors be responsible for providing those updates on a regular basis in an easy-to-read place.  Nobody likes surprises.
  • Define what a feature actually is. New and shiny stuff doesn’t have to be the limit.  Sometimes a feature can be a change in how the software is built, or the removal of some functionality or dependency.  Again, the key here is having the list of features published; removing things arbitrarily if people depend on them, or worse, if someone is actually contributing those things or would commit to improving them if they knew that there were issues that necessitated the removal, sucks.


After the point where features should be done, well, people are probably doing bugfixing for a while, and then testing and getting ready for release.  The length of time for all of these things is up to you; just be sure that, again, IT IS PUBLISHED AND KNOWN. But here are a few other things you can add to make the sprint to the finish line more efficient:

  • Have a list of release criteria.  Nobody wants to sit around arguing whether or not something is shippable. What functionality does the software ABSOLUTELY have to have to make it useful after shipping? Write it down. Make sure people are in agreement. Make sure your test plan actually tests those specific criteria.
  • Publish your test dates. Advertise them.  Make sure when you’re deciding these dates that it’s actually a reasonable amount of time to test things. Methamphetamines are illegal and bad for you, kids: don’t make your QA folks stay up 24/7 for a week.
  • Have a date on which key contributors/stakeholders/stuff-doers can meet or communicate and agree upon shippability.
  • If it is not shippable, have a pre-determined (as in: not during the meeting!) length of time during which bugs will be fixed and testing will happen before you meet again.

Some last bits of advice, at least for this blog post, for those of you who are just absolutely convinced by now (or were already moving that way):

  • Pick your date, and work backwards.  Figure out how much time it takes to reasonably test a final product, how long it takes to build a release candidate, how long you want to do bugfixing on features for before you make a release candidate, how long the development phase is, the date by which all features should be accepted and defined, how long your planning/feature proposal period is. And remember that it’s not all about the code; if you have people doing documentation, translations, etc. make sure that their roles are defined and considered as well.  And above all: Make sure people are in agreement when you’re doing this for the first time.
  • Bugs in the release process are expected. Especially the first time. Document them and fix them, yo.
  • PUBLISH YOUR SCHEDULE. Pro tip: Publishing your schedule on a mailing list and having it be the only place where it is seen is not helpful. Put it on a wiki, a webpage, whatever it is you have. People do not want to go trolling through their mail to find this when they likely refer to it often.  Newcomers do not want to search through archives in the hopes that it might be there.  Users don’t want to do that either.
  • Advertise your schedule at major milestones.  If you have a blog, a twitter account, whatever, NOTIFY people of looming deadlines and of actually reaching those milestones. If people look like they are falling behind, reach out to them personally.  You don’t want people saying, how was I supposed to know? Added bonus: you will look like you have your act together! (Even if inside you’re wondering deep down inside how the hell this is ever going to come together into something that resembles anything.)
  • Bugs. You have them. Remind people of their existence as deadlines loom. Paste the list and owners if necessary.
  • Haz too many dependencies and relationships between tasks? Taskjuggler, my friend. Use it.

And finally: If you are making the move — don’t magically cut over to a point that is skipping half of the steps above.  Seriously: If I’ve been steadily plugging away at something, and suddenly I have this major impending deadline out of nowhere that I can’t meet, or if I am a maintainer of some sort and I am suddenly faced with fix it or it disappears, that’s not a pretty feeling.  Time-based schedules can help to build your community by ensuring that people can be successful contributors to the project, which makes them come back to give more; it helps them to know when they can contribute, make changes, and helps them to prioritize your project amongst all of the other stuff in their lives.  Skipping key milestones, skipping listings of features or changes or agreement upon those changes, effectively prevents some people from being able to participate or contribute.  You can accelerate under certain circumstances – but don’t skip the meat of what needs to happen.  Good processes can help to build great communities, which can build great software. Don’t disenfranchise your contributors (who are also your best evangelists) – they are the ones who will get you through this release, and many after it, and make it better.

And now is the time where Robyn sleeps for a bit.

The Future of FUDCons

I believe we should radically change the concept of FUDCon.

(And if you think this post is looking pretty lengthy, the short version is this: ONE EVENT TO RULE THEM ALL.)

I’ve been to a number of conferences in the past few years since joining Fedora.  It’s a grab-bag of “types” – conferences like Southeast Linuxfest, SCALE, and LinuxFest Northwest, which tend to be free or almost-free, and tend to have more of a community feel; larger-scale, more commercially oriented conferences such as LinuxCon and OSCON; and conferences that are organized more around a singular group, project, or common interest — FUDCon is certainly an example, but also things like Community Leadership Summit (common interests/problems), and the OpenStack Design Summit & Conference.

In the latter example, particularly with project-focused conferences, the face-to-face time amongst project members is absolutely valuable.  It’s the place where contributors can get make decisions, do planning, and generally get things done, in a very high-bandwidth fashion. And I think “planning” is really one of the key attractors.  The OpenStack Summit, for example, is held right after release – and is the place to truly trot out ideas, gather around them, make a plan, and start breaking it down into how it will actually get done – over 3 or 4 days.  And it is not a place to “show what I did” – it is truly a “where am I going and how is the work going to get done and how does that intersect with other areas of the project” type of event.

I guess I know a thing or two about FUDCon planning; since organizing the FUDCon in Tempe, I’ve been helping out in some way or another with nearly every FUDCon. And thus, I’m going to present the following observations:

  • We tend to do a lot of “what I did” or “how this thing works” at FUDCons – and not a lot of planning.
  • Hackfests – which gather together specific contributor groups – tend to not always be well-organized, or focused around “let’s finish this thing we are working on.”
  • FUDCons are not scheduled at times which are obvious “planning points.” FUDCon Lawrence, for example, will be several months into the release cycle – not an incredibly amazing time for planning around F19.
  • We put some focus and effort into the U (users) at FUDCons – which, while valuable, does not require having dozens of contributors present, nor does it make the best usage of the face-to-face time that could be used for actual teamwork.
  • 4 FUDCons per year means that, as a worldwide community, we don’t get to get entire teams together.

The latter point is particularly interesting (and has given me a lot of heartburn).  While we tend to have more planning and hackfests at the North American and to some extent, the EMEA FUDCons, the extent of teamwork and planning done in APAC and LATAM tend to be gathered around regional ambassador leadership, and folks working on translations in that region.  Most of the project teams tend to be distributed globally; people want face to face time with their teams, and we simply can’t haul in everyone from everywhere in our current model.

I’m a true believer in planning and execution.  A lot of this probably comes from my work at Intel in strategic marketing — Intel is absolutely relentless in its planning cycle, but the focus on planning and setting goals is what drives innovation forward.  It encourages people to think big, and imaginatively; it helps to lay out a roadmap of milestones and tasks to a goalpost in the future.

And I think the model of bringing together a global community at an appropriate point in a release cycle to gather around planning and execution, rather than showing off what we did in the past and maybe working on things we already have in the works, is one that will drive Fedora forward.

What I would like to see is the following:

  • One event per year.  Starting in North America, and possibly alternating with other regions. Starting in FY14 (that’s March 2013 – Feb. 2014, for those who don’t follow ambassador finances.)
  • Get people from other regions to that event. Not “one or two from other regions”; I’m talking about getting engaged contributors with concrete plans and/or demonstrated history of contributions face to face with their teammates. So that that team can get things done, contributors can be part of the planning, take ownership of tasks, and not feel like they’re leaving out a significant portion of their community.
  • Have it at an appropriate point in a release cycle, where we, as teams or subprojects or groups or whatever you want to call it, can take advantage of the length of time before us to think about what we can accomplish over the next 2 releases, plan out activities and tasks, etc.
  • Perhaps move barcamp to the end, and have pre-scheduled, well-organized, planning/team meetings at the beginning.  Yes, I know this is probably giving some of you fits. Here’s why:
    • Barcamp sessions tend to be more around “I want to share this cool thing” – which is sometimes an idea, but more often around “learn how to use this thing I already implemented.”
    • It would be an awesome time to actually share what teams are planning and have accomplished during their time together.
    • Y’all are beat by day three, which I think is part of why hackfests wane a bit on the last day. Oh, did I mention that I think we should move to a longer event? I’ll do that now.
  • More days together.   Possibly straddling a weekend to reduce the drain on everyone’s “days off work” time, maybe not.  But we’re already travelling – and the costs of airfare tend to be higher than the costs of hotel, particularly when hauling in people from all over the world – let’s make the best of the effort spent getting to the event and make it longer.
  • Consider sharing this event with other project communities – for multiple reasons:
    • Leveraging the buying power of more attendees
    • If we’re already planning something – why not let others benefit from some of the planning we’re doing, and offer their community a way to get together in a similar, planning/doing-focused fashion?
    • It’s a great way to cross-pollinate between upstream/downstream communities – though we’d probably want to make sure we’re not going to lose focus from participants.  (Much like when we have had a FUDCon run parallel to a large-scale more general community conference (that is not focused on planning, but more on how-to’s and usage – where people really want to learn about stuff, but also want to focus on the project in which they contribute.)
    • Attract more sponsorships because of a more diverse audience. Money is nice. It pays for food and things.
  • Make this event be focused on the “do-ers” – and not the users. I mentioned previously in this post that it does not make the best use of our face-to-face bandwidth, and I’m sticking to that — and moreover, I think that trying to plan a parallel “user track” just winds up taking people away from getting things done.   This is not a “we don’t care about the users” statement in any way, so don’t jump down my throat. But I think that mixing up the event tends to leave casual users/potential users/non-contributor users unsure about what to attend, and I haven’t seen any evidence on any large scale that users magically become contributors at a FUDCon.  And there is NO REASON IN THE UNIVERSE why we can’t come up with a type of event that costs significantly less to host, requires fewer numbers of contributors to attend, and is geared solely towards users/potential users/potential contributors, and can be made repeatable in many places. The fact that a FUDCon in Pune can draw in a crowd of 500+ shows that there is absolutely interest.

You’ll probably notice that I just used the word “event” a lot, where I might have used the word FUDCon previously.  (FUDCon, for those of you who have come this far without wondering what that acronym is, stands for Fedora Users and Developers Conference.)

I envision this to truly be an event of the do-ers – people who do things, get things done.  And I’ve mentioned before the funny thing about how the word “do” is right in the middle of the word Fedora.  A new type of event – with a renewed focus and purpose – particularly if it becomes more diverse than just us – needs a new name.

DoCon. :)

And to answer your burning question, because I can reeeeeeeeeeead your miiiiiiiiiiiiiinds: Why, yes! I am aware that this will cost a crapton more money. Bringing in contributors from other regions costs more than if we brought those contributors to a FUDCon in their region – and thus a DoCon, or whatever we might call it,  would cost more than the entire 4-FUDCons yearly budget combined.

Is the cost justifiable? I think it definitely is. Will we accomplish more at one worldwide DoCon than we could at 4 FUDCons? I believe we can. Do we have to start thinking about that now? YES.

We are getting to the mid-way point of F18; FUDCon in Lawrence will be mid-through 19.  I would expect that we would quite possibly initiate this at the beginning of F20. TWENTY, folks.  That is a lot of releases – where we have done truly groundbreaking, innovative work.

We have amazing, talented, engaged contributors in the Fedora Project.  And I believe that focusing on the future of Fedora at an event where we have gathered contributors from around the world – planning where we can go and what we can accomplish over the next 2-4 releases, scoping out tasks, executing to plan, and really, dreaming bigger – will lead us through our early 20′s to become greater than ever.