Welcome to The Roundup #10, your bytes of Solus news. In this roundup we are focusing on improving community engagement, reducing barriers to entry, and improving the delivery of Solus news.
We believe good communication is the cornerstone of a healthy community. We always strive to actively communicate with our community and understand that it’s never a matter of just talking at our community, but listening and having a conversation. We can’t implement feedback or make changes unless we listen, engage, and sometimes debate.
Sharing the happenings of Solus to our community occurs across a variety of platforms and services. As we’ve grown as a project and as a community, we’ve been increasing our presence on various platforms. Doing so enables our community to check for Solus news on the platform that fits them best, or the best middleground between what those of us on the Core Team want to use and what is most comfortable for our community members.
Back in the EvolveOS days, this was Google+, our old Wordpress site, Forums, and IRC. Since the EvolveOS days, we’ve expanded to other platforms like:
To this day Google+ still remains one of the most engaged platforms, one which all of the Core Team is available on, and the Google+ Communities feature is one which is used almost daily by our community members and us. In fact, Google+ Communities is one of our favorite systems to interact with. With the unfortunate announcement by Google of their sunsetting of Google+ over the next 10 months, we wanted to take this opportunity to improve communication and engagement across the board.
To do this, we need to address multiple aspects of communication and engagement.
1. Avoiding echo chambers.
We want to provide avenues of communication and engagement that both the team and our community want to use. If the team isn’t interested in using a platform or service (self-hosted or third-party), that just ends up creating an echo chamber where only the voices of our community reside, where they may not feel like we are responsive to their feedback. That isn’t something we want. On the other hand, we need to use a platform or service that our community wants to use, otherwise it’s just an echo chamber of the voices of the team, with little to no engagement from our community. That isn’t something we want either. For example, the Core Team rarely uses the Solus Forums, rather we gravitate towards more social platforms with real time or near real time engagement (such as Google+, Mastodon, Reddit, Twitter).
So ensuring we choose platforms and services that all parties want to use is absolutely crucial.
2. Making it easier to talk about Solus.
There is always Solus news for us to share, whether it’s something major like a release announcement, or something less significant like a new feature or package update. However, these updates would sometimes be posted in a manner which wouldn’t necessarily result in the entirety of our community being made aware of them. Trying to ensure news gets out to all of our community can sometimes be difficult, just as getting news about Solus can be. We want to make the entire process easier.
3. Reducing barriers to engagement.
To make it easier to engage, we need to reduce the steps to actually doing so, on the platforms we intend on using. Let’s lay out some examples where you may need a new or dedicated account:
#budgie-desktop-dev) you will need a freenode account.
We want to reduce this as much as we possibly can, as well as be cognisant that some may not wish to have a million accounts, or accounts of platforms such as GitHub, to engage.
With the sunsetting of Google+ and thusly Google+ Communities, we want to provide a more modern alternative to our forums that not only our community would like to use, but we’d like to as well.
At this moment in time, Flarum is looking like the most appealing option, from both a UX and technical perspective. The Flarum UX is more appealing to us as a result of it delivering a more tag-oriented layout as opposed to topic-based layout, which will make it easier for us to organize content. Additionally, they have plans on introducing a hybrid approach to pagination, which is more appealing to some members of the Core Team.
After assessing the Flarum API, I’m of the opinion that it will overall be easier for us to build open source tools and login methods against it.
For real-time communication, IRC is still in our opinions a mature and reliable standard. However, we are open to additional services in the future, but would do so under the expectation that they meet the following requirements:
We have yet to find a solution that does all of the things listed above. We’re opposed to introducing non-compliant options for real-time communication (like Discord, Mumble, Telegram, etc.) as it unnecessarily fragments our community, as well as makes providing support harder and more time consuming.
The team should be enabled to share news about Solus with the entire community, as easily as possible. Fewer accounts, clicks, copy / pasting, and time spent. To do this, the intent is to create an open source broadcast system which we can tie into various frontends, whether that’s web-based or even on IRC (like with a plugin for the IRC bot I’m developing). It should be able to post to as many platforms as possible, such as:
Additionally it should be able to automatically generate Hugo content pieces (a mix of TOML and Markdown), so we can implement a centralized Solus news “hub” so you can see all our short and long form posts in a single place. Naturally, it would support the ability to get the latest posts, so in theory we could figure out a way to integrate that into an RSS feed that people can follow, a Raven widget, Software Center, or elsewhere. Really we’d have limitless options. For our needs, a custom solution is a better option over the likes of Buffer or Circular, since we’re able to more closely curate the services we support. For example, Buffer doesn’t support Mastodon, which means we’d have to manually post updates there.
For the blog, I’m currently working on a redesign that will enable us to feature multiple pieces of content and hopefully make content consumption easier. This will later be integrated into the News hub so all relevant activity from the team (posts, blogs, etc.) can be discovered in a single place.
In addition to the above mentioned areas, there is also the opportunity to improve and simplify engagement across two other areas of Solus development:
For projects currently hosted on GitHub, we should determine which ones are candidates for migrating to our development tracker (Phabricator), develop processes for tagging new releases and surfacing them on our planned development hub (Solhub) or generated project pages. Some of these projects may include our Software Center, Installer, ypkg, etc. In general, Peter and I have some ideas on using Phabricator’s tag system to make it easier to tag specific pieces of software (as an example,
qt-creator) and ideally that should extend to software developed on Phabricator.
For translations, we should ideally migrate from Transifex to something which is:
Currently I’m assessing Pootle and Weblate. If you have any ideas on other platforms we can use, we’d love to hear from you. I want something that makes it not just easy for developers, but translators too!
Some of the items I’ve mentioned in this blog post are ones which will take time to build, test, and improve upon. So over the course of the next several months, the plan is to tackle the following items:
There are always other ways of improving community engagement and reducing barriers to entry. If you have any suggestions, you’re always welcome to reach out via to us via the Forums, IRC or social media.