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.

Product roadmaps are something many projects struggle with. It fits into the communications and outreach umbrella, which unfortunately is typically an underresourced part of many open source products. They are one small part of a larger strategy around openness and transparency. If customers and stakeholders know what to expect, they gain more confidence in the product and company mission. For instance, this is especially true when the company continuously delivers on its roadmaps and meets its ambitions. As a result, delivering on those ambitions leaves a strong impression.

Highlights from Proton product roadmaps 🔗

Of particular note, these product roadmaps do the following things well from a messaging point-of-view:

1. Builds context with previous work delivered in the last year for the product.

2. Several clearly-defined goals and ambitions for each product are defined and explained. The aspirations for the coming year are spelled out and users can begin to form realistic expectations about what new features to anticipate.

   • Some highly-motivated individuals may use this as an opportunity to make their first contribution to the product, whether in the form of feedback or code.

3. Strong call-to-action at the end of each article, where Proton defines how people can participate and engage with feedback about the products.

Check out each of the three product roadmaps below and let me know what you think about them in a comment on this post.

Proton Mail & Proton Calendar 🔗

[…] we want to provide an update on what’s coming next for Proton Mail and Proton Calendar. As 2022 wraps up and we look into the new year, we want to develop stronger protections against technologies that invade your privacy, improve your reading experience, and make your day more productive through deeper integrations between our products. 

proton.me/blog/proton-mail-calendar-roadmap

Proton VPN 🔗

In March, we shared our 2022 roadmap for Proton, including Proton VPN. Now that we’ve reached November, we feel it’s a good time to revisit our progress this year and explain what you can expect from Proton VPN in the near future.

protonvpn.com/blog/proton-vpn-roadmap-spring-2023/

Proton Drive 🔗

In September 2022, we were excited to launch Proton Drive and introduce the first standalone Proton Drive paid plans. As with all the services we’ve rolled out over the years, we know the launch is just the first step. The real work is in the continual improvements, advancements, and added features that follow. Building an encrypted file storage service is not easy, particularly one that uses end-to-end encryption on both your files and file metadata like Proton Drive.

Many of you have asked us what is next for Proton Drive, and today, we wanted to share with you a short-term roadmap of what you can expect in the coming quarters. Of course, we also have longer-term roadmaps. We look forward to sharing those and keeping you updated on the latest developments as Proton Drive progresses.

proton.me/blog/proton-drive-roadmap

Photo by Slidebean on Unsplash. Modified by Justin Wheeler.

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

But over time, I blurred the lines between personal and professional communication. The emotional words in my vocabulary were gradually phased out through my formal education. There were many influences on the sculpting of my voice. High school teachers critiqued writing styles for A.P. exams. Communication professors clearly outlined how to write business emails in a level of detail I didn’t know was possible. These experiences showed me one way communication could be more direct and effective.

But I believe I may have mistaken professional communication as the only kind of communication. My education prepared me to understand scientific research studies and how a compiler works, but didn’t teach me how to listen to my heart and put words to the emotions I was feeling.

So, now looking back at my blog history, it feels like reading a news site instead of these personal slices into my thinking and what is going on for me at any given point of time. I retained some of it in the beginning, like with my annual Year in Review posts that last published in 2017. But now, there is little here that I think gives meaningful insight to who I am outside of the context of technology or open source.

Indeed, despite being the sole author, publisher, and editor of my own blog, there still seems like a great deal is left unsaid. I cannot speak words where there was already silence, but I can choose to break the silence. So, here is to breaking silences and finding your voice.

This post does not describe what the Principles are (click that link to learn more about them). This post describes the story behind the Principles, and how our Sustain Working Group worked together over three months of virtual facilitation during the COVID–19 crisis to build these Principles.

Overview 🔗

This blog post is a story, or perhaps open source lore. So, here is the abridged summary:

1. The Sticky Idea: How did a discussion topic at a one-day open source sustainability conference evolve into a three-month extended collaboration?
2. Facilitation, Roosevelt-style: The people are here. How do you facilitate a conversation with no scope and few bounds?
3. Is there a next chapter to this story?: The Working Group is winding down. What happens to the Principles next?

If you are hooked, read on.

The Sticky Idea 🔗

How does a discussion topic at a one-day conference evolve into an inter-organizational, international collaboration that spans three months?

When the accountability and transparency discussion groups formed at Sustain Summit 2020, none of us knew what would come after the event. Not to mention, there were several different sustainability topics explored at the Summit.

So, the conversation about corporate accountability was about the same as every other conversation during that morning: someone was motivated enough to step up and say, “I’ll do it – I’ll facilitate this conversation!”

Open Source Accountability Goals 🔗

Duane O’Brien volunteered to lead facilitation on defining goals for open source accountability. Duane proposed four goals to iterate on in the Summit break-out groups:

1. Set and publish a goal for open source contribution relative to value capture
2. Adhere to principles of authentic participation
3. Publish documentation of open source policies, processes, and project governance
4. Well defined reporting process that is publicly available

The morning discussions broadly focused on these goals. After the ice was broken and conversation was flowing, themes and patterns emerged in the stories we shared with each other. Later that day, Allen Gunn asked me if I would lead an afternoon discussion session. The second goal, these principles of authentic participation, were personally interesting to me, and the morning group was engaged too. So I said, “Yes, I’ll do it!” Even though I did not really have any idea what I was going to do yet.

Facilitation of Authentic Participation discussion 🔗

After lunch, I gathered folks for the discussion group to discuss what authentic participation means. If we could propose a basic set of principles that we agree on, could this be a useful tool for the pain points of stories shared in the morning session?

The afternoon discussion was insightful, but lacked firm conclusions. We had great ideas and lots of stories, but nothing to tie them together. I collected email addresses of folks who wanted to continue engaging on the Principles of Authentic Participation. However, I wasn’t sure what the next step would be at the time.

At the Summit, I committed to facilitation of a public Discourse forum discussion, but some attendees voiced that Discourse was not accessible for them. To compromise without exhausting myself across too many platforms, I promised to host a few online discussions for folks to gather and talk about these things again later.

The embers were hot on this discussion at the Sustain Summit. But it was still just embers. How do we get these embers to “spark” into something bigger? Enter the Fireside Chats.

Facilitation, Roosevelt-style 🔗

So, skip ahead a couple weeks. I was ready to push the conversation forward. The time was right for the first follow-up email to the discussion group participants. As promised, I opened a Discourse discussion that summarized our notes from the conference and asked open-ended questions. Later on, I announced the first of four Fireside Chats. The Fireside Chats became the primary vehicle of collaboration for the working group.

Text-based communications are my preference. But video?? I would have to swallow my introverted shyness if I was going to lead this. I never facilitated an online discussion group before. There were also not many public examples to learn from either. The style I took to the Fireside Chats was mostly my own. I relied on my past experience of facilitating open source project meetings and development to drive these Fireside Chats. And I borrowed a little inspiration from former American president Franklin D. Roosevelt’s fireside chats during the 1930s/1940s.

For the first Fireside Chat on 2020 February 28th, I had no idea what I was doing. I prepared a loose agenda, but I left it broad so people could bring their own interests and passions into the conversation. I figured doing this would allow people to bring their own needs, desires, and wants to the conversation. It was unrealistic to expect a collaboration driven by my own motivations.

A successful collaboration requires all participants to have an opportunity to satisfy their own personal motivations for showing up in the first place. So, my approach centered our collaborative work on the group and not just myself, to avoid a high initial interest that dwindles down over time.

How did facilitation start? 🔗

The first Fireside Chat was exploratory. It was our first time talking about the Principles since the Sustain Summit. We caught back up on where we left off, detailed what we wanted to get out of this collaboration, and began scoping out what we thought we could accomplish together.

Although the first chat was mostly unstructured, it was essential to to identify themes and ideas that led to more focused, structured discussions for the next three Fireside Chats. The Discourse thread was also useful as an accessory for the Fireside Chats. I published notes from each Fireside Chat on the Discourse thread, and there was some asynchronous discussion between Fireside Chats.

Beyond the first Fireside Chat, the agendas became easier for me to write and the feedback became more focused. Fortunately, most of this work happened in public on the Discourse thread. So, if you are curious for more details on how the final three Fireside Chats went, take a look at the discussion thread.

Is there a next chapter to this story? 🔗

For now, the Principles of Authentic Participation Working Group is going dormant. We met our original goal of drafting some basic principles.

So, now what happens? So, let’s try to predict the future! (That can’t be that hard, right?)

My hope is that the Principles of Authentic Participation leads to more story-telling about what it means to authentically contribute to open source, whether you are an individual or an organization. To help curate the stories, I created a template to encourage folks to share them with us. The template provides question that makes it easy for a maintainer to copy and paste the story into our published Principles of Authentic Participation website.

Whether this hope comes true or not, we will see. But the Principles have a life of their own now. It doesn’t mean the Working Group will never meet again, or that we won’t revisit these ideas over time. But these Principles are now the “property” of the community to continue building. I will continue to participate where I can to curate stories about the Principles.

Closing thoughts 🔗

My hope in sharing this story is to help other facilitators and activists in the open source world approach digital-only organizing. Digital facilitation and organization is a skill we are all learning, for better or worse, in a COVID-19 world. But it isn’t a new skill. Lots of folks have been doing this for a long time, especially in the digital-first world of open source.

So, I hope this paints a picture of how we pulled off the Principles of Authentic Participation and how others can take what we did and improve on our processes.

It is possible to work collaboratively with new people on digital initiatives across different backgrounds and sectors. Remote facilitation is someone being brave enough to step up and lead, even if they have no idea what they are doing. After all… isn’t that what many other white American men like me do anyways? So can you.

There are several new and noteworthy changes in TeleIRC v2.0.0. This post walks you through the major changes and differences for TeleIRC v2.0.0. Read on for the highlight reel of this release.

Full rewrite to Go 🔗

TeleIRC v2.0.0 is a complete and total rewrite. With the lessons learned and best practices of the NodeJS v1.x.x releases under our belt, the team set out in September 2019 to rewrite TeleIRC in Go. The rewrite was motivated by fun and personal interest, but it was also intended to make the future of TeleIRC more sustainable.

The rewrite makes TeleIRC simple, fast, and lightweight. TeleIRC is unique from other chat bridge software, which usually focus on extensive configuration and supporting many chat platforms.

Additionally, the success criteria in order to release was feature parity with v1.x.x releases. The team accomplished this almost completely, with one exception. TeleIRC v2.0.0 does not include Imgur image upload for IRC; however, a v2.1.0 feature release will include Imgur support.

To summarize, TeleIRC v2.0.0 is written to be a simple and excellent Telegram <=> IRC bridge. No more, no less.

Run TeleIRC v2.0.0 as a compiled binary 🔗

The new release is available as a standalone 8 MB binary. The only deployment assets needed are the binary and a config file. Other pathways, including build from source and Ansible Roles, are also available.

This is a departure from TeleIRC v1.x.x releases, which required a NodeJS run-time and installing project dependencies. TeleIRC v2.0.0 does not require a Go run-time on the host.

Improved TeleIRC v2.0.0 documentation 🔗

End user feedback shaped and improved documentation during development.

Thanks to feedback collected during the pre-release process, the documentation is simplified and written to be easy to understand. We hope you find the TeleIRC Quick Start page a helpful introduction to getting TeleIRC running in little time.

Future roadmap for containers 🔗

Because of v2.0.0 design decisions, there is a planned future for container and container orchestration use cases. At release time, a Dockerfile is available, but it is not yet tested or documented.

In future releases, the TeleIRC Team will continue to test the container image and iron out bugs. Future deployment assets and documentation will offer pathways to run TeleIRC in Kubernetes or OpenShift v4.x.x.

Article format inspired by Ryan Lerch’s format for “What’s new in Fedora Workstation”.

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

Use alt tags for Markdown images 🔗

Often an embedded picture in Markdown looks something like this:

![Screenshot_2019-06-14.jpg](https://example.com/Screenshot_2019-06-14.jpg)

When you render the Markdown, you see your picture. However, you don’t see the Screenshot_2019-06-14.jpg string. You might wonder what its purpose is or why bother changing it at all. But imagine for a moment if instead of seeing your picture when you rendered your Markdown, you only saw Screenshot_2019-06-14.jpg where your picture should be. Screen reader users often encounter this problem.

So instead, describe your Markdown image so a person that uses a screen reader can also follow the conversation:

![A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers](https://example.com/Screenshot_2019-06-14.jpg "A flowchart describing how user data flows from a publisher, to a proxy, and to a group of subscribers")

It takes an extra few seconds of your time, but it is one small way you can help make a better Internet for everyone.

P.S. – The text wrapped in quotation marks between the parentheses adds the title HTML attribute to your image, so the text appears as a tooltip when you mouse over the image. The more you know!

Photo by Roman Kraft on Unsplash

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.

Human aspects of open source governance - Sustain OSS London 2018Download

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.

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.

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.

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!

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.

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.

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.

Communicating between Ambassadors and Design 🔗

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

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

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

Long-term, though… 🔗

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

Communication by Lorenzo Stella from the Noun Project.

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.

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 have stumbled across a single communication platform that exceeds the standards of any other application I’ve used before: Telegram. And guess what? I’m about to tell you why it’s a useful way to communicate over other traditional means.

The case against SMS 🔗

In terms of traditional communication, SMS, MMS, or text messaging (whatever you might prefer to call it) is obviously one of the most dominant forms of instant communication. However, in terms of a modern communication platform, it has several flaws that make it difficult to use effectively for effective communication. So, why not SMS?

Domestic and international costs 🔗

This one simply speaks for itself. Text messaging has long been an expensive form of communication in terms of paying per message or having a cap to work around. While this is beginning to change for domestic messaging, it is certainly not the case for international messaging. As a result, most domestic communication is likely using another form of messaging (even if it’s disguised to look like regular SMS, such as iMessage), and international communication rarely, if ever, considers using traditional SMS. In terms of either saving your wallet or preventing paranoia from going over a cap, SMS is not a cost-effective solution for communication.

May your carrier have mercy 🔗

Mileage may vary with this, but often times, how reliable your carrier is leaves you subject to the stability of their network and whether or not your hardware is compatible. In my case, I am a proud owner of an HTC One M8 running CyanogenMod 12.1, but Sprint has granted me the privilege of having a nearly dysfunctional networking capability on their cellular network. A challenge I have had to face my entire time on Sprint is traveling through an area that clearly has coverage, such as New York City, without being able to use any networking capabilities on my phone. I have had to quietly enter a coffee shop just for free WiFi when traveling far… far too many times.

This is an issue I intend to resolve next upgrade… or maybe next carrier… but point and case being, using SMS / MMS for communication is only as reliable as your carrier allows. There’s no guaranteed way to make sure receipt of your messages, and now I can never be sure if an unreturned message is from lack of interest or lack of receipt.

Why Telegram? 🔗

With that out-of-the-way, I can focus on the main argument I want to present. So of all the different communication platforms available, why use Telegram? What makes it different from everything else and how is it better?

Multi-platform 🔗

This is always the first thing that I notice is that Telegram supports just about everything… literally. From iOS to Android to Windows Phone to Windows desktop app to OS X desktop app to Linux desktop app to Firefox OS to a web platform and more, it’s hard to think of something you can’t use Telegram on… except maybe a brick phone from the early 2000s.

The benefits of Telegram’s multi-platform availability is that it makes it easy for your friends or co-workers to get it running quickly and easily on whatever it is they use. As a Linux user, I was particularly pleased to see the beautiful design of the desktop app, something that is sometimes a rare sight when using software outside of your distribution’s packages. Additionally, since I use a computer far more often than my Android (maybe for the reasons mentioned earlier), having a desktop app is a great convenience for me and makes it easier for me to keep in touch with my friends, family, and other contacts without having to keep my phone out next to my laptop too. That might sound silly, but it’s the way I work personally - which only goes to show that whether you’re someone like me who uses a computer more than a phone, or if you use a phone more than a computer, Telegram will fit your own habits.

Try to find a device made in the past two years that can’t use Telegram one way or another!

Fast and reliable 🔗

Speed is always nice when it comes to instant messaging, and if you’re having a back-and-forth conversation with someone, you want your messages to send quickly and reliably. The overall speed of Telegram is near flawless, and it honestly is right on-par for speed expectations for any messaging platform available in 2015.

Not only is it fast, but it’s also reliable. You’ll know instantly if your message delivered successfully by a check mark next to your message once you send it. If the person you are talking with hasn’t disabled them, you will also receive read receipts for when they have read your message. This makes communication consistent and reliable, and whether or not your message is received by your contact isn’t something you’ll have to worry about.

Secure 🔗

Finally, Telegram is also a platform you can trust. On the Electronic Frontier Foundation’s Secure Messaging Scorecard, the platform as a whole receives a 4/7 and the secret messaging feature receives a perfect score of 7/7. It’s a non-commercial product that has high value in privacy, something that is respectable and admirable in the current day and age.

Get Telegram today 🔗

It actually feels super cheesy to use that action line, but I honestly love Telegram. Ever since I originally installed it from the recommendation of one of my own friends, I am always amazed by the quality and availability of Telegram as a messaging platform. It makes it easier to keep in touch with family, friends, co-workers, fellow students, and all of my contacts. It has definitely become a staple of my everyday communication, and I sincerely recommend it not as trying to hook you on it, but as a fellow member of the sometimes overwhelming digital world in which we live.

Hopefully you will find Telegram as useful as find it.