Up first, let's check in with CC-Ari!

Emi: So you've been hard at work on a number of software solutions. Tell me about that!

Ari: Yeah! I've been working on picking up and familiarizing myself with the Go ecosystem! I've been hard at work rewriting an old interface I made in Python for the Poormans Issue Tracker, which will provide simple & flat file issue tracking solution.

Emi: A flat file... huh?

Ari: Right. A “flat file data structure” is a method for storing relational data (that is, data that relates to specific things) where one file describes one segment of data. In the context of an issue tracker, this would likely include things like a status file that describes the status of the issue and a description file that contains a long-form description of the issue. Simplified even further, these files should be plain-text files that contain raw data.

What this means to a user is that, to read a flat file issue (as described by the the Poormans Issue Tracker), a user simply reads the a directory name as the title of an issue. Then, they can read the contents of status and description for more information on the details of said issue. The spec also defines a standard for tags and blockers, but those are beyond the scope of this conversation.

Emi: “Beyond the scope of this conversation...” Has anyone ever told you that you talk like a programmer?

Ari: *laughs* Yeah, that doesn't surprise me. I have a hard time pulling my head down from the clouds when I'm talking about computer tech.

Emi: So what drew you to this problem?

Ari: Well, like I said, this is primarily a way to learn the full Go(-lang) lifecycle. I started off re-building a simple ping charting software that is a standard programming exercise I do in every language that I try learning. You can check out that code over on our git repository. I find it useless to try to learn a programming language without solving a real world issue – and Issue tracking is an ongoing headache of mine.

Emi: For those of us in the collective who don't look at code repositories all day, what do you mean by “Issue Tracking.”

Ari: Okay yeah! Ehm... So you've likely downloaded something off GitHub before (for example). Maybe a mod, maybe a software, who knows. But you might've noticed the “Issues” tab. This is designed for users to report back bugs, software failures, and all sorts of things relating to the software. Open source software thrives on user reporting. Because most open source projects don't have funding to employ a team of testers like most corporate software, bug fixes simply cannot happen without user feedback.

The problem is that GitHub's implementation of issues requires an end-user to log in and provide information like emails/passwords/etc. This bothers me. I don't want my software to require users to expose themselves/trust me with sign-in credentials just to tell me that there is a problem with my code. I feel like the idea of 0-trust issue submission/reporting is a useful tool for obtaining feedback on your software.

Emi: Isn't GitHub owned by Microsoft?

Ari: Yep! And I don't feel like feeding my code and my insights directly into their GenAI bullshit that is actively ruining software efficiency by the day. Why should someone have to burn who knows how much electricity just to tell a software maintainer that it breaks?

Emi: So, you're trying to create an alternative to this? Are you hoping to influence the open source software community?

Ari: Yes, and no. My goal is to create a simple solution that does not require multiple sets of server technologies just to run. Because issue tracking software is not domain specific to coding, this software is not meant solely for coders. As such, it will never ship with tight git integration or pretty web-servers. The goal is to ship a binary that teams can use to generate a consistent set of data and browse said data (via a TUI). Additionally, a future feature is to implement a simple ssh-style application for managing a central repository of issues (that can be checked out as a git submodule).

So is this something I hope makes waves? Not really. Ultimately higher-tier issue tracking solutions like the aforementioned GitHub implementation have their use cases. A simple repository of flat text files and folders and a binary that does not concern itself with users or authentication does not make for a good solution for mid-size teams and up. I just want to make something that works for us as a collective, and that others may be able to use for themselves.

Emi: Okay so how would I use this software?

Ari: So, on release (it’s still in private development), a user would be able to either grab a binary from our releases page, or build from source using Go. Go is a fully portable language, and can cross compile for any architecture so we will be providing pre-compiled binaries for every major modern architecture.

Once you obtain a binary, it has a simple CLI and TUI for browsing, creating, and managing issues. It is our aim that a non-technical user should be able to make use of the project without any knowledge of command line interfaces.

Emi: So when can we expect it to release?

Ari: Well, I’m currently hard at work finalizing the TUI and data lifecycles. Next will be a simple CLI interface, and then ensuring that tests run effectively. At the pace I’ve been going, I would expect release sometime in the next month or two.

Emi: Well that’s exciting! I can’t wait to hear more!

Up next, let’s check in with Nim!

Emi: Nim, when are you gonna get around to making a blog here?

Nim: Oh god don’t pressure me! I’ll get around to it when I have things to post!

Emi: Fine fine, just bugging you! So. You’ve got some news eh?

Nim: Yeah! I’ve been working with CC-Ari on her DJ kit, and I’m super excited to say that we are going to start streaming DJ sets again!

Emi: Oh thats exciting! What’s bringing Ari back?

Nim: I mean, we’ve been talking about what would go wrong with her old live-stream sets. Realistically it truly came down to a dis-satisfaction with her stream setup and streaming space. It took too much energy for her to set up and tear down every day, as there wasn’t a permanent place to keep her rig set up!

So that’s where I come in! I’m working on updated graphics, stream interactions, and a permanent set up for her rig! I’m going to be stepping in as a stream manager, as well as (hopefully) roping in our good friends over at HootOS to help with the workload!

Emi: Amazing! I can’t wait to groove to the streams again! Will you be streaming anything yourself?

Nim: We’re working on how we want to present a collective wide streaming presence, but yes. I do hope to start doing some gaming streams as well as general art streams!

Emi: When do you expect the channel to be live for that DJ stream?

Nim: We’re working on getting it up and running by sometime mid June.

Emi: Well I can’t wait to see it!

That’s all we’ve got in the pipe right now, but be sure to stay tuned to our site!

We're excited about the future here at The Crow Collective. It sure feels bright with so many possibilities open to us. We could release new music, maybe write a photo essay, potentially even make a game? There are so many options that it felt good to have one thing to focus on.

Anywhos, on to the meat and potatoes. In this post we will be discussing the how's and why's of the choices we made with the design. Keep reading to learn more about our logo!

Design & Development Methodology

Unlike the majority of the design work that the collective has, largely under Ari's purview, this design started with a sketch in Procreate.

While generally speaking we as a collective strive to use open source software where we can, this is not a hard and fast rule. We believe it's important to decouple ideology from practice when it comes to accessibility and tool choice. Ultimately, Procreate was cheap when Emi bought it and continues to be one of the most simple design softwares she has to work with. It is vital to us that our members make the choices that feel best for their body/minds. Procreate continues to be worth the investment time and time again to Emi.

Once we had a sketched out idea of what we wanted to make, it was time for Ari & Emi to collaborate on the vectorization. Ari has been wanting to try out the new offering from Affinity (previously Affinity Designer), especially since it moved to a “forever free” release in partnership with Canva. Ultimately, we aren't too happy with the AI shovelware being forced into the software, but we are glad to have all of our design needs in one place. None of us had ever worked with Affinity's vector graphics offerings previously, but we found it relatively intuitive for the simple use case we had. The “jury” is still out on the new software, but we will be sure to keep you – dear reader – posted!

Design Ethos

Emi's perspective

I had a number of goals and priorities going into this project, all centred in my best understanding of non-western/non-colonialist visual design language. It was important to me that this design represent my own journey in coming to understand myself as a person of metís and indigenous heritage. I wanted to go about this design in a good way that honoured not only this heritage, but the privilege I hold in being able to go until later in life without knowing about it. Therefore, I avoided using any specific design elements, and instead focused on a vague merger of organic geometry and fluid brush-strokes.

Furthermore, the iconography of a crow has many meanings both for the collective as a whole and me specifically. Corvids are incredibly loyal to those who treat them with respect. We've all heard stories of corvids and crows bringing gifts and trinkets to people who treat them like the friends they are. Crows and corvids aren't just smart, they exhibit a wisdom I feel we could all learn from. Crows are regularly observed utilizing their environments to create tools and manipulating them to their own benefit. Crows carefully plan ways to better their surroundings, building community with even those beings completely unlike them.

Collective perspective

We as a collective chose crows to embody our ethos because of their resourcefulness. A bird often associated with death and decay, crows are vital to their respective ecosystems. Crows build partnerships, design systems, and exist within their environments – not despite them. We value these traits. As a collective it is our goal to slowly foster liberationary relationship building both with those we engage with through our work and as an ethos and way of being for all.

The fluid brush strokes of the piece complement our values of natural and sustainable growth. By being free to travel where they want to go, not where they would be expected to go. As a crip/mad collective, we wanted our logo to represent the ways in which our lives must remain ever in flux – waxing and waning with the tides of our symptoms. Where a more traditional design may stray away from fluid/thin lines for readability sake, we wanted to explore just how much we could get away with.

We had very few “requirements” that we reached as a consensus, and one of the only ones was the use of organic geometry. We felt that straight lines and hard angles were antithetical to the queer weirdness of our lives. Hell, it says it on the tin: “straight lines” just aren't something we are very good at. Emi did a fantastic job on this front.

As always with all of our works, we intend on revising and revisiting this design as time goes on. Emi is a perfectionist after all! For now, expect to see it tossed in where we can!

We'll write about it further detail in the coming few days, but for now check it out at https://crowcollective.space!

Well, Ari and I have been hard at work designing just that! Well, I should be say, Ari is designing the site and I'm writing the content – but the point remains the same. We want to make something minimalistic that imparts very little visual identity on members of the collective. It's not the goal of the collective to insist on branding or a particular visual style after all.

We've taken great inspiration from the modern indie-web movement, as well as a number of sites like msx.horse. Ari and I are both in love with the way that these sites make space for personality over function, and especially love sites that allow each different space to have its own unique vibe. We feel that interacting with The Collective's online presence should feel like you are walking into a building we all cohabitate in. We want it to feel like you can get a sense for each of our personalities and unique outlooks on the world.

From a political and ideological standpoint, we want to eschew the homogenization of identity through corporate whitewashing. We want our collective to be just as messy, creative, and daring as our members. To us, The Collective is less something to take seriously and more of a club for cool people. Hopefully our site will eventually feel like that.

For now however, you can expect a very simple and “business-lite” approach to the core pages on the site – again trying not to impart a visual identity on members.

Stay tuned for more, and as always: point your feed reader at our feed to get the latest as it comes out!

• UTC-6:0033: phase one of server maintenance complete.

The server will be down on 2026-03-23 from 0200 to 0600 (UTC-6)

The server and site will be undergoing maintenance, due to bring stability improvements to the site.

For more, check our status page.

Anyways, I set up a LittleLinks site for myself. Gonna set one up for each member of the collective.

Anyways. fuck yeah digital sovereignty

Enter Go, stage left.

I tend to prefer simple solutions that imply great complexity. When comparing the options between C-likes, Rust, and Go, I ended up really being drawn to the sheer simplicity of the Go language. With only 25 keywords and a growing number of services that I use and love being built on Go, I was sold. After a decade of working with dynamically typed languages that will do almost anything, I was looking for something more declarative that would force me to design my data and lifecycle before I wrote code.

Python is great for prototyping, but a headache to revise and refine. Go takes longer to prototype, but makes revising and refining feel like a breeze.

Yes, Python is a wonderful language for prototyping. Yes, Python has an amazing ecosystem with solutions for just about any problem. But Python also makes some choices that feel... antiquated at best. For example, want to write docs that comply with the languages standards? Better learn this massive library with a million options! Want to do some basic http networking/API building? You should probably download a framework for that. Want to write unit tests for your project? You probably want pytest. Want to compile and distribute an immutable executable? You can if you try hard enough...

Go makes sensible choices for all of these issues. Want to write docs? Just add comments with plain language. Want to include tests? The built in testing conventions are batteries included. Want to do some API building? The standard library has you covered. Want to compile to a binary? Just hit go build. Every time I try to do something, the tooling is just better. Even the third party tooling feels better.

Python feels like a fully stocked tool shed. Go feels like a select few versatile tools that are built to last.

Most importantly, Go was built for the age of concurrency. Utilizing asynchronous processing isn't just a feature added to the language, it was a core design principle from the ground up. This really started to appeal to me after trying to write a python script to manage metadata on tens of thousands of raw photographs. The script, while fairly simple when implemented synchronously, became exceedingly difficult to maintain when implementing it asynchronously. It was entirely possible, but what was a sub 100 line script quickly bloomed into a project with object inheritance and more complexity than I care admit.

Reimplementing an asyncio python script as a go program resulted than fewer lines and a more efficient runtime.

As I've continued to port various scripts from python to go, I've seen this pattern repeat time and time again. When doing something well and quickly is more important than fast prototyping, Go reins supreme.

If you'd like to see my first project beyond a simple script, see pingo – my simple latency charting tool for the command line.

Really, this is so that I can set up a reliable/easy to use distribution point for pingo and (eventually) my simple issue tracking software.

For now it will be pretty quiet. It's a private instance for members of this collective and our friends after all. Don't expect a lot.

In the coming weeks, we will be sharing a number of simple CLI & TUI utilities written in Go, a re-imagining of a previously released photo-zine, a number of essay's Emi has been working on for a while, and much more.

Here's a bit more about what's coming!

Transcend 2024 (Redux)

Ari has been working on a remake of her Transcend 2024 photo-zine, with higher resolution printing templates, a new distribution point, and (hopefully) a limited print run!

The original run of the zine was produced using low-quality xerox's from the library. Each zine was printed on a single 8.5”x11” paper, single sided, and hand folded over the course of a few weeks. A print template for a larger, higher resolution, and multi-page document is long overdue. Moreover, the original photos were taken with a sepia color treatment as an artistic choice, which the original printing was not able to replicate (translating each photo to a limited contrast black and white).

Several customers noted legibility issues with the original issue due to image and font size. It is my aim to resolve these however well I can given my limited material resources. Moreover, it was always the intention to release the print ready files for both mini and full size self-printed zine distribution. The redux will provide higher quality open source standard files for no cost.

Now more than ever, I feel this zine has at least something worth being said. – Ari

Retro Reviews

Eric has been working on a review of Ari's “Death & Rebirth”, with additional artist commentary!

The story of the production on this record is just so interesting. It'll be interesting to write down my thoughts on it! – Eric

Not much to say on this front as of yet, more to come!

A simple, flat file based TUI for managing issues

Ari has been working on a TUI implemented in Go of a simple issue tracking solution based on the Poorman's Issue Tracker!

issues-go (or possibly tissues, I'm undecided), is a simple TUI for managing plain text flat file data structures on disk for tracking issues in code. While the software can work for just about any “todo” like structure, it is designed to make life easier for low-scale and low-tech software developers.

Designed with VCS integration, speed, and portability in mind, the project aims to provide an easier to implement solution. Compiling to less than ~10mb to a single stateless binary, it aims to be incredibly portable and able to run on just about any modern hardware, without the need for a centralized server. -Ari

A TUI for displaying latency as a chart

Ari has also been developing a simple TUI application written in Go for displaying ping results on a chart – therefore helping developers and gamers determine what is going on with their latency. She's made it before in many other languages, but this is the first time it's worth sharing – or so she says!

pingo is a Go reimagining of a previous implementation of this latency charting solution written in python, pingstats. Where pingstats was slow, under-performant, and buggy, pingo is limited in scope, fast, and highly tested. Furthermore, it re-does what pingstats tried to do, becoming an extensible module for use in subsequent projects.

Where the design ethos of pingo truly diverges from pingstats however is in its sheer simplicity of scope. pingo just shows latency values on a chart, and lets the user include it in other terminal applications. As such, the project does not currently target Windows based platforms.

A Public Git Repository

Ari is currently hacking away at what will become our git endpoint. She's caught between hosting a full-blown Gogs instance that mirrors our internal repositories, or a much simpler Soft-Serve based solution – with much fewer bells and whistles.

More on this topic very soon.

For our initial repository hosting, see git.crowcollective.space

more in the near future

Foreward

No one voice fully represents a whole truth of what The Crow Collective is, and therefore it is vital that I own my role. As the primary writer and community builder of The Crow Collective I, Emily (she/they) acknowledge that I occupy both the space of a white colonialist on Turtle Island, and the descendant of members of the Metis Nation. I walk through the world through a number of dualities, and work to represent this in my writing.

Mission Statement

The Crow Collective aims to use the dreaming of the mad, the crippled, and the ostracized to envision a better world. Through careful planning, bolstering resiliency through solidarity, and the power of joy in all its queer and mad ways. We aim to achieve this future through the merging of art, technology, and radical reimagining of what defines the status quo.

Art, joy, and creation is how we engage directly with changing the world.

Signed, – The Crow Collective