This post is also an experiment in using AI generated summaries to provide useful, at-a-glance summaries of key Fedora topics. Parts of this content may display inaccurate info, including about people, so double-check with the source material.

Source material: discussion.fedoraproject.org/t/report-from-infra-and-releng-hackfest-at-flock2024/128743

Key Topics 🔗

• Standards for OpenShift app deployments: There’s a need for consistency in deploying applications to OpenShift. The group discussed creating best practices documentation and addressing deployment methods across various applications.

• Infra SIG packages: The workshop reviewed the “infra-sig” package group and identified a need to:

  • Find owners for orphaned packages.

  • Onboard new maintainers using Packit.

  • Remove inactive members from the group.

• Release engineering packages: The group agreed to add a list of release engineering packages to the infra-sig for better management.

• Proxy network: Discussion about potentially migrating the proxy network from httpd to nginx or gunicorn remained inconclusive. Further discussion is needed.

• AWS management with Ansible: The feasibility of managing AWS infrastructure with Ansible is uncertain due to limitations with the main Amazon account.

• Onboarding improvements: The group discussed ways to improve the onboarding process for new contributors, including documentation updates, marketing efforts, and “Hello” days after each release.

• OpenShift apps deployment info: A tutorial on deploying applications to OpenShift was presented and will be incorporated into the documentation.

• Future considerations: The group discussed upcoming challenges like GitLab Forge migration, Bugzilla migration, and a new Matrix server.

• Retiring wiki pages: The group needs to decide where to migrate user-facing documentation from the wiki. Additionally, someone needs to review and archive/migrate/delete existing wiki pages in the “Category:Infrastructure” section.

• Datagrepper access for CommOps: A solution was proposed to provide CommOps with access to community metrics data by setting up a separate database in AWS RDS and populating it with recent Datagrepper dumps.

• ARA in infrastructure: While AWX deployment offers similar reporting features, setting up ARA remains an option if someone has the time and interest.

• AWX deployment: Roadblocks related to the public/private Ansible repository structure were identified. A proof of concept using AWX will be pursued to determine if repository restructuring is necessary.

• Zabbix integration: The group discussed moving forward with Zabbix to replace Nagios. Action items include setting up a bot channel for alerts, adjusting alerts based on comparison with Nagios, and considering an upgrade to the next LTS version.

Action Items 🔗

• Create comments in each application playbook explaining its deployment method.

• Move all apps using deploymentconfig to deployment with OpenShift 4.16.

• Look into deploying Advanced Cluster Security (ACS) for improved visibility into container images.

• Create a “best practices” guide for deploying applications in OpenShift clusters.

• Find individuals interested in helping with orphaned packages and onboarding new maintainers for the infra-sig package group.

• Create a list of release engineering packages for inclusion in the infra-sig.

• Continue discussions on migrating the proxy network and managing AWS infrastructure with Ansible.

• Update onboarding documentation, implement marketing strategies for attracting contributors, and organize “Hello” days for new members.

• Archive/migrate/delete wiki pages in the “Category:Infrastructure” section.

• Work on tickets to set up a separate database for CommOps Datagrepper access.

• Investigate the feasibility of setting up ARA in infrastructure.

• Stand up a proof of concept for AWX deployment and discuss potential repository restructuring.

• Set up a Zabbix bot channel for alerts, adjust alerts based on comparisons with Nagios, and consider upgrading to the next LTS version.

Overall, the workshop was a success, with productive discussions and a clear list of action items to move forward.

Note: The workshop lacked remote participation due to network limitations. The source material encourages readers to express interest in helping with the action items.

Today is May 2nd, 2024. The Outreachy May 2024 round results will be published in a few short hours. This year, the participation in Fedora for Outreachy May 2024 was record-breaking. Fedora will fund three internships this year. During the application and contribution phase, over 150 new contributors appeared in our Mentored Project contribution channels. For the project I am mentoring specifically, 38 applicants recorded contributions and 33 applicants submitted final applications. This is my third time mentoring, but this Outreachy May 2024 round has been a record-breaker for all the projects I have mentored until now.

But breaking records is not what this letter is about.

This day can be either enormously exciting and enormously disappointing. It is a tough day for me. There are so many Outreachy applicants who are continuing to contribute after the final applications were due. I see several applicants from my project who are contributing across the Fedora community, and actually leveling up to even bigger contributions than the application period. It is exciting to see people grow in their confidence and capabilities in an Open Source community like Fedora. Mentoring is a rewarding task for me, and I feel immensely proud of the applicants we have had in the Fedora community this round.

But the truth is difficult. Fedora has funding for three interns, hard and simple. Hard decisions have to be made. If I had unlimited funding, I would have hired so many of our applicants. But funding is not unlimited. Three people will receive great news today, and most people will receive sad news. Throughout this entire experience in the application phase, I wanted to design me and Joseph Gayoso’s project so that even folks who were not selected would have an enriching experience. We wanted to put something real in the hands of our applicants at the end. We also wanted to boost their confidence in showing up in a community and guide them on how to roll up your sleeves and get started. Looking at the portfolios that applicants to our project submitted, I admire how far our applicants came since the day that projects were announced. Most applicants never participated in an open source community before. And for some, you would never have known that either!

So, if you receive the disappointing news today, remember that it does not reflect badly on you. The Outreachy May 2024 round was incredibly competitive. Literally, record-breaking. We have to say no to many people who have proved that they have what it takes to be a capable Fedora Outreachy intern. I hope you can look at all the things you learned and built over these past few months, and use this as a step-up to the next opportunity awaiting you. Maybe it is an Outreachy internship in a future round, or maybe it is something else. If there is anything I have learned, it is that life takes us on the most unexpected journeys sometimes. And whatever is meant to happen, will happen. I believe that there is a reason for everything, but we may not realize what that reason is until much later in the future.

Thank you to all of the Fedora applicants who put in immense effort over the last several months. I understand if you choose to stop contributing to Fedora. I hope that you will not be discouraged from open source generally though, and that you will keep trying. If you do choose to continue contributing to Fedora, I promise we will find a place for you to continue on. Regardless of your choice in contributing, keep shining and be persistent. Don’t give up easily, and remember that what you learned in these past few months can give a leading edge on that next opportunity waiting around the corner for you.

Freedom, Friends, Features, First!

— Justin

During this round, my co-mentor Joseph Gayoso and I experimented with new approaches at handling the tsunami wave. There are two competing forces at play. One, you need to provide engagement to top performers so they remain motivated to continue. Two, you need to provide new opportunities for emerging contributors to distinguish themselves. It is easier to do one of these but hard to do both simultaneously. However, Joseph and I agreed on something important. We agreed that all applicants should end the contribution phase with something practically useful. As mentors, we asked ourselves how to prepare applicants to be successful open source contributors beyond this one month.

In this article, you will get some practical takeaways for mentoring with Outreachy. First, I will share our practical approach for structuring and planning an open source project during the Outreachy contribution phase. Second, I will detail the guiding philosophy Joseph and I follow for how we planned the contribution phase.

About Outreachy 🔗

This article assumes you already know a thing or two about the Outreachy internship program. If not, Outreachy provides internships in open source and open science. Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they live. You can read more on the Outreachy website.

What makes Outreachy unique is that the internships are remote and often open without geographic or nationality constraints. Applicants from nearly every continent of the world have participated in Outreachy. Also, Outreachy is distinguished by the contribution phase. For a one-month period, approved Outreachy applicants are encouraged to participate in the project community as a contributor. Applicants spend the month learning about the project, the community, the mentors, and the work involved for the internship. This provides applicants an opportunity to grow their open source identity. It also gives mentors an opportunity to assess applicants on their skills and communication abilities.

However, this contribution phase can be intimidating as a mentor, especially if you are new to mentoring with Outreachy. A wave of people eager to contribute could suddenly appear overnight at your project’s door steps. If you are not prepared, you will have to adapt quickly!

Pre-Requisite Tasks: Raising the Outreachy bar 🔗

My co-mentor and I knew that a wave of applicants was coming. However, we didn’t expect the wave to be as big as it was. After the first week of the contribution phase, we knew we needed a better way to scale ourselves. We were limited in our person-power. The approach we took to addressing the mental overload was defining pre-requisite tasks.

We defined pre-requisite tasks as tasks that any applicant MUST complete in order to be considered eligible for our internship. Without completing these tasks, we explained that final applications would not be accepted by mentors. The defining characteristics of these pre-requisite tasks were that they were personalized, repeatable, and measurable. We came up with five pre-requisite tasks that all applicants were required to complete beyond the initial qualification for Outreachy:

1. Set up your Fedora Account System (FAS) account

2. Set up a personal blog

3. Write a blog post that introduces the Fedora community to your audience

4. Promote your intro blog post on social media

5. Write an onboarding guide for Outreachy 2025 applicants

How were initial contributions personalized? 🔗

Each of these tasks were personalized to each applicant. They each have a unique account profile, with their pictures, time zones, and chat system usernames. The personal blog is a personal space on the Internet for each applicant to start writing new posts. The blog post prompts encouraged applicants to start filling up their blogs with Fedora content. The social media post helped applicants promote themselves as budding open source enthusiasts in their existing web spaces.

This approach had two benefits. First, it provided clear guidance to all newcomers and early-stage applicants on how to get started with contributing to Fedora for the Outreachy internship. This took a burden off of mentors answering the same questions about getting started. It also gave new applicants something to start on right away. Joseph and I were able to put more time into reviewing incoming contributions and brainstorming new tasks.

Portfolio-driven submissions for Outreachy 🔗

Toward the third week, many applicants had completed the pre-requisite tasks and were ready for more advanced tasks. Many had already taken on advanced projects already, beyond the pre-requisite tasks. Although the pre-requisite tasks did reduce the applicant pool, there were still between 20-30 people who completed them all. Again, the approach had to adapt as our ability to keep up with new contributions slowed down.

From here, we encouraged applicants to build personal portfolio pages that described their contributions with Fedora. This encouraged applicants to use the blog they built in the previous tasks, although they are not required to use their blog to host their portfolio. The only requirement we added was that it should be publicly visible on the Internet without a paywall. So, no Google Docs. Most applicants have ended up using their blog for this purpose though.

How did a portfolio help? 🔗

Building a portfolio solved multiple challenges for our Outreachy project at once. First, the portfolios will simplify how the project mentors review final applications after the deadline on April 2nd, 2024. It will be streamlined because we will have a single place we can refer to that describes the applicant’s achievements. It gives us a quick, easily shareable place to review and share with other stakeholders.

Second, it ends up being something useful to the applicant as well. The portfolio page captures a month’s worth of contributions to open source. For many applicants, this is their first time ever interacting with an open source community online. So, it is a big deal to block out a month of time to volunteer on a project in a competitive environment for a paid, remote internship opportunity. Writing a portfolio page gives applicants the confidence to represent their contributions to Fedora, regardless of whether they are selected for the Fedora internship. It becomes a milestone marker for themselves and for their professional careers.

Our philosophy: You win, we win. 🔗

This idea of applicants building something that is useful for themselves underpins the approach that Joseph and I took on structuring our non-engineering Outreachy internship. If I had to summarize the philosophy in one sentence, it might be like this:

Everyone who participants as an Outreachy applicant to Fedora should finish the contribution phase with more than they had at the start of the contribution phase.

myself

Our philosophy can be applied to engineering and non-engineering internships. However, applying the philosophy to our non-engineering project required improvisation as we went. There are examples of design-centered Outreachy internships, but I have not seen a marketing or community manager internship before. This was a challenge because there were not great models to follow. But it also left us room to innovate and try ideas that we have never tried before.

Adopting this philosophy served as helpful guidance on planning what we directed applicants to do during the contribution phase. It allowed us to think through ways that applicants could make real, recognizable contributions to Fedora. It also enables applicants to achieve a few important outcomes:

1. Get real experience in a real project.

2. Build their own brand as open source contributors.

3. Gain confidence at collaborating in a community.

The contribution phase is not yet over. So, we will continue to follow this philosophy and see where it guides us into the end of this phase!

Share your Outreachy mentoring experience! 🔗

Have you experienced or seen a marketing or community manager internship in Outreachy before? Know a project or a person who has done this? Or is this totally new to you? Drop a comment below with your thoughts. Don’t forget to share with someone else if you found this advice useful.

I am opposed to the impact of Export Administration Regulations by the United States as it pertains to free and open source software. I am a strong believer that the impact of these regulations are most harmful to all free & open source software communities at an individual, human level. When I saw this discussion at the Fedora Council level, it offered me an opportunity to reflect on my own feelings about these regulations, and also to share an opinion on how I believe Fedora Linux could truly live up to its certification as a Digital Public Good to ensure a more equitable world.

Here is what I wrote to the Fedora Council, and perhaps also to anyone reading from Red Hat’s legal team:

Hi, I would like to add a counter-opinion, of course one that holds no weight as an official vote.

As Fedora Linux is forced to this decision by its relationship to its legal sponsor, Red Hat, I therefore believe it is also the responsibility of Red Hat to seek a solution that does not deny an individual their right to realize the Four Freedoms of Free Software on the basis of geography or citizenship.

I recognize no policy is being changed here. It is a deliberate clarification of rules that were always in effect. Yet this ticket opens the context behind the policy for greater scrutiny, and I posit the context is harmful both to the Fedora Project and to Red Hat.

This policy is harmful for diversity and inclusion, and compromises Fedora’s position to be an innovative platform built by a global community. The U.S. laws and regulations driving this decision exist within a specific context, but that context is grossly incompatible with the dynamics of inclusive Free & Open Source communities. In practice, these laws and regulations deny individuals (really, other human beings) of their ability to be a beneficiary of the open licenses we employ for creating our work, collaborating on it together, and sharing it with others.

I see two outcomes of accepting this as an unchangeable norm.

Firstly, it creates confusion, doubt, and feelings of ill intent. These laws and regulations are meant to impact governments and nation-states. In a Free & Open Source community such as ours, these regulations impact individual people. Not governments or nation-states. As an example, a Fedora community member, Ahmad Haghighi, was recently permanently removed from the Fedora Community. In a few quick clicks, Ahmad’s legacy in the project was erased. As a precedent, even if someone’s contributions were not “supposed” to be accepted in the first place, it does not sit well with me that any one person’s legacy of contributions can so easily be removed from project records.

Secondly, it challenges the vision and foundations of the Fedora Project. Particularly our vision statement and the Friends Foundation. When I contribute to the Fedora Project, I do not see people as a citizen of this-country or that-country. I see them as my peers and fellow Fedorans, helping meet that shared vision of creating “a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.” As an American citizen, I know my country makes such discriminations about large groups of people based only on their nationality, but as a contributor to Free & Open Source communities, I see people by their individual character and intention to be a part of our shared vision. But how can we truly aspire to this vision if we are consciously making deliberate exclusions, even if they make little to no sense in our own context? This geographic restriction policy sits in contrast to the vision and purpose we spell out “on paper”.

I understand why Fedora leadership is taking this action due to Fedora’s legal and sociopolitical relationship to Red Hat, an American incorporation subject to American laws and regulations. To an extent, the hand of Fedora is forced.

But I believe this is a great opportunity for Red Hat to be an enabler of Fedora’s First Foundation. Previously, Microsoft stood up for Iranian developers and successfully set a precedent about how the United States Office of Foreign Assets Control (OFAC) treats such cases. I found this excerpt from Nat Friedman’s announcement to resonate:

Over the course of two years, we were able to demonstrate how developer use of GitHub advances human progress, international communication, and the enduring US foreign policy of promoting free speech and the free flow of information. We are grateful to OFAC for the engagement which has led to this great result for developers.

Advancing developer freedom: GitHub is fully available in Iran - github.blog

I believe Red Hat’s legal team should take a stand for individuals in embargoed countries to remain a beneficiary of the free and open source licenses that enable a community Linux distribution like Fedora to exist in the first place.

After all, in Fedora, we are well-known for being first in the Open Source space for innovative new ideas and approaches. We know Fedora Linux is a digital public good that should be accessible to all and everyone. But to make this a reality, the Fedora Project cannot be first here on its own. We need our friendly primary sponsor, Red Hat, to help us clear this burden, which is brought on by our connection to Red Hat in the first place.

I’ll close this counter-opinion with an excerpt from our First Foundation:

“However, the Fedora Project’s goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first.”

From What is Fedora all about?

Here is a chance to be clear on the future we want to provide and for whom.

Background photo by Omid Armin on Unsplash.

Many have started on this same path before. Several communities form a committee as a governance model for important decision-making. Usually committee membership is chosen through an election process. Paid employees, or sometimes, members of the community comprise the elected committee membership. This meritocratic approach is believed to bring in diverse representation and participation of highly-engaged people. After all, who better to represent contributors of a project than a committee of folks elected by their own peers?

Sometimes, committees do accomplish this lofty goal. My argument is that sometimes they don’t – especially if your committees are designed in a way to disable participation.

Context brief: what is a committee? 🔗

Frequently in this post, I refer to committees. But what are committees? I see a committee as a I see a committee as holding the following characteristics:

• Fixed group of individuals charged with important decision-making privileges
• Appointed or elected members with fixed term periods (i.e. an end date)
• May perform their work in a public and transparent way

Challenges of a committee 🔗

If designing a community for participation and engagement, a committee can do the opposite by pushing people away. It can be difficult for non-members to participate in important decisions. When building the foundation of a community on volunteerism, expecting others to give time in huge quantities is a false expectation. An active, long-term commitment as a committee member may be a big ask. Yet even if an individual wants to contribute, their company may not support such policy. So, this person is unable to contribute fully in the committee. Therefore, the opportunity is lost to include their voice as a representative of a larger community.

Furthermore, a committee depends on the engagement of its members to be effective. Committees are limited by the amount of time individual members actively contribute. Committees lose their effectiveness when:

1. Individual committee members practice poor time management, or are simply overloaded with too many responsibilities
2. Inclusion of others with valuable perspectives have no pathway to being heard or represented, unless they are on the committee

Committee members participate for a fixed amount of time as regular participants. This can be good for a healthy turnover rate, but it becomes bad when the same people are running over and over again. Often described as burnout!

What is a better design for community engagement? 🔗

A fatal flaw in community management is being too hands-off or too hands-on from a corporate context. I look back at 2018 in the difference of roles in Fedora Mindshare vs. Fedora CommOps. Red Hat strives for participation beyond paid Red Hat employees, yet the volunteer-driven community struggles at times for participation of any Red Hat employee.

The Mindshare Committee is the community body that leverages power in the community. These are tasks that could have been designed by CommOps too. I think the format and spirit of CommOps encourages collaboration and invitation to contribute. On the other hand, if you are not an elected or appointed member of the Mindshare Committee, there is not much in the ways of contributing. Even if that is more a belief than a fixed rule.

Two years passed since we last met in Bolzano. I remember you traveled in for a day to join the 2018 Fedora Mindshare FAD. You came many hours from your home to see us, and share your experiences and wisdom from both the global and Italian Fedora Community. And this week, I learned that you, Gabriele “Gabri” Trombini, passed away from a heart attack. To act like the news didn’t affect me denies my humanity. In 2020, a year that feels like it has taken away so much already, we are greeted by another heart-breaking loss.

But to succumb to the despair and sadness of this year would deny the warm, happy memories we shared together. We shared goals of supporting the Fedora Project but also learning from each other.

So, this post is a brief reflection of your life as I knew you. A final celebration of the great memories we shared together, that I only wish I could have shared with you while you were still here.

Ciao! 🔗

We had a unique privilege of meeting first in person before meeting online. At Flock 2015, of course I remember coming to your Fedora-Join session. This was my first introduction to the volunteer-supported mentorship community that exists in Fedora. Even though there was one particularly disruptive audience member, I remember learning from you and noting your long-time experience in the Fedora Community.

After that, we would come to know each other better. As I began a new chapter of my life at my university, we would become frequent collaborators. The Fedora Marketing team was always interesting to me, as part of the group of people who helped our community talk about and share the Fedora Project with others. Underneath your gentle mentorship, I learned the focus areas and history of the Fedora Marketing team.

At some point in 2015 or 2016, you asked me if I would like to chair a Marketing Team meeting. Thus began an early step in my journey from a participant to a facilitator. In a tragically ironic way, it strikes me how I did not see your guidance as mentorship at the time. I always saw our conversations as two friends discussing a shared hobby or interest. Such is the subtle art of teaching and mentorship.

Your many contributions 🔗

You were a cornerstone community member of Fedora for many years. Since our connection was from Fedora, it is worth noting the many contributions you made over the years. Long before Fedora or Linux were anything I knew about.

You and Robert Mayr co-authored a book together about Fedora 9, I think for the Italian Linux community. You were a one-time steward of the Fedora Join and Marketing teams. You were an influential member in shaping what Mindshare is today, from the days of the Fedora Outreach Steering Committee, the Fedora Ambassador Steering Committee before that, and grassroots community organizing in Italy even before that.

Beyond the source 🔗

But perhaps the memories I treasure most are the ones that don’t have much to do with Fedora at all. I remember learning that “in real life” you were a co-owner of a heating and air conditioning business in Italy. For many years, my family ran a heating and air conditioning company of our own. This was an experience I could always understand. I remember the times when you would go offline for some time. Then I would hear from you eventually, and you would tell me how the busy season kept you away from helping out in Fedora. And in a few words in IRC private messages, I simply knew and smiled.

We would meet at Flock events, but I find Flock is usually tough to get 1x1 time with others. I remember the day you came up and joined us in Bolzano for the 2018 Mindshare FAD. On a weekend day in March, you came and sat in a wine cellar converted to a conference room, where we spent the day recounting pain points and how Mindshare would address them.

And then, our small group went out for dinner. The food we ate and words we said are now faded memories, but the experience lives warmly in my heart as I think about what your life meant to me.

I was saddened to find no photographs or pictures of us together. But I went looking for our last conversations and found these final messages on IRC:

**** BEGIN LOGGING AT Sun Dec  4 17:49:56 2016

Dec 04 17:49:56 <jflory7>   That would be fantastic... I'll definitely let you know if I have plans to visit Italy. :)

Dec 05 07:00:32 <mailga>    jflory7 hope it happens. :)

**** ENDING LOGGING AT Wed Dec  7 00:28:51 2016

I never got to take you up on your offer to visit your home and meet your family. But I am happy that I had the opportunity to partially fulfill that old promise of meeting together in Italy.

Why write this? 🔗

I didn’t write this post with an outline, or a template. These words came to me while sitting with my own emotions and feelings. I am writing this because this is an effective coping mechanism for me to process what is lost, but also how to move forward from the loss.

The Fedora Project has given me a lot over the last five years. I have met many wonderful people and contributed to things that matter a great deal to me. But Fedora has also taught me about loss. There are many lessons in life that have nothing to do with work, code, software, or engineering, but have everything to do with how we look at the world.

In the wake of losing you, I think of the kind words and memories we shared that I did not tell you were important to me. I think of how the opportunity is permanently missed for me to share my appreciation of your kindness and friendship. The tragedy of youth is perhaps that I failed to fully appreciate our connection until after you passed.

When writing this, I came to realize something for me. And this will be different for everyone. But I like to think for Gabrielle and me, Fedora was never just about building an operating system. It was about collaborating with other people, human beings, on a digital infrastructure project that mattered, and to share kindness unto others – especially beginners and newcomers.

Rest in peace, amico.

DevConf.CZ 2020 is the 12th annual, free, Red Hat sponsored community conference for developers, admins, DevOps engineers, testers, documentation writers and other contributors to open source technologies. The conference includes topics on Linux, Middleware, Virtualization, Storage, Cloud and mobile. At DevConf.CZ, FLOSS communities sync, share, and hack on upstream projects together in the beautiful city of Brno, Czech Republic.

devconf.info/cz/

This is my third time attending DevConf CZ. I attended on behalf of RIT LibreCorps for professional development, before a week of work-related travel. DevConf CZ is also a great opportunity to meet friends and colleagues from across time zones. This year, I arrived hoping to better understand the future of Red Hat’s technology, see how others are approaching complex problems in emerging technology and open source, and of course, to have yummy candy.

Sessions: Play-by-play 🔗

Event reports take many forms. My form is an expanded version of my session notes along with key takeaways. Said another way, my event report is biased towards what is interesting to me. You can also skim the headings to find what interests you.

Diversity and inclusion meet-up 🔗

Would you like to meet other attendees who stand under the umbrella of “Diversity and Inclusion” or would you like a introduction into what Diversity and inclusion is and why it’s a good thing? this is the session for you! All are welcome!

Imo Flood-Murphy

This was a short, informal session ran by Imo to network and get a high-level introduction to diversity and inclusion in open source. Everyone in the room introduced themselves and gave a short explanation of who they were or what projects they represent. I appreciated the opportunity to meet others and better understand how Red Hat approaches diversity and inclusion.

A suggestion for next time is to allow more unstructured time for conversations. I think fun icebreakers get folks comfortable in a short amount of time to help make connections for the rest of the weekend.

Lessons learned from testing over 200,000 lines of Infrastructure Code 🔗

If we are talking that infrastructure is code, then we should reuse practices from development for infrastructure, i.e.

1. S.O.L.I.D. for Ansible.

2.Pair devops-ing as part of XP practices.

3. Infrastructure Testing Pyramid: static/unit/integration/e2e tests.

Lev Goncharov

Lev shared best practices on building sustainable, tested infrastructure. Infrastructure-as-Code (IaC) was important to how T-Systems scaled their infrastructure over time.

My key takeaways:

1. Smaller components:
   1. More sustainable
   2. Easier to maintain
   3. Easier to test
2. Ansible Roles encourage best use practices for Ansible
3. Spreading knowledge is essential (if nobody understands it, the code is broken)
4. Code review creates accountability
5. Use static analysis tools (Shellcheck, Pylint, Ansible Lint)
6. Write unit tests (shUnit2, Rspec, Pytest, Testinfra, Ansible Molecule)

Content as code, technical writers as developers 🔗

In the open-source project Kyma, documentation is an integral part of code delivery. We, the project’s Information Developers, believe that using the same tools and methodology as your good old code developers, we can create comprehensive and accurate documentation. During our talk, we’ll share the whys and hows of our approach, showing you that the “developer” in “Information Developer” isn’t there just because it sounds cool. We’ll prove that creating documentation goes beyond linguistic shenanigans and salvaging whatever information there is from a trainwreck that is the developer’s notes. Testing solutions, finding our way around Kubernetes, tweaking the website, engaging with the community are just a few examples of what keeps us busy every day.

Barbara Czyz, Tomasz Papiernik

“Information Developers” is a cool phrase I learned. Barbara and Tomasz explained the value of technical writing and asserted documentation should live close to project code.

My key takeaways:

1. Documenting processes like release notes enables others to join with less barriers
2. Docs-as-Code (DaC): Visibility of docs across development process is important
   1. Placing docs with code encourages feedback loops and avoids silos
3. Put links to docs in visible places (e.g. API messages, console messages)
4. Management aside: Emphasize/incentivize value of technical writing in your team
5. Remember bridges across skill areas is possible (technical writers can also be community-oriented people too)

Uncharted waters: Documenting emerging technology 🔗

We can’t help but feel the lure towards the hot new thing, especially when it comes to technology. Part of that lure is the breaking of ground, venturing into the unknown, and working on solutions to new problems. But a lot of the same things that make emerging technology fun and exciting to work on are exactly why it can be difficult to document. These challenges are quite different to those associated with mature products.

This talk is for anyone working on new products and emerging technology, or just interested in learning about fast-moving documentation. It is for the developer as much as it is for the writer, since it usually falls to them to write the early docs before a writer is added to the team.

Andrew Burden

This was the talk I didn’t know I needed to go to.

Lately I work with “emerging technology,” which means different things to different people. Regardless of what emerging tech means to you, Andrew focused on how to write documentation in a fast-paced environment with “pre-release” technology, where things change fast and suddenly. Normally this is an excuse to not write docs, but Andrew showed, yes! It is possible to write good docs, even when context changes fast and often.

Key considerations of fast-paced technical writers 🔗

An even balance of these considerations helps get into a user’s mindset:

1. Scope / scale of release
2. Release schedule
3. Developer meetings / face-time
4. Exposure with $TECHNOLOGY
5. Deployment experience with $TECHNOLOGY

Surviving the information wall 🔗

The “information wall” is the endless wall of information and things to know about a project. If information is endless, how do technical writers survive?

• Take notes: Be like a scientist
• Take notes about your notes
• Be organized with your notes

Obviously Andrew was getting at the value of note-taking. Practicing note-taking skills is critical to keep up with the pace of change.

“Multi-Version Syndrome” 🔗

Sometimes you are writing features for things that will not be released in the next release. There is a risk of losing information across multiple releases (e.g. publishing the wrong thing too soon, or the right thing too late). Clarify the release schedule as you go. A good safeguard against losing information is to rigorously understand release cycle cadence and priority.

If your product isn’t mature yet, anticipate change instead of avoiding it.

Access to technology is critical 🔗

Technical writers are often User 0. To understand the technology, you need access. There are interactive and non-interactive ways of getting access. Interactive ways are preferred because they are always reproducible.

• Interactive
  • Deploy your own
  • Get someone else to deploy it for you (but lose install context)
• Non-interactive
  • Live demos
  • Demo videos
  • Asciicinema (CLI-oriented)

Other takeaways 🔗

• Screenshots have high maintainability cost; avoid if possible
  • Sometimes good stop-gaps until something more maintainable
• Where to begin? Make a table-of-contents for the Minimum Viable Product
  • Never underestimate outlines (ahem, like how I wrote this blog post…)
• Avoid documentation scramble near release day:
  • Make lists / check-lists
  • Take more notes
  • Pre-release checklist
  • Think now, and for the future
• Audit your docs: On-boarding new people is a powerful opportunity to test out your docs

Thanks Andrew for a deep dive on this narrow but important topic.

Community management: not less than a curry 🔗

Every volunteer joins an Open Source community for a reason. The reasons could range from technical gains to finding his/her/their passion. This community of diverse volunteers require a leader who can not just mentor them with their interests but also a manager managing the community activities in terms of community engagement and planning. A community manager is not less than a candle of light and in this presentation, I would be highlighting my learnings and experiences about starting a community from scratch around a project and maintaining a healthy community management practices.

Prathamesh Chavan

Prathamesh designed an activity to help the audience understand community management. My key takeaway was community management is about connecting and understanding others as their authentic self.

In the activity, Prathamesh passed papers and pens to the audience. His session had three steps. Between each step, all attendees traded papers with another attendee:

1. Define a project idea (why, how, what)
2. Identify challenges to idea (i.e. questions)
3. Answer challenges

It reminded me of a similar workshop I attended before. This inspired me to work on my own workshop idea for a future conference.

Cognitive biases, blind spots, and inclusion 🔗

Open source thrives on diversity. The last couple of years has seen huge strides in that aspect with codes of conduct and initiatives like the Contributor Covenant. While these advancements are crucial, they are not enough. In order to truly be inclusive, it’s not enough for the community members to be welcoming and unbiased, the communities’ processes and procedures really support inclusiveness by not only making marginalized members welcome, but allowing them to fully participate.

Allon Mureinik

Allon recognizes the importance of diversity, but asking for improved diversity is one side of the coin. A friend recently shared a powerful quote with me: “If diversity is being invited to the party, inclusion is being invited to dance.” Allon’s message was to dig deeper on including marginalized people in our project communities.

He identified ways we accidentally make our communities less inclusive because of our cognitive/unconscious biases. Everyone has blind spots! Allon suggested ways to be more conscious about inclusion in open source:

• Knowledge barriers
  • Procedural knowledge, not just technical
    • How do you submit code? File a bug? Make meaningful contributions? These need to be documented
  • Documentation fosters inclusivity
• Language barriers
  • Working proficiency in English not universal
  • Conversations have extra barriers (e.g. communicating complex ideas, understanding advanced words)
• Time barriers
  • Work schedules no longer 9 to 5
  • Remember other folks in different time zones
  • On giving feedback: Fast is not a metric! Be smart
    • Merging PRs while others are away, or shortly after opening it
    • Allow time for input on non-trivial changes
• Transparency barriers
  • If not in the open, it didn’t open
  • Negative example: Contributor makes a PR, reviewer has face-to-face conversation with contributor, reviewer merges PR without public context
  • Default to open: in many ways
    • If you can’t be open, at least be transparent

Diversity in open source: show me the data! 🔗

How diverse is your work environment? Diverse communities are more effective, they allow us to share the strengths of the individuals who make up the community. Have you ever looked around and noticed that most of our Open Source communities are predominantly male? Why do you think that is? We’ll use gender diversity as a case study and share some intriguing data points. Let us convince you why it’s so important.

Regardless of your gender, we would love for you to join us! We will also give you some tips on how you can make a difference.

Serena Chechile Nichols, Denise Dumas

Serena and Denise divided the talk into two sections: metrics and action. The way they presented, they brought the audience on the same page by visiting a variety of metrics and then transitioned to an empowering discussion about changing trends we see.

Next time, I hope to see expanded messaging by defining diversity beyond only women. Diversity was frequently tied to gender participation metrics in open source. While women are underrepresented, there are additional aspects of identity that can compound discrimination. Race, socioeconomic status, nationality, sexual orientation, and more also play a part in understanding challenges collectively faced in inclusion work.

The data 🔗

• Gender differences by # of contributors:
  • GSoC 2018: 11.6% female-identifying contributors
  • OpenStack: 10.4% female-identifying contributors
  • Linux kernel: 9.9% female-identifying contributors
• U.S. Dept. of Labor: 22.2% of technical roles filled by women
  • 2014-2019: More women entering tech jobs at companies like Apple, Microsoft, Google, etc.
• Years of experience by gender (<9 years):
  • 66.2% female
  • 52.9% non-binary/queer
  • 50.1% male
• GitHub user and developer survey:
  • 95% male
  • 3% female
  • 1% non-binary

Let’s make things better 🔗

Serena and Denise asserted diversity creates change. All changes come with challenges. Diversity can increase the friction in the process, but that is okay. They emphasized the need for multiple perspectives see past our initial biases (conveniently covered by Allon in the previous talk).

This transitioned to questions, comments, and thoughts from the audience. One interesting point was using the phrase, “we don’t do that here” to create and set norms. I gave a suggestion to look at projects you already participate in and see if there is a diversity and inclusion effort there already. If there is, see if there are ways to help and get involved. If not, consider starting one (or network with the Open Source Diversity community).

To wrap up, one recurring theme of Serena and Denise’s talk is to make time to step back and evaluate the bigger picture. Questioning our biases is an important skill to practice. We need the space and time to recompute!

Candy Swap 🔗

Do you have a unique sweet dessert or candy from your country or hometown? Do you love to try new and exciting foods from around the world? Spend an hour with fellows as we share stories and candies from the world with each other. Participants are invited to bring a unique confectionary or candy from their country or city to share with multiple other people. Before going around to try yummy things, all participants explain what item they bring and any story about its origins or where it is normally used. After sharing, everyone who brought something rotates around to try candies brought by others. After all participants have had a chance to sample, the rest of the community is invited to come and try anything remaining.

Jona Azizaj, Justin Wheeler

I am biased when I say this is one of my favorite parts of conferences I go to. Jona originally proposed the candy swap for DevConf CZ. After unexpectedly adding DevConf CZ to my travel list for 2020, we teamed up to share the sweet tradition from Fedora Flock to DevConf CZ! This is one of my favorite conference traditions because I get to know other attendees in a context outside of technology. And food is always an easy way to win me over.

Instead of listening to me, see what other people have to say about it:

Time for the international candy swap! There are so many things to love about #DevConf_CZ but the geographic diversity of attendees might be my favorite part. Thank you for organizing, @jonatoni & @jflory7! pic.twitter.com/rU1ETp5aTa

— Mary Thengvall (she/her); mary-grace.bsky.social (@mary_grace) January 25, 2020

The "sweetest" activity of #devconf_cz: Today at 3 PM! 🍬🍫
Join Candy Swap, share candies, sweets and stories with others from around the world! https://t.co/OlfdmgGa3a pic.twitter.com/Jnlqi3lsaq

— DevConf.CZ (@devconf_cz) January 25, 2020

Candy Swap time at #DevConf_CZ 😍 pic.twitter.com/zFCNnXZoJf

— Jona Azizaj👩🏻‍💻 🥑 @jonatoni@mastodon.social (@jonatoni) January 25, 2020

Well I experienced this for the #Flock 2019. It's a great opportunity to know the tastebuds of diverse people and enjoy! :D

— Aal (Alisha)🌻 (@withloveaal) January 26, 2020

From Outreachy to cancer research 🔗

Outreachy program is helping women and other underrepresented people to make first steps in tech career. Picking a project, making first open source contributions, working on assigned project and learning from advanced people. But what happens when this three months are over? Can Outreachy be a lifechanging experience?

I will share my story of conversion from a chemist and full time parent into a Fedora Outreachy intern and how I found my place as a junior software developer in cancer genomics research at IRB Barcelona.

Lenka Segura

This was a favorite of the weekend. “Fedora Outreachy intern Lenka Segura on how Outreachy opened the door for her career to cancer research at IRB Barcelona!”

I put effort into live-tweeting a Twitter thread. Get the full scoop there!

Connect and grow your community through meetups 🔗

Open source communities collaborate in a multitude of ways - chatting on irc, submitting issues and contributing code on GitHub, discussing and sharing ideas on reddit and other social channels. Face to face gatherings add another dimension to that, where community members can learn and share their experiences. Local meetups provide a venue for people with similar interests to socialize and connect. However, organizing meetups is not trivial. How do we encourage and motivate the community to arrange meetups, and to keep the momentum? In my one year with the Ansible community, we have doubled the number of active meetups in Europe. These meetups are community driven, rather than Red Hat. Find out how we use metrics to analyze the situation and needs, and the steps we are taking to reach our goals of connecting with even more community members. Learn from our mistakes and challenges (100 RSVPs and only 20 turned up?), plus some tips to make your meetups more inclusive.

Carol Chen

Carol explained the role of local meet-ups around the world in building communities around software projects. She emphasized that single metrics are not always useful, so it is more helpful to evaluate on multiple areas. The most useful takeaway for me was the 5 W’s: why, who, what, when, where.

• Why? Common curiosity (noticing something new in your community)
• Who? Connections and networking
• What? Concise, compelling content
  • Consider venue travel (how to make it worth their while?)
  • Provide alternatives to git-based submissions
  • All talks don’t have to be technical! Diversify to appeal to wider audiences
    • Announcements for future events, work-life talks
    • We are more than just the technology we work with
• When? Consistency
  • Helps with venue scheduling
  • Helps retain attendee focus and build habits

Carol also gave suggestions for common points to think about for improved inclusion. All of these need active, not passive inclusion.

• Special needs / disabilities
• Food allergies
• Beverage preference (often alcohol/non-alcoholic)
• Language
• Traffic-light communication stickers
• Photography lanyards
• Gender pronouns

Beyond DevConf CZ 🔗

While the sessions are excellent and fulfilling (and sometimes frustrating when you miss a good talk with a full room), DevConf is also more than the sessions. It’s also the people and conversations that happen in the “hallway track.” It was nice to see many old friends and make new ones.

I spent a few extra days before and after DevConf CZ in Brno. In some of that time, my colleague Mike Nolan and I rehearsed in-person for our FOSDEM talk the following weekend (to come in a future blog post). I also enjoyed coffee and waffles with Marie, Sumantro, and Misc!

A few memories of a great week in Brno

Until next time! 🔗

I learn a lot and have a lot of fun at DevConf CZ. I’m happy to return for a third year. Hats-off to the organizers and volunteers who pulled it all off. Each year, DevConf gradually makes improvements. It’s nice to see inclusion prioritized across the board.

Thanks also goes out to RIT LibreCorps for sponsoring my trip. Extra thanks to Jona Azizaj!

I thought sharing it on my blog might be interesting for others. Don’t read into this too much – it was a quick analysis from a single primary source and a few secondary references.

What is Fedora Modularity? 🔗

The Fedora Project is a common Linux operating system which ships software in “packages”. Since June 2015, project members built a pipeline to ship modular versions of existing packages, known as Modularity. Modularity allows someone to use different versions of the same software (e.g. a programming library) on the same system without dependency conflicts.

In a way, Fedora Modularity shifts some responsibility from the Linux distribution (as a provider of known, good combinations of co-dependent packages) to the sysadmin (as a decision-maker to use different combinations of software versions in their environment). It’s more flexible for a variety of deployment requirements. I see it as a net-positive win for the sysadmin experience since its final release.

Why did Modularity fail in 2017? 🔗

However, in this post-mortem from December 2017, a project lead (Stephen Gallagher) announced Fedora Modularity efforts are scrapped for a total redesign. Even though it was not a final release, it was regarded as a failure because of the late status of the project, since its proposal in mid-2015. The post-mortem explained the amount of effort required by all software packagers was significant and also noted the wide amount of engagement necessary from different stakeholders. New requirements and steps to packaging guidelines were not understood by the community of software packagers, and project milestones were not met because of low participation in the packager community.

Their report reveals the amount of moving parts Fedora Modularity must account for. It demonstrated a flawed understanding of user and developer needs during initial feedback from the beta’s implementation. In other words, the level of complexity for the project exceeded the amount of employee resources available to accomplish the project. The redesigned model (proposed in the reflection) pivoted by utilizing existing tools and infrastructure to support the new features, which required less changes for new software package updates. Thus, the packager community was better able to participate in providing new functionality in existing packages.

Additionally, sufficient documentation of new guidelines was unavailable to users, stemming from lack of engagement and feedback by existing users. This was later remedied with user experience testing through events like Test Days, which allowed any community member to try out new features and functionality with their own packaging workflows.

Since the project was finally implemented in late 2018, it was better received in the community than the failed launch in December 2017. Most success since the first failure came by simplifying project requirements (e.g. by leveraging how existing infrastructure was designed instead of reinventing the pipeline) and getting more user feedback on a regular basis (e.g. with community outreach events like Test Days and classroom sessions hosted live on YouTube).

Gallagher, S. (2017). Modularity is Dead, Long Live Modularity! Fedora Community Blog. Retrieved from https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/

The entry is lifted out of my journal with minimum edits. I thought about fully revising it or updating it before publishing. Many parts I would write in a different way now, but I decided to let it be. It reflects my perspective at that particular moment and time at 19 years old. It is more personal than other posts I’ve published and maybe it’s a little uncomfortable for me to share, but I felt like it was worth doing anyways.

entry002: 2017-02-12 🔗

Picking up the pen to write in this is always difficult because it feels like there’s too much to say. Part of the problem is that I don’t write frequently enough, which I’ll try to improve. Not everything worth saying needs to be publicly lambasted.

I left the apartment for coffee after again reading the story of Seth Vidal, a founding developer of YUM and a one-time Fedora superstar. Seth was killed in a hit-and-run accident while cycling in 2013.

What strikes me so much about Seth isn’t just the work or code he left behind, but his legacy. There is no shortage of blog posts dedicated in his memory, with many written by folks I see regularly in Fedora. He is held in a high respect and regard not only because of his work, but how he worked with people. He was clearly a sincere friend of many in the community and always knew how to use and share his brilliance to bring out the same brilliance of those he worked with. He wasn’t afraid to speak his mind, but he always did so courteously and in a way where there was a next step or improvement. As one memoir quoted him as saying with a cocked head and a smile, “Are you sure that’s what you want to do? Because I’m pretty sure it’s not.”

It’s odd for me to read about Seth and how connected to him I feel, despite his death occurring well before I was anywhere near where I am now. Maybe it’s because I, like [thousands] of others, use his software. But more likely is because I see the type of impact and legacy is something I wish to share. Not having so many people write memoirs of my passing, but more about how many lives, communities, and people he touched. I see a man you could approach with anything, whether he knew you or not, and he would give you his honest opinion to help drive or motivate you to success. It may not be what you want to hear, but it will be what you need to hear. Again, delivery of that message is critical, and Seth seemed to be pretty good at it.

I may not know Seth, nor will I ever, but his legacy gives me a strong reminder about what I hold important and how I want to carry out my presence in the projects I’m involved with. If more people want more Seth Vidal’s in the world, then we need to [understand] his values, compare them to our own, and build those values into our own being. This is part of the idea of actively shaping and adapting our values, and never settling with the way we are because we think we know these things. If the mind is open and willing, we are always learning, and thus, always changing.

In summary? Seth’s light fades out and burns into embers, but it never dies. His legacy will always be there, for friends to remember and strangers to learn from. Amidst all of this panicked writing I have to do after DevConf and FOSDEM, Seth’s legacy levels me and reminds me of what’s important. Sometimes what’s really important is logging off and going for a bike ride, or a coffee with notebook and pen, or sharing precious time with loved ones. Seth, you may be gone and have no memory of me, but I have your memory, and I hope you are with me too.

Justin Wheeler

$ vagrant provision
==> default: Running provisioner: ansible...
    default: Running ansible-playbook...

PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
fatal: [default]: FAILED! => {"changed": false, "module_stderr": "Shared connection to 192.168.121.3 closed.\r\n", "module_stdout": "\r\n/bin/sh: /usr/bin/python: No such file or directory\r\n", "msg": "MODULE FAILURE", "rc": 127}
	to retry, use: --limit @playbook.retry

Problem: Python 3 by default 🔗

This error appears because Fedora 28 does not provide a Python 2 binary by default. Only Python 3 is provided on the base cloud image. I verified this by SSHing into the Vagrant box.

[jflory@vagrant-host vagrant]$ vagrant ssh
[vagrant@localhost ~]$ dnf list installed | grep -i python

Annoyingly, I must install Python 2 manually in the box each time it fails to provision. Surely, there is an easier way? Fortunately, StackOverflow came to the rescue.

Solution: ansible.extra_vars 🔗

It’s possible to tell Vagrant where the Python binary is located. You can pass the path to the python3 binary manually in your Vagrantfile.

# Provisioning configuration for Ansible.
config.vm.provision :ansible do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.extra_vars = { ansible_python_interpreter:"/usr/bin/python3" }
end

Adding these changes to your Vagrantfile allows Ansible to successfully run on the Fedora Vagrant guest. Python is successfully located.

This is an annoying workaround, but it solves the issue and lets you successfully test and iterate changes on Fedora systems. Here’s hoping the Fedora cloud image maintainers add a default binary for /usr/bin/python to point to /usr/bin/python3 in the future.

Transparency is important to me. I wanted to make this announcement ahead of time to set clear expectations for the upcoming months. I am returning to Chicago, IL to work another internship at Jump Trading, LLC. From June to August, I am working at their Chicago office. I am excited to return and learn more from an amazing team of people.

I am not blocked by company policy from contributing to open source, so I won’t disappear completely. However, while I am still able to contribute to Fedora, I do not expect to keep up the level of activity that I contribute at now during my internship.

Away from May to August 2018 🔗

May is filled with other personal commitments, followed by a near immediate departure to Chicago in early June. Thus, I am stepping out of Fedora in early May. I hope to spend time with friends and family before departing for Chicago, so my estimate is a little generous to the benefit of being realistic. My internship ends around mid-August, so I hope to begin my normal levels of contribution around this time.

The only area I hope to stay partially active with is the Fedora Community Blog to continue my post as the editor-in-chief. While I still don’t expect being fully involved, I hope to help with editing and keeping things moving.

I’m looking forward to seeing familiar faces again in August at Flock 2018!

Home is a suitcase 🔗

I began the third year of my degree and moved for the fifth time in two years when I made it back to Rochester in August. This time, I found somewhere to ideally live longer than only a few months of the year. I moved into a house with a few other roommates with more space than I’ve had before. For the first time in a while, it’s somewhere I’ve made to feel like home.

This move came months after I ended a semester of a study abroad program and lived in a city for an internship. Most of 2017 made my suitcase feel like a home, but it afforded many unique experiences.

Croatia: Study abroad 🔗

From January to May 2017, I participated in a study abroad program with my university to Dubrovnik, Croatia. RIT has full campuses in both Zagreb and Dubrovnik. This made planning the semester abroad easy, but also encouraged me to go somewhere I might not have gone otherwise.

My choice to study in Croatia was well-rewarded. On paper, I earned 12 credit hours, but I took away more than what I learned in class. My most important lessons came in the form of midnight bus rides to Albania, photograph exhibits capturing genocide in Sarajevo, and hugs from normally faraway friends in Czechia. My time abroad began a process in finding myself that has continued since my time in Europe.

DevConf 2017 / Fedora Diversity FAD 🔗

At the beginning of the year, the Fedora Diversity Team held a “Fedora Activity Day” (FAD) event in Brno, Czechia. If you’re outside of the Fedora community, think of a FAD as a focused, in-person team sprint. Together with our team in-person and remote, we mapped out our goals and plans for 2017 and set out to continue the work we began nearly three years ago.

In addition to the work we accomplished together, it was fulfilling for me to see my teammates that span three continents. I spent a week with not only my teammates but also my friends. The days we get to spend together are a privileged few in the year, and it was fulfilling and motivating for me to spend some of our time together in a way that wasn’t Pagure tickets or IRC meetings.

Read more about our team sprint in this event report:

https://communityblog.fedoraproject.org/fedora-diversity-fad-2017/

FOSDEM 2017 🔗

In February, I attended the Free and Open Source Software Developers European Meeting (FOSDEM) for the first time. FOSDEM is the largest open source conference in Europe, bringing together over 8,000 open source enthusiasts, contributors, and leaders from around the globe.

I had the privilege to attend as a member of the Fedora community, so my time was between the Fedora booth to meet the community and catching interesting talks. I also gave a talk of my own on the main track, What open source and J.K. Rowling have in common! I gave this talk to a smaller audience at DevConf, but the FOSDEM audience was considerably larger.

In retrospect, my original talk topic is relevant but I have ideas on how I could have delivered my message more effectively. Regardless, it was a learning experience for me to present in front of a new audience. Public speaking opportunities filled my youth, both in theater and in presentations, but I had never presented to a technical audience before (let alone on a non-technical topic). The experience at FOSDEM helped build my understanding and I hope to return with a new topic someday in the future.

Exploring the Balkans 🔗

Outside of open source and Fedora, my time in Croatia included a lot of time outside of Croatia. When many of my roommates went to explore the wonders of Western Europe, I lost my heart in the shadows of the Balkan mountains. My spring break was a solo trip split between Sarajevo, Bosnia and Hercegovina and Tirana, Albania.

Sarajevo 🔗

The three days I spent in Sarajevo were short but significant. I was truly alone on this visit and it was up to me to make the most of it. Originally, I was skeptical to go alone, but I knew that I would never have a better opportunity to go. My fascination with Sarajevo stemmed from a year of studying European history in high school, and knowing the cultural significance of Sarajevo as a meeting point of western and eastern cultures. In the end, I decided to go, and I was rewarded for it.

Most of my trip in Sarajevo consisted of museums. I visited various museums, ranging from eighteenth to twentieth century history. The most rewarding for me were the Galerija 11/07/95 and the Tunnel of Sarajevo. The gallery documented the Srebrenica genocide in July 1995 by the Serbian armed forces. The exhibit was eye-opening and perspective-shifting. The Tunnel of Sarajevo, sometimes called the Tunnel of Hope, is another perspective-shattering experience. The museum introduces the tunnel used during the siege of Sarajevo during the 1990s, when Serbian forces surrounded the city for an almost four-year siege. The tunnel was the only way for citizens and resistance forces to contact the outside world and keep the resistance alive. A small part of the tunnel is preserved, and the other artifacts make it a gripping experience (not to mention it’s a short drive out of the city, so you also have a chance to mentally prepare and later unpack the experience).

Tirana 🔗

I visited Tirana, Albania four times on my trip abroad. In Tirana, my heart was captured by the people there. For years, I read about the Open Labs Hackerspace community based in Tirana and I always imagined an opportunity to see it in person. I actually remember my first encounter with their community was an Ada Lovelace Day event report. And somehow, the circumstances shifted where I was able to meet their community and immerse myself in the culture, if only for a short time.

During my times in Tirana, I participated in the first-ever 48 hour hackathon to support the UN’s Sustainable Development Goals (SDGs), the first edition of Linux Weekend, and the annual Open Source Conference Albania (OSCAL).

https://fedoramagazine.org/students-fedora-linux-weekend-2017/

India 🔗

At the end of my study abroad experience in Croatia, a unique opportunity presented itself to me. I did not buy my return airfare back to the US before I left for Croatia. When price-checking for my trip back, I noticed it was a few hundred dollars extra if I decided to spend a week in India before flying back to the US.

I booked the tickets.

The last day of my classes finally came, and the next day, I was traveling further east, to Mumbai (or Bombay, if you prefer). I had the great fortune of having two great friends who invited me to the homes of their families during my trip. I visited Bee in Mumbai and Amita in Pune, all split across a single week!

My trip to India was eye-opening. For years, I’ve had a fascination with Eastern culture and philosophy, but it was something completely different to experience. Bee and her family took me to the Global Vipassana Pagoda, a personally fulfilling experience for me. We visited the Bandra–Worli Sea Link, Shree Mahalakshmi Temple, and several other places in Mumbai. I remember walking through the streets more than anything.

In Pune, Amita and her family showed me their favorite places. I had a chance to meet many other Fedora friends in Pune too. One of my favorite memories of Pune was a historic gurdwara. Amita took me and the others in our group to visit. For a moment, I finally got to see something I’ve only read about right in front of my eyes. The history and reverence in these places was absorbed into my mind.

I never expected an Indian visa stamp in my passport in 2017, yet it happened. I’m equally filled with wonder at how the circumstances unfolded as I am grateful this experience sneaked into my year.

Chicago: Urban experience 🔗

After my semester abroad and visiting India, I was whisked back to the United States, only to pack up once again for another new experience. From June to August, I lived in Chicago, Illinois to work an internship at Jump Trading. Chicago had a feeling of nostalgia for me because much of my father’s family has origins tracing back to Chicago. But I would find myself losing more of my heart in Chicago than I realized.

The internship 🔗

I worked with a fantastic team of people on exciting projects. Professionally, my time in Chicago was motivating and empowering. I was provided the opportunity to learn and also contribute. I walked in with a dreadful feeling of imposter syndrome and left feeling more confident in my own learning abilities. Docker, Kubernetes, and time-series data became a part of my daily work life, when I had little to no knowledge before then.

By the time my internship finished, I helped contribute to our team’s goal of standing up Kubernetes and contributing a few patches in Kubernetes projects like Minikube. I have great mentors to thank for not only direct, technical assistance but also motivational mentorship and empowerment too.

Everything else 🔗

There was more to Chicago than only the work too. Before long, I felt like a true Chicagoan, traveling the subways into the Loop, catching free concerts in Millennium Park, and indulging in the Chicago tradition of deep-dish pizza.

Unlike other cities I’ve visited, like New York City, Chicago felt easier to integrate into. The culture was notably “slower” than the fast-pace life of NYC, London, or Washington DC. I discovered Middle Eastern markets that became a regular part of my weekends, made friends with the baristas at a local coffeehouse, and had the privilege of hosting friends from three continents for short stays.

I left Chicago and was offered a new contract for the following summer in 2018. I’m looking forward to be back in June again.

Year of Fedora 🔗

2017 was full of time and effort spent in the Fedora community. In addition to the Diversity FAD, I was elected to the Fedora Council (on my third attempt), attended the annual Fedora contributor conference, Flock, and also narrowed my scope for contributions.

When I began contributing to Fedora, I was contributing to many things. Marketing, community operations, Fedora Badges, Fedora Magazine, Ambassadors, Games SIG, Join SIG, the Diversity Team, and maybe a few more things. After a while, I realized my contributions carried great width but poor depth. In 2017, I “reconfigured” my time in Fedora to focus in on the areas where I felt my time yielded the highest impact. This is Fedora CommOps and the Diversity Team.

I resigned as Fedora Magazine editor-in-chief and also formally stepped down from other teams. It made me sad, but I knew it was the right decision for me. I’m happy to spend more time working in fewer projects at a greater depth and focus than I had before.

Flock 2017 🔗

Flock, Fedora’s annual contributor conference, was held from Aug. 29 to Sep. 1 in Cape Cod, Massachusetts. Every year, Flock is an empowering experience for me because of the face-time I get with the people I spend much of my year working with remotely. This year was no different, and many new faces were mixed in with the old ones.

The highlights for me were in three forms: the CommOps session, the Diversity Team session, and the Fedora Magazine session. Together with Sachin Kamath, we led the CommOps session. You can read more about our session here:

https://communityblog.fedoraproject.org/metrics-docs-flock-2017/

The Diversity Team and Magazine sessions were also valuable for both teams to get feedback from the rest of the community. In the Diversity Team session, we had many active participants outside of our team that reminded us the importance of narrowing our focus for higher impact. I also attended other interesting sessions held by the community, like the future of fedmsg by Jeremy Cline.

CommOps FAD 🔗

Towards the end of 2017, I worked together with our team in CommOps to organize our own team sprint, or FAD, in 2018. We successfully planned the event and organized it in Brno, Czechia, similar to last year’s Diversity FAD.

More details on this will be found in its own event report!

ListenBrainz indie study 🔗

In my fall semester of 2017, I took on an independent study to further explore the ListenBrainz project. ListenBrainz is an open source social platform to document the music you listen to over time. If you’re familiar with Last.fm or Libre.fm, it’s a similar concept, but the focus is more on the data than the social features. ListenBrainz is supported by the MetaBrainz Foundation, also the guiding body for the more well-known MusicBrainz project.

In my independent study, I had a chance to contribute documentation and community tools (like issue / PR templates), as well as explore how the project gathers and builds metrics. I didn’t make my original milestone of major code contributions to the project, but I better understood the community and tried to help in the areas of low coverage, like documentation.

The experience was insightful for me and provided me an excuse to work on something that I am genuinely passionate about. Music is a powerful part of human culture, and the MetaBrainz Foundation takes a serious approach to documenting music, especially in a technical sense. ListenBrainz represents an opportunity for us to better explore and understand ourselves through our music listening habits. I hope someday that ListenBrainz will be a platform for data journalism and research about music. That’s my dream.

Opensource.com community moderator 🔗

At the beginning of 2017, I was brought on board as an Opensource.com community moderator. Together with other community moderators and site staff, I help contribute new content and source new writers to the site. My invitation to the community moderator team came shortly after the announcement that I received the 2017 People’s Choice Award. When Rikki Endsley invited me to the team, it felt like a natural alignment to my passion for storytelling.

All Things Open 2017 🔗

I was invited to All Things Open, an annual open source conference in Raleigh, by the Opensource.com team. The day before the conference, I met the rest of the team and other community moderators at the Red Hat HQ in Raleigh. We spent the day locked into a room together to hash out plans and goals for the next year. It was a productive opportunity for the team to work together and also a great opportunity to meet the other members of the community.

Some of my best takeaways from this experience were catching coffee with other community moderators, meeting Jim Whitehurst to talk about Opensource.com, and giving my talk, What open source and J.K. Rowling have in common, for the final time.

I hope I have the opportunity to go again next year to meet the awesome team behind Opensource.com. (If you haven’t considered before, come and write for us too!)

Happiness Packet Challenge 🔗

Another unusual milestone for my 2017 was the first rendition of the Happiness Packet Challenge. I was introduced to the Happiness Packets website in 2016. Happiness Packets are an easy way to say thank you to someone who has had a positive impact on you. I came up with a challenge to my friends and network to write one Happiness Packet a day, every day, for a week.

I followed up with the team behind the project to evaluate the impact of this idea, and I was pleasantly surprised. Here’s the number of messages sent for the two weeks prior to the Happiness Packet Challenge, followed by the week of the challenge:

• Week starting 2017-03-27: 2 sent
• Week starting 2017-04-03: 35 sent
• Week starting 2017-04-10 (challenge week): 72 sent

You can read more about the challenge in my original blog post. Keep an eye out for it again in 2018.

https://jwfblog.wpenginepowered.com/2017/04/happiness-packets-challenge/

Living openly 🔗

Earlier in this post, I alluded to how I felt like I began to find myself when I was abroad. My study abroad experience was the beginning of a longer process that leads into present day.

In April, I went public with my depression, both to help take a weight off my shoulder and to be a voice for others who are afraid to speak up. I was always concerned of the reaction from publishing something like that, but I was met with nothing but loving-kindness from friends and strangers. It gave me new confidence to live more openly and wear my values in the open.

The story continued in October, when I decided to delete my Facebook and Instagram accounts.

https://medium.com/@jflory7/cut-the-plug-deleting-facebook-and-instagram-6cbe7c86d9c9

I considered this for a couple of years before, but I pulled the trigger in October. Like many others, it felt almost too much of a task to disconnect myself from this huge network of people and friends. But the negative impacts of it were draining me and trapping me. Since I deleted my accounts, I’ve noticed a positive impact in overall levels of happiness and awareness. However, I don’t think the social media accounts alone are the reason for this.

In the near future, I hope to do a follow-up post to my decision to cut away from the Facebook and Instagram machines. Keep an eye out for more.

2018 🔗

It’s already February in 2018 when I finished this post. This year, I thought it would be the year when I get the post out closer to the new year, but somehow I always slip. In either case, it gives me a chance to take in some of the new opportunities and excitement of the new year before reflecting and looking back.

This year, I’m working an internship with UNICEF to help lead on open source community engagement and supporting the non-technical areas of their MagicBox platform. In the one month I’ve been doing this, I feel like I have tens of articles I could write about, but the experience is still maturing for me.

I also have another round in Chicago to look forward to over the summer. I’ll get to work with the same team as last year on similar projects, and I’m looking forward to going back.

As for the rest, who knows what’s to come? So many things that made 2017 what it was were the things I didn’t expect. The surprises in life are the salt to the regiment of daily life, and add flavor and spice in unexpected ways. I have no idea what my 2018 Year in Review will look like, and that’s okay. I’m looking forward to seeing what will make it in.

Thank you 🔗

Above all, every year, I think back on the people who positively impacted my life and contributed to the “flavor” of my year. A close friend reminded me recently that we all stand on the shoulders of giants. And isn’t it true? We all have our great mentors, great friends, and unexpected sages that help us find our own footing on this great path of life. We become ourselves from the various pieces impacted on us by others.

I’m thankful for all of the people who have made my year into the experience it was. The list is too long to write and I fear I would leave someone out – even significant impacts were made by people who had a short-term role in this last year.

A long time ago, my open source experience was jump-started by someone who did something kind and exceptional for me. It was a continuing trend since that moment. My only aspiration is to pay forward the good will that so many have bestowed unto me.

Thanks for making it this far down, and I hope to see you in 2018. Or who knows – maybe it will just be me reading this far down for next year, when I go to write my next year in review. Hi future me!

Share your 2017 “Year in Review” 🔗

To communicate with the rest of the Fedora community what we worked on in 2017, the Fedora Community Operations team (CommOps) encourages every sub-project of Fedora put together their own “Year in Review” article on the Fedora Community Blog. The CommOps team has created an easy to use template to document your top three highlights of 2017 and one goal for 2018.

Read the original announcement of the 2017 “Year in Review” on the Fedora Community Blog. Contributors are encouraged to work with their sub-projects to come up with the three 2017 highlights and one 2018 goal. These are only set as a minimum. If your sub-project has a lot to say or has many big tasks for 2018, include more highlights or more goals! The only requirement is to meet the minimum, but there is no limit for what you wish to include.

https://communityblog.fedoraproject.org/fedora-2017-year-in-review/

Where to find “Year in Review” posts 🔗

All “Year in Review” articles end up on the Fedora Community Blog. See examples from 2015 for some inspiration. To find new posts, find them in the “Year in Review 2017” tag.

Start discussing this now and craft your own “Year in Review” post for 2017! Sub-projects are encouraged to have a draft in the Community Blog before the end of February.

Recently, I discovered brightlight, a tool that changes backlight brightness. I decided to try it, and it worked with root privileges. However, I found there was no RPM package in Fedora for brightlight. I decided this was the right time to try creating a package in Fedora and learn how to create an RPM.

In this article, I’ll cover and share how I…

• Created the RPM SPEC file
• Built the package in Koji and Copr
• Worked through an issue with debug package
• Submitted the package to Fedora package collection

Pre-requisites 🔗

On Fedora, I installed these packages for all steps of the package building process.

sudo dnf install fedora-packager fedpkg fedrepo_req copr-cli

Creating the RPM SPEC file 🔗

The first step to create a RPM is to create the SPEC file. These are the specifications, or instructions, that tell RPM how to build the package. This is how you tell RPM to create a binary file from the package’s source code. Creating the SPEC file is likely the hardest part of the packaging process and its difficulty depends on the project.

Fortunately for me, brightlight is a simple application written in C. The maintainer made it easy to create a binary application with a Makefile. Building it was a matter of simply running make in the repo. So now I had a simple project to learn RPM packaging.

Finding documentation 🔗

Googling “how to create an RPM package” yields many results. I started with IBM’s documentation. However, I found it confusing and difficult to understand (although quite detailed; it might be more useful for a complicated app). I also found the package creation instructions on the Fedora wiki. The documentation here was good at explaining the composition and process, but I was still confused on how to begin.

Finally, I found the RPM Packaging Guidelines, written by the amazing Adam Miller. These instructions were helpful and included three excellent examples for Bash, C, and Python applications. This guide helped me better understand how to compose a RPM SPEC, and more importantly, how all the pieces fit together.

After this, I was able to write my first SPEC file for brightlight. Since it is so simple, the SPEC file is short and easy to understand. Once I had my SPEC file, I linted the file for errors. After cleaning a few mistakes, I created the source RPM (SRPM) and the binary RPM, then linted each for errors.

rpmlint SPECS/brightlight.spec
rpmbuild -bs SPECS/brightlight.spec
rpmlint SRPMS/brightlight-5-1.fc26.src.rpm
rpmbuild -bb SRPMS/brightlight-5-1.fc26.src.rpm
rpmlint RPMS/x86_64/brightlight-5-1.fc26.x86_64.rpm

Now, I had a valid RPM to send to the Fedora repositories.

Building in Copr and Koji 🔗

Next, I read the guidelines to becoming a Fedora packager. Before submitting anything, they encouraged packagers to test their packages by hosting the project in a Copr repo and building in Koji.

Using Copr 🔗

First, I created a Copr repository for brightlight. Copr is a service in Fedora’s infrastructure that builds your package and sets up a custom repo for whatever version of Fedora or EPEL that you choose. It’s handy to get your RPM hosted quickly and to share it with others for testing. You don’t need special approval to host a Copr.

I created my Copr project from the web interface, but you can also use the copr-cli tool. There is an excellent guide in the Fedora Developer portal. After I created my repo on the website, I built my package with this command.

copr-cli build brightlight SRPMS/brightlight.5-1.fc26.src.rpm

My packages successfully built for Copr and I was able to install it on my Fedora system easily.

Using Koji 🔗

Anyone can use Koji to test their package on multiple architectures and versions of Fedora or CentOS / RHEL. To test on Koji, you must have a source RPM. I wanted to package brightlight on all supported versions of Fedora, so I ran these commands.

koji build --scratch f25 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f26 SRPMS/brightlight-5-1.fc26.src.rpm
koji build --scratch f27 SRPMS/brightlight-5-1.fc26.src.rpm

It took some time, but Koji built all the packages. Everything was fine for Fedora 25 and 26, but Fedora 27 failed. Koji scratch builds keep me on the right track and make sure my packages build successfully.

Problem: Fedora 27 builds failing! 🔗

Now I know that my Fedora 27 package was failing to build on Koji. But why? I discovered two relevant changes for Fedora 27.

• Subpackage and Source Debuginfo
• RPM 4.14 (specifically, the debuginfo package rewrite)

These changes mean that RPM packages must build with a debuginfo package. This is helpful for troubleshooting or debugging an application. In my case, this wasn’t critical or too necessary, but I needed to build one.

Thanks to Igor Gnatenko, he helped me understand what I needed to add to my package SPEC for it to build on Fedora 27. Before the %make_build macro, I added these lines.

export CFLAGS="%{optflags}"
export LDFLAGS="%{__global_ldflags}"

I built a new SRPM and submitted it to Koji to build on Fedora 27. And success! It built successfully.

Submitting the package 🔗

Now that I verified my package successfully built on Fedora 25 to 27, it’s time to begin the packaging process for Fedora. The first step to submitting a package is to create a new bug in the Red Hat Bugzilla to ask for a package review. I created a ticket for brightlight. Since this was my first package, I made an explicit note that this was my first package and I was seeking a sponsor. In the ticket, I linked to the SPEC and SRPM files in my git repository.

Getting into dist-git 🔗

Edit, 2022 Feb. 14th: It was pointed out on Twitter that the fedrepo-req tool is no longer used. See the documentation linked throughout this blog post for more guidance on best practices for today.

Igor Gnatenko sponsored me into the Fedora Packagers group and left feedback on my package. I learned of some other things specific for packaging C applications. After he sponsored me, I was able to ask for a repo in dist-git, Fedora’s collection of RPM package repositories that host SPEC files for all of Fedora.

A handy Python tool helps make this part easy. fedrepo-req is a tool that creates a request for a new dist-git repository. I submitted my request with this command.

fedrepo-req brightlight \
    --ticket 1505026 \
    --description "CLI tool to change screen back light brightness" \
    --upstreamurl https://github.com/multiplexd/brightlight

This created a new ticket for me in the fedora-scm-requests repo. The next day, an admin created the repository for me. Now, I was in business!

Working with dist-git 🔗

Next, fedpkg is the tool used for interacting with dist-git repositories. I changed directories into my git working directory and ran this command.

fedpkg clone brightlight

fedpkg then clones my package’s repo from dist-git. For the first branch only, you need to import the SRPM.

fedpkg import SRPMS/brightlight-5-1.fc26.src.rpm

fedpkg imports your package’s SRPM into the repo and sets up the sources for you. It’s important to use fedpkg for this because it helps provision the repo in a Fedora-friendly way (as compared to adding the files manually yourself). Once you import the SRPM, push the changes to the dist-git repo.

git commit -m "Initial import (#1505026)."
git push

Building the package 🔗

Once you push the first import to your dist-git repo, you’re ready to do a real Koji build of your project. To build your project, run this command.

fedpkg build

This builds your package in Koji for Rawhide, the unversioned branch of Fedora. You must build successfully for Rawhide before you can build for other branches. IF everything builds successfully, you can now ask for other branches for your project.

fedrepo-req brightlight f27 -t 1505026
fedrepo-req brightlight f26 -t 1505026
fedrepo-req brightlight f25 -t 1505026

Note about building other branches 🔗

Once you import the SRPM initially, remember to merge your master branch to other branches, if you choose to create them. For example, if you later request a branch for Fedora 27, you would want to use these commands.

fedpkg switch-branch f27
git merge master
git push
fedpkg build

Submitting update to Bodhi 🔗

The last step of the process is to submit your new package as an update to Bodhi. When you first submit your package as an update, it goes to the testing repositories. Anyone can test your package and add karma to the update. If your update receives +3 votes (or as Bodhi calls it, karma), your package automatically pushes to the stable repositories. Otherwise, it pushes after a week in the testing repositories.

To submit your update to Bodhi, you only need one command.

fedpkg update

This opens a Vim window with different configuration options for your package. Usually, you only need to specify the type (e.g. newpackage) and the ticket ID number for your package review. For a more in-depth explanation, there is an update guide on the Fedora wiki.

After saving and exiting the file, fedpkg submits your package as an update to Bodhi and eventually synchronizes to the Fedora testing repositories. I was able to install my package with this command.

sudo dnf install brightlight -y --enablerepo=updates-testing --refresh

We’re stable! 🔗

My package was recently submitted to Fedora 26 stable repositories and will soon enter Fedora 25 and Fedora 27 stable repositories. Thanks for everyone who helped me with my first package. I look forward to more opportunities to add more packages to the distribution.

After deep consideration, I am resigning from the Fedora Council effective at the end of the Fedora 26 release cycle.

Why I’m stepping back 🔗

When I decided to run for Fedora Council in July, I had not yet moved back to Rochester, New York. From my past experiences, I didn’t predict an issue to fulfill my commitments to the Fedora community. However, since moving back to Rochester, it is difficult to fulfill my expectations, Council and otherwise, to Fedora.

I’m entering the last years of my degree and the rigor of my coursework demands more time and focus. Additionally, I’m working more hours this year than I have in the past, which takes away more time Fedora. Because student loans are too real.

If I expected these changes, I would not have run for the Council. However, from my short time on the Council, I understand the energy and dedication needed to represent the community effectively. During my campaign and term, this was my driving motivation – to do my best to represent an international community of thousands in the highest body of leadership in Fedora. Now, I do not feel I am meeting my standard of participation and engagement. Already, I’ve stepped back from the Fedora Magazine and Marketing teams to focus more time in other areas of Fedora. Now, it is right to do the same for the Council.

I will spend the most time in the CommOps and Diversity teams, since I believe that is where I can make the largest impact as a contributor.

Fedora 27 Council elections 🔗

I privately shared my resignation with the Fedora Council before writing this post. After discussing with other Council members, the plan is

1. Elect a new, full-term Council member for Fedora 27 and 28
2. Elect a new, half-term Council member for only Fedora 27

In past elections with half-term seats, the candidate with the most votes receives the full-term seat and the runner-up receives the half-term seat. I expect this to happen again, although final details will come once the election phase begins.

Thank you for your trust 🔗

This is one of the most difficult decisions I’ve made in Fedora. Serving on the Fedora Council is the greatest privilege. My election to the Council by hundreds of people was humbling and inspired me to not only lead by example, but represent the perspective of the greater Fedora community to the Council. This was the greatest honor for me and it disappoints me to finish my term early.

However, based on current circumstances, I believe this is the best path forward to make sure the community is well-represented in Fedora leadership. Thank you for your trust and I hope I can return to serve the community in this capacity someday in the future.

Past term 🔗

In this past election, the Council encouraged the new FAmSCo to retool themselves. They should support the Ambassadors in a new age of Linux outreach and events. And they have done exactly that. Clarifications and improvements to the mentorship policies are taking place, the Fedora Ambassadors Membership Administration (FAMA) was reformed, and a Fedora Activity Day (FAD) for the LATAM region was successfully planned and executed. As a voting Ambassador, I am proud of all FAmSCo members and happy to see the progress they have made this term.

One concern 🔗

However, one thing stood out to me the past election. All of the representatives on FAmSCo were only from the EMEA and LATAM regions. Part of the fault is that there were no NA candidates and only one candidate from APAC. Therefore, the benefit of this was that EMEA and LATAM communities were more in touch with FAmSCo, since members in their meeting included elected representatives. In NA and APAC, this was not the case.

For Ambassadors in these regions, we did not have an attendee in our meetings to share news with FAmSCo. If we wanted to keep up, we would have to dig deeper. In March, I filed two tickets to suggest opening the mailing list to public participation and establishing an IRC channel presence. Consequently, FAmSCo has improved on being more accessible and transparent for all Ambassadors.

However, there is still a disconnection when your region doesn’t have an elected official to help represent the unique needs and perspectives of your region. In NA, I thought it would help to have a representative. This past June, I traveled to India and met with some Ambassadors in Pune, India. My discussions with them led me to believe that APAC needs representation in FAmSCo too.

Looking ahead to the next FAmSCo 🔗

Three seats are open for this coming election in August, leaving four (fantastic and well-qualified) FAmSCo members from EMEA to serve another term. Therefore, this leaves one region of the world well-represented by the Fedora Ambassador leadership body. Seeing as there are three seats up for elections and three regions that could be represented, I encourage voters in the next FAmSCo election to remember how big the Fedora community is.

The planet is big, and it’s hard to know what’s happening in different countries, regions, and continents. While we are all united as Fedora Ambassadors, there are unique challenges that our Fedora friends from one region may face that others may not. There are cultural, language, and currency differences. Some communities have a better foundation while others need guidance and encouragement to grow. I encourage all participating voters in this next election to remember our friends around the world and to help keep everyone included and involved in the conversations that drive the project forward.

The Fedora Diversity FAD (a.k.a. Fedora Activity Day, or a sprint) took place during the weekend of DevConf, 27-29 January. The original planning for this FAD started in August 2016, after the Flock 2016 conference. At Flock, the Diversity Team held a panel with open discussion about diversity and inclusion efforts in Fedora. Based on the feedback received during and after the panel, it was a priority for us to continue working on the objectives we had established before Flock. For the FAD, a majority of the Fedora Diversity Team was present along with a few others.

• Amita Sharma (amsharma)
• Bhagyashree “Bee” Padalkar (bee2502)
• Brian Exelbierd (bex)
• Jona Azizaj (jonatoni)
• Justin Wheeler (jflory7)
• Maria “tatica” Leandro (tatica)
• Marina Zhurakhinskaya (marinaz)
• Radka Janek (rhea)

We made significant progress in accomplishing our larger objectives and to contribute to the Fedora Project mission and goals. The primary objectives we established for our FAD were completing plans for the demographic survey, building a campaign based on those results, and analyzing our Code of Conduct to find ways to better impact the community. This report covers each of these objectives, what we accomplished, and what we plan to do next.

Demographic survey / marketing campaign 🔗

The majority of our discussions and planning on Friday and Saturday were focused on establishing strategic goals for the demographic survey and crafting the questions. The wish for having a survey like this predates the Diversity Team back to some of the earliest tickets in the Fedora Council ticket tracker (see #1 and #16). The need for a demographic survey was established by the Diversity Team as well shortly after Flock. At Flock, there was expressed concern about little understanding for the diversity of our community. Fedora is a global community spanning all four corners of the world. It’s hard to understand the unique needs and wishes of our community if we don’t know they are there or what they think we could do better. The survey is the means to this end and how we best understand how our community is composed to make Fedora a more welcoming and inviting place for our global community of contributors.

The FAD enabled us to make significant progress on establishing the groundwork for the survey and move towards deploying a live version of the survey. One of the early outcomes of our discussion was postponing ideas about a marketing campaign until we had actual data and results to work with. This would make sure our efforts and focus on that would not be wasted. While the marketing campaign is a primary goal for our team, we decided it was best to double our efforts on the survey. As it turned out, this was a good decision with the amount of time we had, as the survey discussion and planning took the longest part of our time together.

Building the questions 🔗

Before the FAD, Maria, Bee, and Marina had compiled a list of questions starting in a mailing list thread. Many of the questions at the beginning were based on survey questions used in the FLOSS 2013 and Apache Software Foundation Committer Diversity surveys. We started our discussion about the objectives and problems we wanted to solve with this survey. We established these two points as our primary goals.

1. Gather baseline demographics about the contributor community
2. Determine contributor knowledge about project components that ease contribution

With these points in mind, we revisited the draft of questions prepared by Marina. We took an initial pass discussing the questions and weighing if this was something we needed to know and whether we saw a use for the answers based on our goals. The first pass took the longest amount of time, but it narrowed the questions significantly. After getting to a smaller number of questions with varied opinions, the questions were organized them into a spreadsheet where we weighted them by point values and narrowed it down to our final set. Our final draft of questions can be found in the Pagure ticket tracking this task. We are awaiting feedback from Fedora Legal before moving forward. Once we receive additional feedback, we plan to revisit the implementation questions about how and where to deploy the survey.

Noting the working process 🔗

One thing worth mentioning and explaining is how we narrowed the questions. We originally had a wide set of questions and were struggling with how to narrow them down. The methods we ended up using, suggested by Brian, were successful in us focusing on the purpose and goals we originally identified. The concern was on survey engagement and trying to guarantee survey completion. Too many questions or making it too long could result in people not finishing the survey. It is more valuable for us to have the most important data (even if it’s less) rather than have more questions but fewer responses.

In the beginning, we started with the set of questions curated by Maria, Bee, and Marina. It was over 50 questions with different motivations or objectives. Our first approach was going from top to bottom of all the questions. We discussed each one and tried to justify if it was worthwhile to include. Some questions were easy to remove, but others were more challenging. All of this initial discussion gave background to the questions in the later steps. This took up a significant amount of time and was possibly one of the more difficult parts of this process.

After the initial pass, Brian organized all of the questions into a spreadsheet and established a scale from 1 to 7. Of the remaining questions, we ranked them in this order:

• Category 1: Five questions
• Category 2: Five questions
• Category 3: Five questions
• Category 4: Five questions
• Category 5: Five questions
• Category 6: Five questions
• Category 7: Four questions

After all of the team members ranked the questions by order of preference, we tallied up the points for all of the questions. We ended up taking the top twenty-two questions, which can currently be found in the ticket. This method of going through the options we had forced us into making tough calls and choices on the things we felt were most important. It was powerfully effective for us to go through our options in this way, and it’s a method that could definitely be recycled for other purposes or even by other teams in Fedora.

Code of conduct 🔗

A code of conduct is a valuable part of an open source community. Its purpose is to set clear expectations about how the community interacts and behaves with each other. An effective code of conduct empowers contributors to be excellent to each other. This creates a welcoming and inclusive space.

Background 🔗

Before we all gathered in Brno, we planned to analyze the Fedora code of conduct to understand its strengths and weaknesses. We also wanted to focus on its visibility and ensure that it is well-communicated. This includes new contributors when they first join the community and also current contributors. We published a post about the Fedora Code of Conduct to help raise awareness, but planned to cover this more during our FAD.

A comprehensive code of conduct is important to set the tone for interactions among contributors. This helps promote a global perspective and create a welcoming community. The code of conduct drives the belief that contributors should always be excellent to each other. This builds the community as a united, global team. It was valuable for us to deliver on our proposed impact for the Fedora community through our discussions and planning.

Seeking positive engagement 🔗

After we arrived in Brno, we started to have discussions about this and what some our actions would be. The tone of our conversation switched from looking at it from a disciplinary point of view to an enabling point of view. A code of conduct isn’t the only part of how to empower contributors to be excellent. To this end, we asked ourselves these questions.

1. What kind of behaviors does the Fedora code of conduct encourage?
2. How are we able to reward positive interactions that show this behavior?

While we spent time looking at the code of conduct, the main focus was how to promote the behavior the code of conduct encourages. The biggest idea that came from this discussion was Fedora Appreciation Week. It is a subtle yet positive way for people to be excellent to each other by saying “thanks!” and raising awareness for the work that people put into Fedora.

Fedora Appreciation Week 🔗

This discussion mostly occurred on parts of Saturday and the Sunday of DevConf. This idea was originally suggested on the CommOps Pagure. It was not an original part of our pre-planning, but it became a pivotal point in the context of how to encourage the positive behavior the code of conduct suggests. One of the first changes to the original suggestion was making it into an entire week instead of a day, so we have the most flexibility for planning the event and giving ample time for contributors to participate.

Afterwards, we started to look at systems used in other places to use as case studies. We examined the Red Hat appreciation system and the Happiness Packets project. These examples helped to understand the benefit of co-workers or other community members encouraging each other. The Happiness Packets website puts it simply: “The feeling that you made a difference, that your work matters and has value, and that the people you work with are happy to work with you, is an awesome feeling.” Taking the time to understand the background and motivations behind these systems helped us determine the background and motivations for Fedora Appreciation Week. We divided our plans into short-term and long-term criteria.

Long-term 🔗

The long-term discussion mostly focused on how we could make it easier for people to thank each other with Fedora web services. We started our focus with the existing platform of Fedora Badges. One idea was giving all Fedora contributors the ability to award a special type of badge to other contributors a fixed number of times in a release cycle. Each special badge would fit into one of the Four Foundations of Fedora (Freedom, Friends, Features, First). Each one would have guided criteria to consider when awarding the badge to someone else. The effect of doing is to strengthen our commitment to our Four Foundations and to thank contributors who are committed to any of the four areas.

As one example, imagine someone working on a new feature or exciting change for an upcoming Fedora release. They have invested a lot of time and energy into developing this change. Another contributor who noticed this could give them a “Features” badge to thank them for their commitment to driving Fedora forward. Another example might be when one contributor sends thoughtful words to another, thanking them for their time or for everything they do. That person might give the first person a “Friends” badge for being kind and considerate to them.

We also discussed the idea of tying the accumulation of these badges into a physical reward, such as a special t-shirt or sticker sent via the mail. We ran out of time to discuss this idea further.

Short-term 🔗

We started by trying to establish the general timeline for planning Fedora Appreciation Week. Initially, we want start defining guidelines and creating promotional materials to use and spread leading up to the week. This would include things like giving examples of the different ways contributors can give thanks and also to work on articles or posts.

The month before the appreciation week would focus on general awareness. This would include a Community Blog article and a post to the Fedora announce list. The week before the first day would include a Fedora Magazine article explaining what’s happening and also to provide a way for users or people outside of the contributor community to participate.

Methods to give thanks included thanking in IRC (either thoughtful messages or with karma cookies), writing messages on a public wall or forum, and sending personal notes to individual contributors. Methods we could use to measure this impact included but was not limited to were karma cookies, mailing list traffic, or wiki page edits.

For the short-term focus, more discussion is needed to develop the ideas for running Fedora Appreciation Week in 2017.

Tying it together 🔗

The first-ever Diversity FAD was a great opportunity to spend significant amounts of time looking at how we can build more inclusive environments for Fedora contributors and how to tackle other issues like understanding who makes up the Fedora community. Our team was able to use this valuable time to work on these issues more personally and intently than IRC or mailing lists can provide.

Special thanks and our gratitude go to the Fedora Council for supporting our work with the Fedora Project budget and enabling us to be gather and work on these tasks. To all of us, this also showed that Fedora leadership is committed to supporting these initiatives and helping make diversity and inclusion an important part of the Fedora community. Additionally, we’d also like to thank Brian Exelbierd for participating in the FAD even though his attendance wasn’t originally planned—we were lucky to have him with us and to steal his time from other DevConf activities happening during the weekend!

We’re looking forward to next plan talks and/or workshops at Flock 2017 this year.

Come say hello! 🔗

The Fedora Diversity Team mostly consists of a few active, core members. But we are always looking for more people to get involved and participate! Every contribution is significant and it helps to have numerous people from different backgrounds following along with our discussions, so they can speak up and add their voice when they feel it’s important.

There are multiple ways you can get in touch with the Diversity Team. We have a mailing list you can subscribe to and you can follow our discussions. We have an IRC channel on freenode (#fedora-diversity). You . We meet once every other week on Wednesdays at 12:00 UTC in #fedora-meeting on free

• Mailing list: Subscribe to follow our discussions
• IRC channel: Say hello in #fedora-diversity on freenode (you can join with a web client if you don’t have an IRC client)
• Weekly meeting: Meet every other week on Wednesdays (12:00 UTC) in #fedora-meeting on freenode
• Pagure tickets: See some of the current tasks we’re working on and what needs doing

Come say hello and introduce yourself—we’d love to hear what you have to say!

Heterogeneous group icon by Magicon from the Noun Project

During the hiring process, I was happy to ensure that contributing to open source software would still be possible during my time of employment. I saw during my on-site interview that Jump Trading employs open source software throughout the company but also contributes back to open source, either with hours or donations. However, while I am still able to contribute to Fedora, I do not anticipate being able to maintain the level of activity that I contribute at now during my internship.

Stepping out from May to August 🔗

Due to exams and personal travel plans in May followed by an almost immediate departure to Chicago in early June, I will be stepping out of Fedora beginning in early May. I hope to spend time with friends and family before departing for Chicago, so my estimate is a little generous to the benefit of being realistic. My internship will finish around August 20th, 2017, so I hope to begin my normal levels of contribution around this time.

It will be challenging for me to step back for this long amount of time, after my involvement with Fedora has become such a huge part of my life. However, it is only a temporary change, and the time off ends near Flock 2017. So I will have a lot to get caught up on before the conference begins!

The only area I hope to stay partially active with is the Fedora Magazine to continue my post as the editor-in-chief. While I still don’t anticipate being fully involved, I hope to help with editing and to write a few articles during the summer as well.

I’m looking forward to seeing familiar faces again in August!

Open source projects are built online and a lot of their community members are placed all over the world. Even though projects have people from around the world, this doesn’t stop ambitious community members to organize open source conferences or events in their own cities. Whether they’re focused generally to open source or for a specific project, you can find a variety of conferences, hackathons, workshops, or meet-ups all over the world. Fedora benefits from having Ambassadors to attend these events to introduce Fedora and spread the word about the community. It’s not uncommon to see Fedora participating in these events, and Linux Weekend 2017 in Tirana, Albania was not an exception.

From March 25-26, 2017 in Tirana, Albania, nearly 130 people attended the first-ever Linux Weekend 2017. Linux Weekend was organized by Open Labs Hackerspace at the Universiteti Politeknik i Tiranës as an introduction to Linux for beginners. Throughout Tirana, universities have a strong focus on Windows or macOS operating systems and little focus is given to Linux. Open Labs community members wanted to organize an event that would promote Linux as an open source alternative and demonstrate some of its benefits over proprietary environments. The event collected representatives from various communities, including Fedora, Ubuntu, OpenSUSE, NextCloud, MusicBrainz, and more.

Organizing Linux Weekend 🔗

The Open Labs community is not unfamiliar to organizing open source events in Tirana. Their portfolio includes Fedora release parties, OpenStreetMap map-a-thons, Wikipedia edit-a-thons, and Fedora community meet-ups. However, these events have been targeted towards people who already had prior interest or knowledge about open source communities. The organization and planning for Linux Weekend began in the middle of January as an idea to introduce Linux to complete beginners.

Planning and organizing Linux Weekend was a community effort. Jona Azizaj is a board member of Open Labs and a Fedora contributor, and was involved as an organizer for the event. “This was the first edition of Linux Weekend, so the main focus is to raise awareness about Linux and open source. We wanted to educate beginners and spread the word about the choices that are available,” Azizaj explained. The two tracks for the event were full of talks and workshops to introduce attendees not only to Linux, but also various software and applications of what someone can do with Linux.

Many of the attendees were students who had either heard of Linux in their classes or from their peers. Other attendees included industry professionals or other open source community members. Several representatives of Fedora from different parts of the community were in attendance as well. Ambassadors, designers, and translators were available to answer questions and teach newcomers about Fedora.

Albanian students learn Linux 🔗

Since the focus of the event was to teach newcomers about Linux and how it can be used, Linux Weekend was organized to be an introduction to various parts of the Linux ecosystem. Representatives from Fedora, Ubuntu, Arch Linux, OpenSUSE, Linux Mint, and elementaryOS gave introductions to the operating systems and their communities. In addition to distributions, there were also sessions on open source licenses, NextCloud, text editors, MusicBrainz, and more. The benefit of these sessions were demonstrating the different ways Linux can be used to accomplish various tasks.

In addition to the various sessions during the weekend, there were three community booths for Fedora, OpenSUSE, and Mozilla. Attendees had a chance to get swag from each project and also talk with representatives about their own experiences or how to get started using their project.

Sidorela Uku was both an attendee and a speaker at Linux Weekend. Her talk, “Programming in Linux, editors, and tools”, introduced various text editors and other tools to help customize any Linux distribution to someone’s needs or personal preferences. In addition to sharing her own knowledge, she was also excited to discover new things. “I wanted to attend the talks and workshops to learn as much as possible. I also wanted to figure out the next steps to find a project and get involved as a contributor,” Uku explained. “I also wanted to share the things I know with others to help them get started with Linux.” This was Uku’s first time speaking at an event and she looks forward to more open source events in Tirana in the future.

Fedora contributors introduce community 🔗

Various members of the Fedora community were also in attendance. Some of the Fedora presentations over the weekend introduced the project to newcomers, detailed the translation efforts to bring Fedora to Albanian, and also guided attendees on how to make their first steps as contributors. The Fedora presence aimed to help give newcomers a taste of the operating system but also to show the impact someone can have if they decide to contribute.

Mariana Balla was one of the first speakers on Saturday morning with her talk titled, “Introduction to Fedora Project and how to be a part of the community”. She started with localizing Fedora into Albanian in early 2016 and more recently started to become an advocate as well. “Fedora is one of the most used distributions, and it was great to have Fedora here to spread the word and show what our community is all about,” Balla said. “One thing I hoped to show in my talk was that technical skills aren’t required to contribute to Fedora. There’s so many things that aren’t code that people can help with!” One of the highlights of Balla’s presentation was breaking down the different sub-projects in the community and how they contribute to making Fedora what it is. One site that was mentioned was whatcanidoforfedora.org, a site anyone can click their way through to find an area that interests them.

One key contribution area that was important for the local community was localization. Many attendees and speakers alike thought it was important to have software translated into their native language. Anxhela Hyseni is a Fedora Ambassador and led the workshop on “Translation of Fedora”. “It’s important for Albanians to have software in Albanian because we are Albanians!” Hyseni laughs. “People are better able to understand Fedora and it makes it more accessible for us to have it in our local language.” She hopes that attendees left Linux Weekend with plenty of new contacts in the open source community and a better idea of what Linux is all about. She and others also helped Linux newcomers install Fedora 25 as a dual-boot or for virtual machines in the installfest on Saturday morning.

Wrapping up 🔗

After two days of talks, workshops, and hallway discussions, the final talk finished around 4:00pm on Sunday. Azizaj closed out with some final words of encouragement and thanks for attendee participation.

The presence of Fedora, open source software, and its philosophy was present during the entire weekend. Between stickers, install media, and brochures from community tables and the various presentations during the weekend, participants and organizers felt the event was worthwhile. “We had limited time to plan, but it was important to bring Linux to people to introduce the philosophy, show them how to use it, and also how they can give back,” Anxhelo Lushka, an event organizer and Fedora contributor, explained. “We hope attendees had new experiences and learned something new and useful for the real world, for jobs or studying. We also hope we convinced them to contribute and give back, even if in a small way.”

Now that Linux Weekend 2017 is finished, the organizing team is switching their focus to Open Source Conference Albania (OSCAL), the largest open source conference in the region.

Find Fedora near you 🔗

Open source events are happening all around the world, and Fedora might be closer to you than you think! Check for local user or meet-up groups near you to get involved in some of these events. Meetup.com is a great way to find local events happening in your community. You can also keep an eye on what Fedora is up to by following us on Facebook, Twitter, Google+, or Instagram.

We hope to see you at an event in the coming future!

Preface 🔗

When I started writing this in January, I read freenode’s “Happy New Year!” announcement. Even though their recollection of the year began as a negative reflection, the freenode team did not fail to find some of the positives of this year as well. The attitude reflected in their blog post is reflective of the attitude of many others today. 2016 has brought more than its share of sadness, fear, and a bleak unknown, but the colors of radiance, happiness, and hope have not faded either. Even though some of us celebrated the end of 2016 and its tragedies, two thoughts stay in my mind.

One, it is fundamentally important for all of us to stay vigilant and aware of what is happening in the world around us. The changing political atmosphere of the world has brought a shroud of unknowing, and the changing of a number does not and will not signify the end of these doubts and fears. 2017 brings its own series of unexpected events. I don’t consider this a negative, but in order for it not to become a negative, we must constantly remain active and aware.

Secondly, despite the more bleak moments of this year, there has never been a more important time to embrace the positives of the past year. For every hardship faced, there is an equal and opposite reaction. Love is all around us and sometimes where we least expect it. Spend extra time this new year remembering the things that brought you happiness in the past year. Hold them close, but share that light of happiness with others too. You might not know how much it’s needed.

First year of university: complete! 🔗

Many things changed since I decided to pack up my life and go to a school a thousand miles away from my hometown. In May, I officially finished my first year at the Rochester Institute of Technology, finishing the full year on dean’s list. Even though it was only a single year, the changes from my decision to make the move are incomparable. Rochester exposed me to amazing, brilliant people. I’m connected to organizations and groups based on my interests like I never imagined. My courses are challenging, but interesting. If there is anything I am appreciative of in 2016, it is for the opportunities that have presented themselves to me in Rochester.

Adventures into FOSS@MAGIC 🔗

My involvement with the Free and Open Source Software (FOSS) community at RIT has grown exponentially since I began participating in 2015. I took my first course in the FOSS minor, Humanitarian Free and Open Source Software Development in spring 2016. In the following fall 2016 semester, I became the teaching assistant for the course. I helped show our community’s projects at Imagine RIT. I helped carry the RIT FOSS flag in California (more on that later). The FOSS@MAGIC initiative was an influencing factor for my decision to attend RIT and continues to play an impact in my life as a student.

I eagerly look forward to future opportunities for the FOSS projects and initiatives at RIT to grow and expand. Bringing open source into more students’ hands excites me!

I <3 WiC 🔗

With a new schedule, the fall 2016 semester marked the beginning of my active involvement with the Women in Computing (WiC) program at RIT, as part of the Allies committee. Together with other members of the RIT community, we work together to find issues in our community, discuss them and share experiences, and find ways to grow the WiC mission: to promote the success and advancement of women in their academic and professional careers.

Also, hey! If you’re a female high school or university student in the Rochester area (or willing to do some travel), you should seriously check this out!

Google Summer of Code 🔗

Google Summer of Code, abbreviated to GSoC, is an annual program run by Google every year. Google works with open source projects to offer stipends for them to pay students to work on projects over the summer. In a last-minute decision to apply, I was accepted as a contributing student to the Fedora Project. My proposal was to work within the Fedora Infrastructure team to help automate the WordPress platforms with Ansible. My mentor, Patrick Uiterwijk, provided much of the motivation for the proposal and worked with me throughout the summer as I began learning Ansible for the first time. Over the course of the summer, my learned knowledge began to turn into practical experience.

It would be unfair for a reflection to count successes but not failures. GSoC was one of the most challenging and stressful activities I’ve ever participated in. It was a complete learning experience for me. One area I noted that I needed to improve on was communication. My failing point was not regularly communicating what I was working through or stuck on with my mentor and the rest of the Fedora GSoC community. GSoC taught me the value of asking questions often when you’re stuck, especially in an online contribution format.

On the positive side, GSoC helped formally introduce me to Ansible, and to a lesser extent, the value of automation in operations work. My work in GSoC helped enable me to become a sponsored sysadmin of Fedora, where I mostly focus my time contributing to the Badges site. Additionally, my experience in GSoC helped me when interviewing for summer internships (also more on this later).

Google Summer of Code came with many ups and downs. But I made it and passed the program. I’m happy and fortunate to have received this opportunity from the Fedora Project and Google. I learned several valuable lessons that have and will impact going forward into my career. I look forward to participating either as a mentor or organizer for GSoC 2017 with the Fedora Project this year.

Flock 2016 🔗

Towards the end of summer, in the beginning of August, I was accepted as a speaker to the annual Fedora Project contributor conference, Flock. As a speaker, my travel and accommodation were sponsored to the event venue in Kraków, Poland.

Months after Flock, I am still incredibly grateful for receiving the opportunity to attend the conference. I am appreciative and thankful to Red Hat for helping cover my costs to attend, which is something I would never be able to do on my own. Outside of the real work and productivity that happened during the conference, I am happy to have mapped names to faces. I met incredible people from all corners of the world and have made new lifelong friends (who I was fortunate to see again in 2017)! Flock introduced me in-person to the diverse and brilliant community behind the Fedora Project. It is an experience that will stay with me forever.

To read a more in-depth analysis of my time in Poland, you can read my full write-up of Flock 2016.

Maryland (Bitcamp), Massachusetts (HackMIT), California (MINECON) 🔗

2016 provided me the opportunity to explore various parts of my country. Throughout the year, I attended various conferences to represent the Fedora Project, the SpigotMC project, and the RIT open source community.

There are three distinct events that stand out in my memory. For the first time, I visited the University of Maryland for Bitcamp as a Fedora Ambassador. It also provided me an opportunity to see my nation’s capitol for the first time. I also visited Boston for the first time this year as well for HackMIT, MIT’s annual hackathon event. I also participated as a Fedora Ambassador and met brilliant students from around the country (and even the world, with one student I met flying in from India for the weekend).

Lastly, I also took my first journey to the US west coast for MINECON 2016, the annual Minecraft convention. I attended as a staff member of the SpigotMC project and a representative of the open source community at RIT.

All three of these events have their own event reports to go with them. More info and plenty of pictures are in the full reports.

• Going to Bitcamp 2016
• HackMIT meets Fedora
• SpigotMC goes to California for MINECON

Vermont 2016 with Matt 🔗

Some trips happen without prior arrangements and planning. Sometimes, the best memories are made by not saying no. I remember the phone call with one of my closest friends, Matt Coutu, at some point in October. On a sudden whim, we planned my first visit to Vermont to visit him. Some of the things he told me to expect made me excited to explore Vermont! And then in the pre-dawn hours of November 4th, I made the trek out to Vermont to see him.

Instantly when crossing over the state border, I knew this was one of the most beautiful states I ever visited. During the weekend, the two of us did things that I think only the two of us would enjoy. We climbed a snowy mountain to reach an abandoned fire watchtower, where we endured a mini blizzard. We walked through a city without a specific destination in mind, but to go wherever the moment took us.

We visited a quiet dirt road that led to a meditation house and cavern maintained by monks, where we meditated and drank in the experience. I wouldn’t classify the trip has a high-energy or engaging trip, but for me, it was one of the most enjoyable trips I’ve embarked on yet. There are many things that I still hold on to from that weekend for remembering or reflecting back on.

A big shout-out to Matt for always supporting me with everything I do and always being there when we need each other.

Finally seeing NYC with Nolski 🔗

In no short time after the Vermont trip, I purchased tickets for my favorite band, El Ten Eleven, in New York City on November 12th. What turned into a one-day trip to see the band turned into an all-weekend trip to see the band, see New York City, and spend some time catching up with two of my favorite people, Mike Nolan (nolski) and Remy DeCausemaker (decause). During the weekend, I saw the World Trade Center memorial site for the first time, tried some amazing bagels, explored virtual reality in Samsung’s HQ, and got an exclusive inside look at the Giphy office.

This was my third time in New York City, but my first time to explore the city. Another shout-out goes to Mike for letting me crash on his couch and stealing his Sunday to walk through his metaphorical backyard. Hopefully it isn’t my last time to visit the city either!

Finalizing study abroad 🔗

At the end of 2016, I finalized a plan that was more than a year in the making. I applied and was accepted to study abroad at the Rochester Institute of Technology campus in Dubrovnik, Croatia. RIT has a few satellite campuses across the world: two in Croatia (Zagreb and Dubrovnik) and one in Dubai, UAE. In addition to being accepted, the university provided me a grant to further my education abroad. I am fortunate to have received this opportunity and can’t wait to spend the next few months of my life in Croatia. I am currently studying in Dubrovnik since January until the end of May.

During my time here, I will be taking 12 credit hours of courses. I am taking ISTE-230 (Introduction to Database and Data Modeling), ENGL-361 (Technical Writing), ENVS-150 (Ecology of the Dalmatian Coast), and lastly, FOOD-161 (Wines of the World). The last one was a fun one that I took for myself to try broadening my experiences while abroad.

Additionally, one of my personal goals for 2017 is to practice my photography skills. During my time abroad, I have created a gallery on 500px where I upload my top photos from every week. I welcome feedback and opinions about my pictures, and if you have criticism for how I can improve, I’d love to hear about it!

Accepting my first co-op 🔗

The last big break that I had in 2016 was accepting my first co-op position. Starting in June, I will be a Production Engineering Intern at Jump Trading, LLC. I started interviewing with Jump Trading in October and even had an on-site interview that brought me to their headquarters in Chicago at the beginning of December. After meeting the people and understanding the culture of the company, I am happy to accept a place at the team. I look forward to learning from some of the best in the industry and hope to contribute to some of the fascinating projects going on there.

From June until late August, I will be starting full-time at their Chicago office. If you are in the area or ever want to say hello, let me know and I’d be happy to grab coffee, once I figure out where all the best coffee shops in Chicago are!

In summary 🔗

2015 felt like a difficult year to follow, but 2016 exceeded my expectations. I acknowledge and I’m grateful for the opportunities this year presented to me. Most importantly, I am thankful for the people who have touched my life in a unique way. I met many new people and strengthened my friendships and bonds with many old faces too. All of the great things from the past year would not be possible without the influence, mentorship, guidance, friendship, and comradery these people have given me. My mission is to always pay it forward to others in any way that I can, so that others are able to experience the same opportunities (or better).

2017 is starting off hot and moving quickly, so I hope I can keep up! I can’t wait to see what this year brings and hope that I have the chance to meet more amazing people, and also meet many of my old friends again, wherever that may be.

Keep the FOSS flag high.

When people first think of “open source”, their mind probably first goes to code. Something technical that requires an intermediate understanding of computers or programming languages. But open source is a broad concept that goes beyond only binary bits and bytes. Open source projects hold great regard for community participation. The community is a fundamental piece of a successful open source project. For my experience getting involved with open source, I began in the community and worked my way around from there. At the age of fifteen, I was beginning my open source journey and I didn’t even know it.

Gaming introduces open source 🔗

One of my strongest memories of a “gaming addiction” was when I was fifteen and a younger cousin introduced me to the game Minecraft. The game was in beta then, but I remember the sandbox-style of the game entertaining the two of us for hours. But what I discovered was that playing the game alone became boring. Playing and mining with others made the experience more fun and meaningful. In order to do this, I learned I would have to host a server for my friends to connect to play with me.

I originally used the “vanilla” Minecraft server software at first, but it was limited to what it could do, and didn’t compare to other multiplayer servers in existence. They all seemed to be using something that offered more, so players could play games, cast spells, or do other unique things that would normally not be possible in the game. After digging, I discovered Bukkit, an open source Minecraft server software with an extensible API to let developers change the multiplayer experience. I soon became wrapped up with Bukkit like a child with a new toy. Except this toy had me digging through my computer to set up “port forwarding”, “setting NAT records”, and “creating static IP addresses”. I was teaching myself the basics of computer networking in the guise of creating a game server for my friends.

Over time, my Minecraft server hobby began to take up more and more time. More people began playing on my server and I began searching for ways to improve the performance of my server. After doing some digging, I discovered the SpigotMC project, shortened to just Spigot. Spigot was a fork of the Bukkit project that made specific enhancements to performance. After trialing it on my server, I discovered the performance gains were measurable and I would commit to using Spigot from then on.

Participating in SpigotMC 🔗

Before long, I began running into new challenges with managing my Minecraft server community, whether it was finding ways to scale or finding the best ways to build a community up. In October 2013, I registered an account on the Spigot forums to talk with other server owners and seek advice on ways I could improve. I found the community welcoming and accepting to helping me learn and improve. Several people in the community were owners of larger servers or developers of unique plugins to Spigot. In response to my detailed inquisitions, they responded with genuine and helpful feedback and support. Within a week, I was already in love with the people and helpfulness of the Spigot community.

I became an active participant in the forum community in Spigot. Through the project, I was introduced to IRC and how to use it for communicating with other server owners and developers. What I didn’t realize was a trend in my behavior. Over time, I began shifting away from asking all the questions. Almost as if in a role reversal, I became the one answering questions and helping support other new server owners or developers. I became the one in an advisory role instead of the one always asking.

In April 2014, the project lead of Spigot reached out to me asking if I would consider a role as a community staff member. Part of my responsibilities would be responding to reports, encouraging a helpful and friendly community, and maintaining the atmosphere of the community. With as much prestige and honor as my sixteen-year-old self could muster, I accepted and began serving as a community moderator. I remember feeling privileged to serve the position – I would finally get to help the community that had done so much to help me.

Expanding the open source horizon 🔗

Through 2014 and 2015, I actively served as a moderator of the community, both in the forums and the IRC network for Spigot. I remained in the Spigot community as the project steadily grew. It was incredible to see how the project was attracting more and more users.

However, my open source journey did not end there. After receiving my high school diploma in May 2015, I had set my sights on the Rochester Institute of Technology, a school I noted as having the country’s only Free and Open Source Software minor. By coincidence, I also noticed that my preferred Linux distribution, Fedora, was holding its annual contributor conference in Rochester, a week before I would move in for classes. I decided I would make the move up early to see what it was all about.

Flock 2015 introduces Fedora 🔗

The summer passed, and before I knew I was ready, I was packing up from my home outside of Atlanta, Georgia to leave for Rochester, New York. After fourteen hours of driving, I finally arrived and began moving into my new home. A day after I arrived, Flock was slated to begin, marking my first journey in Rochester.

At Flock, I entered as an outsider. I was in an unfamiliar city with unfamiliar people and an open source project I was only mildly familiar with. It was all new to me. But during that week, I discovered a community of people who were united around four common ideals. Freedom, Friends, Features, First: the Four Foundations of the Fedora Project were made clear to me. The community members at Flock worked passionately towards advancing their project during the talks and workshops. And after the talks finished, they gathered together for hallway discussions, sharing drinks, and enjoying the presence of their (usually) internationally dispersed team. Without having ever attended a Fedora event before, I knew that the Four Foundations and the community behind Fedora were the real deal. Leaving Flock that year, I vowed to pursue becoming a part of this incredible community.

Pen to paper, keyboard to post 🔗

The first major step I took towards contributing to the Fedora Project was in September 2015, during Software Freedom Day. Then Fedora Community Action and Impact Coordinator Remy DeCausemaker was in attendance representing Fedora. During the event, I reached out to the Fedora Magazine editorial team asking to become involved as a writer. By the end of September, I penned my first article for the Fedora Magazine, tying in my experience in the Spigot community to Fedora: run a Minecraft server using Spigot.

My first step getting involved with the Fedora community was an exciting one. I remember feeling proud and excited to see my first article published on the front page, not only helping Fedora, but also helping Spigot. I realized then that it was relatively straightforward to contribute this kind of content, and I would keep writing about software I was familiar with for the Magazine.

As I continued writing posts for the Fedora Magazine, I became aware of another team forming up in Fedora: the Community Operations, or CommOps, team. I subscribed to their mailing list, joined the IRC channel, and attended the first meetings. Over time, I became wrapped up and involved with the community efforts within Fedora. I slowly found one thing leading to another.

Today in Fedora, I am the leading member of the Community Operations (CommOps) team, the editor-in-chief of the Fedora Magazine, a Marketing team member, an Ambassador of North America, a leading member of the Diversity Team, and a few other things.

Advice for other students 🔗

When you’re first getting started, it can sometimes be tough and a little confusing. As students getting involved with FOSS, there are a few challenges that we might have to face. A lot of this can be with making the first steps into a new project. There are countless open source projects of various sizes and they all do things a bit differently from others, so the process changes from project to project.

One of the most obvious challenges with getting involved is your personal experience level. Especially when getting started, it can be easy to look at a large project or well-known project and see all the work devoted there. There are smart and active people working on these projects, and many times their contributions are quite impressive! One of the many concerns I’ve seen other students here face (including myself at first) is wondering how someone with beginning to moderate experience or knowledge can get involved, in comparison to some of these contributions from active contributors. If it’s a large project, like Fedora, it can be intimidating to think where to start when there’s so many things to do and areas to get involved with. But if you think of it all as one big project, it is intimidating and difficult for you to make that first step.

Break a bigger project into smaller pieces. Start small and look for something you can help with. A healthy open source project usually will have things like easyfix bugs that are good ones to start with if it’s your first time contributing. Keep an eye out for those if you’re getting started.

Another challenge you might face as a student or beginner to open source is something called imposter syndrome. For me, this was something I had identified with before I knew what it was. For a definition, I’ll pull straight from Wikipedia first: " Term referring to high-achieving individuals marked by an inability to internalize their accomplishments and a persistent fear of being exposed as a “fraud”.

Imposter syndrome can be a common feeling as you get involved with open source, especially if comparing yourself to some of those active and smart contributors that you meet as you become involved. But you should also remember you are a student – comparing yourself or your contributions to a professional or someone with years of experience isn’t fair to yourself! It’s not apple-to-apples. Your contributions as you get involved with open source are worthy and valuable to an open source project regardless of how deep, how many, or how much time you spend on the project. Even if it’s a couple of hours in the week, that’s saving others those couple of hours and it’s adding something into the project. A contribution is a contribution – it’s a bad idea to rate the worth of contributions to other contributions.

Those are some of the challenges that are useful to know and understand as you become more involved with FOSS. If you know the challenges you are up against, it makes it easier to handle them as they come.

There are also benefits to contributing to open source as a student as well. Contributing to open source is a great way for you to take knowledge and info you have learned from classes and begin applying it to real-world projects and gain experience. It’s one thing to take you to the next level as a student. If you are contributing to a project in the real world, that is unique experience that is helpful for you for future career outlooks as well.

It’s also a great networking opportunity. In open source, you meet many incredible and smart people. In my time in Fedora, I’ve met many contributors and had various mentors help me get involved. I’ve made new friends and met people who I normally would never have had the opportunity to meet.

There are also opportunities for leadership in open source projects. Whether it’s just one task, one bug, or even a role, you might find that sometimes all it takes is someone willing to say, “I’ll do this!” to have leadership on something. It might be challenging or difficult at first, but it’s a great way for you to understand working in team environments, how to work effectively even if you’re remote, and how to break down a task and work on finding solutions for complex problems.

Lastly, it’s important for younger people to become more involved with open source communities. As students and younger community members, we add unique perspective and ideas to open source projects. It’s important to a healthy community for an open source project and any open source project worth contributing to should be welcoming and accepting to students who are willing to spend time working on the project and helping solve those problems, whether they’re bugs, tasks, or other things. In short, there is absolutely a role for students getting involved with open source!

About Open Labs 🔗

Open Labs Albania is a non-profit organization and community based out of Tirana, Albania. Open Labs focuses on freedom, transparency, and decentralization to empower the community. They support and contribute to a variety of open source projects to tackle local problems. Sometimes, this even includes regional and international issues. Each year, the Open Labs team organizes their annual conference, OSCAL (Open Source Conference Albania). Hundreds of people from across Europe gather to “promote software freedom, open source software, free culture and open knowledge”. In 2016, over 50% of attendees and 70% of organizers were women, numbers unheard of anywhere else in the world.

The story of Open Labs in Albania is a growing but powerful story of people from a developing country working together to build real solutions to real problems. The story of their movement is motivating, insightful, and worth sharing.

About FOSS Wave 🔗

FOSS Wave is a group of open source developers and students dedicated to connecting other students into open source communities. They help develop students’ professional skills for the industry. The mentors have a “Boot Up” program where interested students reach out for a mentor. Mentors offer direct support to students on getting started. Program organizers also attend various universities to deliver workshops and talks about open source technology. Many mentors are female and speak about diversity in open source communities and give advice for women who want to get involved.

https://communityblog.fedoraproject.org/foss-wave-women-in-technology-part-2/

https://communityblog.fedoraproject.org/foss-wave-fedora-bangalore-india/

https://communityblog.fedoraproject.org/foss-wave-bangalore-uvce/

Virtual meetup 🔗

Over the next month, we hope to combat time zones (six hours in Europe and nine and a half with India) to find mutual times that work well for both communities. These are two separate virtual meetup opportunities, one with WiC and Open Labs, and another with WiC and FOSS Wave. We are trying to collect responses from members of both communities of when they would be available to take part in the meetup.

Are you a member of WiC, Open Labs, or FOSS Wave? Please make sure you fill in your available times in either poll so we can select a date soon!

• WiC + Open Labs meetup time poll
• WiC + FOSS Wave meetup time poll

I’m looking forward to these awesome communities meeting, sharing experiences, and learning about what other groups of students, women, and other great role models in tech are working on across the world. Hope to see you there too!

https://communityblog.fedoraproject.org/hackmit-meets-fedora/

HackMIT is the annual hackathon event organized by students at the Massachusetts Institute of Technology in Cambridge, Massachusetts. HackMIT 2016 took place on September 17th and 18th, 2016. This year, the Fedora Project partnered with Red Hat as sponsors for the hackathon. Fedora Ambassadors Charles Profitt and Justin Wheeler attended to represent the project and help mentor top students from around the country in a weekend of learning and competitive hacking. Fedora engaged with a new audience of students from various universities across America and even the globe.

Arriving at HackMIT 🔗

The Fedora team arrived in Massachusetts a day early on Friday to ensure prompt arrival at the event the following morning. Fedora was one of the first sponsors to arrive on MIT’s campus Saturday morning, and scouted one of the best positions on the floor. Fedora was given a choice of anywhere in the bleachers surrounding the floor. As a result, the team set up Fedora’s banners close to many of the tables where hackers would spend the weekend.

On the morning of the first day, over a thousand students arrived on the MIT campus. Around 10:00am, the kickoff ceremony began in the main auditorium. The event staff introduced themselves and the structure of the event. After covering the basics, every sponsor was given a 30 second “elevator pitch” to explain their company or project, and share anything important with the hackers. Justin represented Fedora and Red Hat on stage to introduce Fedora and what Fedora wanted to help students with. He introduced Fedora as a distribution targeted towards developers, briefly introduced the three editions of Fedora, and offered help for anyone wanting to open source their hack or seek support with open source tooling.

May the hacking begin! 🔗

After the sponsor introductions, hackers relocated to the main floor to start seeking teams and begin working on projects. While HackMIT was getting into full swing, many people visited the Fedora area before jumping into a project. Many of the students who talked with Charles and Justin were either surprised to see Fedora at an event like HackMIT or were curious to know what was going on in Fedora. For the most part, many students were familiar with Linux through classes or lectures. The ones familiar with Linux knew about it from hands-on experience or from guided instruction in classes. A smaller number of people were running Linux environments or using them in servers or other ways.

Overall, the demographic of people attending the hackathon were generally familiar with Linux, but not at an advanced level. This group was ideal for promoting Fedora as a developer environment. The ease of setting up a development workspace or installing dependencies for projects intrigued many students. HackMIT was an ideal opportunity to present Fedora to a new group of budding technological enthusiasts. HackMIT participants had an organic interest in Fedora and wanted to know how Fedora made development easier or what made it different from other distributions.

Personal engagement 🔗

During the event, Charles walked around the various tables to talk with students while Justin manned the Fedora area. Charles introduced himself to the hackers and asked to know what they were working on or what their plans were. For many teams, he provided advice on how to get over hurdles with first planning and project direction. He checked back in with these groups across the weekend to see how they progressed.

At the Fedora space, Justin fielded questions from students about Linux, what Fedora offers, and about open source software. Some people were familiar with Fedora, and a small handful of students were running Fedora as a primary operating system. However, most students were only familiar with Linux and were curious to know more. As a student, Justin offered specific advice about contributing to open source software and how helpful it is to gain real-world experience. Some students expressed interest in contributing but were unsure about where to start. Justin coached students through key steps to start with on beginning their open source adventure. He identified the process of choosing a project to contribute to, matching something genuinely interesting with technical skills, and getting involved with the community.

Additionally, there were two students organizing other hackathons in the country with a specific focus towards open source software development. The Ambassadors engaged with these students and joined in a dialogue about making open source a critical part of hackathons. More information about these events will become available in the coming future.

Evaluating impact 🔗

To help gauge our impact with the event, there was a limited edition HackMIT 2016 Attendee badge that attendees could claim during the event. The team leveraged Fedora Badges as a tool to help tell the story of our impact at the event. Through Badges, you can see a list of FAS accounts that claimed the badge from the event and their account activity in the long run. Bee Padalkar’s FOSDEM event evaluation demonstrates how this data can be used. Ten people claimed the badge during the weekend. One of the benefits of using badges as a tool for measuring impact and engagement is the follow-up it allows us to make with what badge claimers do in the Fedora community.

However, there were more ways to measure engagement with the students and hackers than only with badges. Many of the most valuable insight into our impact was follow-up on the second morning. Charles went around to most of the tables he visited on the first day leading up to the final deadline. With one team, he helped do some live testing in the last 30 minutes before the deadline since her team was asleep from the previous night. Engagements like these left a positive impression of Fedora, and by extension, the community.

What was our engagement? 🔗

The type of interactions and conversations Fedora held with students and other attendees was productive and motivating, not only to the students but also to the Ambassador team. People were genuinely interested in Fedora and it was easier to shape their interest into an insightful discussion about what Fedora enables students to create and develop. A powerful message about open source software development was also delivered during the event. This stands in contrast to some other hackathons in the United States which are sometimes set up more like unofficial career fairs. HackMIT clearly held a strong focus on community. Events with that kind of management and direction are where Fedora succeeds and has a more valuable impact.

Leaving the event, the Fedora team was confident that we had a powerful impact on students during the event. For many, Fedora was not only introduced as an operating system, but as a tool for accomplishing and doing. Fedora provides the tools and utilities students need to build their projects and drive them forward. Open source as a development practice was also introduced to many for the first time, or deeper explained for those with a mild interest. These messages and the team’s other engagements were warmly received.

Looking ahead 🔗

The Fedora Ambassadors of North America would like to make a special thanks to Red Hat and Tom Callaway for partnering to sponsor this event. Without Red Hat’s help, attending this event would not have been possible. Our engagement and impact after HackMIT excites the Ambassador team. We hope many students from the event turn to Fedora not only as an operating system, but as a tool for their expanding technological toolbox. A congratulations also goes to the organizers of HackMIT for putting together a thoroughly planned and carefully executed event that placed a strong focus on community, which fits within one of Fedora’s four key foundations, Friends.

We hope to return to Cambridge again next year!

You can read Charles Profitt’s event report on his blog.

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.

https://jwfblog.wpenginepowered.com/2016/08/fedora-flock-2016/

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.

Today, I am pleased to announce my new role as the Fedora Magazine editor-in-chief. After deciding to shift focus to other areas of the Fedora Project, I am receiving the torch from Ryan Lerch. Ryan has helped lead the Magazine, edit pieces from other contributors, contribute his own pieces, and decide strategic direction for the Magazine.

He leaves big shoes to fill, but I hope to offer my own leadership, creativity, and direction in coming years as well. I’d like to thank both Ryan, Paul Frields, and Remy DeCausemaker for their mentorship and guidance towards becoming involved with Fedora and the Magazine. I’m excited to have the opportunity to help guide the Fedora Magazine in how it fits with the rest of Fedora.

History of the Magazine 🔗

The Fedora Magazine began in late 2013, replacing the former publication, Fedora Weekly News. The Magazine delivers all official news and announcements for the Fedora Project, covers how-to guides on using software available in Fedora, and other general tips and tricks for using Fedora. The Magazine has had a large number of contributors assist in getting it off the ground and to where it is now.

A special thanks goes out to Ryan, Paul, and Chris Roberts for helping bring the Magazine to where it is today. There are surely many more names than these too worth mentioning, but it would be impossible for me to cover them all here.

Write for the Magazine! 🔗

Want to write your own article for the Magazine? Know a useful piece of software you want to share with other Fedora users? Want to write about how using Fedora made something easier for you? Or maybe your own “top 5” list of tools for doing an everyday task? Come write for us! If you’re interested, check out this guide about writing an article, and then how to write a pitch for the Magazine team to review.

Book by Sergey Demushkin from the Noun Project.

Deliverable items 🔗

The last deliverable items from my project are two (2) git patches, one (1) git repository, and seven (7) blog posts (including this one).

• Git patches (ansible.git and infra-docs.git)
• Git repository
• Blog posts

Closing plans 🔗

At the end of the summer, I was using a private cloud instance in Fedora’s infrastructure for testing my playbooks and other resources. One of the challenges towards the end of my project was moving my changes from my local development instance into a more permanent part of Fedora’s infrastructure. For these reasons, I had some issues with running them in a context and workflow specific to Fedora’s infrastructure and set-up (since I am not a sponsored member of the Fedora system administration group).

My current two patches were submitted to my mentor, Patrick. Together, we worked through some small problems with running my playbook in the context of Fedora’s infrastructure. There may still be some small remaining hoops to jump through for running it in production, but any remaining changes to be made should be minor. The majority of the work and preparation for moving to production is complete. This is also something I plan to follow up on past the end of the GSoC 2016 program as a member of the Fedora Infrastructure Apprentice program.

My patches should be merged into the ansible.git and infra-docs.git repositories soon.

Reflection on GSoC 2016 🔗

As the program comes to a close, there’s a lot of valuable lessons I’ve learned and opportunities I’m thankful to have received. I want to share some of my own personal observations and thoughts in the hopes that future students or mentors might find it useful for later years.

Planning your timeline 🔗

In my case, I spent a large amount of time planning my timeline for the project before the summer. Once the summer began, my original timeline was too broad for having smaller milestones to work towards. My timeline on the student application was more broad and general, and while it covered the big points, it was difficult to work towards those at first. Creating smaller milestones and goals for the bigger tasks makes them easier to work through on a day-by-day basis and helps add a sense of accomplishment to the work you are doing. It also helps shape direction for your work in the short-term and not just the long-term.

For an incoming Google Summer of Code student for Fedora (or any project), I would recommend creating the general, “big picture” timeline for your project before the summer. Then, if you are accepted and beginning your proposal, spend a full day creating small milestones for the bigger items. Try to map out accomplishments every week and break down how you want to reach those milestones throughout the week. I started using TaskWarrior with an Inthe.AM Taskserver to help me manage weekly tasks going into my project. But it’s important to find a tool that works for you. You should reach out to your mentor about ideas for tools. If possible, your mentor should also have a way to view your agenda and weekly tasks. This will help make sure your goals are aligned to the right kind of work you are doing for an on-time completion.

I think this kind of short-term planning or task management is essential for hitting the big milestones and being timely with your progress.

Regular communication 🔗

Consistent and frequent communication is also essential for your success in Google Summer of Code. This can be different depending on the context of how you are contributing to the project. For a normal student, this might just be communicating about your proposal with your mentor regularly. If you’re already an active contributor and working in other areas of the project, this might be spending extra time on communicating your progress on the GSoC project (but more on that specifically in the next section).

Regardless of the type of contributor you are, one thing is common and universal – be noisy! Ultimately, project mentors and GSoC program administrators want to be sure that you are spending the time on your project and making progress towards accomplishing your goals. If you are not communicating, you will run the highest risk of failing. How to communicate can vary from project to project, but for Fedora, here’s my personal recommendations.

Blog posts 🔗

Even for someone like me who spends a lot of time writing already, this can be a difficult thing to do. But no matter how hard it is to do it, this is the cornerstone for communicating your progress and leaving a trail for future students to learn from you as well. Even if you’ve had a difficult week or haven’t had much progress, take the time to sit down and write a post. If you’re stuck, share your challenges and share what you’re stuck on. Focus on any success or breakthroughs you’ve made, but also reflect on issues or frustrations you have had.

Taking the time to reflect on triumphs and failures is important not only for Google Summer of Code, but even looking past that into the real world. Not everything will go your way and there will be times where you will be face challenges that you don’t know how to resolve. Don’t burn yourself out trying to solve those kinds of problems alone! Communicate about them, ask for help from your mentors and peers, and make it an open process.

IRC check-ins 🔗

Whether in a public channel, a meeting, or a private one-on-one chat with your mentor, make sure you are both active and present in IRC. Make sure you are talking and communicating with your mentor on a regular basis (at a minimum, weekly). Taking the time to talk with your mentor about your challenges or progress is helpful for them so they know what you’re up to or where you are in the project. It also provides a chance for them to offer advice and oversight into your direction and potentially steer you away from making a mistake or going into the wrong direction. It is demotivating when you’ve spent a lot of time on something and then later discovered it either wasn’t necessary or had a simpler solution than you realized.

Make sure you are communicating often with your mentor over IRC to make your progress transparent and to also offer the chance for you to avoid any pitfalls or traps that can be avoided.

Hang out in the development channels 🔗

As a Fedora Google Summer of Code student, there are a few channels that you should be present in on a regular basis (a daily presence is best).

• #fedora-admin
• #fedora-apps
• #fedora-summer-coding
• Any specific channel for your project, e.g. #fedora-hubs

A lot of development action happens in this channels, or people who can help you with problems are available here. This also provides you the opportunity to gain insight into what the communication in an active open source project looks like. You should at least be present and reading the activity in these channels during the summer. Participation is definitely encouraged as well.

Balancing project with open source contributions 🔗

I think my single, most difficult challenge with Google Summer of Code was balancing my proposal-specific contributions with the rest of contributions and work in the Fedora Project. I believe I was a minority of Google Summer of Code students who applied for the program as an active member of the project almost a full year before the program began. Additionally, my areas of contribution in Fedora before GSoC were mostly unrelated to my project proposal. My project proposal mostly aligned with my intended degree and education I am pursuing. A lot of the technology I would be working with was new to me and I had minimal knowledge about it before beginning the summer. As a result, this presented a unique set of challenges and problems I would face throughout my project.

The consequences of this were that I had to spend a lot more time researching and becoming familiar with the technology before advancing with creating the deliverable items. A great resource for me to learn about Ansible was Ansible for DevOps by Jeff Geerling. But I spent more time on learning and “trying out the tech” than I had anticipated.

This extra time spent on research and experimentation were in tandem to my ongoing contributions in other areas of the project like Community Operations, Marketing, Ambassadors, the Diversity Team, and as of recently, the Games SIG. Balancing my time between these different areas, including GSoC, was the biggest challenge to me over the summer (along with a separate, part-time job on weekends). A separation of time to different areas of Fedora became essential for making progress on my project. What worked well for me was setting short-term goals (by the hour or day) that I wanted to hit and carry out. Until those goals were reached, I wouldn’t focus on anything other than those tasks.

Special thanks 🔗

I’m both thankful and grateful to those who have offered their mentorship, time, and guidance for me to be a member of the GSoC Class of 2016. Special thanks go to Patrick Uiterwijk, my mentor for the program. I’ve learned a lot from Patrick through these past few months and enjoyed our conversations. Even though we were both running around the entire week, I’m glad I had the chance to meet him at Flock 2016 (and hope to see him soon at FOSDEM or DevConf)! Another thanks goes to one of my former supporting mentors and program administrator Remy DeCausemaker.

I’m looking forward to another year and beyond of Fedora contributions, and can’t wait to see what’s next!

Although my report comes a little late, it comes with a lot of thought and reflection over the week at Flock. I participated as a speaker for my talk with Jona Azizaj titled, “University Outreach: New task or new mindset?” I also worked with Bee Padalkar on running the Community Operations (CommOps) team workshop for planning our own future tasks in coming months and knowing what issues or topics the community had in mind. And lastly, due to last-minute scheduling issues, I helped plan and organize the Diversity Panel with Amita Sharma and many other incredible contributors.

Without further ado, this is my analysis and report on the events at Flock 2016. And for anyone wondering what “żegnajcie” in the title means, Google Translate tells me that means “farewell!” in Polish.

General experiences around Flock 🔗

As a second-time visitor to Flock, I was a little familiar with the conference structure. Joe Brockmeier made a call for volunteers to help transcribe talks over IRC. I signed myself up to help transcribe all the talks and workshops I was attending to help cover them in the “CommOps-style” way that I run meetings. This proved effective and I hope that my transcriptions were useful both to those who wanted to keep up with Flock from home and attendees who wanted to remember specific parts of talks after the conference ended. You can find an index of all talks and their transcriptions on the wiki.

The event organizers did an effective and incredible job of planning the fine details for the conference. When I arrived on August 1 at the airport, Rafał Lużyński greeted me and provided a ride from the airport to the hotel. Along with us at the airport was Bee Padalkar, Amita Sharma, Stephen Gallagher (thanks for sharing a plane ride with me!), and Ryan Lerch. Throughout the entire conference, I was always amazed at the hospitality and constant willingness to help by all the local organizers. For traveling in a country where the language was completely foreign, I never felt too confused or had a difficult time. I remember when Rafał helped translate the menu options for me at the restaurants we ate at on the first day, which was a major help for finding vegetarian choices. My impression on Kraków and then Poland is high and I hope to return again someday in the future.

Overall, the “i’s were dotted and the t’s were crossed”, as the saying goes. I am impressed by and thankful for the hard work that went into organizing this conference. The work of the organizers is one of the most important roles of the entire conference as it enables us to come together as a community. Events like Flock are powerful in many ways, and it would be easy for a conference to fall towards the “lousy” side of the scale. But the organizers, volunteers, and staff behind Flock help make the conference an amazing experience for all attendees. It’s difficult to explain my appreciation for this work that enables so many incredible experiences and magic to come together every year.

My participation at Flock 🔗

Unlike last year’s Flock, I also participated as a speaker. In all, I helped organize and plan three different talks and workshops, which are detailed individually as follows.

University Outreach: New task or new mindset? 🔗

My first talk was on Tuesday. Together with Jona Azizaj, we presented on the topic of outreach to students and university staff and faculty for the Ambassadors program. The talk structure was past, present, and future. We begin by looking at past efforts and trying to see what we could learn by things that have happened before now. Then, we looked at how Fedora is doing in working towards the University Involvement Initiative and what tactics are effective now. We also focused on areas of student outreach with the events we are attending now. Everything up to this point was more of presenting information.

After running through the past and present, we presented the direction for moving forward with improving our outreach to universities, high schools, and their students and faculty members. We broke up the main points into four big topics: on-boarding, mentorship, focusing on not just students, and improving visibility. We presented some of our own thoughts on these topics and then opened the floor for community ideas and brainstorming.

My original plan for this talk was to present more hard information on how to begin moving forward sooner than later (e.g. “less talking, more acting!”). However, I had made plans and expectations for an EDU FAD to happen in late July, which at the time, would be the place where resources and guides were created focusing on this specific topic. But due to sudden complications, the FAD never happened. The resources I hoped to have were not available. So the end of this talk was a valuable time for attendees to leave their own thoughts and ideas on generating these resources and what kind of areas we should focus on first. The room was packed, and many people with diverse ideas had something to offer. The feedback was at times harsh, but I appreciated the directness towards coming up with solutions and the interest in the topic (after all, a full room says a lot more than an empty room).

A super big and special thanks goes to both Ardian Haxha and Jona Azizaj. Ardian was originally the other co-speaker for this talk, but was unable to attend Flock due to visa issues in Kosovo. Jona willingly stepped up as an interested member of the community to help deliver the talk and her help was greatly appreciated and helpful.

Once the videos of Flock are uploaded, I hope to review the comments and feedback from the talk once more and begin converting the ideas into action.

Diversity Panel 🔗

The first-ever Diversity Panel was originally headed by Fedora’s Diversity Adviser, María ’tatica’ Leandro. But due to medical concerns, María was unable to make it to Flock. Amita Sharma stepped up to help lead and organize the panel this year. Amita reached out to me for help as a fellow member of the Diversity Team, along with several others at the conference.

I was invited to take part, but I didn’t get to spend as much time answering questions or offering ideas as I would have liked to. I helped organize and establish a remote call with María to participate from her home and also helped document the panel with some picture-taking. I feel I have to say this because the picture I’ve seen shared the most from the panel has me looking down at my phone while the other panelists look deep in thought! At that exact moment, I was replying to messages with María to help troubleshoot some audio problems and help her identify who was speaking.

Overall, I feel the panel was a great success and I hope to see it become a regular part of Flock every year. We were able to target and name issues that the community feels needed focus in terms of diversity. Awareness was also raised for the incredibly large and diverse community we have. I hope together we can work towards breaking some of the stereotypes of Linux and open source communities, starting with our own. Big thanks (and hugs!) to Amita for helping organize the panel at the last minute, and a round of applause for all the panelists (Matthew Miller, Marina Zhurakhinskaya, Sylvia Sánchez, Bee Padalkar, Jona Azizaj, and Marie Nordin).

CommOps workshop 🔗

The Community Operations (CommOps) workshop was originally headed by Fedora’s Community Lead, Remy DeCausemaker, but due to an opportunity of a lifetime, he left his position at Red Hat and was unable to make it to Flock. Together with Bee Padalkar, we took over responsibility for this workshop.

Together, we helped plan out the key areas of focus we wanted to have for the workshop. We decided to focus on on-boarding discussions with community members and planning ahead for tasks we wanted to work on in the coming year. We created and developed some slides to help structure the workshop. Most of our preliminary planning work was done in an Etherpad, but some of the general structure and outlining exists in our wiki planning pad.

In the literal last minute before the talk began, Remy reached out to me and we patched him in for a brief audio introduction over Google Hangouts. He added some background and context to the work happening in CommOps over the past few months. Even with the suddenness of the arrangement, I was glad to have Remy with us for a time as we launched into the workshop. Unfortunately, it was only after his words we realized that our recording hadn’t started. So his words will live on in our minds and memories forever instead.

The on-boarding discussion was shaped by those who were in attendance, but as I anticipated, even a few people would be enough to begin discussion to know areas that need extra focus and attention. Two areas we spent a good amount of time covering and reviewing were the Python SIG (thanks to Miro Hrončok) and the Ambassadors (thanks to Christoph Wickert). We collected a lot of feedback and notes on these two specific teams. Until the workshop, the Python SIG wasn’t on the CommOps radar, and knowing that they could use some help and assistance with on-boarding new team members is the exact type of feedback that was perfect to hear. I knew the Ambassadors would be a large one to tackle, but we were able to get some added context and feedback from a FAmSCo member and veteran Ambassadors to help steer the direction for how that discussion and subsequent actions will be shaped and directed.

We also spent some time collecting feedback on “wishes” for community metrics that would be helpful to understand both our impact and areas that we could spend more time focusing on. Most of this part of the discussion was lead by CommOps metrics genius Bee. You can see some of her past work on her blog (like her FOSDEM analysis). One area that would be better to understand is the Globalization and translation parts of the project. It would also be powerful to measure contributions by location for translations. The example used was if a small number of translations begin appearing in a new language, we can spend time providing resources and help to new contributors, with the goal of helping spur organic growth and interest in translating Fedora to that local language.

Of course, there are hundreds of different ways we could spin this story on metrics, but hopefully with the information we gained, we can begin directing focus at specific areas and teams. Bee has already started reaching out to Fedora’s G11N team!

Again, I’d like to reserve a very special thanks to Bee for helping organize, plan, and execute this workshop. I didn’t originally anticipate being tasked with this and I had never organized something like this before. Having her help was a lifesaver and I think together we turned it into a productive and informative session. I’m looking forward to another year and beyond on working with her throughout the Fedora Project.

What Flock was for me 🔗

The context differences between my first and second Flock are immense. At the first Flock, it was a stroke of luck that it happened to be hosted in the same city as where I was already planning to move for attending my university. At Flock 2015, I was a newcomer and even an outsider. I didn’t know anyone in the conference, I didn’t know the city, and I had only ever wished to contribute up to that point. But I hadn’t done much leading up to Flock 2015 other than observe. But even at the conference last year, there was one thing that was evident to me even as an outsider. The community is strong. The community is together. It was clear that the relationships within Fedora also extended outside of Fedora. I remember seeing people have a heated discussion about Fedora, or spend an entire workshop focusing on a particular issue… and after all the work was done for the day, they would walk out, have dinner together, buy each other a drink, and celebrate. There were smiles, there were hugs, there was a true air of friendliness across the entire conference. I didn’t have to be much of a contributor to see that, even then.

Changing roles 🔗

Now, at Flock this year, the roles were reversed. Since becoming involved in Fedora around September and October of 2015, I slowly became immersed and absorbed into the community that I had watched and observed from the sidelines at Flock 2015 (and a year or so before then). But instead of watching this time, I became a participant. IRC names become names, and names become faces. In place of giving karma cookies, we shared real cookies, high-fives, hugs, and our thanks for each other. We had intense discussions on real issues or dilemmas in our project and our community. We built solutions and addressed tricky topics, we challenged each others’ ideas, we focused on how to improve the thing we spend so much time working on, either paid or volunteering.

And then we would walk around the city, jump on a river boat, visit a brewery, or hit the dance floor together. We smiled, we laughed, and we enjoyed the rare opportunity to eliminate the factor of distance and spend time with our community members. There’s an air of incredibleness to this that makes it difficult to describe. But when you’ve experienced it, you know exactly what it feels like.

Difference in saying goodbye 🔗

The one major difference between Flock 2015 and 2016 for me, outside of changing roles from an observer to a participant, was something I wasn’t expecting. Unlike the previous year where saying goodbye was driving a couple of miles to my apartment and thinking about all the things I saw and experienced, this time it was saying goodbye to new friends, shared memories, and an empowering sense of community. The names in IRC weren’t just usernames, but they were faces… people. They were conversations, they were walking around together in a foreign city, they were sharing the view of a beautiful sunset on a river. It was remembering that we’re all humans with unique ideas, perspectives, and personalities, even if the tools we use to communicate make it easy to forget that.

Saying goodbye at the end of the week was far harder than I anticipated, and it made me crave the opportunity to close the factor of distance again at the soonest possible opportunity.

On a more personal note 🔗

To this end, Flock came at the right time for me this year. Over the past few months, I’ve spent a lot of time working across all different areas. My weekdays focused on Fedora and Google Summer of Code, my weekends woke me up at 4:00am for my weekend job at a local coffee shop in my hometown, and any extra time I could sneak goes into managing my now four-year-old Minecraft server community, CrystalCraftMC. Before that, I finished my first year of my undergraduate degree at the Rochester Institute of Technology, and I’m preparing to move back up to Rochester this week.

As much as I may have tried convincing others and myself that I wasn’t at least a bit burnt out, it was definitely beginning to wear on me. Anyone who has experienced burnout knows what the feeling is like. It’s different in how it affects all of us. But I was reaching that point through this summer. But Flock helped remind me of all the different people who are involved in this incredible project and why we’re doing the work we are doing. Anyone who isn’t familiar with open source will always question why we spend so much time working on something without being paid for it. But it’s more than just that. It’s more than a financial thing. The reason anyone volunteers willingly to open source is rarely ever to meet a financial or monetary goal. This is also a difficult thing to describe, and I hate to write something off as “you have to experience it to know what I mean”, but maybe this applies in this situation.

On that note, Flock served as a vital reminder for me about why I choose to involve myself with the Fedora Project. And it helped show me that the answer I need to take away isn’t to contribute more, but it’s to contribute enough for me. The several times someone in the community came up to me personally and said, “Hey, thanks for all the work you’re doing” or something along those lines was incredibly powerful and moving to me. And that helped provide value for all the contributions and time I spend in Fedora. I want to make sure that I am at my best where I am able to contribute without burning myself out and away from Fedora. The unique opportunity of being in the same physical place with so many other Fedora contributors added that context for me. And who knows, maybe this realization from Flock saved me from hitting a wall at some point in the future. But now, I am confident and ready to continue with another year, and beyond, of Fedora contributions.

Thanks for having me 🔗

I am incredibly thankful and grateful to be a part of the Fedora community. The opportunity to attend a conference like Flock with sponsorship in a country I’ve never been to before was an incredible experience. Without a doubt, it’s something that will stay with me for a long time. There are so many people I have to thank for helping open a door or offer pointers and tips for getting involved. There’s the Fedora Magazine team, the CommOps team and its original founder, the Marketing team, the Ambassadors (both globally and locally), the Diversity Team… to list names would both be incredibly time-consuming and unfair (because I’m beyond sure I would forget some name of someone who did have an impact on me getting involved).

I would like to give special thanks and appreciation for the companionship and friendliness of Amita, Bee, Jona, and Giannis during Flock. We probably spent a large part of our time at the conference together and I have a deep appreciation for the opportunity to get to you know you all personally, not just as fellow contributors but as true friends. I anticipate the next time we can all be together in the same space again!

Looking ahead 🔗

2016 is past halfway complete and we’re on track towards a speedy arrival of 2017. But there is a lot to do before we get there. Flock has helped give the opportunity for the community and all of its teams to find their direction and aim for the next few months and to work towards that. I am refreshed, reinvigorated, and ready for another year of noting all the #info, answering the calls for #help, and taking on #action items to build and grow the Fedora Project forward.

See you in channel, on the mailing lists, or wherever our paths will collide next… as I’m sure they will.

Next steps for GSoC 2016 🔗

My last steps for the project are moving closer to production. Earlier this summer, the best plan of action was to use my development cloud instance for quick, experimental testing. Once a point of stability is reached, it would be tested on a staging instance of the real Fedora Magazine or Community Blog. Once reviewed and tested, it would work its way to production for managing future installations and upgrades for any WordPress platform in Fedora.

When the time comes to move it to production, I will file a ticket in the Infrastructure Trac with my patch file to the Ansible repository.

One last correction 🔗

One sudden difficulty I’ve found is using the synchronize module in my upgrade playbook. Originally, I was copying and replacing the files using the copy module to carry out this, but I found synchronize to offer a better solution, using rsync. However, after switching, I ran into a small error that had me hung up.

When running the upgrade playbook, it would trigger an issue with rsync requiring a TTY session to work as a privileged user. I found a filed bug for this in the Ansible repository. Fixing it required setting a specific flag in the server configuration when using rsync. To avoid doing this, I altered my upgrade playbook to not avoid dependence on a root user for running, and instead using user and group permissions for the wordpress user. I’m working through smoothing out a few minor hiccups with the synchronize module during today, mostly dealing with the directory not being found when executing the module, even though it exists.

Flock 2016 🔗

On Sunday, I’ll be flying out to Poland for Flock 2016, Fedora’s annual contributor conference. During Flock, I’ll meet several other Fedora contributors in person, including my mentor. We plan to set up the staging instance either later tonight or during Flock, depending on how time ends up going.

I’ll also be delivering a talk and hosting a workshop during the week as well! One of the workshops I’m hoping to attend is the Ansible best practice working session. I’ll be seeing if there’s anything I can glean to build into the last week of the project during the workshop.

Documentation 🔗

The first complete draft of my documentation for managing WordPress installations in Fedora’s infrastructure is available on my Pagure repository. The guide covers deployment, including upgrades, as well as more notes about working with the playbooks. As my project work begins to finish, the documented procedure is an outline for the final work. It will also be expanded as I close out the project.

Installing new WordPress site 🔗

After testing on my development instance in the Fedora cloud, my playbook is able to successfully install multiple WordPress sites to various hosts (pending one caveat for automatically setting up MySQL databases). I was able to spin up multiple sites quickly and easily to a point where I was satisfied with how it worked.

A few challenges I faced in this part were figuring out templating the right information into the WordPress configuration file. I was originally going to try using a variable file, but due to the issue of storing private information, I was trying to use external variables. After revisiting the idea with Patrick, I’m going to use a variables file with the information for each hypothetical installation. This file will then be stored in the private Ansible repository that holds server and application credentials.

Determining SELinux flags and contexts was also challenging. I had to learn which ones to apply to WordPress for basic functionality to still work (particularly for things like uploading media files to the server and letting WordPress cron work as expected). I’m not wholly satisfied with how I implemented it yet, as I want to dig more into setting the contexts with different parts of modules like unarchive and file, if possible.

Upgrading and master 🔗

The last significant task to handle is writing the playbook for handling upgrades for WordPress installations. There were two options originally available. The first option would be to allow upgrading via the WordPress admin panel. The second option would be writing a playbook to handle the upgrade. We opted for the second method as this will allow the files on the web server to be read-only, which will serve as an extra measure of hardened security.

I hope to have a playbook created in the next week to tackle upgrading an existing WordPress installation to a newer version. This will be the last significant task of my proposal, before I begin taking what I have so far and finding ways to integrate it into Fedora’s infrastructure.

One of these smaller but important tasks will be writing a “master” playbook to orchestrate the entire process of setting up a machine to run it (and referring to the necessary roles). Some of these roles I’ll be referring to are the httpd and mariadb roles.

Moving towards Flock 🔗

With Flock fast on approach, I’m hoping to have the majority of my project work finished and completed before that time frame. Anything past Flock should mostly be tidying up or fully documenting any changes made in the last stretch. This is my target goal at the moment! I’m looking forward to being a part of Flock again this year and meeting many members of the Fedora community.

Flock, now in its fourth year, is a conference for Fedora contributors to come together, discuss new ideas, work to make those ideas a reality, and continue to promote the core values of the Fedora community: Freedom, Friends, Features, and First.

This year, I am attending as a contributor to the project, giving a talk, and leading a workshop!

Poland: New experience 🔗

Last year, I attended Flock 2015 without having much of an idea of what to expect. Flock 2015 was less than ten minutes away from my then future university, the Rochester Institute of Technology. I was a user of Fedora since 2013, but I had never figured out how to start contributing to the project. To take advantage of this experience, I made plans to move into school early so I could see what Flock was all about.

Fast forward a full year, and a lot has changed. Now, I spend many hours a week working on the Fedora Project in many places. I help lead the CommOps and Marketing teams. I organize and attend events on the US East Coast as an Ambassador. I’m a Google Summer of Code 2016 student for Fedora. When I walked into the conference center last year as a shy student, I never imagined that many of the people I met would become familiar faces in short time.

This year, Flock 2016 in Poland will be a different experience, and I am looking forward to seeing what it will bring. Do you have plans to attend? If so, allow me to share some details for sessions you will want to add to your schedule!

Evaluating our impact in education 🔗

At 17:30 UTC+2 on August 2nd, 2016, together with Jona Azizaj, we will lead a talk titled, “University Outreach – New task or new mindset?”

In early 2015, the Fedora Council proposed a new objective: the University Involvement Initiative. The purpose? Try to increase exposure of Fedora in university settings to gain new users, but also to hopefully gain new contributors. In order to carry this out, is it a new task, or does it need a new mindset? In this talk, we begin looking at the current mindset and marketing thoughts around attracting university students to Fedora. What is working? What isn’t?

We will look at personal experiences among the presenters with getting involved with Fedora as a student for an example. We will focus on how changing the ways we approach reaching out to students might be the best way to begin making an impact on students with Fedora.

If you are someone interested in reaching new audiences of students with Fedora, make sure you work this talk into your agenda.

CommOps Workshop 🔗

As of recently, I will also be leading the CommOps workshop on August 4th, 2016 at 13:30 UTC+2.

This year, for the first time, CommOps will be hosting its own workshop to tackle existing tasks and project items, offer a place for the community to add their own ideas and wishes for what they would like to see, and planning for the future growth of our sub-project. Flock offers a unique venue to do this as it brings together multiple people from different areas of Fedora in the same rooms. This is a great place for us to take advantage of the combined people power to accomplish tasks that would be hard otherwise.

The workshop will be designed to also try to keep remote contributors in mind, where possible, over IRC and possibly other means.

To help organize thoughts and ideas on the workshop in a public and open way, the workshop planned in the open on the wiki. We’re working with other CommOps contributors on shaping how the workshop will run. We hope to have you join us and see what we’re up to in CommOps land!

Thank you Red Hat 🔗

Finally, I want to offer my sincere gratitude and appreciation to Red Hat and the Flock sponsors for sponsoring my travel costs to Flock 2016. As a student, there would not be a way for me to afford making this trip on my own expenses. Thanks to the great folks behind Flock, I will be attending and hope to contribute my worth with the above talk and workshop, as well as throughout the entire conference.

Thank you for granting me this opportunity, and I look forward to seeing many other Fedora contributors next month in Poland!

Image courtesy Alexey Topolyanskiy – originally posted to Unsplash as Untitled.

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.

Background for Fedora 🔗

Understanding the background context for how WordPress fits into the needs for Fedora is important. There are two sites powered by WordPress within Fedora: the Community Blog and the Fedora Magazine. Each site uses a different domain (communityblog.fedoraproject.org and fedoramagazine.org, respectively).

At the moment, there are not any plans to set up or offer a blog-hosting service to contributors (and for good reason). The only two websites that would receive the benefits of a multi-site network would be the Community Blog and the Magazine. For now, the intended scale of expanding WordPress into Fedora is to these two platforms.

Setting up the WordPress network 🔗

To test the possibilities of using a network for our needs, I used a development CentOS 7 machine for my project testing purposes. There are some guidelines on creating networks for reading first before proceeding. After reading these, it was clear the approach to take was the domain method. I moved to the installation guide on the development machine.

I wanted to document the process I was following for the multi-site network, so I created a short log file of my observations and information I found as I proceeded.

One of the time burners of this section was picking up Apache again. A few years ago, I switched my own personal web servers to nginx from Apache. Fedora’s infrastructure uses Apache for its web servers. It took me a little longer than I had hoped to get familiar with it again, mostly with virtual hosts and SELinux contexts for WordPress media uploads. Despite the extra time it took with Apache, I feel like this will save me time later when I am working on polishing the final deliverable or working with the Apache roles available.

In addition to this, I also picked out the dependencies for WordPress, such as the PHP packages needed and setting up a MariaDB database. After a while, I was able to get the WordPress network established and running on the development machine. It was convenient having a testable interface at my fingertips to work with.

WordPress network: Conclusion? 🔗

At the end of my testing and poking around, it appeared to me that there would not be an easy solution to using a WordPress network for Fedora. The network had the best ability when set up to use wildcard sub-domains, which wouldn’t be a plausible solution for us because of the two different domains. There were more manual ways of doing it (i.e. not in the WordPress interface) with Apache virtual hosts. However, I felt like it would be easier to write one playbook that handles a single WordPress installation, and can be run for both sites separately (or new sites).

Given that the factor of scale is two websites, I think maintaining two separate WordPress installations will be the easier method and save time and keep efficiency.

This week’s challenges 🔗

This week had a late start for me on Wednesday due to traveling on a short vacation with my family from Sunday to Tuesday. Coming back from the trip, I also have a new palette of responsibilities that I am assisting with in Community Operations and Marketing, following decause’s departure from Red Hat. I’m still working on finding a healthy balance of time and focus between other important tasks I am responsible for and my project work.

I’m hoping that having a full week will allow me to make further progress and continue to overcome some of the challenges that have arisen in the past few weeks.

Next week’s goals 🔗

For next week, I’m planning on focusing on my existing product and making it feel and run more like a “Fedora playbook”. I mostly want to work on saving unnecessary effort and being consistent by tapping into the existing Ansible roles in Fedora Infrastructure. This would make setting up an Apache web server, MySQL database, and a few other tasks more automated. It keeps the tasks and organization in a consistent manner as well since they are across Fedora’s infrastructure already.

By next Friday, the plan is to have a more idempotent product that runs effectively and as expected in my development server. Beyond that, the next step would be to work on getting my site into a staging instance.

Communicating between Ambassadors and Design 🔗

From our conversation, I learned that there was a disconnect between the Ambassadors and the Design team. As a sponsored Ambassador myself, I had never seen anywhere documenting the steps or process I should take to ask for art assets when needed for an event. There were also things I had not considered about what goes into the printing and production process for items too. Every region of the world seems to do things a little differently!

With the information I learned from our conversation in a CommOps meeting, I penned up a first draft of what the communication process should look like between Ambassadors and the Design team. The page is not official yet, and I posted a bit ago to the Design Team mailing list requesting feedback on the page. Hopefully, if the information passes approval from the Design Team, we can work on socializing this information with all Ambassadors across the four regions of the world. The end goal of this is to make it easier on both the Ambassadors and the Design Team by doing the following…

• Making it clear what to do as an Ambassador for requesting art assets / printed items
• Reducing strain / load on Design Team from repetitive situations / “common questions”
• Creating a faster and more efficient workflow for Ambassadors organizing events and Designers creating art and deliverables

Long-term, though… 🔗

In this discussion, we acknowledged a wiki page is not a long-term solution to this problem. There are now initiatives in the project to help bring greater unity and cohesion between different sub-projects. CommOps is definitely one of the biggest players to this. The future formation of FOSCo will help specifically towards communication between groups like Ambassadors, Design, and Marketing. Fedora Hubs will also contribute to making this process easier by having improved methods of communicating key information like this.

Communication by Lorenzo Stella from the Noun Project.

Understanding background 🔗

My project proposal originated from a discussion based on an observation about managing the Fedora Magazine. Fedora’s infrastructure is entirely automated in some form, often times using Ansible playbooks to “conduct” the Fedora orchestra of services, applications, and servers. However, all the WordPress platforms within Fedora are absent from this automated setup. This has to do with the original context of setting up the platforms.

However, now that automation is present in so much of the Infrastructure through a variety of tasks and roles, it makes sense to merge the two existing WordPress platforms in Fedora into the automation. This was the grounds for my proposal back in March, and I’ve made progress towards learning a completely new technology and learning it by example.

Initial research 🔗

The second resource is, as one would expect, the Ansible documentation. The documentation for Ansible is complete and fully explanatory. Usually if there is an Ansible-specific concept I am struggling with learning, or finding a module for accomplishing a task, the Ansible documentation helps point me in the right direction quickly.

Research into practice 🔗

After making some strides through the book and the documentation, I began turning the different concepts into practical playbooks for my own personal infrastructure. I run a handful of machines for different purposes, ranging from my Minecraft server, a ZNC bouncer, some PHP forum websites, and more. Ever since I began using headless Linux servers, I’ve never explored automation too deeply. Every time I set up a new machine or a service, I would configure it all manually, file by file.

First playbook 🔗

After reading more about Ansible, I began seeing ways I could try automating things in my “normal” setup. This helped give a way to ease myself into Ansible without overwhelming myself with too large of tasks. I created repositories on Pagure for my personal playbooks and Minecraft playbooks. The very first one I wrote was my “first 30 minutes” on a new machine. This playbook sets up a RHEL / CentOS 7 machine with basic security measures and a few personal preferences ready to go. It’s nothing fancy, but it was a satisfying moment to run it in my Vagrant machine and see it do all of my usual tasks on a new machine instantly.

For more information on using Ansible in a Vagrant testing environment, check out my blog post about it below.

https://jwfblog.wpenginepowered.com/2016/06/setting-vagrant-testing-ansible/

Moving to Minecraft 🔗

After writing the first playbook, I tried moving to focusing on some other areas I could try automating to improve my “Ansible chops”. Managing my Minecraft server network is one place where I recognized I could improve automation. I spend a lot of time repeating the same sort of tasks, and having an automated way to do these tasks would make sense.

I started writing playbooks in the adding and restarting Minecraft servers based on the popular open source server software, Spigot. Writing these playbooks helped introduce me to different core modules in Ansible, like lineinfile, template, copy, get_url, and more.

I have also been using sites like ServerFault to find answers for any starting questions I have. Some of the changes between Ansible 1.x and 2.x caused some hiccups in one case for me.

Using Infrastructure resources 🔗

After getting a better feel for the basics, I started focusing less on my infrastructure and more on the project proposal. One of the key differences from me writing playbooks, roles, and tasks for my infrastructure is that there are already countless Ansible resources available from Fedora Infrastructure. For example, to create a WordPress playbook for Fedora Infrastructure, I would want to use the mariadb_server role for setting up a database for the site. Doing that in my playbook (or writing a separate role for it just for WordPress) would increase the difficulty of maintaining the playbooks and make it inconvenient for other members of Fedora Infrastructure.

Creating a deliverable 🔗

In my personal Ansible repository, I have begun constructing the deliverable product for the end of the summer. So far, I have a playbook that creates a basic, single-site WordPress installation. The intention for the final deliverable is to have a playbook for creating a “base” installation of a WordPress network, and then any other tasks for creating extra sites added to the network. This will make sure that any WordPress sites in Fedora are running the same core version, receive the same updates, and are consistent in administration.

I also intend to write documentation for standing up a WordPress site in Fedora based on my deliverable product. Fortunately, there is already a guide on writing a new SOP, so after talking with my mentor, Patrick Uiterwijk, on documentation expectations and needs next week, I will be referring back to this document as a guide for writing my own.

Reflection on GSoC 2016 so far 🔗

I was hoping to have advanced farther by this point, but due to learning bumps and other tasks, I wasn’t able to move at a pace as I hoped. However, since starting GSoC 2016, I’ve made some personal observations about the project and how I can improve.

• Despite being behind from where I wanted to be, I feel I am at a point where I am mostly on track and able to work towards completing my project proposal on schedule.
• I recognize communication on my progress has not been handled well, and I am making plans to make sure shorter, more frequent updates are happening at a consistent and regular basis. This includes a consistent, weekly (if not twice every week) blog post about my findings, progress, commits, and more.
• After talking with Patrick this week, we are going to begin doing more frequent check-ins about where I am in the project and making sure I am on track for where I should be.

Excerpt from GSoC 2016 evaluation form 🔗

As one last bit, I thought it would be helpful to share my answers from Google’s official midterm evaluation form from the experience section.

“What is your favorite part of participating in GSoC?” 🔗

“Participating in GSoC gave me a means to continue contributing to an open source community I was still getting involved in. I began contributing to Fedora in September 2015, and up until the point when I applied for GSoC, I had anticipated having to give up my activity levels of contributing to open source while I maintained a job over the summer. GSoC enabled me to remain active and engaged with the Fedora Project community and it has kept me involved with Fedora.

The Fedora Project is also a strong user of Ansible, which is what my project proposal mostly deals with. My proposal gives me a lot of experience and the opportunity to learn new technology that not only allows me to complete my proposal, but also understand different levels and depths of contributing to the project far beyond the end of the summer. With the skills I am learning, I am being enabled as a contributor for the present and the future. To me, this is exciting as the area that I am contributing in has always been one that’s interested to me, and this project is jump-starting me with the skills and abilities needed to be a successful contributor in the future.

GSoC is also actively teaching me lessons about time management and overcoming challenges of working remote (which I will detail in the next question). I believe the experience I am getting now from participating in GSoC allows me to improve on myself as an open source developer and contributor and learn important skills about working remotely with others on shared projects.”

“What is the most challenging part of participating in GSoC?” 🔗

“The hardest part for me was (is) learning how to work remotely. In the past, when I was contributing at school, I had resources available to me where I could reach out to others nearby for assistance, places I could leave to focus, and a more consistent schedule. Working from home has required me to reach out for help either by improving how well I can search for something or reaching out to others in the project community about how to accomplish an objective.

There are also different responsibilities at home, and creating a focused, constructive space for me to focus on project work is an extremely important part of helping me accomplish my work. Learning to be consistent in my own work and setting my own deadlines is a large part of what I’m working on doing now. Learning the ability to follow and set personal goals for working on the project was a hard lesson to learn at first, but finding that balance quickly and swiftly is something that is helping me move forward.”

What is Vagrant? 🔗

Many people in the tech industry are already familiar with virtual machines (VMs) and using them for testing. If using a virtual machine is useful for testing and experimentation, Vagrant takes that idea and makes it a thousand times for powerful. Vagrant creates and configures a single virtual machine or several groups of inter-connected virtual machines. For someone trying to learn configuration management software like Ansible (or Puppet, or Chef, or Salt…), it features tight integration for creating virtual machines from playbooks.

Using Vagrant allows you to make quick, simple, and easy changes in a safe, local environment. Vagrant is also incredibly easy to set up, and in my experiences, it also ran well on a laptop. My trusty Toshiba Satellite with 8GB of RAM and an Intel i3 chip was able to handle three CentOS 7 virtual machines at once, and still manage to do other regular tasks.

Installing Vagrant for Fedora 🔗

Since I’m working with Fedora on my hardware while working on the Fedora Project over the summer, it would make sense for this guide to cover how to install and set up Vagrant inside of Fedora. However, I imagine it’s similar for most other distributions, so try adapting these commands for your own distribution.

The Fedora repositories have a Vagrant package available. To install it, run the following command.

$ sudo dnf install vagrant

This will pull down Vagrant and all the dependencies it needs to run. However, what it won’t do is pull down some of the many providers that it might need to use a virtual machine.

Vagrant and providers 🔗

For my testing, I used a centos7 box image from geerlingguy. This image creates a current, updated CentOS 7 virtual machine. In order to use it, you must have one of the two providers available: VMware or VirtualBox. Seeing as how VirtualBox is easier for me to install and use on my system, I chose to use VirtualBox as the “provider” for building and simulating the CentOS 7 box within Vagrant.

It took a bit of figuring out at first, but I found a current and well-documented guide on how to install VirtualBox on to a Fedora 22 or 23 system. For a more detailed explanation of how to do it, you can read the instructions, but for simplicity, I have the commands here to show how to add it to your Fedora system quickly.

$ sudo dnf upgrade
$ cd /etc/yum.repos.d/
$ sudo wget http://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo
$ sudo dnf install VirtualBox-5.0 binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel dkms
$ sudo /usr/lib/virtualbox/vboxdrv.sh setup
$ sudo usermod -a -G vboxusers your_username

From here,  VirtualBox  will be available as a provider within Vagrant.

Running a CentOS 7 image 🔗

Now that you have both Vagrant and VirtualBox installed, you can create a Vagrant virtual machine with this image. Navigate to a new directory you want to use for managing your virtual machines. Once there, you can use the following commands to start your CentOS 7 virtual machine.

$ vagrant box add geerlingguy/centos7
$ vagrant init geerlingguy/centos7
$ vagrant up --provider virtualbox

After a lot of downloading and then waiting for the first setup to finish, you should receive a notification that your virtual machine started! Huzzah! You can log in directly to it by typing vagrant ssh in the same directory you ran the above commands.

There’s a lot of cool things you can do to set up your virtual machines and configure how they start. For example, you can choose to use the VirtualBox GUI for running your virtual machines if you don’t want to SSH into it. You can tweak several different flags to alter the environment for the virtual machine. However, that is out of the scope of this guide, and there is a fair amount of documentation already online.

Provisioning with Ansible 🔗

The fun part (and what was really cool for me) was provisioning new virtual machines with Ansible. You can instruct Vagrant to seek an Ansible playbook when creating a new virtual machine. It will use the instructions of the playbook to configure, install, or tweak whatever is in the playbook, as if it’s being run for the first time. Or maybe it’s the second, the third, the fourth time you’ve run it. In either case, the idempotent nature of Ansible should help make sure you avoid repeating anything that doesn’t need repeating.

In order to tell Vagrant to search for an Ansible playbook, you will need to edit the Vagrantfile for wherever you initialized Vagrant. Open it up in your favorite text editor and add the following bits at the bottom, but before the final end statement.

config.vm.provision "ansible" do |ansible|
  ansible.playbook = "playbook.yml"
end

These short but sweet instructions tell Vagrant to look for a playbook.yml file when starting this virtual machine. It will then be easy to provision (i.e. configure / modify / change) the machine with your playbook later on.

Writing the playbook 🔗

For this blog post, I’ll offer a simple but clear example of a playbook you can use to start a Vagrant machine. This snippet specifically comes from Ansible for DevOps by Jeff Geerling, which I have (and am) using as a guide as I continue to learn more about Ansible (I highly recommend the book, consider getting a copy).

---
- hosts: all
  sudo: yes
  tasks:
  - name: Ensure NTP (for time synchronization) is installed.
    yum: name=ntp state=present
  - name: Ensure NTP is running.
    service: name=ntpd state=started enabled=yes

All this example playbook does installs NTP if it is not present on the system, and then start and enable it, if it is not already. This is a very simple example, but it’s good for getting started quickly.

Running the playbook 🔗

In the same directory as your Vagrantfile, create a playbook.yml with the above content. Once you have the YAML file there, running the following command will run the Ansible playbook and allow you to see how it runs.

$ vagrant provision

Now, Vagrant will take your playbook and instantly run it in your machine. If all goes right, your virtual machine will now have NTP installed and be syncing your clock to the Internet! While a simple task, it was a satisfying feeling for me to see this run, but also to imagine the other possibilities that this could be used for. It would be easy to run a playbook on one, two, ten, a hundred, a thousand servers, and have it do the same thing on all of them.

The automation was fascinating to me and began giving me ideas of how I could automate my infrastructure, as well as to creating one for WordPress (for my GSoC project).

Congratulations! By the end of this short but (hopefully) useful guide, you will have Vagrant virtual machines that are controlled and orchestrated by Ansible.

Bad puns aside, I am actually enormously excited to announce that I am participating in this year’s Google Summer of Code program for the Fedora Project. If you are unfamiliar with Google Summer of Code (or often shortened to GSoC), Google describes it as the following.

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school.

I will work with the Fedora Project over the summer on the CommOps slot. As part of my proposal, I will assist with migrating key points of communication in Fedora, like the Fedora Magazine and Community Blog, to Ansible-based installations. I have a few more things planned up my sleeve too.

Google Summer of Code proposal 🔗

My proposal summary is on the GSoC 2016 website. The full proposal is available on the Fedora wiki.

The What 🔗

The Community Blog is becoming an important part of the Fedora Project. This site is a shared responsibility between CommOps and the Infrastructure team. Unlike most applications in the Fedora infrastructure, the Community Blog is not based off Ansible playbooks. Ansible is an open-source configuration management suite designed to make automation easier. Fedora already uses Ansible extensively across its infrastructure.

My task would consist of migrating the Community Blog (and by extension, Fedora Magazine) to an Ansible-based set up and writing the documentation for any related SOPs.

The Why 🔗

Ansible is a useful tool to make automation and configuration easier. In their current set up, the Community Blog and Fedora Magazine are managed separately from each other, and are managed by a single member of the Infrastructure team. By moving them to Ansible-based installations and merging the WordPress bases together, it provides the following benefits:

1. Makes it easier for other Infrastructure team members to fix, maintain, or apply updates to either site
2. Prevents duplicate work by maintaining a single, Ansible-based WordPress install versus two independent WordPress sites
3. Creates a standard operating procedure for hosting blog platforms within Fedora (can be used for other extensions in the future)

Thanks to my mentors 🔗

I would like to issue a special thanks to my mentors, Patrick Uiterwijk and Remy DeCausemaker. Patrick will be my primary mentor for the slot, as a member of the Fedora Infrastructure team. I will be working closest with him in the context of my proposal. I will also be working with Remy on the “usual” CommOps tasks that we work on week by week.

Another thanks goes out to all of those in the Fedora community who have positively affected and influenced my contributions. Thanks to countless people, I am happy to consider Fedora my open source home for many years to come. There is so much to learn and the community is amazing.

Getting started 🔗

As of the time of publication, the Community Bonding period is currently happening. The official “coding” time hasn’t started yet. Without much delay, I will be meeting up with Patrick and Remy later today in a conference call to check in after the official announcement, make plans for what’s coming up in the near future, and become more acquainted with the Infrastructure community.

In addition to our conference call, I’m also planning on (formally) attending the next Fedora Infrastructure meeting on Thursday. Shortly afterwards, I hope to begin my journey as an Infrastructure apprentice and learn more about the workflow of the team.

Things are just getting started for the summer and I’m beyond excited that I will have a paid excuse to work on Fedora full-time. Expect more check-ins as the summer progresses!

Bitcamp is a place for exploration. You will have 36 hours to delve into your curiosities, learn something new, and make something awesome. With world-class mentors and hundreds of fellow campers, you’re in for an amazing time. If you’re ready for an adventure, see you by the fire!

The Fedora Project attended as an event sponsor this year. At the event, we held a table in the hacker arena. The Ambassadors offered mentorship and help to Bitcamp 2016 programmers, gave away some free Fedora swag, and offered an introduction to Linux, open source, and our community. This report recollects some highlights from the event.

Getting to Bitcamp 2016 🔗

I left Rochester, New York around 4:00pm after my classes for the day had finished. Bitcamp check-in started at 7:00pm on Friday, April 8th. It was about a six hour drive for me to get there, and I got to Maryland right around 9:30pm.

Once I arrived, walking in was a crazy experience. Tables upon tables of hackers were lined up bu the hundreds. Most were already working on brainstorming. I meandered my way through the crowds to the Fedora table where Corey Sheldon, Mike DePaulo, and Chaoyi Zha were set up.

Meeting the hackers 🔗

Many other students came up to the table before the hackathon officially began. We interacted with several students and helped establish ourselves as mentors as well. Additionally, we also had a badge that attendees could scan to get added to their FAS account!

Once the event officially began, teams of people began working on their projects. Many people had grand ideas of projects to cram into the one weekend. For a brief time, the Ambassadors had a chance to rest from answering questions and helping people with their own hardware.

The hackers began settling into a groove for the evening.

Spending the night 🔗

As the day turned into night, the home stretch of the hackathon was beginning. Those with firm ideas were deeply focused on their projects. Others were taking their plans back to the drawing board to overcome unexpected difficulties. Things began settling down for the night. The same cycle repeated itself for both Friday and Saturday nights.

Around this time, we had waves of interested hackers in Fedora, open source software, and Linux approach the table. This time was great for personalized, one-on-one conversations with visitors. Many excellent connections happened during this time!

Mentoring 🔗

During Bitcamp, there were several opportunities and connections made between Fedora Ambassadors and university students.

For most of one night, Corey worked with one student who was aiming to do a full dual-boot installation on his laptop with Windows 10 UEFI. For a mixed variety of issues, he was unable to get Fedora working properly on his system. With the help of Corey, he was able to install and use Fedora on his laptop. He was very excited to finally get it working and was hoping to use it for development work in both classwork and personal projects. He was also a repeat visitor from BrickHack and remembered some of the booth members from the last hackathon.

Chaoyi traveled around the hacker space and worked with students looking to get help on web development projects. Chaoyi was able to give advice and help for students working with HTML, JavaScript / NodeJS, and Python. He traveled around the room for most of both nights teaching and showing students how to work on their projects and promoting the benefits of doing their work open source.

Mike also helped several students at Bitcamp, and like at BrickHack, his triple-booted MacBook with OS X, Windows, and Fedora was a popular item. Students with Macs often came and asked him about his setup and how he got it working. Mike was also able to help answer questions about developing in Fedora and share his experience working with tools available in Fedora for working on his projects for work and for fun.

Many students were looking for help with how to better get experience working on software for their future careers. As a student familiar with open source, I enjoyed talking to these students about how open source was a great resource for them. I explained how open source is a great way to get real world experience without working an “official” job, showed how they could make an impact on the world and start doing things, and why we do open source. It was gratifying the see these students get something out of our discussions and build something awesome in the open by the end of hackathon.

Overall, I feel like the Fedora Project’s impact was notable and concentrated at the event. I am extremely thankful and fortunate to have been sponsored to attend Bitcamp as an Ambassador for the Fedora Project.

BrickHack 2016 and Fedora 🔗

This year, I attended with the Fedora Project team, which included people like Remy DeCausemaker, Mike DePaulo, Charles Profitt, Ralph Bean, and Ryan Scott Brown. In addition to the Fedora crew, many of my friends and fellow students were there, like Mike Nolan and Brendan Whitfield. There were countless others that made the weekend awesome and incredible.

For pictures and more details, read my full report on the Fedora Community Blog.

https://communityblog.fedoraproject.org/brickhack-2016-event-report/

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 🔗

Yesterday, Fedora contributor and CommOps team member Bee Padalkar published an article on her blog about measuring the impact of Fedora’s participation at the FOSDEM conference in Europe.

Looking at FOSDEM 🔗

In her analysis, Bee looked at people who scanned the FOSDEM badges for 2014, 2015, 2016. Leveraging tools like fedmsg, she was able to draw conclusive evidence of how people who scanned the badge began contributing for the first time or started contributing more than before the conference. The statistics are fascinating and the analysis is comprehensive in how it measures contributions. It’s worth the full time to read how we’re making an impact at conferences!

Looking ahead 🔗

The other awesome factor of this is that these kinds of reports are extendable to other events in the world of Fedora. Other Ambassadors can use tools like Fedora Badges and track metrics of how they impact and affect the people they engage with at conferences and hackathons. I’m hoping for us to be able to use these kinds of analytics for the past event at BrickHack 2016 that I helped organize as an Ambassador. Stay tuned for an event report and plenty more on the Community Blog with details about BrickHack.

Read all about it! 🔗

Read the full analysis on her blog!

This post serves as the project proposal for me and my team’s Humanitarian Free and Open Source Software Development “Community Architecture” project (shortened to CommArch)!

In this project proposal, we take a preliminary look at the project we’re looking at analyzing, Tahrir, and the different criteria we are assigned to look at.

Team Members 🔗

Project 🔗

Tahrir by the Fedora Project

Description 🔗

Tahrir is a Pyramid app for distributing your own custom badges (based off of Mozilla Open Badges). The back-end is written in Python with an HTML/CSS and JavaScript front-end and the project is a smaller part of the Fedora Project.

Team Member Roles 🔗

Justin and Wilfried 🔗

1. Project Report I-R
2. git_by_a_bus

Stephen and Bobby 🔗

1. Project Report A-H
2. Calloway Coefficient of Fail

Source Code Repository URL 🔗

fedora-infra/tahrir

Upstream Mentors 🔗

Communication Methods 🔗

The following methods of communication are ordered in the most preferred way to the least.

1. IRC channel on freenode (#fedora-apps)
2. Issue tracker on GitHub
3. Mailing list via infrastructure@lists.fedoraproject.org

What are the easy parts? 🔗

• Project is fairly small (even though it is part of a larger project)
• People to ask for help when needed
• Git-by-a-bus is going to make analytics of contributors super easy
• Distribution of work will allow us to complete the project in a timely manner

What are the hard parts? 🔗

• Lack of a frame of reference for some team members who have never worked with open source projects in the past (e.g. we are unable to compare activity or its community to other projects)
• Since the project is a smaller project inside of a larger one (Fedora Project), it will be challenging to look at it in a modular sense
• Separation of dependencies from project requirements (Open Badges requirements and Tahrir requirements)

How will you overcome both? 🔗

Hard Stuff 🔗

• We have two people who are more advanced at hacking who can hopefully guide the two who aren’t through the project, effectively eliminating the lack of reference point.
• Three of our members are not people involved in the Fedora Project, and as such won’t be distracted by its involvement with Fedora and will only look at the project itself.
• Read up on the existing documentation and test the various endpoints of the project to identify what is needed with Open Badge and what the project is implementing itself.

My Year in Review 🔗

With an hour left until the New Year, there never seemed a better time to begin writing my Year in Review article. While it is a stereotypical kind of thing to do, I also think it’s a great opportunity to reflect on the gifts, changes, and special occasions that this past year has presented to me. 2015 is special to me in many ways because it marks a significant milestone in my life of moving away from home and beginning my journey into full adulthood.

There are many important and special people in my life that have made this year incredible, and I want to reflect and make note of this.

</high school> <college> 🔗

This past May, I graduated from high school. Looking back, it’s interesting to see how much has changed in my personal life and even in my own interests. Some friends have come and gone, but there are an important core of people who have always been present in my life, and I am privileged to have been one to know them deeply over the past four years.

Interestingly enough, it wasn’t until my junior year when I realized that I wanted to spend my life working in computer science. I remember when I walked into the classroom of my AP Computer Science teacher asking how I could get going with only one year left. Now, here I am immersing myself in digital technology in countless different ways. I feel like I am where I am meant to be.

These four years haven’t been easy either. I worked hard to get to the place I wanted to go. Despite quite a few personal challenges, I was fortunate enough to afford an education here at the Rochester Institute of Technology. Just in the semester and a half that I have been enrolled here, I’ve met countless people who have affected my life and helped shape the direction of where I’m going in the world. Special shout-out to the FOSSbox and RITlug, and everyone involved with both.

Coffee and Doughnuts 🔗

For most of 2015, I worked a not-so-typical job at Dutch Monkey Doughnuts in my hometown. Dutch Monkey is an important part of my town and they have helped create a name for people visiting the region. They’re well-known for their homemade doughnuts and Counter Culture Coffee, both of which are legendary within their own right.

During my time at Dutch Monkey, I was able to attend workshops and classes at the Counter Culture Coffee Training Center in Atlanta. Throughout the eight or nine classes I took, I was able to further my understanding and appreciation for an extremely complex and fascinating beverage. My appreciation and love for coffee has become a part of my being. The coffee industry is a wild and exciting place, and it is very much an ethical hotbed of all kinds of issues. I joke to myself that if sysadmin doesn’t work out, the coffee industry could always make a good fallback…

I was also fortunate to have some awesome co-workers who helped make the 4am shifts a little more enjoyable. Special shout-out to Jordan Hughes for the long talks about music, the music industry, and so many other things. I learned a lot from you and you’ve had a big impact on my own music tastes.

MINECON and SpigotMC 🔗

This was single-handedly one of the most profound events of the year for me. If you weren’t aware, I am a community moderator for the SpigotMC project. I have been a moderator since April 2014. Spigot is my true first open-source project, even though I wasn’t a contributor of code, but a community builder (or so I like to think).

MINECON announced 🔗

In February of 2015, Mojang announced that MINECON 2015 would be happening in London, England. Instantly, I thought there would be no way I would ever be able to afford a trip overseas for a two-day convention. However, I found the application for a MINECON Agent, which is the small group of “interns” that volunteer to help set up and prepare MINECON for over 10,000 people with the Mojang team. The only benefit to being an Agent was a waived ticket cost (around $120 last year). I applied for the program, unsure of what would come of it, doubtful I would be able to go even if I were accepted.

April rolls around, and I finally hear back from Mojang! “Congratulations, you are now a MINECON Agent!” It was difficult to believe at first, but I wasn’t sure I would be able to go regardless.

Getting in gear for MINECON 🔗

I began talking with the rest of the team at SpigotMC. We were also getting in gear for MINECON 2015 and were planning to attend as an organization with our own booth. We had arranged to have a booth and most of the team knew who was going to be there. Michael, our project lead, would be in attendance, along with Matthew, the other lead developer; Jordan, another community moderator like myself; Cindy, our local wiki staff, IRC staff, and contributing developer, or also the official “Spigot Mom”; and Miguel, our witty Spigot volunteer who has an ambiguous position with Spigot. Cindy’s son Alex was also going to be in attendance.

I didn’t think I would be able to attend. However, a very unique set of events happened one after another, and suddenly, the possibility of me attending MINECON this year began to materialize. Thanks to awesome people behind Spigot, I was fortunate enough to make it out to this year’s convention. When I figured out that I would be going to London, I was beyond stoked.

Going to London and MINECON 🔗

I would be there from Saturday, July 4 to Wednesday, July 8, 2016. Saturday and Sunday were the days of MINECON. Together with the team, we helped represent the SpigotMC project among thousands of convention-goers. We had brochures, bracelets, and a video running in the booth for visitors to take and see. I met some incredible people from our community, and I am privileged and honored to have met some incredible people there.

Thanks to Michael being the incredible individual he is, we went to a few dinners and meet-ups with others in the Minecraft community. I met two of the major Minecraft developers, Nathan (Dinnerbone) and Erik (Grum) and countless others in the YouTube and development community. It was almost unbelievable. The entire time I was in London, the experience felt surreal. Six months before this, I would never have believed any of this would ever have happened.

The Monday and Tuesday we were there, Cindy, Jordan, Alex, and I went around London doing our proper duty as tourists. We went to see Big Ben, Westminster Abbey, rode a double-decker bus, went to the Queen’s castle, and indulged in what Jordan called a “proper British meal”. On Monday night, Jordan treated me to a short trip around London hopping between bars (although everything closed so early)! We ended up crashing in some late-night diner, had a meal, and headed back for the next round of sightseeing on Tuesday.

Thanks to the team 🔗

This was truly a life-changing experience that was bestowed upon me. I was honored and privileged to have met the other members of the Spigot team that I’ve been working with for the past two years. I wouldn’t trade my time in London for anything else, and I’m hoping that I’ll be able to help host the crew this upcoming MINECON if it ends up in the northeast US.

Open Source and Fedora 🔗

I have used the Fedora operating system on my laptop since December 2013. I began using it on my desktop I built in November 2014. I have used this operating system for almost two years and I never had thought too much about the community behind the Fedora Project. I knew that it was a large and complex community, but I was never sure where to take the first step. I had always wanted to be an Ambassador, but questioned my usefulness or whether I was a right fit for the program.

Flock to Fedora! 🔗

I learned that Flock, Fedora’s annual contributor’s conference, was to be hosted in Rochester, NY in 2015 from August 5th to the 9th. I would be moving right next door to Flock just a week after the conference! After contacting a pair of people who seemed knowledgeable about the details back in February 2015, little did I know I was setting in motion an entirely new track of events in my life. The two gents I emailed, Remy DeCausemaker and Prof. Stephen Jacobs (SJ), helped give me advice on travel details and how I would get myself into Rochester in time for Flock.

Come August, I am back from MINECON, packing my bags for Rochester, and ending my last few days at Dutch Monkey. When I arrived in Rochester with my mother, it was an exciting and new experience, something I had looked forward to for a long time. Once Flock rolled around, I was almost instantaneously immersed in the Fedora community, and over the course of the week, I would begin to feel a part of a Project that I had questioned how to enter for almost a year.

The talks were fantastic, the speakers were passionate, and the community was welcoming. I was jump started into Fedora at Flock 2015, despite walking in a stranger. At first, I questioned whether coming was such a grand idea. It was obvious everyone knew someone already and I was only an excited Fedora user and fan. These were the people who did all the heavy-lifting to make this operating system and its community run. What was I doing here?

I distinctly remember Pete Travis (randomuser in IRC) coming up to me, introducing himself and asking me a few questions. In retrospect, I probably looked like I was feeling a bit out-of-place. He and I began talking a bit about his role in Fedora and some of my little experience in open source. After he spoke to me, I began to feel a little more attached to the conference. After a while, I began speaking up at some of the talks I attended, or trying to share some of my perspective or thoughts as an outsider. These were the stepping-stones that got me involved with the project.

One thing about all else stands out to me about the conference. I remember Remy saying to me towards the end (with minor paraphrasing), “You should check out this Community Operations thing that’s coming up soon. It’s going to be awesome.”

Fedora Magazine 🔗

Over the course of the next few months at RIT, I started working with Paul Frields, Ryan Lerch, and a few others on the Fedora Magazine. I began contributing as a writer, with my first article about using Spigot on Fedora. As time went on, I began helping as an editor, revising and reviewing other people’s articles to help get them published for the Magazine. By the end of 2015, I believe I would come to establish myself as a permanent member of the editorial team behind the Magazine.

CommOps 🔗

Additionally, during the months after Flock, I would follow up on what Remy told me, and I checked out this whole Community Operations (shortened to CommOps) thing. It was in the early formation stages, but the core idea behind CommOps was that they were the supporting team to offer support to all the other sub-projects in Fedora. Or in my eyes, a team focused on building and supporting the community with resources and assistance. This was something I thought I could contribute to. My programming skills were not at a level where I’d feel comfortable hacking on to Fedora either on the Infrastructure or as a Packager. But CommOps was that kind of thing that hooked me from the start. I wanted to help build Fedora up, and I could see what exactly CommOps was trying to target and how it was wanting to fix the long-term issues.

Now, months later, my involvement with CommOps has resulted with many tickets filed and many tickets closed. It has been a productive time while I have been with CommOps, and I never feel like there is too little to do. Our horizon is vast and there is much work to be done… 2016 offers great promise to the success of our sub-project, which in turn offers great promise to the Fedora Project. I am looking forward to seeing where this year takes us. I am also happy to work with such an awesome and dedicated group of people as those behind the CommOps team. There are too many to name, but I’m thankful for the leadership of Remy to keep us all together, focused, and driven.

2016 🔗

2016 will have a lot of ground to cover over 2015, but there is a large potential for this to be done. My own personal story with open source continues to grow, and I am beyond excited for what the future may bring. I am exposed to a unique group of people and minds here at RIT, and I am actively pursuing the Free and Open Source Software (FOSS) minor.

This self-reflection has turned into a much longer post than I anticipated, but I think this reflection is necessary and useful for my own purposes. Taking a moment to reflect on the events of the past year helps remind me what it’s all about and why I’m doing what I’m doing, especially at the times where everything seems confusing and I begin to question what I’m doing. But the path is illuminated and I am driven to succeed. There are a lot of things at stake for me and my family, and I hope to be able to meet many personal goals and better support the people closest to me in my life.

I would also like to give a special thanks to all the people who have made this year so incredible for me, and for those who have ridden the ride with me. There are so many names to list, and it’s hard to come up with this list in the dark hours of the morning when I know I should be sleeping. But to all of those who play a special and important role in my life, I want you all to know that none of what has happened to me would be possible without your support. Your continued guidance, counsel, and companionship teaches me much and inspires me greatly. My only wish is that I will someday be able to repay all the good deeds that others have bestowed upon me. If not to the original giver, I hope to someday inspire others and help others in the same way you all have shown and taught me. Maybe this is less of a 2016 thing and more of a “crystal ball into the future” moment… but I think it’s worth mentioning regardless.

Thanks for a fantastic 2015. I’m looking forward to seeing where 2016 takes us next.

Step 1: Identifying the bugfix 🔗

møte 🔗

When I started this homework assignment, there was originally one project I had in mind. As a non-code contributor to the Fedora Project, I frequently interact with Fedora’s own implementation of Meetbot. Meetbot is an IRC bot that adds meeting functionality to IRC channels. It makes it easy to highlight important info and summarize the meeting into a tidy HTML summary afterwards.

Fedora has a custom front-end for the Meetbot bot. This project is called møte and is developed by Fedora contributors Chaoyi Zha, Ralph Bean, and many others. One of its features is clustering Fedora sub-projects into teams and sorting their meetings together with JSON mappings.

Some Fedora sub-projects do not have their alias or meeting names set in these JSON files, making it difficult for their own team members or the general public from finding the records of their meetings. This inadvertently reduces transparency. Seeing as Fedora is an open project not only in code, but also in action, it made sense to try to clarify these mappings in a better way.

FOSSProfiles 🔗

More recently than møte, I am working with Prof. Stephen Jacobs this semester with FOSS@MAGIC. I am on an independent study on Open Source Journalism to help assist with marketing and growing additional exposure for the program. The website for the program is dated in its current form, and one of the goals this semester is to get it rewritten with a more modern, up-to-date layout and information.

One thing we want to have on the site is profiles of our students, alumni, mentors, and faculty. A Jinja-powered HTML generator for student profiles was made over a year ago, titled FOSSProfiles. In this project, students add their information to the repo in the form of YAML files. A user runs a Python script, and the program generates a raw HTML template with all of the students’ information in the repository. Wow! Useful.

When I went to try running it, I immediately ran into an issue and the program spat out a stacktrace at me. After troubleshooting the program and reading logs, I found two issues:

1. Student biography lines could not be over 140 characters
2. Python script did not support Python3

Step 2: Doing the bugfix 🔗

møte 🔗

My commits ranged throughout the month of January and I tried to accomplish a number of things. Before I cloned the repo and started making changes, I crawled around møte for a while to find any teams or meetings that may not have been added.

Thanks to the power of fedmsg, I was able to make a week of observations about teams that were frequently meeting in Fedora. As I observed for a week about what teams were active or inactive, I made bookmarks to their meeting pages to revisit later on.

After comparing the teams that were present in møte to the meetings I observed in a week, I began adding aliases and mappings for the teams that were lacking in the name_mappings.json file. I also added a new category to the category_mappings.json file for the Fedora Community Operations team (where I spend a lot of my own time in Fedora).

The Fedora teams I helped identify and add to møte are as follows.

• CommOps
• EMEA (Europe, Middle East, Africa) Ambassadors
• Fedora Council (formerly known as Fedora Board)
• LATAM (Latin America) Ambassadors
• Fedora Magazine editorial board meetings

During my time of my bugfix, I made 13 commits to the repository. I’m not planning to stop there, either – there’s a few more teams I hope to try adding to møte in the near future, like the Fedora Workstation, Server, and Cloud special interest groups.

Also in the process of contributing, I discovered a handful of problems and reported them in the issue tracker (see: #75 and #83).

You can see my bugfix changes live in møte here! Thanks Chaoyi for helping mentor me along in contributing.

FOSSProfiles 🔗

140 char maximum 🔗

My first step with this bugfix was in troubleshooting the stacktrace I was given running the program in Python2. The stacktrace confirmed the error was that a profile biography was over 140 characters long, and I began sorting through all existing profiles to find any that were over the limit. After a little bit of searching, I found that wilfriedE.yaml was the one over the 140 character limit. This was an easy correction and after making changes, I was able to run the program with Python2.

Python3 support 🔗

Lastly, I wanted to add support for Python3 to this program so it would run in a modern and current workstation. This in particular required a lot of research for me to look into as I had never programmed in Python before.

My first problem with running the script in Python3 was an ImportError for a specific module, ifilter. After searching for an answer, I found an easy fix. It was supported by default in Python3! To fix this error was as simple as removing the line.

Secondly, after fixing the ImportError, I found a certain string was required to be encoded as UTF-8 before Python3 was able to handle it. After looking up the encode() method and figuring out how it worked, I simply encoded the string to UTF-8. That wasn’t so bad…

Step 3: Post-bugfix analysis 🔗

For me, the most fun part was the optional part of the assignment to the end. As part of the assignment, we could add our projects to OpenHub. OpenHub is an aggregator of open source projects that makes it easy to discover, track, and compare open source projects across the web.

I added a project page for møte and FOSSProfiles and claimed my contributions as a contributor.

I’m also playing around with other projects in OpenHub… you can find my profile here.

“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!

Today, the Fedora Elections for December 2015 officially began at 00:00 UTC. The voting period will be open from now until December 14th, 2015, at 23:59 UTC. Fedora is a community-driven project, and voting is one of the greatest ways you can have an impact in how Fedora runs, either as a user or a contributor. Your vote is powerful, and you should be informed before casting your vote!

Fedora Elections for FAmSCo 🔗

This Election is especially interesting because of the open seats for the Fedora Ambassador Steering Committee (FAmSCo). The plan is to phase out FAmSCo in order of the Fedora Outreach Steering Committee (FOSCo). However, this plan is still one that is in progress and there are many details being hammered out. Because of the plans to transition, the current board sitting in the Fedora Ambassador Steering Committee have been elected for the past year, something that normally has new elections every six months. In the interim period while FOSCo is expanded, FAmSCo is running an Election to bring new, fresh blood into the board.

Inform yourself 🔗

There are a lot of things happening across Fedora right now, so it is important that you inform yourself for the Fedora Elections. I have had the unique perspective of reading, reviewing, and proofreading many of the candidate interviews. As a result, I have had the advantage of reading every candidate’s platform and what their vision for the Project is. It’s important that you vote with an informed opinion about whose platforms you agree with most. There are a lot of important topics on the table for this Election cycle, and an informed vote is the best way to make a vote. Please take the time to read the candidate interviews!

Fedora Elections, December 2015 Interviews 🔗

• Fedora Ambassador Steering Committee interviews
• Fedora Engineering Steering Committee interviews
• Fedora Council interviews

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 popular Voice Over IP (VoIP) program, Mumble, is being repackaged again for Fedora 22 and 23. Fedora contributor fedpop unretired the package from the Fedora Package Database and is working on getting it added to the stable repositories.

Mumble is available for testing for Fedora 22 and 23 users. Once enough positive feedback is received, it will be added back to the stable repositories for all users. Testers are welcome, especially for Fedora 22!

How to test Mumble 🔗

To test, open a command line and run the following command.

$ sudo dnf install mumble --enablerepo=updates-testing

Confirm the installation and the application will appear on your system. Give it a run and make sure everything works as expected! If it all checks out, leave feedback for the build in Bodhi so the package. This helps move it closer to being packaged for the stable repositories (links are below).

For help enabling the testing repository, see the QA Testing wiki article.

Why I love Mumble 🔗

Mumble is a package I originally installed when I first began using Fedora in Fedora 20. It is one of the few major VoIP clients that can be classified as “FOSS” (Free and Open Source) and is available on multiple platforms. It’s fairly simple to get a server (Murmur) up and running, and it’s a great way for communicating over voice with friends, family, or communities. I used to use it often when I was active in various Minecraft server communities, and for a short time, I used it for my own Minecraft community as well.

When it originally disappeared in Fedora 21, I was disappointed since Mumble is an important piece of software that I think is important in any modern Linux distribution. Finally, Fedora users will once again be able to seamlessly install it without having to manually compile the software.

Big hat tip to fedpop for repackaging this awesome piece of software! This also seems to be his first experience as a Fedora packager, so a big welcome goes out to him as well. I can’t wait to start recommending Mumble again for Fedora users.

Find it in Bodhi 🔗

Fedora 22

Fedora 23

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

CommOps in Retrospect 🔗

Over the past few months, I have worked closely with the Fedora Community Operations (CommOps) team on a variety of tasks and goals as part of our mission to improve community infrastructure within the Fedora Project. This is certainly a broad and demanding goal, but broken into smaller duties, it is much easier to take on and slowly work towards. Several members of the team specialize in different areas, such as Ralph and Bee who work more on numerical-oriented tasks (i.e. metrics and improving software evaluating our community), Remy who (more or less) does it all, and then me focusing on improving areas of communication and messaging across the Project. Everything is still in early stages of progress, but it’s exciting and moving quickly, and I hope to share a bit more about what I’ve been working on.

Community Blog 🔗

As of now, this is where most of my time is going in terms of working on the CommOps team. Just last week, we officially unveiled the Community Blog (affectionately nicknamed the “CommBlog”) with the rest of the Project via an article on the Fedora Magazine. The CommBlog is an ongoing effort to centralize Fedora news in a single, specific place. The problem the CommBlog intends to resolve is that of disparity in where “Fedora stuff” gets shared. With a project as large as Fedora, there are all kinds of things happening every day in the different subgroups and teams, so it’s hard for any person to know everything going on all at once.

My role in the Community Blog is primarily as a content contributor and partly as an administrator of the WordPress panel. The most recent pieces I contributed to the CommBlog were things like an interview with Python maintainer Matej Stuchlik about the Python 3 Fedora Activity Day, news about the Fedora Magazine breaking view records, an announcement about the Fedora Developer Portal, and the introductory article to the CommBlog. I also helped establish basic guidelines for contributors looking into writing an article. Nonetheless, this is fully a group effort between members of the CommOps team, and these are created with collaboration and guidance of others in the team.

5tFTW 🔗

In addition to the happenings at the Community Blog, another goal of the CommOps team is to help bring more “heat and light” to the different areas of the Project, which then makes it easier to cherry-pick any number of news for other purposes. Already in existence is Fedora Project Leader Matthew Miller’s (mattdm) series called “5 Things in Fedora This Week”, otherwise known as “5tFTW”. The CommOps team aims to make it easier for Matt to find the hot topics to write about. In the long run, the Community Blog will help carry this out, but for now, we are helping compile lists and summaries of topics to cover for each week’s “hot topic” list.

When I’m trying to find news about events in the Fedora Community, I will also have 5tFTW in the back of my mind, since they have intersecting interests. I helped compile the list of topics for 2015 11 06 and I am in progress of finding more topics along with the rest of the team. This upcoming week, some of the things we have on the list so far are the migration of the Fedora mailing lists to HyperKitty, announcing the Fedora Elections cycle, the Fedora Python 3 Activity Day, and Wayland being the default in Rawhide.

Other things 🔗

In addition to the tasks I’ve been working on with the CommOps group, I have also been continuing my work with the Fedora Magazine as part of the Marketing subgroup. These past few weeks were active publication weeks, including my “Upgrading from Fedora 22 to Fedora 23” article (viewed over 25,000 times as of present day) and “Never Leave IRC Again with ZNC”, a beginner’s article focused on explaining how to get started with ZNC (viewed over 5,000 times as of present day).

I’m also in the process of becoming a Fedora Ambassador, and I am now in the review period of my mentorship. This has been a personal goal of mine for close to two years, and I’m happy to finally be moving forward with this to (officially) become a representative of freedom and choice through Fedora.

I’m going to try to get in a better habit of quick, short blog updates to help document my progress and work in the FOSS community. And maybe I might even write about my time at my university at some time… hmmmm…

I am a user of open source software. My earliest experiences with open source software was with the Minecraft server software Bukkit as a kid, when I was attempting to make a cool game server for friends. I started using Fedora in December 2013 with my first laptop, ending a lifetime of using Apple devices. I like to believe that I am familiar and experienced with open source software as an everyday user.

Open Source Contributor 🔗

I am a contributor of open source software. Despite using it so often, I am still new to contributing and I am learning new things every day about free and open-source software communities. These past three months have passed by seemingly faster than light. And yet, despite being new as a contributor, I am passionate about what I am doing and what others around me are doing. I believe that open source goes beyond just software - it is a culture, a way of thinking, maybe even a way of life. There are reasons why I love open source as much as I do, and while it was challenging, I narrowed it down to three of my favorite things.

Freedom 🔗

Since I started using free and open source software, I gradually became educated about what software freedom is and what makes it so important. An open source project is one thing on its own. But is it free? And this not the traditional meaning of free, as in “no cost”. But does it protect your freedom? Do you control the software or does it control you?

This is something that is probably one of the most discussed parts of Free and Open Source Software (FOSS), yet it is without a doubt one of the most important. At the end of the day, the people who work behind major FOSS projects such as Linux distributions (like Fedora), major software programs and languages, and even Minecraft server software share a core set of beliefs: the software you and I use needs to place value in freedom to manipulate and distribute as we see fit. It is within our right to do with our software as we wish. This is something that I sincerely believe will help bring the world to a better place.

Seeing as this is one of the most discussed elements of FOSS, I will not spend as much time on this. But it is important to realize that it is part of the foundation that everything else builds from.

Fun 🔗

There’s hardly a better way to put it. Working in open source communities is fun! Whether you’re the programmer or the writer, the designer or the maintainer, it’s incredibly engaging and rewarding to take part in an open source community that understands the value in community.

For developers, it’s a greatly satisfying feeling to write software and see it being used across several devices or systems, and then to get feedback about your software from users who think what you worked on is awesome. Does that mean all the feedback is always fun? No, but I believe the overall positive experiences always outweigh the few negative cases. As a FOSS developer, you can readily see your software’s impact on the world.

There is more that goes on for open source communities than just writing code too, so even if you’re someone like me who loves to write, there are ample opportunities to help in a fun and meaningful way. The articles I publish on the Fedora Magazine and Fedora Community Blog are enjoyable for me to write, and every thankful comment received makes it just the more worth it. For instance, I recently published an article about using an IRC bouncer software called ZNC and shared it across multiple channels of communication. Shortly after doing so, a user messaged me and asked questions about using the software I described in the article, and shortly after our discussion, he successfully tested and started using ZNC for his own IRC communication. How awesome is that?! Even just by contributing writing, I can readily see my impact on users.

At the end of the day, many of the people involved with FOSS do it out of their own time and effort. Most people aren’t paid or have the convenience of having their jobs allow them to work on their own projects. So why do it if there’s “no benefit” to doing it? To continue the previous point, it’s because software freedom is important, but it’s also because it’s fun. Usually, it’s not about the money or personal fame… it’s about making a difference doing the things that make us happy. Whether that is software development, writing about the software being developed, making awesome graphics for the community around the software, or any other aspect, we do it because we like doing it. There’s not much else of a way to put it.

Community 🔗

Finally, the third thing I love about free and open source software is community. This is my favorite thing of all, truthfully. In my experiences working and interacting with members of open source communities, I am always met with welcoming and accepting attitudes and people who want me to succeed in contributing. I have discovered this especially in the Fedora Project community, more than any other project I’ve contributed to.

When I first introduced myself to the Fedora Marketing mailing list as an interested contributor to the Fedora Magazine, I was warmly received and provided with the resources I needed to set up my toolbox for success. Quickly after drafting my first articles, the Magazine team happily reviewed and revised my work and set it on track for publication. Seeing my first article go out on the Magazine was extremely rewarding, and I felt awesome that I had helped write something that readers would find interesting and be able to learn something new.

Another experience I had this past week was entirely unexpected. Fedora Community Lead Remy DeCausemaker recently published an article on Fedora Magazine about Software Freedom Day at RIT, an event on my university campus that I attended and participated in. Part of the article talked about some of the tasks I worked on and included a short interview with me. Later that evening, the same day the article went out, I received an unexpected message from a Fedora contributor in Panama who had happened to read the article. In summary, she left me some encouraging words about what I did at Software Freedom Day and said it was good to have people like me in the project. It caught me off-guard and I wasn’t expecting that - and from someone who I had never talked with before! This only reaffirmed the thoughts I have had for a long time about FOSS communities, in particular Fedora. The community behind these projects is incredible and the friendships that are founded here make everything all the more worth it.

It’s hard to see a future for me now without open source being an integral part along the way.

Special Thanks 🔗

Special thanks to Michael, Cindy, Jordan, Remy, Paul, Ryan, Patrick, and Kiara for helping make my experiences in open source as amazing as it has been - I am looking forward to more experiences to come.

The Negatives 🔗

The desktop is broken 🔗

Without a moment’s delay, the bold statement was offered by Levente: as of right now, the Linux desktop is broken.

56.26% of the desktop market share is Windows 7. 18.26% is Windows XP, 13.52% is Windows 8, 5.26% is OS X, 1.34% is Linux. Of the Linux distros out there, Mint, Ubuntu, Debian, OpenSUSE, and Fedora are the top five. Yet this doesn’t seem that impressive considering how small of a position Linux as a whole takes in the desktop realm.

In terms of mobile-oriented operating systems, it’s almost spectacularly reverse: 84.04% Android, 11.07% iOS, 2.09% Windows Phone, 2.80% is others. As many already know, Android is based off of the Linux kernel. So it’s clear that we’re doing something right with the mobile market. What can we take away from this and apply to the universe of the desktop?

Answer: We must be doing something wrong on the desktop!

The masses 🔗

Choice 🔗

One reason why Linux doesn’t appeal to the masses is the plethora of desktop environments; or in other words, choice! There are several different environments which provide different user interfaces… and they’re all different. An end user can get lost in this as they’re not going to care about how it runs under the hood – they just want it to be easy to use and have it be the same every time they use it. Android has about the same UI and  looks every year and every update. On the other hand, the controversial transition from GNOME 2 to GNOME 3 completed changed the UI of the Linux desktop, subsequently not offering much consistency for users who avoid having to “learn something new”.

In the big picture, they’re all different. For developers and daily Linux users, this is good and awesome because they like choice and decision! But for the regular end user, this isn’t good because they want consistency in how they use their computer. For the masses, the difference is bad.

Perhaps the answer is to never upgrade the computer, but that’s bad from a security standpoint. Not to mention, it’s certainly not very “cool” either. More often than that, having the latest and greatest in software is in the interest of users.

Configuration 🔗

The next big complaint is configuration. There’s countless configuration applications, all with different settings, and then sometimes they all don’t share the same settings. Again, we see the sad but true pattern of no consistency. Compare between KDE and MATE: you might configure something like printers in one desktop environment, but then you move to a different environment and they’re all lost to the oblivion. You have to go through a painful workaround to reconfigure the same thing twice. This is probably why people love OS X computers because they promise to “just work”, which they usually deliver on, at the expense of losing the freedom that a Linux distribution would offer.

Distributions 🔗

The next complaint, and possibly most controversial, is distributions themselves… we all love choice and variety, but for end users, with so many different distributions, it’s another mess. Take installing Firefox. If you’re running Fedora and want to install Firefox, but you found a .deb file, you’re not going to have success because it’s a Debian package, not an RPM package. If you’re a computer newbie, you’re likely not going to know (or care, for that matter) about the distribution that you’re running. It’ll just end in frustration and confusion for a non-technical end user. They don’t want to figure out why it doesn’t work or how to fix it – they just want it to work.

Examples of the above being yum install on Ubuntu, development packages in Fedora repositories, and… how do I set up my printers? These are reasons why people will switch from Linux back to Windows or OS X.

“The efforts to standardize on a kernel and a set of core libraries were undermined by the Distro of the Day that held the position of power.” - Miguel de Icaza

Graphics 🔗

Another frustrating aspect of Linux is that the kernel can fully support a 4096-processor supercomputer, but a laptop can have difficulties waking up from sleep.

This brings us into the next reason why the year isn’t coming soon: VGA and graphics. We miss the “it just works” moments, and sometimes the issues with graphics drivers can be more frustrating and challenging than anything near enjoyable. In the kernel, it was suggested and subsequently dismissed to support graphics via VGA, but for reasons buried in the mailing lists, it’s not in the interest of the kernel to support graphics. It’s more of the desktop developers that do this.

But part of the issue is also with hardware manufacturers. If hardware manufacturers made their software utilities for Linux, it would allow for more powerful troubleshooting and debugging.

Reverse Compatibility 🔗

Then we can look at reverse compatibility on the Linux desktop. Before looking at Linux, it’s important to consider the number one adversary, Windows. Take  Win32k… Windows 98 apps can still run on Windows 8. That’s 19 years of reverse compatibility. As much as we all love to hate on Microsoft, that’s pretty incredible. Take GTK and Qt – neither are backwards compatible with older versions.

This goes hand in hand with the next point, rate of change. Windows updates its major version every two to three years, sometimes longer. There’s usually no big changes in the interim period between major releases. You could be on XP and upgrade service packs and you won’t notice anything significant. On the other hand, Linux distributions release far more frequently and sometimes introduce major changes, such as GNOME 2 to GNOME 3.

So these are the negatives of the Linux desktop. But! There are positives…

The Positives 🔗

Gaming 🔗

Probably didn’t expect to see this as a positive, did you? The gaming side of Linux is making leaps and bounds, and it’s worth noting. Perhaps the most notable example is SteamOS, which is completely based off of Linux. CryTek Engine, Unreal Engine 4.1, all of these major game design engines are turning to Linux and are encouraging more support for Linux platforms. This is a major pull factor for users.

For gaming hardware, there are also positives. Nvidia is now compatible with bumblebee (which developers more familiar with this are praising), and there are many improvements to GPU drivers, such as performance, stability, and so much more. Some of the things that make us love Linux as a desktop.

When is our year? 🔗

So… when is our year?! It’s going to come… one day. Just not soon. There’s too many issues in terms of appealing to the masses and making the Linux experience easier for end users.

Some people believe that the time has come and gone for the desktop, but the mobile market shines a light of a positive future for us. Is Android a better idea of the future than a Linux desktop environment? Only time will tell.

Sources 🔗

This talk was given by Levente Kurusa. Levente is a Linux enthusiast focusing mostly on kernel development. He is also a frequent speaker at various Linux events, where he talks about the various way an individual can join the kernel development community. He participated in an annual open source competition called Google Code-In, where he was a finalist for KDE and became a KDE developer in the process. He currently works for Red Hat on the Virtualization Team.

The majority of the content of this article was taken by my own notes I took during his talk – if you want a less pretty version, you can still read my Pastebin summary.

Flock to Fedora 🔗

My first major interaction and experience with the Fedora community was at Flock 2015, the annual contributor’s conference where people from around the world come together to work on the project. I had been looking forward to this conference for months, and after finding out that it would be hosted in the same city I would be moved to for college in a few months, I knew I had no choice but to go. I moved up early just to make sure I could attend!

When I arrived, I was almost overwhelmed by the incredible people and companies that were here. I went to all kinds of workshops and sessions, such as “The State of Fedora”, a talk led by the Fedora Project Leader, improving Fedora’s visibility in schools, an overview of gaming on Fedora over the years, “Marketing is not a spectator sport”, and so much more. However, the thing that really stuck out to me was how this community of people weren’t just here to just work on software, or just work on internal projects. The people there were a community of individuals all passionate and dedicated to working on a project that makes an impact on the real, everyday world. And that’s something beautiful in itself. To say the least, I was hooked. Even though I was a complete and total newcomer, I felt welcomed and most definitely a part of the community.

Software Freedom Day 🔗

Not too long after Flock, on the weekend of September 19th to the 20th, my university, the Rochester Institute of Technology, hosted a Software Freedom Day event on campus. I knew this was something that interested me and I made plans to show up to the hackathon.

Fedora Community Lead Remy DeCausemaker was there representing Fedora by launching a Fedora Badge-athon event, which was a contest among participants to work towards gaining the most badges. I knew it might be a little hard for me since I had all of the “really easy” ones out of the way, like making an account, changing your password, and so on, so I decided I would put forth the effort into really earning some of the badges!

I started with checking out the Fedora Package Tagger, which is a fun organizational tool that anyone can use to contribute to the project by sorting through tags for the various packages in Fedora, and either upvoting or downvoting the existing ones or adding new, relevant ones. I spent a good amount of time doing this, and I earned a good number of badges for both voting on tags and adding my own to the packages of Fedora.

Afterwards, I set to work on helping with wiki gardening tasks for the Fedora Wiki, as where we left with our wiki workshop from Flock. I sorted through a large number of outdated pages and attempted to update them with current information or I categorized them as old pages to be deleted or reviewed in the future. I also helped categorize the poor orphan pages without a category to call home.

Finally, the last task I did was the beginning of a longer-term commitment: I sent out an email to the Fedora Marketing mailing list inquiring to become an author for the Fedora Magazine.

Marketing and the Magazine 🔗

Most recently, I have been working closely with the Marketing team as a contributor to the Magazine. I have already published a couple of articles, with my best pieces so far being Using Spigot to Run a Minecraft Server and In Summary: Flock to Fedora 2015. I already have a few more planned in the near future, including articles featuring using OpenVPN to protect your privacy and ZNC to make your IRC experience way more convenient. Watch for them in the near future!

In summary… 🔗

My adventures into Fedora and the magic of free and open-source are just beginning, and I eagerly anticipate the upcoming future as I become more involved and make my impact in the Fedora community!