about adopting a theme 🔗

Recently, Joseph Gayoso from the Fedora Marketing Team proposed the idea of the Fedora Marketing Team adopting a theme for 2024. Together with the below video explainer, I felt his explanation was also convincing for the Team.

YouTube: Your Theme. CGP Grey. Premiered 26 January 2020.

But it was not only good advice for the team. I tend to avoid resolutions for as a new year tradition. But I recognize change as something that can happen independent from January 1st. That is where the role of an annual theme comes into focus. It offers a flexible framework with wide guideposts. I can choose how to measure my success. Working from a theme provides me a clear way to measure incremental progress while also enabling me to feel tangible accomplishments along the journey.

So, if I could commit to one theme, what would it would be? It would have to be something that I believe in.

storytelling is my theme 🔗

I admire storytelling since a long time. I admire its flexibility to be simple yet powerful. It is flexible because there are multiple forms of storytelling. Storytelling can be defined in a literal sense and a metaphorical sense.

In a literal sense, storytelling is the telling of stories. Telling could mean written, spoken, or shown. Stories could mean almost any expression of human experience that fits into a timeline with a plot. Therefore, storytelling is creatively sharing a human experience with others.

In the metaphorical sense, storytelling connects communities. Stories represent several aspects of life that happen around humans. The most powerful stories compel hearts and minds to change. Someone who tells stories that change the hearts and minds of others is an influential person. In this metaphorical sense, storytelling becomes a skill that is honed and practiced.

building my storytelling habit back 🔗

What does this have to do with my theme? I am adopting storytelling as my theme because I admire the habits of good storytellers. I want to hone my own ability for both personal and professional contexts. My ability is weakened from lack of practice; it is like a muscle that is sore from not being used in a while. By adopting storytelling as my 2024 theme, it empowers me to write more often in my authentic voice. Lately, recent posts on my blog undergo a rigorous self-editing before I publish them. But in adapting with a theme of storytelling, I commit to being fine with not maintaining maximum production-value on everything I publish. I commit to being authentic over rigorous; honest yet open. I commit to the pursuit of documenting my own human history, or “the world as I see it.”

So, 2023 was a year of big changes for me personally and professionally. I have plenty of things to start writing about. To improve, I need to publish more and be ready to make some mistakes. That’s how I learn, after all.

So with that all in mind, more blog posts seems like a good starting point. To make this plan actionable, it needs more specific steps. My goal for right now is to make the commitment within myself, and follow it up with action in 2024.

Happy New Year, reader.

Original photo by S O C I A L . C U T on Unsplash. Modified by Justin Wheeler. CC BY-SA 4.0.

While I was pondering this reflection, my employer announced layoffs a couple weeks ago. While there is a lot that could be said about that, what I will say is that a certain root was pulled; the foundation of trust built between leadership and employee was shaken. Only further action and time will show the full impact on the company and my remaining colleagues. Nonetheless, a very recent negative experience with regard to trust also expanded my perspective of how trust is defined and what its role is in a community.

Brené Brown on trust 🔗

Later, I came across a sound bite of an interview with Brené Brown about trust (and more). Toward the end of the interview, she talks about her book, Braving the Wilderness (which I haven’t read, but seems interesting). She explained what the wilderness is and a tool that we can keep with us (“BRAVING”) to stay grounded in ourselves and also what trust means.

She also had a powerful definition of belonging, which put forward the idea that belonging is internal to ourselves and even is a spiritual practice; belonging is not defined externally or given to and taken from us by others.

Below is my summary of “BRAVING” and the wilderness, together with notes and thoughts about how community leaders can act honestly and authentically, both when times are good and when times are hard.

Trust: Remember “BRAVING” 🔗

There are seven elements to building, developing, and measuring trust. Each of these seven elements are a resource for being honest, authentic, and genuine in both easy and hard times. You can remember these seven elements as an acronym: “BRAVING”.

B: Boundaries 🔗

You set boundaries. When you don’t know what they are, you ask. You are clear about what is okay and what is not.

R: Reliability 🔗

You do what you say and you say what you do. The hard thing is that you are not hustling for worthiness, so you are not completely over committing and not delivering.

A: Accountability 🔗

You don’t back channel and blame. You hold people accountable in a straightforward way.

V: “Vault” 🔗

You do not use stories that are not yours as social currency. You keep them in “the vault.” Using others’ stories as a bid for connection causes others to trust you less. This is the other side of confidentiality.

I: Integrity 🔗

You choose courage over comfort and practice your values. You choose what is right over what is fun, fast, and easy. Your accomplishments stand out when you operate from a place of discomfort, or outside of your comfort zone.

N: Non-judgment 🔗

You can ask for help without feeling judged. I can ask for help without judging myself.

G: Generosity 🔗

When something happens, you assume positive intent. Give someone a chance, or the benefit of the doubt, before launching into anger.

Braving the wilderness 🔗

What is the wilderness? It is those times when we stand alone, the times when we go out on a limb, the times we walk away from what we know in our ideological bunkers and beliefs.

“BRAVING” is a tool to help us manage the wilderness. There will be times when standing alone feels too hard, too scary, and we’ll doubt our ability to make our way through the uncertainty. Someone, somewhere, will say, “Don’t do it. You don’t have what it takes to survive the wilderness.” This is when you reach deep into your wild heart and remind yourself, “I am the wilderness.”

Photo by Artem Sapegin on Unsplash. Modified by Justin Wheeler.

May I continue to hone this practice into an art. 🙏🏻 This is my meditation for the day!

Survey says: What? 🔗

At some point, after we opened the survey, a question emerged about how to handle an unruly response. In the ongoing responses, our data manager noticed one response that was objectively harmful. The person was strongly against the D.E.I. initiative that organized the survey. The response was written in a hostile tone, made insulting and derogatory comments about groups of people, and was entirely opposed to the project spending any time and resources on diversity, equity, and inclusion. The question asked to our group was whether we would include this response in the published data, or whether we would omit it.

There were two perspectives. Some elected to remove this response from the final report and any published data. Others felt it was important to wait and see if this response would become a pattern as we ran the survey. I found myself in the second group that felt it was important to wait and see first. I want to unpack this rationale, both for future me and perhaps someone else reading.

On discarding the survey response 🔗

There were good points about removing the harmful response.

Firstly, the response used harmful language and was likely triggering. This particular response included angry rhetoric that was reflective, to a degree, of the social and political “climate” of our world today. Including the response in our final reporting could also be giving it a platform, which would arguably be a harmful act. It would validate that input as acceptable input. Our group was not in disagreement that the response was harmful and not behavior the community should tolerate.

Second, the response did not provide actionable insight or useful asks to the project and community. It was written in an aggressive, angry tone towards the reader and did not offer workable suggestions other than ending and divesting from all D.E.I. work immediately. Given this was not an acceptable option, there wasn’t much there for us to learn or understand about CHAOSS from this individual response. So, why include or save this response?

There is an option to ignore feedback by intentionally discarding it, but what if the individual feedback represents a larger trend?

What is community culture? 🔗

It is important to be aware of threats to community culture. What is community culture? My improvised definition is any organizational culture oriented towards the care, well-being, and thriving of others (including the self) within a single, shared community environment. Regardless of other values and goals in a project, the shared culture of the project can either lean towards a collective, communal-oriented approach or an independent, individual-oriented approach. The communal approach that prioritizes the well-being of all instead of a privileged view could also be considered as community culture. Many traditional “Open” projects skew toward a strong community culture.

On monitoring survey responses for a pattern 🔗

Coming back to the survey response, what if omitting the data leaves holes in the story of your community? If there is not just one, but several of these kinds of responses, what comments does that make about the community culture? Is there already a strong community culture, or is there resistance and challenges to building a more cooperative, caring environment? There is real work to do at both ends of the spectrum, but what that work might look like depends on which side you are on.

I posit that omitting the “unhappy” or harmful responses can create a dangerous blind spot to toxicity within a community culture. When it comes to direct, interpersonal interactions with others (e.g. meetings, emails, chats, etc.), stewards of the community culture need to take direct action against visible challenges and threats to the community culture. If someone starts swearing out at someone in a meeting, that is a hard-to-miss action. It is visible, and anyone could observe it or even record it.

In anonymous surveys, you might find a more subtle layer of the community culture than what is shown by the actions of a small few. There can be greater trust that someone’s comments will not be tied back to their identity, so some responders may feel emboldened with their words and true opinions.

Don’t discard a blind spot. 🔗

The point of this is that especially in larger communities, it is worth noting negative and harmful responses and not totally ignoring them. Communities that organize in more decentralized ways will always have supporters, users, and contributors from both the core and the periphery. The core project membership may not interact or engage often with the periphery often, so there can be a blind spot to parts of the project that identify with the community but are a few degrees removed from the inner ring of the project community.

Noting whether something is indicative of a larger pattern is important. If your community has a ton of jerks, you need to know that your community is full of jerks so that you don’t waste time persuading people otherwise, when the lived experience is very different.

In the original conversation with the CHAOSS Project team, this data scrubbing question emerged in the process of running the survey instead of after the data collection concluded. The survey later closed and our data manager confirmed that the flagged response from earlier was the only one of its kind. As a group, we then felt more confident in discarding that one outlier as an anomaly since the survey was open to the general public.

Feature photo by JESHOOTS.COM on Unsplash. Modified by Justin Wheeler.

If you are missing the memories, you can still find a good part of the forums archived via the Internet Archive’s Wayback Machine. Click here to navigate to the last snapshot of the official forums. You can also find downloads of the survival and creative Minecraft worlds below:

• Creative world: 2015 Nov. 2 backup (~29MB)

• Survival world: 2018 Sept. 22 backup (~43.6GB)

• Survival world: 2018 Dec. 3 backup (~44.1GB)

History of the CrystalCraftMC forums 🔗

Since December 2013, I maintained the CrystalCraftMC forums on my own infrastructure and dime. Even after I passed the torch in April 2018, I continued to maintain and manage the forums. When the game server finally closed in December 2018, I continued to keep the forums alive as a novelty for past players. For me, whenever I felt nostalgic, the forums always gave me a place to remember good friends and memories from that era of my life.

If you are one of the few original folks who kept up with CrystalCraftMC in its lifetime, you may remember we used a different forum at one point, hosted by Enjin. Those forums are (miraculously) still alive, and you can still find them! Visit old.crystalcraftmc.com to get a nostalgia trip on the oldest memories of our Minecraft community.

Why the forums closed 🔗

The forum software behind crystalcraftmc.com was called XenForo. We used the 1.x versions of XenForo. XenForo was a great fit for us when CrystalCraftMC was in full swing, but the forums fell behind on updates. The forums eventually stopped receiving maintenance and security updates for XenForo 1.x when XenForo 2.0.0 was released. Since I never renewed our license and didn’t have time to complete the complicated upgrade, the CrystalCraftMC forums remained on XenForo 1.x.

This month, I took on a project to reduce the costs of my personal infrastructure. The total cost to run the CrystalCraftMC forums was >$200 USD every month. I hoped to reduce the cost to less than $50 USD every month. My goal was to migrate the database for the forums to a competitive and more affordable hosting service. However, during the migration, I discovered that XenForo 1.x did not support newer versions of the MySQL database software. I would need to continue paying my bill for a hosting service that supported the legacy version of the database used by the CrystalCraftMC forums.

After careful consideration, I decided ten years was a good run and it was time to finally close things down. It was not the outcome I wanted, but it was what had to be done. Nevertheless, I took a final “snapshot” of the forums and database. I retained a final copy, and perhaps one day in the future, I may choose to put a read-only copy online again. But for now, the forums will remain offline until further notice.

(This also doesn’t even note the hundreds of spam, scam, and porn emails I received every day because of the contact form on the website not having a captcha form to stop spambots!)

What now for CrystalCraftMC? 🔗

I will continue to pay for the domain names of crystalcraftmc.com and ccmc.pw. Both domains will now redirect to this blog post, which might be how you ended up here. But otherwise, there are no more public archives of CrystalCraftMC other than our memories, YouTube “Let’s Plays” and Echophox video series, and the super-old forums. This is the end of the road for CrystalCraftMC.

To all the players and the CrystalCraftMC community, you will always have a special place in my heart. CrystalCraftMC was one of these incredible things that happened to me in my life, especially when so many things in my life were honestly upside-down. I wish you all the best and hope you all also have fond memories of building spawn points, running drop parties, building amazing forts and bases (while hoping they don’t get raided), and hanging out with other folks who ended up becoming close friends.

Long live CrystalCraftMC.

Photo by Johannes Plenio on Unsplash. Modified by Justin Wheeler.

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.

Accommodations move us closer to equality but not equity. The presence of accommodations implies a belief in an “us” and a “them”. One group benefits from default inclusion, while another group either raises a collective voice, or is de-facto excluded. Instead of designing our world for others different than ourselves, we must design our world together. It is a quicker way to achieve a more just world.

The “abled” community needs to challenge our perspectives and do our share of the learning required to see things from another perspective.

An example I saw from Twitter that made an impression on me was how someone explained the idea of combinations and permutations of the five human senses: sight, hearing, smell, taste, and touch. The commonly-held belief is that lacking one (or more) of these senses leaves you deprived. Without one of these senses, your potential is limited and you deserve to be pitied.

Multi-sensing > accommodations 🔗

So, what does it mean to be multi-sensing? Most of us see our five senses (sight, hearing, smell, taste, touch) as a fixed state of sensory stability. These senses and basic mental stability are socially-assumed as always present. They define how we individually experience life.

Often those lacking one or more of these senses are seen as deprived. They are perceived as missing something or to have lost something they can never fully regain. The absence of a human sense comes with the added psychological burden of living in a world where you are often the afterthought, the “new use case”, the countless trials of countless beta versions of any kind of software that might help overcome the disadvantage of “missing” a sense or mental disability.

I suggest an alternative way to design for accessibility and inclusivity. A personal deviation is not written off as “missing” something, but instead as a new combination of senses gained. Designers should assume an expected and guaranteed variable of this new combination. Accessible design must be a first-class citizen in early project management planning.

To put it another way, observe the presence and lack of senses among us as a matrix of combinations, instead of large swathes of characteristics assumed to always be present. We unlock the best of our design knowledge to think in the pursuit of access to the greatest many instead of “what ticks off the box”.

Before, we saw an accommodation as when a specific feature is added to software for someone lacking one or many senses. But we must shift from accommodations to full inclusion. Accommodations are acknowledgements of disability. It assumes a fixed state where a set of critical features to guarantee usability will always lag behind for a subset of people. True equality is seeing access for those with disabilities as equal to the design of features for those with five active senses.

Featured image photo by Matthew T Rader on Unsplash.
Modified by Justin Wheeler.

I don’t say that casually either. I have involuntarily found Open Source as my calling. Or my people. I contribute to Open Source because I love to collaborate and work together with other people. This challenges me. It humbles me in a way that I know I can always learn something new from someone else. For this, Open Source and Free Software have enriched my life. They have also given me, again involuntarily, an odd but productive way of coping with my own mental health issues, anxiety, and depression.

So how do I make sense of the emotions and feelings I have now? How do I untangle this complicated web of events and reactions by other people? To ignore it doesn’t seem possible. If I remove emotion, I am left with a purely rational motive to involve myself in this contemporary issue. My work, profession, and career goals are directly affected by however this discussion goes. There is no way out for me. It’s my job, so I have to care. But if you add emotions back in, to stand still and remain idle is heartbreaking. To do nothing is to commit to defeat. Resignation. The darkness.

Yet what is there to do? The only thing Stallman ever directly gave to me in life was an email explaining elegantly how there was nothing he could do for the Minecraft GPL community fiasco. At a time when I was so personally lost as I saw a community I love tear itself apart, he stood by idly as the so-called steward of these licenses that I was just too naïve to believe in. That experience to me now is amplified in the light of the much more egregious things he is accused of.

So, the Free Software Foundation welcomes Richard Matthew Stallman back to its board. Wonderful. Congratulations Mr. Stallman. I am going to pause for a moment of sadness and hurt as I contemplate the impact of this moment on our fragile movement, which has much bigger enemies today than it has in its 40 year legacy. But then…

I will move on. Because we have to. The only way is forward.

When I was a kid, one of the most important lessons I learned was saying “thank you” when someones does something nice for you. So, a few years ago, I learned about this awesome little website called Happiness Packets. Its purpose is simple but powerful. Happiness Packets are open source thank-you cards you can send over email. You can send Happiness Packets to anyone for anything. Your message can be as short or as long as you like. You can put your name on it or keep it anonymous. The choice is yours. And now, I want to challenge you (yes, you) to the 2020 #HappinessPacketChallenge!

What are Happiness Packets? 🔗

Upstream describes it best. This comes straight from the Happiness Packets website:

People are generally much more loved than they think they are. Especially when things don’t go according to plan, other people almost never think as harshly of you as you might think of yourself. It’s easy for us to complain when bad things happen, and yet we’re often fairly silent when things are good. Open-source communities are no different, especially when our main communication channels are textual and virtual.

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. With Open-Source Happiness Packets, we’re trying to spread that feeling.

How does it work?

Openly expressing appreciation, gratitude, or happiness to other people can be difficult. This is especially true when you don’t know them very well. Many of us come from cultures in which people are not open by default about such feelings, and naturally feel uncomfortable or even creepy to share them.

Open-Source Happiness Packets is a very simple platform to anonymously reach out to the people that you appreciate or to whom you are thankful in your open-source community. Your message can be sent anonymously if you feel uncomfortable to share your name with the recipient. Of course, we encourage you to share your name, but it’s completely optional!

What are Open-Source Happiness Packets?

You can learn more about the Happiness Packets Challenge by browsing through the Twitter hashtag.

Take the challenge! 🔗

So, what is the #HappinessPacketChallenge? I challenge you to do the following: write one Happiness Packet a day, every day, for one week starting Monday, 27 April and ending Sunday, 3 May. At a minimum, this is seven times where you say “thank you” to someone else. Of course, nothing is stopping you from sending more if you want!

Maybe you are overwhelmed by the negativity on social media or the news channel. Especially today, when everyone is talking about one single thing: COVID-19. Whatever the platform is, the negativity can eat at you. For one week, this is your opportunity to choose something different. For all of the good things and people in your life, spend a few minutes of each day this week to make someone’s day. It seems simple—and it is! But the power you have to spread the positivity is a big power. So this is the challenge you have: to commit yourself to spreading your little packet of happiness every day for one week.

“But, I don’t know what to say…” 🔗

Having a hard time coming up with words or not sure who to thank? No worries. Your message can be as short or as long as you like. If you’re not sure who to thank, look at software you are already using. Look for names and emails of maintainers of open source software you enjoy. If you’re already contributing to open source, consider folks in your community! Thank someone who had a hand in helping you get started, or gave you a little bit of encouragement when you needed it most.

Maybe you have other ideas or reasons to thank others. (Heartbleed or Shellshock anyone?) Whatever the reason, don’t make an excuse to not say thanks! The options are limitless. If you have a lot to say, say it! If not, even a simple “thanks for all the work you do!” can go a long way to make someone’s day.

Share your Happiness Packets 🔗

The magical part of Happiness Packets is sharing happy moments with others. If you receive one, don’t be afraid to share it with the world! Tweet at @happinesspacket on Twitter. Use the #HappinessPacketChallenge hashtag. Encourage other people to send their own thanks. If you get one other person to take the challenge, that has an impact on seven more people! Imagine what would happen if all of those seven people decided to take the challenge too.

So, I hope you will join me this year in this fun tradition. Get ready from Monday, 27 April to Sunday, 3 May to send some happiness! And if you’re feeling bold, challenge someone you know directly.

Love Letter by Vectors Market from the Noun Project.

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!

Where Byfield was accurate 🔗

While I don’t agree with all of Byfield’s sentiments, he identified some key challenges that still hold truth today: a predisposition to focus on differences and not similarities, an outreach approach centered on ethics and not software, and the importance of opportunities for intersectional interaction.

Predisposition towards difference 🔗

First, Byfield notes the differing age groups of the activist communities and the tendency for viewing others by their differences first, not their similarities. He seems to attribute the tendency to view others by differences first as a characteristic of older generations; however, this is not necessarily the full truth.

As a member of the young activist community, this explanation is too simplistic of the underlying cause. There is also a political motivation by established power to sow division among the population of a nation-state. It makes community organizing more difficult and presents diversity as an issue to “solve” instead of a source of greater unity and common strength.

This is exemplified by the social media algorithms of today that reward sensational content (judged on likes, views, clicks, or other user feedback) and share it widely across a huge platform. In 2006, it was difficult to imagine the relationship social media would have in the lives of an everyday person; today, a great deal of social power is granted to those who understand how to leverage social media, either for good (e.g. social activism) or harm (e.g. deceptively persuading large parts of a nation-state’s population leading up to a national election).

The politics of division are within the fabric of our political systems; this is a challenge for modern-day activism and community organizing to overcome. In identifying this as a challenge, Byfield is correct that a differences-first approach makes it harder to share and spread the importance of FOSS in other activism circles, especially as technology becomes an increasingly relevant way of how we experience our lives and how our systems of law and justice are enforced.

Outreach on ethics, not software 🔗

Second, Byfield suggests an ethics-based approach to outreach is more effective than a software-based approach. This is also correctly noted, even if perhaps overemphasized. The jargon and language of the technology world is not accessible to the large majority of the global population. While some degree of technology literacy might be expected in some populations, much of the existing FOSS community is deeply rooted in technology. Sometimes this limited perspective is counterproductive.

This revisits the rebranding of “Free Software” as “open source” in 1997. For many subsets of the wider open source community in 2019, the default approach to open source software is merely a secondary thought for how to collaboratively work on technology. This is part of the outcome of the Open Source Initiative’s gamble in 1997 by beginning to emphasize the business sensibility and practicality of open source, and de-emphasize the social roots of Free Software (or rather, try and position itself as some sort of translator between these two “worlds”, as if they cannot be spoken of together in the same room).

As such, those who work on open source software projects are not necessarily predisposed to assume the role of an activist. Truly if Free Software is to take root outside of technology, then those who see the ethical values of Free Software need to better organize and promote the values of FOSS externally. This will contribute to the diversity of Free Software activism by helping non-technology activists add FOSS as a tool to their existing work.

Intersectional movement building is the future 🔗

Thirdly and finally, and perhaps most importantly, Byfield suggests the importance of intersectional interactions between Free Software communities and other activist communities. This is a fundamental requirement for the growth of Free Software as a social movement. Those of us in Free Software see the world around us informed by a background informed by technology; this background is emphasized in a world that is generating new, advanced technology at an unprecedented rate. However, while software and technology are important parts of the world around us, they are not the world around us. They are one part of a greater picture of fighting for a common good and welfare for all people. There are others in similar niches who have a deep understanding of their problem space and how they want to approach a challenge.

“One group may be working against child poverty, another for recycling, but the people in these organizations can almost be transferred from one to the next.”

Peter T. Brown, Free Software Foundation Executive Director (2006)

Just like a healthy garden, cross-pollination of these niches is vital to help others understand how we can help each other in accomplishing our mutual goals (this also feeds into why the politics of division explained above is so pervasive and difficult). Bringing Free Software technologists to activist communities where there is not an overwhelming Free Software background (and vice versa) is vital to building an intersectional social movement that strengthens the social impact of Free Software, not just open source.

Where Byfield didn’t go far enough 🔗

Byfield made one assumption on how activists have “their own share of insularity” and that the presence of connections between two movements does not mean they could immediately connect their existing beliefs with new ones. Fioretti’s challenge was in others understanding why they should listen to him; there was a lack of foundational knowledge of open source and technology that is normally assumed of someone who works as a software engineer.

Indeed, attention is a currency in the world of an activist. It is not enough for a FOSS advocate to expect others to listen to you on an appeal of technology. Part of the work in sharing is understanding who you are sharing with; if FOSS wants to take deeper roots in the activist community, it needs to understand the backgrounds of activist communities and be creative in how to appeal the mission of FOSS to the mission of their work. Where you can build in-roads together with others through common initiatives is the beginning of grassroots community organizing. So, while Byfield is right that there is an almost competitive nature of ideas in activism, it is not enough to write insularity off as a fixed aspect of nature. To not acknowledge this is to deny the influence of capitalist power structures in the humanitarian sector as they pertain to sustainable funding.

What are today’s challenges? 🔗

Some of today’s challenges are about inclusion and power.

Inclusion builds power 🔗

Diversity and inclusion (D&I) are important but poorly understood; not only are D&I about including people of different identities in technology, but also people with backgrounds outside of technology. FOSS stands to benefit by including more people who do not necessarily have a strong technology or engineering background. The goal is to inspire different perspectives to contribute in meaningful ways to build sustainable technology.

Instead of seeing diversity and inclusion initiatives as problematic or unneeded, D&I groups in FOSS communities stand to be the most effective people at building community and influence.

Power and governance 🔗

In the activist / humanitarian / non-profit world, there is a power struggle for sustainability as it pertains to funding. Funding models in non-profit work (usually sustained by grants, sponsors, and donors) encourage solutions that get funded, not necessarily solve problems the most effective way. Many organizations struggle with how to achieve sustainable funding without being so dependent on the expiration date of a grant’s funding.

We need more representative governance models in open source communities that reflect the interests of the communities around them, not necessarily an individual, a company, or group of companies. Building governance models that empower people within a community to make decisions and reduce the corrosive influence of money from humanitarian work.

Where do we go from here? 🔗

This blog post is an active reflection of my own thoughts and perspectives of Free Software, activism, and humanitarian work. If you are interested in pushing this conversation further, find me in Brussels, Belgium for any of the following three conferences and let’s chat further:

• 30 January 2020: Sustain Summit
• 31 January 2020: CHAOSScon
• 1-2 February 2020: FOSDEM

If you want to discuss this further, you can also drop a line in our online discussion community, fossrit.community.

Photo by Walid Berrazeg on Unsplash

The blog post I wrote comes from this place in my life. It writes in a voice I would not write in today. It also does not accurately reflect my current perspectives. However, instead of tossing it, I figured to publish it unfinished with this disclaimer would be no different.

Unmodified text: The Integral of a Community 🔗

Many times I’ve sat down to write about the same topic in this same seat. Many times I’ve been filled with the same unique feeling. It’s difficult to put into words. It’s easier to understand it and describe it in my head. But it’s easier to describe it to others when I’m still feeling this feeling. It’s harder to come back to it later and write about it.

This “feeling” is something powerful and organic. I believe it is derived from a core part of what makes us human. In part, it’s a form of social stimulation, but it’s also a little more. The “feeling” is what I’m beginning to term the integral of a community.

integral: (adjective) ˈin(t)əɡrəl,inˈteɡrəl/ - necessary to make a whole complete; essential or fundamental.

From Oxford Dictionaries

What is a community? 🔗

Communities are a fundamental part of our daily lives. We all belong to a community in one form or another. In my view, community is a loosely-defined word that gives rise to many forms. Our immediate family is a community. Our workplaces are a community. Our friends are a community. Our schools are a community. Our homes are a community.

Maybe we feel different about some of the above examples of a community. Your feelings on your familial community may be different from mine. Maybe we feel different about our school communities. But regardless of where you fall, there is a community that you are attached to. Maybe you don’t realize it, maybe you do. But this community holds a special part in your heart. It is, by definition, integral to what makes you, you.

Going forward, it is important to establish your own personal definition of this integral community. Whatever group of people you feel most comfortable with. It doesn’t matter what size. It could be one person or it could be twenty. It could be a hundred. But this community is fundamentally important to you.

What is integral of a community? 🔗

Several different components comprise a different community. They are formed around a range of different topics. Communities can be based around blood ties. Your family. They can be based around a shared interest, like art or technology. You may belong to a community based on your profession, such as a group of educators. Or perhaps you belong to a community full of differences. All of its members come from different backgrounds, professions, races, or anything. Maybe it’s because of close geographical location. Maybe it’s because of a former close geographic location. It depends on the community you identify with.

With such wide difference, it can be curious what makes a community so incredible for you. What components are integral to you? If you break down the outer shell, the answer becomes more clearly visible.

You identify with a community when you share a mutual interest, passion, or engagement with the others in your community.

When you feel most interconnected to your community is when you can feel or understand this most.

< more here >

My community 🔗

My community is the free and open source software community at the Rochester Institute of Technology. There are several individuals who have built this community from the ground up to make it what it is. It has endured its fair share of hardships and challenges. It has celebrated victories and achievements among its members. In the stereotypical application of the phrase, it feels like family.

Our communal responsibility 🔗

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 shared context is the most valuable piece of the conference. As a first-time attendee, I was blown away by the depth and range of topics covered by attendees. This blog post covers a narrow perspective of Sustain OSS through the sessions I participated and co-facilitated in.

Speed breakout groups 🔗

The morning started with speed breakout groups of between six to twelve people. Several attendees acted as facilitators for discussion on special topics. Every attendee could about half of all groups. I took extensive notes in the following groups:

• Charitable participation in open source
• Diversity and inclusion
• Turning open source projects into sustainable projects / companies
• Design in open source
• Open source financial sustainability models

Sustain OSS: High-level takeaways 🔗

To save you time, these are my high-level takeaways across all breakout groups I participated in:

• Open source isn’t something just done in people’s free time

• Complex systems can enable systemic bias in terms of what “open source” means

• Sustainability as topic of first priority / consideration, not an afterthought

• There is no “silver bullet” solution to any of these challenges; they all require adaption to work across communities, projects, and organizations

Charitable participation in open source 🔗

This breakout group focused on the connection between charitable organizations and free software projects. It was facilitated by the esteemed Karen Sandler of the Software Freedom Conservancy.

Overall, the conversation was split among creating ethical software, finding sustainable funding models, and balancing how much control to relinquish as a managing organization of an open source project. Some felt pride and ideology were strong drivers for contributors to ideological projects (which also mirrors my experience at UNICEF). These could be key motivations to understand for contributors. Additionally, the challenge around sustainable funding models was common across charitable foundations focused on free software. Grant funding is a common strategy employed by charitable organizations, but the short-term nature of grants puts additional strain on resources to continue searching for new funding. Lastly, for charitable organizations overseeing or supporting free software projects, there was uncertainty over how much control should be left to projects. Attendees generally expressed a desire to let projects do what they want, but it sometimes came at the risk of additional overhead for the organization when everyone does something of everything. The concern over toxic communities came up, and how some issues remain buried until farther along in a relationship with a project. One successful solution employed was to hold monthly meetings among all member projects of an organization to address difficulties.

One interesting detail that captured my attention: one attendee noted how extensive effort into fundraising campaigns targeted to members of a foundation actually increased member engagement with the foundation.

Diversity and inclusion 🔗

My biggest takeaway from this session was the danger in thinking of open source as something we do in our free time. This can be exclusive to different genders, races, and socioeconomic statuses. Some “free time” is more equal than others. The actionable piece for me is to be more conscious in building and growing communities to support different levels of contribution in a community.

The question I wanted to explore after reflecting is to ask of those who feel disadvantaged:

• What factors makes a project more or less inviting for you?
• What can we do better when designing for participation in our communities?

Turning open source projects into sustainable ones 🔗

My notes weren’t thorough on this session, but there was an interesting point on trademark that came up during discussion of the Commons Clause. One participant was pursuing trademark law to enforce commercial protections and sustainability. They gave an example of a large corporation advertising support with a major open source project (e.g. a major software/hardware vendor supporting a specific NodeJS version). They wanted to use this as a way to create a more financially sustainable model for some projects.

Design in open source 🔗

This breakout group focused on sustainable design and design practices in open source communities. The role of designers in technical projects was also discussed and how we can build technical communities to be more inclusive for designers. It was facilitated by Elio Qoshi.

My takeaways from this breakout were that established ways of working can be unfriendly to designers and there is a need to emphasize diversity across different roles in a project or organization. Certain tools, platforms, or other mechanisms for contributing have poor user interfaces. They can push people away because of barriers to contributing with a frustrating user experience. Next, the need for diversity in roles was noted, with an example of engineers leading project management. Sometimes bias or oversights afforded as an engineer accidentally excludes others like designers or writers from contributing to our project. We should endeavor for people to spend more time on their preferred and most effective methods of contribution.

Financial sustainability models 🔗

This breakout session focused on the traditional sense of sustainability: in finances and resources. Attendees discussed different models used to fund open source projects and foundations. The session was facilitated by the founder of the MusicBrainz project, Robert Kaye.

The model used by MetaBrainz essentially as a data broker was interesting and unique. MetaBrainz offers commercial data usage at a cost, and companies using their data have a strong need for the data and see value in it. Through other parts of their model since changing three years ago, they had significant gains in their revenue and were able to increase paid staff working on the projects.

The Amazon invoice cake is also an amusing story, but you should ask Robert directly about it.

Hour breakout sessions 🔗

After lunch, attendees participated in two hour-long breakout sessions to explore specific topics in greater detail.

Human aspect of governance 🔗

Longer form notes are available below. I won’t go into detail since it has its own document with notes and highlights.

University engagement 🔗

Together with Josh Greenberg of the Alfred P. Sloan Foundation, we co-facilitated a spontaneous session on how universities can engage with open source communities and vice versa.

In our session, two major topics were discussed:

• Education (e.g. curriculum, institutions, programs, etc.)

• Research

We asked all participants why they decided to participate and what questions they had, even though we weren’t able to answer all of them:

1. How do we get the word out?
2. What research is most valuable for open source?
3. How to long-term sustain projects?
4. How to actually do and support research?
5. How to engage both students and faculty?
6. How to harness / enable institutions to make positive contributions to ecosystem?

For education, we agreed that introducing and teaching open source in curriculum better serves students and the institution (both financially and in career satisfaction). Many technology companies today are participating in open source and it is an important skill to have for students entering the workforce. For research, students are already doing research and proposing topics, so better student engagement in open source is better for research.

Our takeaways were to better engage with existing organizations working on these problems for years already (e.g. POSSE), shifting the perspective of universities to be stewards of FOSS, and using collegiate hackathons as a way to better engage with undergraduate students.

One additional point that stood out to me was the emphasis across all breakout participants for a need of good communication skills to be successful. In many cases, the companies hiring top tech talent (from our breakout attendees) listed this as most desirable skill. Technology and new skills can be learned, but teaching good communication skills and how to work collaboratively are not easily learned.

Other takeaways 🔗

One takeaway I couldn’t fit elsewhere was my changed perspective on “technical” vs. “non-technical” work. The phrase “non-technical work” implies an “other space where development does not occur”. Does the phrase place unequal priority on technical work? One action item is to avoid using “non-technical work” as an umbrella term, and instead call these areas by what they are: design, documentation, writing, marketing, community building, etc.

For me, I still want an umbrella term for these things, but I’m open-minded for better alternatives to non-technical.

Skill share: conflict resolution 🔗

The last event of Sustain OSS was a 1x1 skill share. Roughly half of the attendees identified a “skill” they could teach someone else in the room. The other half of attendees paired with someone teaching a skill they wanted to learn more about. I paired with Jono Bacon on a short breakout on conflict resolution.

Jono detailed steps of working through and resolving conflict, including how to identify root problems, how to make steps to resolve them, and some personal philosophy of how we build and maintain relationships with others.

An important first step is to identify the critical point: this could be an ongoing crisis, dealing with interpersonal conflict, or dealing with burnout. When someone is explaining a problem, listen fully to them and understand what they are saying. Let them get it off their chest. Is there something else causing this behavior? Tap into the cloud of ranting and determine what the root cause is.

Once common ground is established, make a plan to resolve it. Jono’s advice was to create written next steps and be explicit about expectations. This way, everyone is on the same page of what the next steps are and everyone involved has signed off on these next steps (this creates a sense of commitment and the next steps become written as “law”). Encourage others to restate the goals of conflict resolution in their own words. Once you have written goals and expectations, the crucial next step is follow-up. Check in on a regular basis with the person or people involved. Try to be neutral and unbiased when listening to others in these conversations. Go in with an open mind.

Lastly, we contextualized conflict resolution in personal philosophy of how we build and maintain relationships with others – both in and out of our open source projects. Sometimes the best way to address difficult interpersonal problems is to stop avoiding them and simply address them. Much easier said than done, but otherwise there is no escaping the perpetuated cycle of conflict if someone doesn’t make a first step.

It’s not just about code.

Thank you 🔗

To wrap up this Sustain OSS report, a few obligatory thank-yous are needed:

• Sloan Foundation / Ford Foundation: For the financial support I needed to attend and participate in the event – this is never something I take for granted and I am happy to have received a scholarship to attend and participate

• Josh Greenberg @ Sloan Foundation: For helping me get over some imposter syndrome and co-facilitate the university engagement breakout session with me – thanks for the gentle push

• Robert Kaye @ MetaBrainz: For being generally awesome and finally giving me someone to nerd out about all these crazy ideas of how free culture and music can actually be related!

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me map a strategy to get the most out of Sustain OSS

Sustain OSS gave me a lot to think about and consider. I’m glad and fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in London this year.

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

Across this spectrum of bold headlines and addicting scrolling, I began to wonder about identity. What determines how we choose to identify where we originate from? What makes us decide to disassociate from our birthplace? What parts of our culture make us proud and content and what parts are like fresh wounds withheld from time and space needed to heal? I started to wonder about my own identity and what it means to me to be defined as an American.

I fight a growing sense of dissatisfaction and disbelief of what I read happening each day. As I read about the United States and how its citizens are represented on a global stage, a feeling of repulsion sinks into my stomach. Society greatly shaped my perspective of what it meant to be an American as I grew up. What is around me now is contradicting: the qualities of inclusiveness and diversity espoused to the identity of being an American are the same qualities I feel are under attack.

One afternoon as I walked back to my Chicago apartment, I passed a Mexican restaurant. As I walked by, I searched for a menu to measure how authentic it would be compared to offerings in Atlanta (I’ve notoriously had a difficult time finding authentic Mexican food north of Virginia). However, I was disappointed, as the choices fell into the category of American-Mexican food and not the authentic dishes I craved.

But even though I continued on and left the food behind me, the restaurant didn’t leave my mind. As I continued to ponder on what it means to be American, I couldn’t get this restaurant, and countless others like it, out of my mind. One of the most unique observations of my travels is how culturally homogeneous so many countries are. From my experience living in Europe and visiting India, the difference of cultural diversity from my American experience was impossible to miss. Each country was mostly shaped by its dominant ethnic group. To see a Nicaraguan in Croatia or a Swede in India would be a memorable encounter because it was outside of preconceived expectations. But in America, I board a New York City, Chicago, or Washington DC subway, and I always remain pleasantly surprised at how unique and different all the passengers are.

But what of the Mexican restaurant? If my train rides reflect this unique cultural identity, what is the significance of the Mexican restaurant and why can’t I forget it?

Suddenly, I realize perhaps American culture is several shards of all other cultures that assimilate here. Instead of the restaurant being an imitation of the real thing, what if it is as real and independent of an experience as the original? Instead of being a clone or a derivative, what if they are their own original craft and subculture? In a way, they are mostly unique – many of the fusions of culture, from food to celebrations, and architecture to film are only found in this sort of combination here.

These pieces of foreign culture are transplanted seeds, taken from their native soil and planted into a new environment. It requires adaption and perhaps creativity too. But these pieces of culture, whether they are motivated to be imitations or not, are created from a place of love and genuine human connection. They stem from a desire to celebrate who we are and where we come from. Furthermore, they offer an opportunity to share these things with others and to pass along the memories and experiences to others in the hopes that they too will see the world from a different perspective, if only for a passing moment.

As I continue to read past another day of headlines, I feel hopeful knowing this spirit of America, although challenged today, remains and exists. In a city like Chicago, it would almost be impossible to miss this range of diversity. While some choose to wrap words of hate and fear around the red, white, and blue stripes of the American flag, I try to remain mindful to keep this flag closer to me too, and wrap it around my values of love and compassion for others, and what it means to me to be an American in this political era.

Managing an open source project is challenging work. The challenge grows as a project grows. Eventually, a project may need to meet different requirements and span across multiple repositories. These problems aren’t technical, but are important to solve to scale a technical project. Business process management methodologies such as agile and kanban bring a method to the madness. Developers and managers can make realistic decisions for estimating deadlines and team bandwidth with organized development focus.

At the UNICEF Office of Innovation, we use GitHub projects boards to organize development on the MagicBox project. MagicBox is a full-stack application to serve and visualize data for decision-making in humanitarian crises and emergencies. The project spans multiple GitHub repositories and works with multiple developers. With GitHub project boards, we organized our work across multiple repositories to better understand development focus and team bandwidth.

Here’s three tips from the UNICEF Office of Innovation on how to organize your open source GitHub projects with the built-in project boards on GitHub.

Bring development discussion to issues and pull requests 🔗

Transparency is a critical part of an open source community. When mapping out new features or milestones for a project, the community needs to see and understand a decision or why a specific direction was chosen. Filing new GitHub issues for features and milestones is an easy way for someone to follow the project direction. GitHub issues and pull requests are the cards (or building blocks) of project boards. To be successful with GitHub project boards, you need to use issues and pull requests.

The UNICEF MagicBox team uses GitHub issues to track on-going development milestones and other tasks to revisit in the future. The team files new GitHub issues for development goals, feature requests, or bugs. These goals or features may come from external stakeholders or from the community. We use the issues as a place for discussion on those tasks too. This makes it easy to cross-reference in the future and visualize upcoming work on one of our projects.

Once you begin using GitHub issues and pull requests as a way of discussing and using your project, organizing with project boards becomes easier.

Set up kanban-style project boards 🔗

GitHub issues and pull requests are the first step. After you begin using them, it may become harder to visualize what work is in progress and what work is yet to begin. GitHub’s project boards give you a platform to visualize and organize cards into different columns.

There are two types of project boards available:

• Repository: Boards for use in a single repository
• Organization: Boards for use in a GitHub organization across multiple repositories (but private to organization members)

The choice you make depends on the structure and size of your projects. For the UNICEF MagicBox team, we use boards for development and documentation at the organization level, and then repository-specific boards for focused work (like our community management board).

Creating your first board 🔗

Project boards are found on your GitHub organization page or on a specific repository. You will see the Projects tab in the same row as Issues and Pull requests. From the page, you’ll see a green button to create a new project.

There, you can set a name and description for the project. You can also choose from templates to set up basic columns and sorting for your board. As of writing, the only options are for kanban-style boards.

After creating the project board, you can make adjustments to the project board as needed. You can create new columns, set up automation, and add pre-existing GitHub issues and pull requests to the project board.

Now, you may notice new options for the metadata in each GitHub issue and pull request. Inside of an issue or PR, you can add it to a project board. If you use automation, it will automatically enter a column you configured.

Build them into your workflow 🔗

After you set up a project board and populate them with issues and pull requests, you need to integrate them into your workflow. Project boards are effective only when actively used. With the UNICEF MagicBox team, we use the project boards as a way to track our progress as a team, update external stakeholders on development, and estimate team bandwidth for reaching our milestones.

If you are an open source project and community, consider using the project boards for development-focused meetings. Additionally, it helps to remind yourself and other core contributors to spend five minutes each day updating progress as needed. If you’re at a company using GitHub to do open source work, consider using project boards as a way to update other team members and encourage participation inside of GitHub issues and pull requests.

Once you begin using the project board, yours may look like this!

Open alternatives 🔗

GitHub project boards require your project to be on GitHub to take advantage of this functionality. However, there are other open source alternatives available. You can use tools to replicate the same workflow explained above. GitLab Issue Boards and Taiga are good alternatives that offer similar functionality.

Go forth and organize! 🔗

Now, you can bring a method to the madness for organizing your open source project. These three tips for using GitHub project boards encourage transparency in your open source project and make it easier to track progress and milestones in the open.

Do you use GitHub project boards for your open source project? Have any tips for success that aren’t mentioned in the article? Leave a comment below to share how you make sense of your open source projects.

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!

A series of heavy noreasters hit the US east coast over the last couple weeks. This coincided with my travel dates back to Rochester, NY. While we didn’t have flooding, we had a lot of snow. A lot of snow means canceled flights.

As I made my way through border control in Dublin, Ireland on March 7, I discovered my connection to New York City would likely be canceled. A meander from baggage claim to the check-in desk confirmed this. Fortunately, Aer Lingus had no issue putting me up in a hotel overnight with dinner and breakfast to catch the next flight to New York the next day.

While waiting in airport queues, a friend happened to retweet a local event happening in Dublin the next day.

For International Women's Day on Thursday, we'll be celebrating Female Firsts in medicine with @RCSILibrary https://t.co/RvIHtwAhys
Saturday, we have our @artandfeminism event in @UCC, celebrating our Irish and local female artists from 12-3pm https://t.co/ZMpKQOSR3q pic.twitter.com/0G7Kn3zpS6

— Wikimedia Community Ireland (@WikimediaIE) March 5, 2018

The event was a local Wikimedia meet-up to celebrate International Women’s Day. Participants would create and edit Wikipedia pages for influential women in the history of the Royal College of Surgeons in Ireland. After digging deeper, I found out the event was 30 minutes away from my hotel from 09:30 to 12:30. My flight was at 16:10.

I put in my RSVP.

Meet the Wikimedia Ireland community 🔗

In an opportunistic stroke of fate, I would spend my extended layover for my first time in Dublin learning and listening about role model women in the Irish medicine community. I didn’t know it yet, but I would also take part in writing some of the history too!

#WomenOnWalls 🔗

The first part of the morning was an introduction to editing on Wikipedia and establishing the focus for edits.

The Royal College of Surgeons in Ireland (RCSI) started a new campaign to promote influential women in the history of the university. There is a historical board room in a prominent place on its campus. Inside the board room, there are portraits of influential people in the history of RCSI. But all of them are men. This makes it difficult for women to have role models or inspiration of women like them who “made it” in science and medicine.

On the contrary, there was also no shortage of influential women in the history of RCSI. Part of the morning was an introduction to primary sources that explained the pivotal work of female Irish doctors and pediatricians throughout the 20th century. After hearing about these inspirational women, it was a wonder – why were none of them represented in the board room?

This was actually the focus for the edit-a-thon. Recently, RCSI commissioned new portraits for some of the influential women alumnae. Half of the portraits in the board room would be relocated and replaced by the new portraits. This was part of their #WomenOnWalls campaign.

Discovering Victoria Coffey 🔗

After an introduction to the sources available and how to edit on Wikipedia, we began the editing. Organizers encouraged participants to improve an existing page first, since most of the participants were first-time editors.

Since I had some experience with Mediawiki mark-up and do a lot of writing, I decided to write a new page. There were a list of suggested women alumnae to write about. After hearing about Victoria Coffey, I decided to focus my two hours of writing on her legacy.

Who is Victoria Coffey? 🔗

Victoria Coffey was an Irish pediatrician. She was an alumna of RCSI, and one of the first to research sudden infant death syndrome (SIDS). Coffey spent most of her time in medicine researching and studying congenital abnormalities in infants and pediatrics. Later in her life, she founded the Faculty of Paediatrics at the Royal College of Physicians of Ireland in 1981 and was the first female president of the Irish Paediatric Society.

Writing her Wikipedia page 🔗

With the help and guidance of the Wikimedia Ireland and RCSI staff, I found resources to research and learn more about Victoria Coffey. While some public sources were available, I was also provided with a primary source from a paid online Irish encyclopedia.

From there, I had the basis to begin writing a stub for her biography. I created an infobox to summarize some of her contributions, wrote a paragraph on her life, and left external links for someone to expand and write more in the future.

You can find her Wikipedia page online now. Since its creation, it was viewed nearly 100 times, edited five times, and edited by three people.

Thank you RCSI and Wikimedia Ireland! 🔗

In a strange and opportunistic stroke of fate, I was lucky to meet this local community and work with a room of inspiring women in medicine (students, alumnae, and faculty) on lowering the wiki gap of women on Wikipedia. It was a privilege to take part and learn a unique kind of history for Ireland in my short stay in Dublin.

Thank you for this great experience, RCSI and Wikimedia Ireland!

I’m not sure if this will make me anticipate flight cancellations more or less from now on.

My internship at UNICEF is unique: I support open source community engagement and research as my primary task for the MagicBox project. For years, I’ve done this in open source communities in my free time (namely SpigotMC and Fedora), but never in a professional role. As I navigate my way through this exciting opportunity, I plan to document some of the experience as I go through blogging. My intent is that my observations and notes will be useful to someone else in the humanitarian open source space (or maybe to a future me).

But first, what does “open source community engagement and research” really mean?

What am I actually doing? 🔗

“Community engagement” is a buzzword phrase for the open source movement in the 2010s. Often, we hear about “community engagement” or the work of those “leading communities”, but it’s an abstract concept. In other words, building communities of humans and people is hard. There is no one-size-fits-all solution for any community. Every community has its own unique needs and goals. This means different methods of management and communication work better for some communities than others. My job is to help light the way for what this pathway means for the MagicBox team.

Since I started in January, a lot of my time so far was spent learning. What is MagicBox? What are we trying to deliver to our stakeholders? To the open source community? How does our data pipeline piece together? All these questions and more, I’ve tried to answer to different levels of success.

What’s next? 🔗

Now, I’m beginning to take a more hands-on role with the work, with a clear vision of what I want to do. The next few posts to come will dive deeper into what I’m up to.

If you have questions or are interested in keeping up with what’s going on, feel free to leave a comment here or subscribe to my blog to automatically receive future updates.

Opinions and views in my blog are my own and do not reflect the views of my employer.

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.

On November 7, 2017, members of the RIT community came together for the annual Election Night Hackathon held in the Simone Center for Student Innovation. This year marked the seventh anniversary of a civic tradition with the FOSS@MAGIC community. As local and state election results come in across nine projectors, students and professors work together on civic-focused projects during the night. Dan Schneiderman, the FOSS@MAGIC Community Liaison, compiled lists of open APIs that let participants use public sets of data made available by governments at the federal, state, and local level.

The hackathon officially began at 5:00pm and went until 10:00pm. Plenty of pizza and drinks were provided to fuel participants during the evening.

Open source with open government 🔗

Each year, the hackathon welcomes students and faculty to analyze civic problems happening in the local community, state, or country, and then propose a project to address them. MAGIC Center faculty help students choose open source licenses to share their projects. Organizers encourage students to use a site like GitHub to publish and share their code.

Second Avenue Learning, an educational game company in Rochester, demonstrated their Voter’s Ed app that replays historic elections, keeps voters up-to-date on current ones, and lets them simulate their own using open data and HTML. It also allows users to examine key issues and hot topics related to national level events. The company, represented by the founder Victoria Van Voorhis and two employees (one an RIT alum) held a design discussion for new features to prototype with students and the community. Sean Sutton and Paul Ferber (RIT faculty) provided subject matter expertise to the application.

While people began their projects, coverage of the local and state elections were displayed across nine different projectors. As the night progressed, votes from local and state elections rolled in. Rochester coverage was enhanced, since Monroe County is one of three counties in New York that releases public data for election coverage. Some participants even used the local Henrietta data for their own projects.

LibreCorps internship 🔗

Pratik Shirish Kulkarni, a second-year computer science major from Mumbai, India, presented the current status of his FOSS@MAGIC LibreCorps internship. LibreCorps placed Pratik with UNICEF Innovation in Manhattan, where he worked on MagicBox, a set of big data APIs and technologies used to chart Zika outbreaks and connectivity across schools in Africa.

Pratik demoed some of the work, which he is continuing part-time on campus this semester, funded by UNICEF. Another internship to work on the project is currently posted in Handshake.

Where can I vote? 🔗

Third-year student Chris Bitler created a tool to make it easier to get to the polling booth. His web application, “Where can I vote?”, takes a specific election and your address, and gives you directions from your address to the closest polling location. It uses the Google Civic Information API to find election data and calculate a specific address’s voting district and candidates.

Chris was exploring for project ideas in the beginning of the hackathon, but quickly found the civic data API returned interesting data about polling locations. “After seeing that, I gave some thought to how some people don’t know their polling location and how a simple website could be useful for that,” Chris said. His web application was motivated by simplicity, so anyone could navigate without being lost in information.

In the spirit of open source, Chris open sourced his project on GitHub under the MIT License.

Linkybook: Local election data in real-time 🔗

Another project during the night focused on tracking local election data in Chautauqua, Monroe, and Suffolk Counties. RIT and FOSS@MAGIC alumni Nathaniel Case continued work on his monroe-elections application during the night. The site shows data for all races in the three counties.

During the night, his web application updated in real-time as the results from the local elections began to appear. Election results for the races is quick to understand and read. Additionally, referendum results and other non-partisan elections are available.

Nathaniel open sourced his project on GitHub under both the DBAD and GPLv3 licenses.

Join us next time! 🔗

The night ended after a quick round of project demos and finishing up project work. FOSS@MAGIC has more events planned in the near future. On November 15th, Christine Abernathy from Facebook’s Open Source Program talks about how Facebook approaches open source and how they’ve solved engineering problems with it.

You can learn more about the FOSS@MAGIC initiative on their website. Participation on the mailing list is welcome.

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.

Internet Relay Chat, or IRC, is one of the oldest chat protocols around and still popular in many open source communities. IRC’s best strengths are as a decentralized and open communication method, making it easy for anyone to participate by running a network of their own. There’s also a variety of clients and bots available for IRC. But on the reverse side, usability is a concern. Most common user interfaces for IRC clients or platforms aren’t always intuitive. People from parts of the world with unstable Internet connections are challenged with remaining connected to participate in conversation. Many people have tried addressing this problem before, but none have come as far as Riot.

What is Riot? 🔗

Riot is a free, open source, and multi-platform client based on the Matrix protocol. To understand better, think of Matrix as the protocol and Riot as the client. Matrix is a decentralized, secure, messaging protocol. It has the benefit of using HTTP / JSON APIs, is capable of sending and receiving messages with full end-to-end encryption, WebRTC VoIP / video calling, and maybe most importantly, integration capabilities. Matrix was built to integrate with IRC servers and other communication protocols, meaning you can use the Riot client as an IRC bouncer. You can read more of the details on what separates Matrix from Riot on their FAQ.

As a result, Riot becomes most useful in its implementation as the default Matrix client. It’s convenient and decentralized, as anyone is able to launch their own Matrix “homeserver” and connect it with Riot. However, Matrix by default has servers bridged with Freenode, Mozilla IRC, and more. This lets you use Riot as a persistent client that keeps you connected to IRC even when you’re not there.

Outside of the web application, you can also find it as a desktop application for Mac, Windows, and Linux, or a mobile application for iOS and Android. In this guide, you’ll learn how to get started using Riot as a full-time messaging client with the default Matrix / IRC integration servers.

Register and get a client 🔗

First, you’ll need to grab an account from Riot’s website. Registration is straightforward and shouldn’t take you much time. You can find the registration form here. Once you’re registered and have confirmed your email, you’ll need to get the Riot applications on your devices of choice.

Desktop clients 🔗

There are desktop clients available for Windows, macOS, and Linux. If you’re running Windows or macOS, you can download the right version for your desktop on the Riot downloads page. If you’re using Debian, Ubuntu, or a related operating system, you can add a repository to your system to install the Riot desktop client. You can read this guide on how to add the repository and install Riot to your system.

Fedora 🔗

Riot is not yet officially packaged in Fedora’s repositories. However, there is a third-party Copr repository where the desktop application is packaged. Until it makes it into Fedora’s repositories, you can use this version to get started with Riot. You can find the Copr project and install instructions here.

Mobile clients 🔗

Want to have Riot integrated on your phone or prefer a mobile client? You can also find official versions of Riot on iOS, Google Play Store, and F-Droid. Using any of the mobile clients will integrate fully with a desktop client, if you choose to use both. This guide will focus more on the desktop clients.

Setting up Freenode in Riot 🔗

Riot currently supports eight IRC networks: Freenode, Moznet, Snoonet, OFTC, GIMPNet, Foonetic, Rizon, and EsperNet. Although you can use any network you like and the instructions will mostly be the same, this guide focuses on using Freenode.

Joining your first channel 🔗

One of the first things you’ll see after signing into Riot is the directory. In the directory, you can search through chat rooms on Matrix itself or any of the other IRC servers that are integrated. To join your first channel, you can select the IRC channel of choice in the dropdown menu and search for a channel.

For example, if we want to find #opensource.com on Freenode, you can select the Freenode option and search for #opensource.com. Once it’s there, you can join and say hello to the rest of the Opensource.com community hanging out in IRC.

Alternatively, if you would prefer directly joining a room, you can type the following as a command from any chat window in Riot.

/join #freenode_#channelname:matrix.org

Setting your IRC nick 🔗

By default, your IRC nick, or username, will be similar to your display name in Riot. Sometimes it will have a [m] appended to the end. However, after you connect to a channel, you can change your nick on the IRC side as well. You’ll need to start a new conversation with the IRC integration bot between Riot and Freenode.

In the bottom left corner of your Riot client, you can start a new personal chat with any user. To message the IRC integration bot, start a new chat with @appservice-irc:matrix.org. This will put you and the bot together in a private chat. To change your nick, send the following command to the bot:

!nick irc.freenode.net <IRC nick>

You should receive a confirmation message, similar to: “Nick changed from ‘OldNick’ to ‘NewNick.’” For more help, you can read the official documentation on changing your nick.

Authenticating with NickServ 🔗

One of the other vital functions you might need to do is authenticate with NickServ. This is especially important if you want to use your registered IRC nick or are a member of invite-only channels. However, it’s possible to do this too.

You’ll need to start another direct chat again. This time, you can search for the user @freenode_NickServ:matrix.org. This will put you into a private message with NickServ on Freenode’s servers. To authenticate, you can send a message just like you normally would.

IDENTIFY <username> <password>

After doing this, you should receive the normal confirmation that you are now logged in as your account. Remember to use caution when opening this chat in a public place, as your password will be displayed in plaintext whenever you open that direct message with NickServ.

Say hello! 🔗

Once you’ve joined a channel, claimed your nick, and authenticated with NickServ, you will be all set to begin using Riot. In any channel bridged in IRC with Matrix, all of your messages from Riot will show up in the IRC channel. Riot can also act like an IRC bouncer that keeps you persistently connected. Whenever you open Riot, you will be able to see a log of past discussions even if you weren’t connected to the Internet.

Both Matrix and Riot are open source projects. You can find Matrix’s code and Riot’s code on GitHub. If you want to better understand how the integration bridge works, you can read this blog post by one of the developers.

Have any comments or stories to share about using Riot? Are you already using it for IRC? Share your comments with us down below!

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.

If you’re outside of the Mediterranean region, the Open Labs Hackerspace might be one of the hidden secrets of the region that you never knew existed. Free software and open principles build the community’s foundation. In their hackerspace, they support various open source projects with time, energy, and activism. Members work on various open source projects, ranging from Fedora, Mozilla, Nextcloud, Wikipedia, OpenStreetMap, and more. But the open source way goes beyond the software. The hierarchy of this Albanian non-profit organization is flat and open too. The hackerspace places a strong emphasis on empowering others to have a voice and to take part in the governance. No question is ever dumb, and anyone who wants to learn is able to find someone who will help guide them in the right direction. The combined effect of open software and open culture has helped Open Labs grow over the past five years.

Why Open Labs? 🔗

There are many hackerspaces in the world, but why does Open Labs mean so much to me? They love free and open source software and believe in the open source way… sure. That’s definitely part of it. But beyond the mission, beyond the activities, Open Labs fosters an inclusive and empowering culture. This culture has the effective of motivating others to understand that their voice matters and that they can have an impact on something far bigger than themselves. The hackerspace helps give young people in Tirana a platform to stand up and share their ideas. But beyond that, it provides them with the resources and community to help turn the ideas into reality.

So, what is the secret? Simply… the people.

Everything that the community here does, they take their unique passion and energy into those tasks. They invest their own personal resources into building solutions to answer complicated problems, inside and outside of Albania. Some of their work is best demonstrated in events that happened earlier this year. In March, Open Labs helped coordinate the first-ever 48 hour hackathon for United Nations Sustainable Development Goals. Later in March, they organized Linux Weekend, an introductory event to help introduce Linux to students. This was done by demonstrating what can be done with Linux and open source and then connecting students to professionals from Tirana and abroad. The organic energy that came from these events is almost immeasurable. Even an event report is hard to convey how inspiring that energy was.

This past weekend, from May 13-14, 2017, the community organized the fourth edition of the annual Open Source Conference Albania (OSCAL) in Tirana. This is the largest open source event in Albania and one of the most notable in southeast Europe. No event report for this yet, but you can expect one soon.

Why part of my heart is at Open Labs 🔗

Whenever I visit Albania and visit Open Labs, I learn something new. There’s many different types of things I learn. Sometimes it’s something about an open source project or community. Other times, I learn about events and opportunities happening in the local Tirana area for open source. And then other times, I gain unique insight towards some of the unique challenges and problems that citizens face here. Every time I visit, my perspective is always broadened in a way that I wouldn’t be able to normally find. It’s exhilarating.

I am privileged and honored to be an official member of this community. However, I am mostly an observer in my role. The passion and interest are at the heart of the hackerspace. The members from Tirana have invested so much of themselves into this community, its mission, and its values. From reading, visiting, and talking with the people involved with Open Labs, you see many of their hearts dedicated to what they’re doing. And when you see someone else who invests their heart into something, it’s challenging to not lend some of your own too.

And in today’s world, where the hearts of many people close with borders and the world shifts towards coldness, the warmth that radiates from Open Labs is refreshing, inspiring, and powerful.

Discover Open Labs 🔗

You can learn more about the Open Labs Hackerspace on their website. Additionally, you can also follow them along on Facebook and Twitter to see what they’re up to. You can also see their Discourse forums to say hello and take part in any discussion too.

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

What exactly are Happiness Packets? 🔗

Fortunately, I don’t have to do a lot of work to explain this, because it’s all on the front page of the Happiness Packets website. Repeated below for your convenience:

People are generally much more loved than they think they are. Especially when things don’t go according to plan, other people almost never think as harshly of you as you might think of yourself. It’s easy for us to complain when bad things happen, and yet we’re often fairly silent when things are good. Open-source communities are no different, especially when our main communication channels are textual and virtual.

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. With Open-Source Happiness Packets, we’re trying to spread that feeling.

How does it work? 🔗

Openly expressing appreciation, gratitude, or happiness to other people can be difficult. This is especially true when you don’t know them very well. Many of us come from cultures in which people are not open by default about such feelings, and naturally feel uncomfortable or even creepy to share them.

Open-Source Happiness Packets is a very simple platform to anonymously reach out to the people that you appreciate or to whom you are thankful in your open-source community. Your message can be sent anonymously if you feel uncomfortable to share your name with the recipient. Of course, we encourage you to share your name, but it’s completely optional!

Take the challenge 🔗

So, what is the #HappinessPacketChallenge? I challenge you to do the following: write at least one Happiness Packet (or more!) every day for one week. At a minimum, this is only seven times where you say “thank you” to someone else in open source. Of course, you can send more if you want to.

If you open your social media feed or turn on the news channel, you probably see a lot of negativity. Whether it’s world events, politics, or other sad news, the negativity gets at you. For one week, this is your opportunity to have the opposite effect. For all of the good things and people you see, you can spend a few minutes of each day this week to make someone’s day. It seems simple—and it is! But the power you have to spread the positivity is a big power. So this is the challenge you have: to commit yourself to spreading that message every day for one week.

“I don’t know what to say.” 🔗

Having a hard time coming up with words or not sure who to thank? No problem. Your message can be as short or as long as you like. If you’re not sure who to thank, look at some of the software you’re using now. If you’re using a Linux distribution, start there! Look for the names and emails of maintainers of software you enjoy using. If you’re already contributing to open source, consider some of the people in your community! You can thank someone who had a special role in helping you get started or impacted why you decided to work on a project.

Maybe you have other ideas or reasons to thank others. Whatever the reason is, don’t make an excuse to say thanks! The options are limitless. If you have a lot to say, say it! If not, even a simple “thanks for all the work you do!” can go a long way to make someone’s day.

Share your happiness 🔗

The magical part of Happiness Packets is sharing happy moments with others. If you receive one, don’t be afraid to tell the world! You can tweet at @happinesspacket on Twitter. Use the #HappinessPacketChallenge hashtag. Encourage other people to send their own thanks. If you can get one other person to take the challenge, then you’re already making the days of seven more people! Imagine what would happen if all of those seven people decided to take the challenge too.

So, what are you waiting for? Get started! Go send a Happiness Packet now! And if you’re feeling bold, try challenging someone directly.

Love Letter by Vectors Market 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.

On Tuesday, November 8th, 2016, the FOSS@MAGIC at the MAGIC Center at RIT held the annual Election Night Hackathon. Over 140 students from across campus and across departments gathered together to work on a range of civic projects as the election night results came in. This year’s hackathon was the sixth in a long-standing tradition of civic duty and open source collaboration.

Starting the Election Night Hackathon 🔗

For this year’s event, registration was a ticketed event because of the overwhelming interest in the election. At 5:00pm, the sign-in table popped up in front of the Student Innovation Hall, where the hackathon would take place. Students began lining up to receive their wristband for admission, food, and open source swag.

The space quickly became filled over the next hour as people began settling in for the night to work on projects (or maybe homework). On all sides were a range of projector screens with a range of sources for election night coverage. There would not be a lack of information through the night. In addition to the federal election, local and state elections throughout New York were also included on the projectors.

The Election Night Hackathon had no shortage of goodies provided by numerous open source organizations, companies, and supporters. The “swag table” featured plenty of stickers for people to add to their laptops or other devices. The Fedora Project, GitHub, Red Hat, the MAGIC Center, and more were available for attendees to pick their favorites out.

Projects 🔗

At the peak of the event, nearly 140 students, faculty, staff, and local citizens filled the MAGIC Center and overflow work spaces. Dan Schneiderman, the event coordinator and FOSS@MAGIC Research Associate and Community Liaison, led the event on a high note with a brief kick-off ceremony. Hackers were provided with a list of resources for building applications related to civic hacking. Shortly after the start, attendees began talking with one another to discuss project ideas or other topics to work on throughout the night. Professors and alumni provided mentorship, advice, and help for students planning projects.

Tyler Reimold worked on creating an open source server for real-time election updates in a Reddit thread. His Python-based project used the Huffington Post and Reddit APIs to build the application.

Adjunct professor at Monroe Community College  David M. Shein gathered a small group of hackers to build a website. The website, thankyousuffragists.org, honors and maps the graves of women around the country who campaigned for the right to vote. The early stage site allows people to add the locations of graves around the country to a map. “I personally loved how a number of our attendees were inspired by the crowds that stopped by Susan B. Anthony’s grave in Rochester, which then led to a project focused on honoring her work,” Schneiderman said.

Additionally, another project was the 2016 Election Viewer by Mark Repka. His Node-powered application delivered a state-by-state breakdown of election results throughout the night. Attendees were encouraged to check it out and provide feedback as he built the site to provide accurate coverage during the heat of the election coverage. You can view Mark’s application on his website, browse its own API, or find the source code on GitHub (MIT License).

Many other students worked on smaller projects or collaborated with professors on other ideas. Dr. Vullo at RIT opened a call for students to help him with a virtual reality idea powered by AFrame. Most of the projects and work from the evening was published on GitHub in the spirit of contributing civic hacking projects to the open source ecosystem.

And the winner is… 🔗

After seven hours of hacking and nail-biting, the election results were mostly called by midnight. With a short conclusion speech by Schneiderman, the hackathon began closing down in time for the next day of classes. “[My favorite part was] the collaborations and the mixing of students from majors that don’t usually get to work alongside each other. Attendance was a mix of computer science, marketing, political science, engineering, history, and visual arts,” Schneiderman said. Special thanks for the event go to the MAGIC Center at RIT for providing space and resources for the event. Additional thanks go to Red Hat for supporting the FOSS@MAGIC initiative so these events are made possible. You can find the full photo album from the event on 500px.

November 8th is a day that will stand in memory for a long time, and the Election Night Hackathon is a great opportunity for students to engage in discussion and collaboration with others in the community to identify issues in the civic area and try to build open source solutions to those problems. We’re looking forward to continuing the tradition next year for the next round of local, state, and federal elections.

More and more students are learning about the world of open source through video games. Games like FreeCiv let players build empires based on the history of human civilization while games like Minetest emulates Minecraft in an open source block-building sandbox. Students are encouraged to dig deeper into games like this, and projects like SpigotMC empower kids to write plugins to extend their favorite games. However, the tools in open source to build the actual games do not share the same prominence. Rochester Institute of Technology student Matt Guerrette hopes to help change that with his open source gaming engine, Hatchit.

Introducing Hatchit 🔗

Hatchit was a project started between Matt Guerrette and fellow student Arsen Tufankjian together in February 2016. After working with game engines for other classes, they both found challenges over how popular game engines are designed for developers. They noted that these game engines were more design-oriented. It lacked some technical details they were looking for when working on their own personal or academic projects. Together, they had the idea to build their own open source gaming engine with a goal of exposing more of the technical sides of the process to developers. “We want to give you more access to the programming side of the game engine,” Matt explains.

Hatchit is written in C/C++ and licensed in a mix between GPL and LGPL. Originally, the project was started to take advantage of the DirectX APIs for development. However, Guerrette and Tufankjian ran into an unexpected event while they were getting started. Nvidia released the Vulkan APIs in competition to the DirectX APIs. Originally, they had attempted to support both APIs simultaneously, but later opted to focus on Vulkan.

Inspiration for Hatchit 🔗

Guerrette remembers a specific type of task he wanted to accomplish with Hatchit. In the game editor, he wanted to be able to construct a render pass instead of having the engine handle it internally. An earlier project had motivated the need for this feature. By being able to create the render passes in real time, a developer would be able to create something like a custom shader that bends vertices into straight, geometric shapes in real-time. His earlier project, Mineshaft Mayhem, demonstrates this concept with how the mineshaft seems to be warping and turning, but the tunnels are actually straight in the editor.

You can find more videos of Guerrette’s work on his YouTube channel.

What’s happening now 🔗

Since starting the project, Tufankjian graduated and is now working at Amazon Game Design. Over the summer, the community started to show interest in the project. They’ve received a pull request from one member outside of the core developer team and have several issues filed against the different repositories for the engine.

Matt has a few milestones set ahead for the project this year. One of the biggest tasks he is working on is getting the Vulkan renderer multi-threaded design implemented and working. This vastly speeds up the render time when working on projects and is also proving one of the greatest challenges so far. In addition to the multi-threaded design, he hopes to have game objects and components serialized with JSON. This would make it easier for the editor application to modify game data and manipulate configurations with Qt.

Looking at FOSS and Hatchit 🔗

Guerrette is not unfamiliar with open source, but this is his largest undertaking yet with an open source project. While working on the project, using an open source development model has made it easier to receive feedback, work with community contributors outside of the RIT community, and also handle some technical aspects well.

Benefits of working in the open 🔗

Working on the project on GitHub has proved to benefit the project in a variety of ways. One of the most clear ways this helped is having people file issues and raise concerns over parts of the code. In one case, someone filed an issue against an older library that made a mathematical error in its calculations. “Having the world’s eyes on your project to catch errors is a good thing,” Matt said. Guerrette found the freedom to use other open source libraries and dependencies for the engine especially useful. All the licenses were compatible and presented no issue to work with.

Some technical challenges were also made easier with open source tooling. One of the greatest challenges for the Hatchit team was writing the build system to use build system generator software and maintain compatibility with both Windows and Linux. Locally linking dependencies in the project was inconvenient and made the project unnecessarily huge. With git, they used submodules to link dependencies in the repository and build them from source when compiling Hatchit. “Being able to link dependency repositories has been really useful, especially for developing on Windows,” Matt found. Additionally, some of the continuous integration features on GitHub and other services made it easy to quickly test new changes for compatibility.

Challenges of open source 🔗

Along the way, some challenges came by developing in the open that the team worked to resolve. With the convenience of using git submodules also came a difficulty of tracking upstream changes. On occasion, a dependency might break in the project. The team then has to check if the project has updated or changed upstream or if a fix needs to be made locally in their project.

Additionally, community outreach is a challenge Guerrette is hoping to focus on as the new project lead. He shares development updates on his YouTube channel and occasionally will stream his development on livecoding.tv. One thing is working on to make it easier for new contributors to get involved is recommending them to try building the engine from the source code. This gives potential developers experience with compiling the engine and walks them through a variety of documentation available with the project.

Get involved 🔗

The Hatchit team is working further on the game engine and are looking for community participation. To get involved, Guerrette recommends checking out the lHatchit Gitter chat and to review the README file on the main repository. Any contributions are welcome, either in the form of pull requests or filing issues.

Teams for purpose, teams for tracking 🔗

Team structure and designation are some of the most important ways to use organizations effectively. Since GitHub revamped teams, they are an effective way to categorize members and to assign privileges. You can decide who can create repositories, who can push code to what repositories, or who has admin rights on projects.

You should create teams that have a purpose and will work with real repositories. For example, if your club has various committees, you should create a team for each committee. Then, you can give each committee privileges to their own repositories and leave it to them to manage. Being smart with what teams you create is important. Teams with a purpose should exist to carry out certain tasks within the organization. Equip them with the means to do so.

It’s also helpful to create teams for tracking. In a university setting, students will graduate in a certain year and then they’ll be gone. For university clubs using GitHub organizations, create teams for every graduating class, staff and faculty, and alumni (e.g. “Class of 2019, Class of 2020, University staff, Graduated members, etc.). While it may seem trivial with a few people in the beginning, it is useful as the organization grows. If someone wonders why someone is part of a repository or if they are still participating in the club or organization, it is easy to see whether the student is still on campus or whether they are a graduated alumnus or alumna.

Use organization for on-boarding 🔗

Organizations are a powerful tool for bringing new people into your club or group. The moment someone receives an email inviting them to be a member of the GitHub organization, it holds a certain weight. “Wow, I’m officially a part of this thing!” It’s a great way to create an inclusive environment and enable new contributors to feel like they are a part of the team.

Having a team for newcomers or new recruits is helpful to have in place beforehand. The group doesn’t have any real permissions in the organization, but it is a temporary holding ground for new members while they figure out their position in the club. But this way, they get to be included in the member list and show off your organization’s logo in their profile if they choose.

Publicize your membership on GitHub 🔗

If someone is in your organization, make sure you encourage them to show it off! By default, GitHub sets the team member visibility to private. Unless a member of the organization sets themselves as public, they won’t appear as a part of the organization to visitors.

Publicizing your membership is an underestimated step in bringing new contributors in. It’s even helpful for older members too. By publicizing memberships, you are giving faces and real people to characterize your organization. If someone finds your organization in a search or in a link, it looks better to have rows of people associated with the group. The alternative of a team with what looks like no members implies your club is inactive. It can also make your club look smaller than it is. Additionally, individual team members also get to show off your organization on their individual profiles. This is helpful for anyone visiting their profile for activities or programming experience. For university students, this is helpful for applying for co-ops or internships.

To make a membership visible, the organization member has to go to the “People” page of the organization. On the page, next to their name, there is an option for “Public” or “Private” in a drop-down menu. Change it to “Public”.

Consider repository for tasks 🔗

While not essential, a repository for real-life tasks or issues in a club can be a helpful planning tool. It also makes it easy for people to see what the club or group is working on. This promotes the idea of transparent and open leadership. You can use labels to tag issues for specific types of work or committees. Milestones are useful for deadlines or goals the group is working towards. The new Projects feature may also be useful in a repository for real-life task management.

For an example of a repository like this, you can see the FOSSRIT/fossbox-tasks repository on GitHub. We even planned a dinner on GitHub!

Go forth and conquer! 🔗

Congratulations! You now have some basic knowledge and ideas on how to effectively use GitHub organizations for a club or small team. While this guide is not completely thorough, it helps give some starting points to consider when you’re setting up your organization for the first time. It’s also never too late to make changes later, if your organization is already formed.

If you have questions, comments, or feedback, I’d love to hear about it! Feel free to leave a comment below.

What is a rainbow cookie? 🔗

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

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

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

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

Thank you! 🔗

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

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

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

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.

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.

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.

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

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!

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.