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.

Download TeleIRC v2.0.0 now! 🔗

If you want to skip the text and get to the software, head to the GitHub v2.0.0 release for more info. If you want the story behind this release, read on!

Eight months later… 🔗

The conversation started in a university hallway after the first RIT Linux Users Group meeting in the Fall 2019 semester. Together, Tim Zabel, Nicholas Jones, and Justin Wheeler set out to rewrite TeleIRC from NodeJS to Go. This was done to address a growing backlog of challenging feature requests on TeleIRC, but also a way for us to gain more experience working with Go. Along the way, we also ended up facilitating an agile-inspired software release process adapted for open source.

So, what happened in the eight months after the first conversation? The team meet for weekly meetings each Saturday afternoon (at first in-person, later virtually), two new core contributors joined the team, and some drive-by contributors provided feedback andf added code to the new release. There were charts, whiteboards and dry-erase markers, and lots of Blue Jeans video calls. But after all this time, we made it to release day!

Thank you amazing volunteer contributors! 🔗

This endeavor was a shared commitment by our volunteer committer team. All five of the volunteer core maintainers spread patience and sustained effort over time. At the end, we made something really cool to show for this work.

A huge thanks to our core maintainers and all current and past contributors to TeleIRC. You have all contributed to the success (and motivation!) for this project. It is fun to work on cool projects with friends!

A proper shout-out goes to the core maintainers who joined the team over the last eight months working on this release:

• Kennedy Kong
• Kevin Assogba
• Nicholas Jones
• Tim Zabel

“I found a bug in TeleIRC v2.0.0!” 🔗

If you run into a problem, check out the TeleIRC documentation and open an issue if it does not answer your questions.

Get in touch! 🔗

If you have questions, get in touch with the developer community. You can find us on Telegram and on IRC (#rit-lug-teleirc on chat.freenode.net).

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”.

What’s coming in TeleIRC v2.0.0? 🔗

TeleIRC v2.0.0 is a complete rewrite of TeleIRC. The team is migrating the code base from NodeJS to Go. In September 2019, the team began scoping the requirements and how to approach this large task. TeleIRC v2.0.0 does not add new features, but aims to have feature parity with the v1.x.x version of TeleIRC.

You might be asking, why bother with a total rewrite? What does this actually accomplish for the project? To answer this question, some historical context is needed!

TeleIRC v1.0.0 was an experiment. 🔗

TeleIRC v1.0.0 was originally created and released in September 2016 by RIT alum Mark Repka. Mark created TeleIRC as a cool project for the RIT Linux Users Group (RITlug) when he was a student and vice president of RITlug. The project was written in hackathon spirit: to prove that something that was not yet common wasn’t that hard to do.

Fast forward to today: TeleIRC ends up being pretty popular! As do chat bridges (Matterbridge, Matrix/Riot, etc.) as a whole. The Fedora Project is one of our largest users, with a dedicated Special Interest Group to manage the bots. The LibreOffice community is another one of our biggest users. Several international communities also adopted TeleIRC to make their chat rooms more accessible to a new generation of open source fans. Some example users are Linux and BSD user groups and hackerspaces in Argentina, Albania, and across Asia. You can see the full list of TeleIRC users for yourself.

TeleIRC has grown in a way we never thought it would. Which is awesome! But the project was not originally designed to grow or scale the way it has. Additionally, by being at a university, contributors come and go as students graduate and move on to industry. We also have to think about how to maintain TeleIRC beyond the typical student life-cycle common in the academic world.

Let’s approach TeleIRC v2.0.0 as engineers. 🔗

A full rewrite allows us to fully leverage our knowledge as software engineers. In 2020, we know TeleIRC has a large user community and is an important part of how many open source communities communicate. We also know that breaking code into smaller, more modular pieces makes it easier to maintain and bring in new contributors. A full rewrite allows us to apply the lessons the team has learned over the years, in a way that incremental feature releases does not allow.

A few areas are in clear focus for the TeleIRC v2.0.0 rewrite:

1. Write clean, simple code that is easy to understand
2. Test the code so it is easy to tell when things are working and when they aren’t
3. Think about how to bring in new contributors to continue the project in the future

But maybe you are also asking, why the jump to Go?

A Go rewrite distinguishes our project. 🔗

When Mark and I launched the project in 2016, we didn’t look around to see if anything else like RITlug’s TeleIRC already existed. Turns out, there was another NodeJS project with the same name. Skip forward a few years, and there are also projects like Matterbridge, pytgbridge, and other implementations. So, with all this commotion out there these days, why bother with our version of yet another chat bridge?

First, there is one design principle guiding our project from others like us: to do one thing and to do it well. Matterbridge is an excellent tool, and we even use it in conjunction with TeleIRC at our university. However, it is a complex tool with many features and options. For some people, this is a non-issue. But the TeleIRC team likes to think there is beauty in simplicity. Instead of offering a tool with the most features and configuration options, we aspire to do a single thing and to do it really well: connect Telegram groups and IRC channels together.

Second, although the FruitieX/teleirc project is archived today, it was once the biggest alternative to our project, also written in NodeJS. When we decided to launch TeleIRC v2.0.0 development, it had a larger community and user base then ours. So instead of offering a “similar but different” NodeJS project, we would be the first Telegram-IRC bridge written in Go. (Yes, Matterbridge is also written in Go, but see the above paragraph.)

Third… many of the existing maintainers of TeleIRC simply wanted an excuse to learn Go. It is an opportunity to expand our knowledge, experience, and skills, especially since we are students preparing to enter the industry.

Go has a better story for Kubernetes / OpenShift. 🔗

Finally, we are carefully considering the needs of one of our biggest downstream users: the Fedora Project. Several TeleIRC developers also support Fedora’s TeleIRC SIG. Recently, the Fedora Infrastructure team launched an OpenShift instance for the Fedora community, called Communishift. All existing infrastructure in Fedora is gradually moving from virtual machines or OpenStack to OpenShift. To support this migration, we want to make a Go-based TeleIRC as easy to deploy in OpenShift as possible.

And fortunately, Go has a great story in the container orchestration world. Kubernetes and OpenShift are also Go-based projects. Go is the dominant language of this ecosystem. Its excellent performance in the niche of networking makes it a great choice for what TeleIRC does.

Now that you know more about the “why is this happening,” let’s talk on where things are and what you can expect!

TeleIRC v2.0.0: Progress so far 🔗

TeleIRC v2.0.0 is approximately 76% complete. All progress is tracked in the v2.0.0 milestone on GitHub. 46 issues and pull requests were closed since we began in September 2019. At publishing time, about 16 more issues and pull requests are left before we cut the v2.0.0 release.

Earlier in 2019, the maintainer team consisted of Justin Wheeler, Tim Zabel, Seth Hendrick, Nate Levesque, Nic Hartley, and Robby O’Connor. Now joining the committer group, we are happy to welcome Nicholas Jones, Kevin Assogba, and Kennedy Kong to the team. The current core group of maintainers for v2.0.0 are Justin, Tim, Nicholas, Kevin, and Kennedy.

When to expect TeleIRC v2.0.0 🔗

TeleIRC v2.0.0 is targeted for a release date of Friday, May 15th, 2020. At this point, we expect to have full feature parity with the v1.x.x version. We will recommend all existing users to upgrade to the latest release then.

In the meanwhile, the team is getting ready to cut a v2.0.0-pre1 release, our first “pre-release” of the Go port. We expect this release to be available on our Releases by Saturday, March 28th. Along with the v2.0.0-pre1 release, there are a few other details to note:

1. TeleIRC v1.5.0, the final version of the NodeJS version, will be released.
2. No future contributions will be accepted to the NodeJS version.
3. master branch in git will reflect the latest Go version of TeleIRC.

Once the v2.0.0-pre1 release is available, we want help to take it for a test drive! If TeleIRC is critical for you, we do not recommend using it yet, as it does not have full feature parity yet. But your early feedback can help improve the future of the next release while we are in active development.

Get involved with TeleIRC! 🔗

You can be a part of the upcoming TeleIRC v2.0.0 release. We’d love your help! There is no formal commitment to contributing, although we ask for participation through a single sprint cycle.

Read our Contributing guidelines on how to get started with TeleIRC. Virtual developer meetings take place every Saturday at 15:00 US EDT, so anyone can join and participate.

Come say hello in our developer chat rooms, either on IRC or in Telegram!

Background photo by Daria Nepriakhina on Unsplash.

Special thanks and appreciation goes to Tim Zabel and Nic Hartley for their contributions this release cycle.

What’s new 🔗

• Bold usernames in message prefixes (#134, Nic Hartley)
• Include filetype in IRC string when a document is uploaded on Telegram (#139, Tim Zabel)
• Include zero-width space in username for join/part messages to group (#139, Tim Zabel)

Additionally, contributor documentation improved. I added contributor guidelines and instructions to set up a development environment. Also, our friends at Ura Design designed our new project logo. Thanks to Ura, we have an awesome project logo and stickers in time for Imagine RIT 2019 later this month!

They're here! Check out our new @uracreative logo and stickers for the #TeleIRC project. Grab some stickers at the @RITlug @Imagine_RIT festival on April 27! pic.twitter.com/KGjT4F0qdY

— RIT Linux Users Group (@RITlug) April 17, 2019

TeleIRC v1.3.1: sprint retrospective 🔗

Originally, we planned to release v1.4 at the end of this sprint. For a number of reasons, this did not happen. We decided to reduce our scope and finish strong with a bugfix release instead of the originally-planned feature release. This retrospective summarizes “lessons learned” for future project sprints with a team of university students.

Extended holidays are sprint bookends 🔗

In the last sprint, our university had a week-long break from classes. Most students use this time to visit family or travel outside of Rochester. Originally, we agreed to pause the sprint and resume when we returned. In retrospect, it didn’t work out like that.

It was harder to start again when we returned from the break. Instead of an extended holiday acting as a pause in an ongoing sprint, extended holiday breaks should divide two separate sprints. The breaks from classes are personal time; working on projects is not possible for everyone. The interruption caused by a break impacts productivity of the team. Therefore, future sprint planning will take the university calendar into consideration.

Adjustable sprint length to semester 🔗

Sprint lengths should have an adjustable length depending on what part of the academic semester the sprint is. For example, earlier this semester, we released v1.3 in a two-week sprint. For this v1.3.1 release, it was over a month. What happened? Should sprints have a variable length?

When working with an academic crowd, variable sprint lengths are worth considering. The first half of a semester typically has less assigned coursework. Final projects are not at play. Therefore, usually team members have more time to invest in the project at the start of a semester. Towards the end of the semester, coursework and class projects pile on and make it difficult to find bandwidth to work on side projects like TeleIRC.

The compromise is keeping our sprints short at the start of a semester and stretching them out as a semester goes on. This gives students more flexibility to work at a pace that encourages quality work but isn’t overwhelming with other responsibilities of being a student. Going forward, we will try variable-length sprints in the Fall 2019 semester.

Get involved with TeleIRC! 🔗

More opportunities are coming to participate with TeleIRC! The team is happy for new people to join us. Opportunities are available for short-term and long-term contributions.

Come say hello in our developer chat rooms, either on IRC or in Telegram! Watch for TeleIRC development reports on my blog for more announcements.

Background photo by Daria Nepriakhina on Unsplash.

What’s coming in TeleIRC v1.4 🔗

TeleIRC v1.4 is the next feature release of TeleIRC. The targeted release date for v1.4 is by the end of April 2019 (i.e. the end of the academic semester for students involved with the project). Following v1.4, the project will likely enter brief hibernation until Fall 2019 when the RIT academic semester begins again.

At the developer meeting on March 23rd, we discussed the scope of this sprint and what we felt is realistic for project maintainers to work on:

Primary goals 🔗

• Include limited characters from Telegram replies in relayed IRC message (RITlug/teleirc#51)
• Create doc page on development environment (RITlug/teleirc#77)
• QoL Improvements: show file-type of documents in IRC, insert ZWP character in join/leave messages (RITlug/teleirc#130)
• Allow user to configure more variables for IRC server connection (e.g. port, SSL certs, etc.) (RITlug/teleirc#113)

Secondary goals 🔗

• Add Telegram-side highlighting for IRC messages prefixed with username (RITlug/teleirc#44)
• Bold usernames on Telegram and IRC (RITlug/teleirc#19)

Recap of TeleIRC v1.3 sprint 🔗

The TeleIRC v1.3 release follows the v1.2.2 release on December 8th, 2018. This release is a significant change in how project development is done. For the first time, a special interest group inside of RITlug exists around the project. The team shifted to an agile-like development practice to fit inside of the RIT student academic schedule.

A special shout-out is earned by Tim Zabel for his support and participation as a core contributor during the v1.3 sprint.

Get involved with TeleIRC! 🔗

More opportunities are coming to participate with TeleIRC! We would love to have more people get involved and participate in the project. There is no formal commitment to contributing, although we ask for participation through a single sprint cycle.

Soon, we will have better new contributor on-boarding docs. Our weekly developer meetings are now happening over public audio/video call each Saturday at 15:00 US EDT, so anyone can join and participate.

Come say hello in our developer chat rooms, either on IRC or in Telegram!

Background photo by Daria Nepriakhina on Unsplash.

Read on to learn more about what’s coming in TeleIRC v1.3.

What’s coming in TeleIRC v1.3? 🔗

The developers’ meeting focused on identifying critical tasks to work on for the next sprint. The following open issues were identified as essential for v1.3:

• #41: Sending an image with a caption in telegram then editing the caption causes the image to get sent again
• #44: Add Telegram-side highlighting for IRC messages prefixed with username
• #53: multi-line messages should have each lined prefixed with the userid
• #102: Splitting of messages sent to IRC, prepending TG username to each one
• #112: Insert zero-width space in Telegram usernames sent to IRC
• #115: Image url reveals bot’s token
• #118: Refactor documentation into smaller pages (to make it more readable)

Of these, #53 and #102 will be closed by pull request #102. Michał Rudowicz contributed #102 and it should be merged during this sprint window. (Thanks Michał!)

Keep up with more development news by watching the v1.3 milestone on GitHub.

When is TeleIRC v1.3 coming? 🔗

TeleIRC v1.3 is projected for Saturday, March 2nd. For the selected issues, we felt four weeks was sufficient to accomplish and meet all existing goals. If we move faster than expected, we may move items from the v1.4 milestone up to this release.

How can I participate? 🔗

Want to help out or get involved with TeleIRC? We are happy to welcome you! Past contributors have come from all around the world.

Say hello in our Freenode IRC channel, #ritlug-teleirc, or join the Telegram group. You can also look through our “good first issue” tickets in GitHub. If something looks interesting, leave a comment of interest in the GitHub issue and a committer can offer more guidance.

If you are a user and want to share feedback or thoughts with the team, leave a comment on this blog post and they will be shared with the team.

Background photo by Daria Nepriakhina on Unsplash.

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

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

How do I earn Telegraphist? 🔗

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

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

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

The Telegraphist tl;dr 🔗

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