What is a rainbow cookie? 🔗

If you’re not aware already, Fedora has a unique system of rewarding positive contributions in the community through karma cookies.

Karma cookies are a unique way of rewarding positive interactions and actions in Fedora with a friendly, quantifiable number. In any official Fedora IRC channel, Fedora contributors can give any other contributor Karma by adding ‘++’ after their nick (e.g. mattdm++ or puiterwijk++).

This “positive” karma cookies are distributed by zodbot, Fedora’s IRC bot. A contributor can give another contributor a “karma cookie” once a release cycle before they are able to give another one. For reaching certain milestones of karma cookies, contributors are awarded badges via Fedora Badges. Fedora uses this as a method to promote positive behavior in the community as well as help support and build community in Fedora. This reflects upon the “Friends” part of the Four Foundations of Fedora. I love the concept of karma cookies and I think it’s a small and great way for us to share our appreciation for other contributors in the project.

The Rainbow badge is awarded after receiving 100 karma cookies across all Fedora releases.

Thank you! 🔗

I did spend a lot of time giving thanks and appreciation in my Flock 2016 write-up, so I think it would be better to point there for a longer, more verbose expression of gratitude.

I am still appreciative and thankful of all the people who have spared their time for helping get me started in Fedora. Sometimes, it’s hard to believe it hasn’t yet been a full year since my first contributions. The opportunities and friendships that being a member of the Fedora community have provided are irreplaceable. I hope that I am able to continue making an impact on Fedora far into the future and share some cookies with some other contributors. And as always, I hope to pay forward the kindness and guidance that others have bestowed to me towards others who are entering our project.

Thanks to all the mentors both past and present, friends, and fellow community members who have participated in my journey so far.

Badges Prerequisites 🔗

Before beginning to consider whether you are going to push a badge, you must first meet the following prerequisites.

1. Clone the badges repository, where all badges live.
2. Be a sponsored member of the sysadmin-badges FAS group

Taking care of art assets 🔗

Before publishing the badge, you will need to make sure all the art assets are in the right place for the ticket. This usually consists of a PNG and SVG, but can also include an STL file for 3D printing a badge design.

The following steps are a handy checklist of things you need to do for gathering all the art assets together.

1. Go to the ticket for the badge and pull both art asset types (PNG and SVG) into the badges repository. If there is a YAML rule file, pull that down as well.
2. Place both art assets (and YAML file, if applicable) into their appropriate folder. Make sure both files share the same name. It is preferred to name the files the name of the badge for easy indexing later on.
3. Double-check to make sure the image assets you pulled down are “good” - sometimes the images can be corrupted and this can cause problems later. Check if you can view both files.
4. Change directories into bin/ and run the export.sh script. This will create an STL file for the badge and move it in the right place for you. Check the README file in bin/ for more info about running the script.
5.  Add the files in git and commit. If you have push privileges, go ahead and push. If not, create a patch file and add it to the original badge ticket.

At this point, all the art assets will now be prepared and ready for deployment.

Pushing out badges 🔗

Once you have committed the badge to the FedoraHosted repository, it doesn’t mean the badge is “out there” yet. To do this, you will need to use an Ansible playbook for that purpose.

These steps will take you to the Batcave and have you push the badge out to the Badges front-end, Tahrir.

1. Log into the batcave machine and find the push-badges.yml playbook. Execute it.
   1. Note that you will need to have proper privileges to execute and run the playbook. Sysadmins with privileges (sysadmin-badges FAS group) will be able to run the playbook to pull the changes from FedoraHosted to batcave - the changes then get synced to the badges-web server.
   2. If you are only a member of sysadmin-badges but not other groups, you can use the rbac-playbook tool to execute this specific playbook. For more information on role-based-access-control playbooks, read the original announcement.
2. Wait for the playbook to finish. Once complete, check if the PNG file is publicly viewable on the Badges website.
   1. https://badges.fedoraproject.org/pngs/{{ badge_name }}.png

Now, the hard work is done. From this point, you will have to use the front-end of Tahrir to finish adding the badge.

Adding badges from Tahrir 🔗

Once the art assets are on badges-web, you will be ready to make the badge. But be warned! Creating a badge is easy, but editing it is not! Make sure the information you are entering is right on the first go. Otherwise, fixing it will involve fixing the data with SQL statements.

1. Log into the admin interface on badges.fedoraproject.org.
2. Go to the “Add badge” section.
3. Enter in all the information as provided in the badge ticket. Make sure to include the right name, description, and location of the image file. Once you have double-checked and verified the information is correct, hit “Create badge”.
   1. Tags are an important part of this process too. Compare to other similar badges when adding a new one, otherwise it may not be categorized correctly in the badges index.
   2. Some information is consistent across all badges, like the Badge Criteria field. For this field, you should always put the link back to the original Badges Team ticket where the badge was proposed, designed, and discussed.
4. If the badge does not have an automatic rule for being awarded, you will need to grant authorizations for issuing the badge. You can do this at the bottom of the admin interface. Use the badge name and the @fedoraproject.org email for the person gaining privileges.

After pushing the badge out, do some last checks to make sure the badge pushed correctly. Make sure the page is viewable and double-check that it’s categorized correctly in the badge index. If everything looks right, you should be finished.

Congratulations, you just pushed your very own Fedora Badge!

Image courtesy Anna Dziubinska – originally posted to Unsplash as Untitled.

Today, I received the Pizzelle badge in Fedora Badges. I was awarded with Pizzelle after a short “karma storm” in the EMEA Ambassadors meeting. After finding out I was awarded the badge, I had a light bulb sort of moment. As of this month, it has been a year since I first found myself wanting to get involved with the Fedora Project. I remember seeing the announcement for Flock 2015 and how that was right next to my soon-to-be university, the Rochester Institute of Technology. I remember lazily dismissing the idea of taking any further steps into Fedora until after Flock 2015. And now, a year later, I’m reflecting back on crazy of a past few months it has been.

What is a pizzelle? 🔗

If you’re not aware already, Fedora has a unique system of rewarding positive contributions in the community through karma.

Karma is a unique way of rewarding positive interactions and actions in Fedora with a friendly, quantifiable number. In any official Fedora IRC channel, Fedora contributors can give any other contributor Karma by adding ‘++’ after their nick (i.e. jflory7++).

This “positive” karma is distributed by zodbot in the form of “cookies”. A contributor can give another contributor a “karma cookie” once a release cycle before they are able to give another one. For reaching certain milestones of karma cookies, contributors are awarded badges via Fedora Badges. Fedora uses this as a method to promote positive behavior in the community as well as help support and build community in Fedora. This reflects upon the “Friends” part of the Four Foundations of Fedora.

The Pizzelle badge is awarded to a user after received 50 cookies from other users in Fedora.

Thank you! 🔗

A special thanks goes out to all of those who have helped mentor and guide me towards contributing to Fedora. There’s really too many names to list, and everyone has impacted me in their own unique way. I hope that through my contributions, I can return the kindness and support that so many others have shown me.

I think karma is cool because it’s a simple way users can show their appreciation for others. The more karma you receive, the more you realize that it really is like karma – the more you give, the more you get back out of it. If you put forth the effort and willingness to help others, those same others will return the favor to you in one form or another.

Special shout-out to the CommOps team for working on some awesome tasks in Fedora! I don’t know if I’d be as deep in Fedora if it weren’t for the folks behind CommOps.

A. Describe software project, its purpose and goals. 🔗

Tahrir is a project that allows its users to create their own Open Badges – graphical icons that show that a user has attended a particular event, completed a specific challenge, or any number of other accomplishments.

B. Give brief history of the project. When was the Initial Commit? The latest commit? 🔗

The Mozilla OpenBadges project’s wiki page was created in November of 2010, mentioning a few other projects that used a badge system and encouraging people to contribute to that project. Once Mozilla’s OpenBadges project was established, Fedora Infrastructure team member and Red Hat employee Ralph Bean created the first commit for the Tahrir project in April of 2012. Since then, twenty-two contributors have worked on the project, with commits as recently as March 2nd, 2016.

C. Who approves patches? How many people? 🔗

There did not seem to be an established, formal process for who has the privileges or authority to approve patches, but based on the most recent pull requests, the following users have been actively responsible in the past year for approving patches.

• Chaoyi Zha (cydrobolt)
• Ralph Bean (ralphbean)
• Patrick Uiterwijk (puiterwijk)
• Trishna Guha (trishnaguha)
• Remy DeCausemaker (decause)
• Pierre-Yves Chibon (pypingou)

D. Who has commit access, or has had patches accepted? How many total? 🔗

Based on total contributions, Ralph Bean and former contributor David Gay (oddshocks) made more contributions to the project than any other users. However, the list of users listed above (being able to approve patches) also seem to have commit access as well. From the outside, it is difficult to determine user permissions, but the contextual evidence provided from issues and pull requests seems to support this conclusion.

In total, the project has had twenty-two contributors.

E. Who has the highest amounts of “Unique Knowledge?” 🔗

Based on the diversity of commits and git_by_a_bus results (at the bottom of this post), Ralph Bean appears to have the highest amounts of unique knowledge for Tahrir.

F. What is your project’s “Calloway Coefficient of Fail?” 🔗

Your source is configured by editing flat text config files. +20

Score: 20 points of fail

G. Has there been any turnover in the Core Team? 🔗

Has the same top 20% of contributors stayed the same over time? If not, how has it changed? 🔗

In the first two years of the project, David Gay (oddshocks) had a greater number of lines of code contributed to the project, and had some huge activity spikes in July of 2013. Since then, Bean and Uiterwijk have taken up a lot more of the work, and Gay hasn’t contributed since October of 2014.

Overall, Bean has been the greatest (and most consistent) contributor to the project.

H. Does the project have a BDFL, or Lead Developer? 🔗

Bean would be the closest thing to that. He guides the development of the project. After the project stabilized and all the core functionality was implemented, any further contributions seem to be minor bug fixes for the overall QOL of the project.

As a team, we could not necessarily speak to Bean’s role as a BDFL during the development process, especially without any chat logs from relevant IRC channels or email lists.

At the project’s current state, he seems to be keeping the project going along in a healthy direction and fixing the minor bugs that come up as they’re reported or patched.

I. Are the front- and back-end developers the same people? What is the proportion of each? 🔗

Tahrir is created under the GitHub organization of the Fedora Infrastructure team. As a result, even though there is a core group of developers working on Tahrir, it wouldn’t be an invalid assumption to say someone else in Fedora Infrastructure could take the code, change it for something that arose in production, and deploy it back into production.

As a result of the “DevOps” sort of relationship between the Fedora Infrastructure team and most of the projects on their GitHub, it is difficult to draw a firm conclusion about which developers work on the front end and which developers work on the back end. The unique circumstances of being an “open source project inside of an open source project” skews the answer to this question.

J. What have been some of the major bugs, problems, and/or issues that have arisen during development? Who is responsible for quality control and bug repair? 🔗

To categorize the issues reported against during Tahrir’s lifetime, we categorized the issues into three categories: Concerning (15 or more comments on issues), Eyebrow raising (10 - 14 comments on issues), and Intriguing (5- 9 comments on issues). These three categories are intended to be representative of the issues that caused the most conversation and interest by many developers or other members of the community.

Concerning 🔗

• #152: Tried to get undefined file at undefined and got an HTTP undefined (18 comments)
• #168: Link to 3d-printer spec files (22 comments; you can 3D print badges… whoa!)

Eyebrow Raising 🔗

• #117: Match_all not working on tags view just yet. (12 comments)
• #141: Emit a fedmsg when a new leader is crowned! (11 comments)
• #244 : Stuck on a white page after OpenID login (11 comments)

Intriguing 🔗

• #21: Admin view not properly escaped (8 comments)
• #69: Render badge descriptions from .rst to html (6 comments)
• #70: Fix error code images (5 comments)
• #101: Fallback avatar looks bad on user view (too small). (5 comments)
• #108: Export badges is broken in staging (9 comments)
• #112: Implement opt-out mechanism (7 comments)
• #176: Ask badges relate to username, but that’s not working (5 comments)
• #319: Libravatar badge not being awarded (5 comments)
• #339: Represented Fedora at event not awarded (5 comments)

Quality Control 🔗

Looking through the 145 closed pull requests, it’s clear to see that once again, Bean is leading the quality control and testing on Tahrir pull requests. There are a few pull requests where Uiterwijk and Chibon either submit code and the other one reviews and approves it. In these edge cases, it seems to be the contributions of more experienced members of the Infrastructure submitting code and getting another experienced member to check the submitted code.

For new contributors or contributions from non-consistent contributors, Bean seems the be the defacto “King of PRs” for Tahrir.

K. How is the project’s participation trending and why? 🔗

Based on activity graphs of the lifetime of the project, the most participation and development of Tahrir occurred in the summer months of 2012 and 2013. This can likely be attributed that the heaviest development work was happening in these time periods while Tahrir was being built and shaped into what it is.

Once a stable point was reached and most issues were resolved, development greatly slowed, likely because the developers moved  on to new projects, while a subset of the original core developers remained active as maintainers after the stable point was reached.

L. In your opinion, does the project pass “The Raptor Test?” Why or why not? 🔗

Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor? 🔗

For the purposes of this question, we will assume Bean is the lead contributor at the current point in the project’s life cycle.

If he were eaten by a velociraptor, the project would still be able to survive even in his absence. Since the core development work has already been accomplished and the main development work now is resolving issues and maintaining the existing codebase (as compared to writing new features), it’s safe to assume there are others in the Fedora Infrastructure team who would be able to keep up this project and make sure its longevity is guaranteed (although I am sure that the Infrastructure team would suffer a great loss without the wisdom and mad wizardry that Bean provides).

The fact that Tahrir is “nested” inside of another open source project (Fedora) likely attributes to the likelihood that Tahrir would survive the sudden absence of its most active developer.

M. In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not? 🔗

This question is more difficult to answer than the previous question because of the relationship the top 20% of the contributors have to Tahrir, Fedora, and other open source projects. The top 20% of contributors mostly consist of the core Fedora Infrastructure team members, who are also responsible for working on other projects within Fedora, maintaining the servers and services that power the infrastructure, and working on apps such as Tahrir.

In the event that the top 20% of Tahrir’s contributors were all hit by a bus, it’s difficult to know if Tahrir would be able to sustain. Because of the work the core developer circle does throughout the Fedora Project, it would be very difficult for others to pick up the cumulative amount of work that is shared among the Infrastructure team now. The documentation and stability of the code would be useful attributes for the prospect of someone new picking up maintaining the code, but in a broader view, the amount of work that would need to be picked up across the board creates new issues within itself.

For these reasons, if the top 20% of contributors to Tahrir were to disappear, it’s difficult to forecast the future of Tahrir (and other projects managed by the Fedora Infrastructure team).

N. Does the project have an official “on-boarding” process in place? 🔗

Can include new contributor guides, quick starts, communication leads who focus specifically on newbies, etc… 🔗

While there is no on-boarding process in place specific to Tahrir, there is a process for the Fedora Infrastructure team, which would in turn lend itself to Tahrir. Some of the advice given includes how to be a successful contributor and introducing yourself on their mailing list.

O. Does the project have documentation available? Is it extensive? Does it include code examples? 🔗

The project does have documentation in the README file for installing, running, and developing on Tahrir, but they are not an extensive set of “documents” or wiki pages that explain the entire process. The guide does seem to assume the person reading the documentation is capable enough to run a few commands in a command line or install Python dependencies with tools like pip.

For anyone who knows anything about Python, this documentation will be plenty, but if you are a new developer looking at getting started for the first time, you may have a learning curve with figuring out what all the commands you are instructed to do actually do on yourself.

There do not seem to be code examples for Tahrir (if there are, their presence is not clearly stated).

P. If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how? 🔗

If we wanted to contribute to Tahrir, it seems like the best points of contact are either the #fedora-apps channel on Freenode or the Infrastructure mailing list. IRC appears to be the preferential way of getting help.

Q. Based on these answers, how would you describe the decision making structure / process of this group? 🔗

Is it hierarchical, consensus building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals? 🔗

In the current state of the group, decision making seems to favor the lazy consensus sort of voting; that is, if there are no objections or negative feedback on a feature addition or a bug fix, it is assumed there is not an issue and development presses forward. However, there seems to be an informal, undocumented precedent that every contributor must get their code signed off by at least one other member of the Fedora Infrastructure team (even if the contributor is an experienced, active member of the Infrastructure team).

In short, the development and community architecture of Tahrir seems to be greatly left to Bean and the rest of the Fedora Infrastructure team. In the event of new ideas or “topics worth discussion”, usually there is activity either in IRC or on the mailing list before heavy development goes forward.

R. Is this the kind of structure you would enjoy working in? Why, or why not? 🔗

The system that the Fedora Infrastructure team appears to follow seems to be documented and regimented, so getting involved isn’t difficult and the community appears supportive of new developers. For me, I believe the community architecture surrounding the Tahrir project is a friendly and welcoming environment for any level of contributor of open source to get involved with and hack on a cool project.

Community Architecture: Git by a Bus Summary Results 🔗

Note: values smaller than 10 have been truncated in the interest of space.

Note: the scale of the bars is relative only within, not across, tables.

Top 100 Projects by highest estimated unique knowledge 🔗

Top 100 Projects by highest estimated shared knowledge (devs still present) 🔗

Top 100 Projects by highest estimated risk 🔗

Top 100 Devs by highest estimated unique knowledge 🔗

Top 100 Devs by highest estimated shared knowledge (devs still present) 🔗

Top 100 Devs by highest estimated risk 🔗

Top 100 Files by highest estimated unique knowledge 🔗

Top 100 Files by highest estimated shared knowledge (devs still present) 🔗

Top 100 Files by highest estimated risk 🔗

Community Architecture: Git by a Lion Pie Chart Results 🔗

“Speak Up!”: What is it? 🔗

The Speak Up! badge is categorized as a “Community Badge” and is defined in this Trac ticket. But what’s the real scoop behind the Speak Up! badge?

In short, the Speak Up! badge is awarded to anyone who says something in an official Fedora IRC meeting. A lot of important conversations and work in Fedora all happen in IRC, and meetings are the best time to get the pulse of a particular subgroup or team. It’s also a great time to introduce yourself to other contributors and begin moving towards becoming an active contributor. This badge is a great gateway towards earning many others!

How do I earn “Speak Up!”? 🔗

Earning Speak Up! requires you to be somewhat familiar with the Internet Relay Chat protocol (a.k.a. IRC). If you’ve never used IRC before, it’s like a large chat network. You connect to a particular IRC network, and you can join any number of chat rooms (called channels). The Freenode IRC network is a favorite of many open source projects and organizations. This includes Fedora! Fedora has several different IRC channels for all kinds of purposes. General support is in the #fedora channel, the Design Team is in #fedora-design, the Marketing team is in #fedora-mktg, the Fedora developers are in #fedora-devel, and the list goes on!

Usually on a regular basis, most of the Fedora subgroups have meetings where they discuss the tasks on their agendas, look at what needs doing, and welcome any newcomers! Introducing yourself in a Fedora IRC meeting is one of the best ways to begin the journey of becoming a contributor and meeting other contributors who are willing to help you get started.

You can check the Fedora Calendar app to see when a particular subgroup or team meets. For example, the Fedora Community Operations team meets on Tuesdays at 17:00 UTC in #fedora-meeting-2. Find the meeting time for a team you’re looking at contributing to and see if you can make yourself available for that time slot. When the meeting begins, introduce yourself towards the beginning. It doesn’t have to be complex! Just say hello, who you are, and maybe a few words on why or how you want to contribute. And that’s all it takes!

One thing to keep in mind is that to be awarded this badge, your IRC nickname must be the same as your Fedora Account System username, or you must specify your IRC nickname in your account. In Fedora IRC meetings, everything is logged, so the Meetbot will know if your username said anything in the meeting.

Congratulations, you have now earned the Speak Up! badge!

The “Speak Up!” tl;dr 🔗

1. Make sure your IRC nickname is the same as your Fedora Account System username, or you have your IRC nickname specified in your account
2. Find out when a subgroup or team that interests you is meeting on the Fedora Calendar app
3. Find time to attend meeting, speak up and say hello! We don’t bite. :)

“Vacation”: What is it? 🔗

The Vacation badge is categorized as a “Community Badge” and is defined in this Trac ticket. But what’s the real scoop behind the Science badge?

With the December holiday season right around the corner, this seemed like the perfect badge to feature this week. In short, the Vacation badge is awarded to contributors who mark when they will be unavailable in the Fedora Calendar app. Marking when you are helps others know when you will be away and know where to pick up the slack. If you an active contributor to any subgroup, team, or other entity in Fedora, this is especially important so people know when you will be away! Everyone needs a vacation every once in a while, so let others know when “the doctor is in” becomes the “the doctor is out”.

How do I earn “Vacation”? 🔗

Earning the Vacation badge is simple. To earn it, you will need an active account in the Fedora Account System, and it is only recommended you do this if you are an active contributor in some aspect of the Project.

To earn it, first navigate to the Fedora Calendar app and sign in at the top with your FAS information. Once you do so, go to the Vacations calendar and create a new entry by clicking the “+” button in the side bar. For Meeting name, just fill in your username. Choose the start and end dates for when you will be away (and times, if necessary). If you wish, you can include some extra information or comments about your availability in Information box.

Once everything looks good to you, hit the “Add” button at the bottom, and viola! You have now added when you will be away to the calendar and Fedora contributors will be able to quickly see when you are away and when you will be around after your vacation ends. You will be automatically awarded the badge.

The “Vacation” tl;dr 🔗

1. Sign into the Fedora Calendars app and visit the Vacations calendar
2. Share when you will be unavailable by creating a new event and adding it to the calendar
3. Get badge!

“Science”: What is it? 🔗

The Science badge is categorized as a “Quality [Assurance] Badge” and is defined in this Trac ticket. But what’s the real scoop behind the Science badge?

In short, the Science badge is part of a larger series of badges given to anyone who helps test the Fedora kernel using a set of Python scripts to test for important functionalities of the kernel in your system. Running these tests and uploading the logs to the Kernel Development Team helps improve the kernel by providing useful insight and feedback for the kernel team to analyze. All it takes is running a few scripts, uploading logs, and boom - a new badge!

How do I earn “Science”? 🔗

Earning Science requires you to clone a git repository, run a few scripts to test the Fedora kernel on your system, and upload the logs generated by the tests to the log tracker. This began with the Kernel Testing Initiative, pioneered by Fedora contributor Justin Forbes in early 2012.

The purpose of this initiative is to allow you, a user of Fedora, to run regression tests of the kernel in Fedora on your own system and provide an analytical report of the tests to the Fedora Kernel Team. These logs help act as “milestones” and “pointers” for how the Fedora kernel is running out in the real world. There are a lot of different architectures and environments, and this option allows users with all kinds of hardware to easily submit this info (and get a few badges for doing it)!

Clone the git repository 🔗

The first step you will need to do is clone the git repository where the kernel test scripts are hosted. To do that, open a terminal and run the following command (this requires that you have git already installed).

$ git clone https://pagure.io/kernel-tests.git

Once you do this, the scripts will be in a new folder in whatever your present working directory is.

Run the scripts 🔗

Now that the scripts are on your system, you can now get started running your regression tests! In the terminal, you can run the default test by executing the script with no arguments.

$ ./runtests.sh

You can follow the progress of the tests as the script executes. Once it finishes, a log file will automatically be generated in the logs/ folder. This is the file you will need to get your badge.

If you’re feeling like being adventurous, there are a few other tests you can run.

• Stress
• Performance
• Destructive

The stress and performance tests execute a few additional tests in addition to the default tests to help provide more detailed information about your system and how it works with the kernel. Whenever I run kernel tests, I usually run the default set, the stress set, and the performance set. Be warned, the first two tests can take a long time to execute, so if you are planning to do work while the tests are running, you may want to make a cup of coffee instead.

To run the specific tests, you can use the -t flag followed by the name of the test. For example, let’s say I want to run a performance test.

$ ./runtests.sh -t performance

Note that there is also a destructive test suite. As the name implies, this set of tests does contain some functions and tests that can potentially have devastating effects on your system. In an ideal case, this would not happen, but if the odds are not in your favor, this set of tests can leave you with a broken machine.

If you are running a system with Rawhide or have a spare computer that you don’t care for much, it can help to run the destructive tests on those machines. But it is not advised to run them on a system you depend on or actively use!

Upload your results 🔗

Once you finish running tests, it’s time to upload your logs. You can do so via the Kernel Logs app. Uploading the logs will require you to log into the site using your Fedora Account System username and password. After you log in, you will find the page that prompts you to upload new log files.

Upload any logs that were generated from the test or tests that you ran. As soon as you submit the log files, it will be registered in the system, and you will be awarded the badge automatically afterwards.

Congratulations, you have now earned the Science badge!

The “Science” tl;dr 🔗

1. Get the test scripts by cloning their git repo (git clone https://git.fedorahosted.org/git/kernel-tests.git)
2. Run the test scripts by executing the runtests.sh file (try the stress and performance tests too!)
3. Upload the logs to the Kernel Logs app
4. Get badge!

The Extra! Extra! badge is categorized as a “Content Badge” and is defined in this Trac ticket. But what’s the real scoop behind the Extra! Extra! badge?

In short, the Extra! Extra! badge is awarded to Fedora contributors that write an article for the Fedora Magazine, the premiere publication offered by the Fedora Project. The Fedora Magazine offers user-oriented content relating to the Fedora Project, whether it’s a how-to on using some awesome software, a major event report, or other cool things happening in the Linux world.

How do I earn “Extra! Extra!”? 🔗

Earning Extra! Extra! requires a good idea and a willingness to write about it! To write your own article for the Fedora Magazine, you should start by shooting a brief introduction to the Marketing mailing list.  Tell a little bit about yourself, what you’re interested in, and maybe why you want to write for the Magazine. After you introduce yourself, you will be granted contributor privileges on the Magazine!

You can learn more about the process for writing for the Fedora Magazine on their walkthrough page.

The first step to getting your article published and syndicated is by proposing a pitch for your idea. A pitch is a short, brief summary of what you want to write about and how you want to go about it. This helps make it easier to approve articles and prevent you from wasting your time writing an article if there is a reason that your idea isn’t suitable for the Magazine. Get started by learning how to write a good pitch!

After your pitch is ready, send a link to your article to the Marketing mailing list announcing that it is ready for review. All pitches and drafts are reviewed weekly at the Magazine editorial board meetings.

Once your article is given the “OK”, you are free to begin drafting your article and move towards publication. After your article goes live, you will be manually awarded the badge!

The “Extra! Extra!” tl;dr 🔗

1. Introduce yourself on the Marketing mailing list, explaining why you want to write for the Magazine and what your idea for an article is
2. Once you are promoted, start a pitch to be reviewed by the editorial board, email to list when done
3. When your pitch is approved, begin drafting and move towards publishing
4. After publishing, badge is manually awarded by Magazine editors

This information is also on the Magazine “How to write an article” page.

The Telegraphist badge is categorized as a “Quality [Assurance] Badge” and is defined in this Trac ticket. But what’s the real scoop behind the Telegraphist badge?

In short, Telegraphist is awarded to Fedora contributors and users who map the names of their favorite upstream projects to packages available in Fedora. This makes it easier for developers and users to monitor updates on their favorite packages, and to make sure that new versions of upstream software are packaged and made available in Fedora. The software backing this site is called Anitya, and you can use it now on release-monitoring.org! The original announcement for this site was made by Ralph Bean on the developers mailing list in February 2015.

How do I earn Telegraphist? 🔗

Earning Telegraphist is easy! First, you should look through the list of software you have installed on your system. What are some of your favorite apps? What do you use all the time and think you couldn’t live without? Try searching for it on Anitya. Does it exist?

It may be that the package you search for is already mapped. In that case, take a look through it and see if the information is still correct and relevant. Sometimes a project’s homepage may change, or they might switch the locations of where they host their code. If something’s wrong, edit it and correct the info.

On the other hand, it may be that the package you want to add doesn’t exist. Viola, a badge opportunity has presented itself! You can help Fedora developers by providing the relevant info for a project. Click on “Add project” on the top bar and begin entering all the relevant info. For an example, see my mapping of the yubikey-personalization-gui in the screenshot.

The Telegraphist tl;dr 🔗

1. Awarded to contributors who map upstream project info to specific packages in Fedora
2. Automatically awarded when you map a project on release-monitoring.org
3. Find project info for your favorite software, and if it doesn’t exist, add it to the database

What is this? What is this?! Introducing a new series being published weekly on my blog - “Gotta Badge ‘Em All!” This series aims to introduce readers to the hundreds of Fedora badges that members of the Fedora community can earn. Maybe you’re a newcomer looking at becoming more involved by earning more badges, or maybe you have been around for a while and just want to grow your badge numbers.

No matter who you are, this series aims to educate and teach readers about how to earn some of the less obvious Fedora badges available. Not all the badges are obvious, and I want to bring more light to the “how-to” process to picking up some of these badges.

Publishing Schedule 🔗

The schedule I intend to follow aims for a new article in the series every Monday at 3:30 UTC. If you’re from the US East Coast, like me, this translates to Sunday evenings at 22:30 (10:30pm).

Read more 🔗

Wanting to keep up with the series? Just follow the tag “Gotta Badge ‘Em All” on my blog (if you’re an RSS person, use this)!

Stay tuned for the first article in the series coming very soon, explaining the Parselmouth badge!

The Parselmouth badge is categorized as a “Miscellaneous Badge” and was defined in this Trac ticket. But what’s the real scoop behind the Parselmouth badge?

In short, Parselmouth is awarded to Fedora contributors who assist in porting Python 2 packages in Fedora to Python 3. As of present date, the current version of Fedora (Fedora 23) defaults to using Python 3 for new installs. While Python 2 is easily installed, there are still a large number of packages that are not up to date to using the latest version of the language. As recognized by the developers of the programming language and the countless that use it, Python 3 is the future, and it is important that Fedora helps lead the way towards making Python 3 the standard.

How do I earn Parselmouth? 🔗

Parselmouth is a manually-awarded badge by some of the Python maintainers in Fedora. In order to earn the Parselmouth badge, you will need to help port packages and be noticed by the maintainers.

“But how can I do that?!” 🔗

There are a number of ways you can earn the badge. Periodically, there are Fedora Activity Days (FAD) which are dedicated days or sometimes weekends where contributors work together during coordinated times over IRC to help make progress on porting packages. Just recently, there was a Python 3 Porting FAD that successfully helped port many more packages to Python 3. One way to earn this badge in the future is by watching for any more announcements of a Python 3 Porting FAD on the Community Blog.

Alternatively, jump into the #fedora-python IRC channel on Freenode and introduce yourself to the channel. Explain that you want to help port packages, and someone will be able to help guide and direct you to where you can get started.

The Parselmouth tl;dr 🔗

1. Awarded to contributors who help port Python 2 packages in Fedora to Python 3
2. Typically awarded during Fedora Activity Days for Python porting
3. Can be earned by helping port packages any time year-round