Tag Archives: contribution

Contributing to Pagure made easy.

I don’t get as much of a chance these days to do things like patches or other technical contribution. But I had some time free the other day and used it to stick my hands directly into a cool project, Pagure (pronounced roughly “pag-yOOR,” or listen here). You may have read about Pagure in this Fedora Magazine article a few months back.

It was tremendously easy to get Pagure, fix a bug, test the fix, and contribute it back (see my pull request here). I specifically looked for “easyfix” bugs, since I knew I didn’t have a lot of time to spend to help. So I decided to work on this issue, a button showing up when it shouldn’t.

First I forked the repo in Pagure. Then I cloned my new fork, and set it up as documented in the README. In the clone, I checked out a new branch using the issue number as a name, issue839.

To track down the fix, I ran the app locally and duplicated the error. I looked at the CSS style containers for the button and some of the surrounding elements. Using that information, I did a text search on the code to find the file that was generating the button. Then I simply applied some logic to find the fix for the problem, even though I wasn’t really familiar with the code involved.

Thankfully Pagure has a test suite, so I could also check that my fix didn’t break any of the tests. Then I committed and pushed my changes, and made a pull request using the button in Pagure’s web page.

I also learned something useful. Since I forked the repo to do my fix and make a pull request, if I force-pushed changes using git to my branch from which I made the pull request, the pull request was automatically updated with the changes! This is probably expected by people who do this all the time, but since I’m new at it, I was excited.

Bugs like this are something that just about anyone with a small amount of beginning programming skill could fix. Pagure even has other bugs like this waiting for people to handle. Maybe one of them is waiting for you! 😉

Fedora kernel engineer.

Red Hat has an immediate opening for a full-time engineer to join the kernel team in Fedora Engineering. This job will work with Josh Boyer and Justin Forbes to maintain and improve the kernel in Fedora, and participate and contribute to upstream development and testing. This job interacts with the Fedora team and community, the RHEL kernel engineering groups, and the upstream kernel community.

Ideally we’re looking for someone with significant kernel experience. We want someone who can help manage our own kernel releases. But also we want to get patches and code upstream where it can benefit the entire community, for example to improve hardware support. Red Hat’s a challenging and exciting place to work, and the Fedora team is a great bunch of people to work with. A talented, motivated kernel hacker will find plenty of opportunity here for growth and collaboration.

Applications are being accepted now. You can find more information about the job, and apply online, via the posting here on our Red Hat Jobs site.


Git by a bus.

David Gay pointed me to an interesting project called Git by a Bus. Git by a Bus analyzes your git repository and attempts to quantify risk of having lots of code knowledge tied up in only a few people. Git by a Bus does its analysis by going through the repo history and making an estimate of what it calls unique knowledge.

This project blog page describes the analysis and metrics used. Perhaps this is a useful way to show how Fedora is doing as a project, across repositories like our web applications and infrastructure. It might show where we need to encourage further community development and participation so we avoid the “eaten by raptors” problem.

You might recall that “eaten by raptors” is Fedora shorthand for “hit by a bus” (violent idiom) or “going to work for another company” (not always applicable to Fedora, although certainly to Red Hat as a major contributor). We try to solve this problem by spreading project knowledge and documenting our processes. That way, if someone was eaten by velociraptors, the project can keep going without too much of a disturbance. This problem is common to any team or enterprise, not just open source. But I like to think our velociraptor spin is unique.

Here’s an example output I prepared for the MirrorManager project, which we use to provide content to Fedora mirrors worldwide. This is a potential example of high risk. One developer (the inimitable and awesome Matt Domsch) has unique knowledge of this project that is at risk if velociraptors manage to track and eat him. No doubt Matt would put up a good fight, but as you probably know they are clever girls.

Thankfully, there is a MirrorManager related Fedora Activity Day happening later this year. During that time the Fedora infrastructure, release engineering, and applications teams hope to accumulate and document more MM-related knowledge. At the same time they’ll be using this knowledge to architect, plan, and further develop the next revision of MirrorManager.

If you’re a principal in an FOSS project using git for your code, you might find Git by a Bus useful.

Sub Hub hubbub.

Have you seen Máirín Duffy’s post on the Fedora Design team’s next-generation design for the Fedora Project website? It’s a brilliant design based around the idea of a “sub hub.” These screens help customize the website to fit different sub-communities, initiatives, teams, or projects.

Máirín published this post with the design mockups a few weeks ago and they’re still open for feedback. I love the concept and the mockups, and the way it brings the site a little closer to the functionality people expect for interaction in other communities. The sub hub design offers a sites not just for promotion, but also for bringing people together for communication and information.

I’m sure the Design team will move forward at some point to bring these concepts into reality. But before they do, I know they’d appreciate hearing from community members. Even just offering feedback that “This is awesome!” is useful, so the designers know there is a solid mass of people who like the work. You can visit the site here to offer your constructive comments.

If you don’t, that’s OK too! Just be polite and specific in your comments. Rather than saying how to fix something, talk about why something doesn’t work for you. Designers are good at figuring out how to solve usability problems once they know more about the effects on the user. Those of us without a lot of design and usability experience often suggest solutions that seem like they’d work, but really might cause more problems for other users. So it’s best to concentrate on symptoms.

So if you haven’t checked out the post and offered some constructive feedback, please feel free. I’m really looking forward to seeing how things move forward with these designs and hope you’re excited about them too.

If you’re excited enough about the work to get involved and help, the Design team would love your contributions. There’s also more information about how to contribute here. There are several repositories set up where you can test existing ideas, change them with your own, and contribute changes back to the team using a pull request. Getting involved is easy, and the Design team is famous for their friendliness and willingness to help people get started contributing. So don’t be afraid to jump in!

PulseCaster 0.1.10 released!

Today I released PulseCaster 0.1.10 with some under the hood improvements:

  • Switch from GConf to GSettings, and include schema file
  • Providing appdata for GNOME Software
  • Provide hidden “audiorate” key for 44.1/48 kHz selection
  • Complete GObject introspection switchover, eliminating excess dependencies and fixing bugs (RHBZ #1045717)
  • Automatically provide .ogg filename extension in standard mode
  • Additional translations

I’m planning some UI improvements for this little podcasting utility. I’m also hoping to do significant code refactoring for 0.2, tentatively scheduled for late spring/early summer. I’m also thinking about moving the central development repo to GitHub, since that’s where a lot of other Fedora incubated projects have migrated.

Of course, updated packages are coming shortly for Fedora 20.

PulseCaster lets you record interviews with simplicity. It pulls audio from two sources via PulseAudio, then mixes them into an Ogg Vorbis file for you. There’s also an expert mode that allows you to lossless audio in WAV format, and mix the audio yourself with post processing. For example, you could interview someone via a Voice-over-IP (VoIP) application, then include the interview in your podcast.

I used a little time between sessions (and during one session where I was completely in over my head) to push this out. It was nice to work on some free software of my own at a conference for developers! Hope you enjoy the new PulseCaster release.

Contributions of late.

Here’s a smattering of stuff I’ve been doing in the Fedora Project lately. Although I don’t get to spend as much time on Fedora in my new job, I’ve been putting aside some off hours and a portion of Friday (or as I like to call it, my “no meetings day”) to make extra headway.


    Jiffy Pop meeting minutes.

    For some reason this week I feel like blogging about some of my time-saving tools. I’m certainly not a superstar when it comes to eliminating wasted time. But when I was FPL I had to figure out ways to be more effective so I could spend more time on the tasks that truly required it.

    If you run meetings online, you probably already know there are cool projects like Debian’s meetbot to make the process easy. You can give instructions to the bot during the meeting, which are recorded in the minutes, using commands like #info, #agreed, #action, and so on. We use meetbot in Fedora as well, for just about every meeting we run. We even use it to log hackfests and other groovy online get-togethers.

    But how do you get those minutes out to subscribers of the team’s mailing list? I’ve seen some people encounter problems doing this quickly. Those problems cause stress, because you want to do a good job for your teammates. If the process is hard, it’s tempting — heck, sometimes it’s necessary — to put it off, so you can do other priority tasks. Then you feel guilty about it later when the minutes aren’t out on time. Wouldn’t it be great to eliminate that stress and guilt?

    Now, I have zero doubt that someone could automate a no-time-required solution, and maybe some folks out there use such a system. But in my case, I do like to look over the minutes first, and sometimes prepend a little text at the top. For instance, I might want to add an explanation or extra pointer for context, or a note about something that went wrong mechanically. If you’re in a similar situation, or just not ready for full on automation for some reason, here’s how I do minutes very quickly. Maybe it will help you in the future:

    1. I have my IRC client and my email client, Mutt, up in separate windows.
    2. When the meeting ends, I send the command #endmeeting, and meetbot outputs information about where to find the minutes and log.
    3. I immediately start a new email in Mutt, with the subject “<Name of meeting> recap <date and time>”. This calls up Emacs for me, but it doesn’t matter if you’re using a different email client.*
    4. I copy the three lines (Minutes, Minutes text, and Log) that meetbot outputs, usually with a mouse. (If you’re in screen or something, use its copy function.)
    5. I paste the lines into my email and align them properly if needed.
    6. I use the mouse to copy the link address for the text-format minutes.
    7. In Emacs I run a shell command using Alt+1, Alt+Shift+!.** The command is curl -s -o – <paste the link address from step 6>. This command retrieves the text-format minutes straight from the internet into the buffer.
    8. I trim the headers as needed.
    9. I send the email. (Here’s an example from today.)

    That looks like a lot of steps, doesn’t it? But since almost everything there is copying and pasting, the actual time to complete this is under 2 minutes. (If you’re a fast typist and good with your editor, it’s more like 30 seconds.) Thus the title for this post!

    Many thanks to Kevin Fenzi and the Infrastructure team for providing meetbot functions for our use in Fedora. They’re a big, big help every week for me personally.

    * Well, it does matter a little. When I used Evolution, there wasn’t a way to insert the output of shell commands easily into my compose window. That’s totally sensible because Evo isn’t designed for the 0.1% of people who like running shell commands. It’s barely more work to just use a terminal and then Evo’s function to insert file content.

    ** The Alt+1 means that the following shell-command, run by Alt+Shift+!, will dump its standard output into the current buffer, which is where the email’s being composed. If you were using a terminal with some other email program, you could do curl -O <paste link address> which would retrieve the minutes to a file. Then you could paste the file into your email compose window.

    Fedora 14 Alpha is go!

    As John posted last night, Fedora 14 Alpha was declared ready for release next week. Although there was a one-week slip to handle the fact that our blocker list wasn’t clear, Fedora developers and testers in the community have worked hard together both to resolve the remaining issues and make sure that our Alpha would pass the release criteria. There were a number of developers who hopped in to fix things quickly to yield package builds that would clear the runway, so thanks to all of you guys.

    I also wanted to take a moment to say how impressively the QA team has beefed up the definition of these criteria. Not only that, but the team continues to take opportunities to refine them whenever we hit a question that’s difficult to answer under the current criteria. We still can improve our effectiveness at turning the combination of the blocker bug list and the criteria into getting response from developers where needed, but that’s more of a shared issue. As with our criteria and our schedule, we continue to improve these processes in an iterative way, and openly to boot.

    Here’s one place where everyone will be able to pitch in — making sure that any common issues in the Alpha are properly noted. We have a wiki page for common Fedora 14 issues, and it’s very important for us to keep it updated for all those trying out the pre-releases. If you’re in doubt whether it’s a common issue, that’s OK. There are some notes on that wiki page on how to add your issue:

    • Add it yourself, if you have wiki access. Please follow the style and guidelines explained in the comments in the page source. (You’ll see them when you start to edit.)
    • Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug. To expedite your request, add a comment to the bug that includes
      1. a summary of the problem
      2. any known workarounds
      3. an assessment on the impact to Fedora users

    If in doubt, we’d rather see the issue than not. 🙂

    The Alpha release is meant for advanced users and Fedora participants to download and test. It’s not code-complete, meaning a few things may be broken. We want and need your help to identify, report, and resolve these problems. As always, the best way to do that is to file bugs! Random blog entries, tweets/dents, and mail may be interesting, but to track the problems to resolution, bugs are the right way to go. We look forward to your participation as always — if you’re not already installing from the pre-release tree, you’ll be able to pick up the official images next Tuesday, August 24.

    In summary, nice job to everyone involved, and I’m looking forward to switching a few systems here at home to F14 Alpha!

    Criteria and documentation.

    John Poelstra wrote in his blog about how objective criteria support sustainability in an open source project. It was insightful and I wanted to follow up about how that extends to process documentation as a whole.

    Lots of people talk about documentation as “that thing you do when you’re finished building something.” But in an open source project, where you’re trying to attract people to help you build or make, that’s an unworkable approach. It’s something you do to make sure that people with skill and energy, who want to help you, have what they need to get started. You want to ensure they can learn the required bits without you having to hold every individual hand, because if you do that, you can’t work on the project yourself. By writing everything down somewhere, you give people the opportunity to self-serve when it comes to learning the basics.

    Sometimes acronyms are obfuscatory, but sometimes they help. The “standard operating procedure,” or SOP, is an acronym we do use quite a bit on some of our teams, because it’s a great shorthand for saying, “the stuff you need to know to accomplish a task with minimal or zero help.” An up-to-date SOP document makes it possible for anyone to carry out mechanical steps, observe and report the results, and take follow-up actions if needed. Our Infrastructure team has one of the most comprehensive collections of SOPs in the Fedora Project. But other groups are starting to catch up, like Release Engineering and QA. (Some teams don’t categorize their SOPs like this, which is fine — the point is not what they’re called, but that people can find the procedures and follow them.)

    It’s tempting to think that some processes are so important or fiddly that we can’t turn them into SOPs. But I believe those are precisely the ones we should be investing in documenting. It boils down to these simple ideas, which I believe are intrinsic to the open source way:

    • The more we believe our work can’t be reproduced by someone else, the harder it is to get anyone to help with it.
    • By extension, the more we believe our work can’t be reproduced by someone else, the less likely we will solve the “eaten by raptors” problem*.

    People like Mel Chua have written (and practiced!) exhaustively on combating this problem, and often the solution is as simple as “teach someone now, and make it the student’s job to document while learning.” Paradoxically, teaching someone with a lower level of general skill can be more helpful than teaching someone who needs less tutelage. Doing so can expose the specific prerequisites, which otherwise might be just hazy notions (“the practitioner needs to have a high skill level in ___”).

    Ideally, anyone in Fedora ought to be able to be absent at any point in our release cycle without unduly affecting any of our release processes. The more we make it possible for any contributor to follow a process like judging against criteria, producing media and art, spinning release candidates, and so forth, the closer we get to that goal. The result is a more sustainable Fedora Project.

    *The “eaten by raptors” problem, simply put, is that having institutional knowledge locked up with a small number of people represents substantial risk in a project. This is especially true when the number is one, or if the project is an open source effort. To mitigate the risk that your project will suffer if any member is eaten by velociraptors, eliminate knowledge silos wherever possible.

    A spoonful of sugar.


    Thanks for your thoughtful posting about being helpful in the Fedora support channels. I think among the keys to understanding what someone seeking help needs — let’s just call this person “Nathan” to make this blog post easier to read — are:

    1. Good listening skills
    2. Good empathizing skills

    Essentially, a good helper need to be able firstly to turn off any immediate reactions or conclusions to which they might jump about Nathan’s situation. Not concentrating on assumptions about Nathan’s problem or skill set allows the helper to concentrate more on the actual facts needed, and elicit them from the person seeking help. Once the helper has a good idea of what Nathan’s problem really is, and what skills to solve it Nathan might lack, it’s easier to decide what level of help is required — or spoon feeding if you prefer.

    Then the helper needs to empathize with Nathan to some degree — put himself in Nathan’s shoes, and allow that understanding to guide how he deals with Nathan’s needs. Often people forget this step and as a result the communication can turn a bit sour. But by making the effort to step outside ourselves to determine how Nathan might view our advice, we can increase the effectiveness of our help by orders of magnitude.

    Help in any support venue affects not only Nathan, but the helper too — and in addition, even people who are just watching that help happen in the support venue are affected too! The better each individual interaction is, the better the overall environment for everyone, including newbies, experienced users, helpers, and lurkers. And of course, a more positive environment means more fertile ground for encouraging contribution to free software.

    Every helper needs to understand his own level of comfort with listening and empathy, and let that guide his interactions with Nathan. That’s what I like so much about Kevin’s blog post. It shows a level of personal insight to determine Kevin’s comfort level and honest evaluation of where he thinks he can be effective as a helper.

    All of us who help support people of any kind, regardless of experience level, should have a somewhat regular checkpoint of introspection, where we honestly think about our own effectiveness at listening and empathy. Then we can adjust our dealings with those we support to maximize the constructiveness of our interactions, and thereby have a direct, positive effect on the culture of free software.