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:

KNOW YOUR FEATURES

• 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.

DEFINE THE END GAME

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.

Reminder: Voting in runoff election for remaining board seat ends June 20th at 00:00:00 UTC (so on Tuesday the 19th in many time zones)

A quick and friendly reminder:

As previously announced, the recent Board election resulted in a two-way tie for the third elected seat, between Nick Bebout and Robert ‘Bob’ Jensen.

The runoff election for this remaining seat has started.  Voting started Tuesday, June 12, at 00:00:00 UTC, and will end Wednesday, June
20, at 00:00:00 UTC, which is actually occurs TODAY, June 19th, in many time zones.

Please refer to a UTC time zone converter if you are unsure of your time zone’s relation to UTC, such as:
http://www.timeanddate.com/worldclock/converter.html

Ballots may be cast on the Fedora Elections System at:
https://admin.fedoraproject.org/voting

For more general information about the election, including eligibility information, please refer to:
http://fedoraproject.org/wiki/Elections

As noted in previous announcements for elections, information about the candidates may be seen here:
Fedora Board:
* Nominations and questionnaire answers
* Town Hall Logs

Get your votin’ on, yo!

A different kind of miracle! Join Fedora in a food drive at Southeast LinuxFest for Loaves and Fishes

Planning on attending the always-epic SouthEast LinuxFest this weekend? Stop by the Fedora booth with your canned goods — we’ll be collecting this weekend for the Loaves and Fishes food pantry in Charlotte, NC.

Their priority list includes canned meats, canned pasta (such as spaghetti’os, ravioli, etc.), cereal, canned fruit, and 100% fruit juice. Nothing in glass, please!

Plus, you’ll get a little surprise in return – I won’t give it away, but as you might have guessed… it’s something that is definitely beefy. 🙂 Hope to see you there!

Bring out your votes!

So for those of you who HAVEN’T voted yet:

Voting ends today, June 7th, 2012, at 23:59:59 UTC. While you can check a handy-dandy time-zone calculator to see how far off that is, I suggest voting now.

Some other interesting tidbits related to voting:

• If you just want to read about voting and skip my long-windedness, you can read the Elections wiki page for more information.
• Voting is available for the Fedora Board, Fedora Engineering Steering Committee (FESCo), and Fedora Ambassadors Steering Committee (FAmSCo). You need to meet certain eligibility requirements to vote, and these vary from body to body.
• There is a plethora of information available about the candidates, so that you may make an informed vote; I highly encourage you to read these bits of information, which are, again, detailed on the Elections wiki page. These include candidates’ nomination information, including name and brief bio; their answers to questionnaires, which were populated with questions proposed by members of the community; and finally, two IRC town halls were held for each elected group, in which community members could pose questions live for nominees to answer.  Logs for these town halls are available for your reading pleasure. (Log links are appended to the end of each table in the Town Hall Schedule, in case they’re hard to find.  Questionnaire answers have been appended to each candidates’ nomination statement.)

I’d like to sincerely thank everyone for their participation in these elections – whether it’s voting, participating in town halls, contributing to the administration and organization of these elections, or simply helping to remind others that voting is ON. These groups help to steer the direction of Fedora in a variety of ways; be sure to cast your vote to be represented!

From the wayback machine: Tales from LinuxFest Northwest

(Note: things have been a bit hectic since attending this a while back. Teehee.)

I had the pleasure of attending LinuxFest Northwest, in Bellingham, Washington, April 28th and 29th.  This was my second year at the event, and the folks who put on this event continue to impress me with a great show.

Don’t get me wrong – I’m of the opinion that most of the regional, community-grown, Linux fests/cons/expos are just fantastic,  but all in their own individual ways. So here’s a quick wrap-up of what I find awesome about LFNW:

• Location, location, location.  It’s beautiful up in Bellingham – and the event is held at Bellingham Technical College, which has plenty of rooms, a decently-sized (though increasingly packed with more people) area for booths, and a great outdoor area where they have grilled lunch each day. Despite being 2 hours north of Seattle, they still manage to draw a good-sized crowd, and it’s close enough to Portland and Vancouver (the Canada one, as well as the Washington one) to have people driving or taking the train from out of town. This year’s party was at the SPARK Museum of Electrical Invention, which in itself is worth checking out – absolutely fascinating exhibits there.
• No keynotes.  Yes, I know some people like keynotes, and I do too, but at a two-day event it feels sometimes like… well, like you’re missing out on the chance to choose from 6 more sessions, more if they do morning and evening keynotes. People get to dig in to what they’re really interested in, which is cool.
• Awesome booth attendance. Seriously, lots of great questions here – not a lot of drive-bys for free swag, but plenty of good, engaged conversation.  Which made the moment when someone came to the booth and I asked if they had a question, and they looked at me and said, “Oh, it’s a *technical* question,” as they nodded towards Jeff in the other half of the booth, as though I was, you know, somehow incapable of answering those Hard Questions…. well, forgiveable. 🙂
• I never feel like it’s a giant sales pitch here – sure, there are vendors with booths, and lots of donations to the raffle, but you never feel like you’re bombarded with overwhelming advertisements for sponsors.

I gave a presentation on Fedora – a general “Who we are, what we do, what’s coming in F17” presentation – which was well-received, albeit by a slightly small crowd.  Which tends to be the case when you present in one of the last slots on the second day, which is much more lightly attended.  The first day’s sessions were absolutely overflowing; several sessions I tried to attend were literally completely packed, to the point that they were not letting additional folks in due to fire code regulations.  LFNW, at least from my perspective, seems to have a more hands-on, and perhaps slightly more technical, audience, and the session lineup – voted on by the community – reflects that audience.

The booth turned out well this year, despite some last-minute wrangling; a huge thanks to Leslie Hawthorn for driving to someone’s house in Portland and grabbing the reportedly very stained Fedora tablecloth, which was temporarily separated from its event box, washing it, and overnighting it directly to Jeff’s hotel at LFNW (it was beautiful and pristinely clean!).  The famna folks also cobbled together some of the last bits of north american swag, including F16 media, stickers, balloons, pens, and a few XXXL shirts, and got it to the event.

Aside from that – in addition to meeting new people and talking to them about Fedora, it’s always good to get some facetime with other Fedora folks, and I again enjoyed meeting up with Jeff Sandys this year, who organized our booth presence.  Jesse Keating and Greg DeKoenigsberg were also in attendance, and I spent a lovely meal with them catching up on life/work/things, and lots of other good folks were around as well.

 

Fedora 17: The beefiest release yet. With a side of awwwwwwww.

For those who missed this morning’s beefalicious news: Fedora 17, “Beefy Miracle,” has been released into the world, ready for consumption by freedom-lovers everywhere.

You can read the full release announcement here, but that’s not what this post is about, really.

One of the things I truly, ahem, relish about our community is our ability to play well with others.  And I think we’re doing an exceptional job of that lately.  It’s easy to look at a list of features and say, “Woo! We haz something,” but looking at the ties and bonds we are making from the Fedora Project to other communities is what’s really impressive.  When you look at things like having JBoss AS7 in F17, or having the newest version of OpenStack in F17, it’s not just “in” — it’s really apparent that we’re not just packaging something up, but we’re building bridges between communities.  People who have never been exposed to Fedora before may take their first proverbial bite, so to speak, because of their participation in these other communities; conversely, people who have never used JBoss AS7, or any of the other of the number of projects that you see in F17, may finally give it a try, simply because it’s available, and it works.  It’s mutually beneficial, and, well, it’s just rockin’.

And for that, and for so many other things: I thank you all, for being stellar community superstars, for being amazing friends, for embracing others with open arms, for scratching that itch and reaching out to other communities, and for staying up all night (multiple times), and showing the world what the open source way is truly about.

In conclusion: I promise that no corn was harmed in the making of this blog post, despite apparent corniness levels. Corn can be used for corn dogs, who are relatives to the Beefy Miracle. And we wouldn’t want that.

Go out. Download Fedora 17. Enjoy this release.  Lots of mustard — and you know that that means progress. 🙂

Best wishes to our friends at FUDCon: Kuala Lumpur.

It continues to delight me to see the investments in our APAC region FUDCons pay off in terms of attendance.  Much like FUDCon: Pune late last year, Kuala Lumpur’s attendance — at more than 400 registrants — is just huge, and is a testament not only to the desire to learn about free and open source software in the region, but also to the excellent planning capabilities of the local FUDCon team in Kuala Lumpur.

I’m sad that I can’t be in attendance at this event, but one of the amazing things about FUDCon is that they are truly designed to be shared with the worldwide Fedora community.  I know we are all looking forward to seeing your blog posts throughout the event and social media interactions, and I’m particularly excited by the enthusiasm I have seen for some real time projects, such as the crowd-sourced FUDCon book.  And don’t forget about the #fedora-fudcon channel on IRC – it’s not just a great place to interact with folks onsite, but those of us who are at home as well.

Christoph Wickert, awesome as always, is giving the keynote talk this morning — I am sure that he will have incredibly interesting and inspiring things to say, and I know that the wisdom of his Fedora experiences will be shared with you not just during his talk, but throughout the course of the weekend – and many others of you will do the same as well. FUDCon, in many ways, is truly about sharing – sharing our experiences, our knowledge, our future plans, and a few drinks – be they beer or tea or otherwise – and I hope that everyone makes the best of their shared time together in Kuala Lumpur.  There is a large audience present — let’s be sure to send them home with some great knowledge about free and open source software, a good feeling from a positive experience, and the invitation to come and participate in the Fedora Project if they have never done so before.

Give your hosts a round of applause.  They deserve it!

My best to everyone there.  I hope you all have a lovely time. 🙂

Are *you* the next Fedora Program Manager?

Many moons ago, in October 2010, I followed in the footsteps of the amazing John Poelstra (also known as Poelstra as a Service) and took a job at Red Hat as the Fedora Program Manager.

As most of you know by now… well, I have a new gig as the Fedora Project Leader, but I am still kind of toting along this job as the Program Manager for Fedora (and other projects) as well. Which means I am incredibly happy to tell everyone that there is now, officially, truly, a job opening for the Fedora Program Manager position!

So, to put this in a nutshell: The bulk of program management in Fedora-land is feeding and nurturing and publishing the schedule, wrangling features and moving them through the feature process, working with the good folks in QA and release engineering as we approach releases to get ducks in rows and do blocker meetings, release readiness meetings, and Go/No-go meetings.  There’s also an element of problem-solving, eliminating bottlenecks, and identifying and fixing broken processes.  The great thing about this position is being able to dive into problems and help people out in fixing them, and being able to do that in a variety of areas in the project. Like John, I also do some program management for other projects within Red Hat, although that was not my primary role right after joining – it was more of something to grow into, and it’s an awesome way to learn how other projects work and do things.

You can read more about the job requirements in the official job posting, but I’ll just point out that actually being part of the Fedora Project community and knowing what the heck we actually do around here is an excellent start, and you probably know more than you think you know. 🙂  Communication skills, and a dedication to openness and transparency, are also vital. And for those of you wanting to know if you have to be in a certain location, fear not: Candidates can be considered from remote locations, though you’re of course welcome to be in an office as well.

The job posting is here, and  if you think you might be interested or want to know more about the position, feel free to drop me an email at robyn at redhat.com.  But here is a snippet:

This person is held ultimately responsible and accountable for the Program Management side of the Fedora Project. This includes preparing and maintaining release schedules, facilitating cross-functional meetings, providing status to Red Hat, tracking and encouraging the resolution of release-blocking issues. In essence, doing whatever necessary to enable a smooth and efficient running distribution creation and release process through full engagement with the Fedora Community.

As such, this job is exceptionally public-facing and requires a high level of involvement in the Fedora Community to achieve these goals.

Feeling awesome because of addition!

This post, dear friends, is about one thing:

ROBYN FEELING PRETTY AWESOME, because I actually figured out how to do something.

Behold!!! Can you spot the awesome?

Yup. That’s right: The newly added, handy-sandy Trac SumFieldsPlugin has been converted into actual usage within a trac instance, and actually configured and made into queries by MOI!

Now, I know some of you are sitting there still wondering why on earth this is actually useful to anyone (while others of you are probably making grand fistpump movements and thinking of all the awesomeness this could bring).  So I’ll give you the nutshell version:

Right now, the way budget tracking works for things like Regional Support (money Ambassadors spend for events, swag, media, etc.) and for Premier Fedora Events (FUDCons and FADs) is this: People decide to spend money, we (someone with a Red Hat credit card) pay up front, or we reimburse people, sometimes before an event, sometimes after an event (or purchase, etc.)  The money spent (and thus, money leftover for the quarter or year) are tracked manually in a wiki page by the budget owner.

Unfortunately, we haven’t come up with better ways to plan out expected spending for a whole year, or to track actual expenses (for, say, an event where hotel or other expenses are incurred) directly in Trac; the receipts wind up going to the budget owner, and then they have to figure out how to aggregate everything.  It’s not efficient, and I think that with the proper mechanisms in place, that the Ambassadors and FUDCon owners and payment-makers could be more self-sufficient in terms of the tracking.

This is why the above picture is so cool: The SumFieldsPlugin allows you to do queries, and specific a field (and then column) to do Sums on.  For the above example, it is summing up spending for Q1 and Q2 of FY13, in North America (component), and only for regional spending (not fudcons). For the below example, it is showing all spending, by quarter, by region, for both Regional Support AND FUDCons.

To summarize: I am pretty jazzed about working this into an improved workflow, which a number of ambassadors are already talking about doing, which can help all of us to be less dependent on a wiki page, and even be more proactive when thinking about where spending is going for the year (for example, we could have estimated costs vs. actual costs).

Also: Thanks to a few people, of course – Spot and Nirik for doing some packaging work on a few plugins, cwickert for reviewing, to all for helping out with getting it pulled into our trac instance and for not thinking I’m c-c-c-crazzzy (outside of, you know, normal circumstances).  And to Max for grinning wildly as he reads this, right before he sends me a note telling me how totally awesome this is, I’ll just thank you ahead of time. 😀

Finally: I know it’s disappointing, but BigGiantConference is not an actual Real Event 🙂