#Project threads migrating to text channels

1 messages · Page 1 of 1 (latest)

glacial drift
#

There is a major pain point when it comes to project threads where the way Discord hacked their thread channels together makes it so you cannot create a thread within a thread. This pain point became more apparent as we moved to work more in the open, after almost a year of us used to working in Slack where the flexibility of threads is quite nice. But it was already kind of there before that.

You can see some of the pain I've addressed with the creation of the main channels in here, which closed out some of the projects threads. This works for the engineering channels very well. The problem now comes in my second part of the plan: how do we talk about the individual projects that product is designing themselves?

#

My plan for this is a new category in the server called Discussions. Any feature that is already in the hands of the user but not complete should be in this category in my eyes - my vision is that it's the text channel where we continue to work in the open but allow regular users to chime in. I view this separate from the Feedback category, where users should give feedback on the features rather than a discussion of how things are built; which is also separate from Support, in which a user is trying to solve a problem they are having. I have started to restrict this category (Building in the open) to only employees, developers, and designers so that the focus here can be on the planning and backend development of incoming features. Here is where people start to disagree with me and why I haven't pulled the trigger on my vision yet.

One point that gets driven is regular users shouldn't weigh in on the actual development of the projects.
I don't completely agree here but understand the point. We want people to weigh in early like on GitHub, but there are some technical aspects that require handholding to fully grasp what we are working on. My thought is that when we're bashing this things out, we split off threads in the appropriate text channels here. This has mostly worked for the engineering channels. When it comes to product discussions like UX and UI, it's more complex where exactly things would live.

#

There is talk about forcing threads with a bot that I will explore. https://discord.com/channels/330944238910963714/1479161177933353032

I've created this thread to continue this discussion from here: #1351529028112224359 message There is a high need from others to be able to create threads within a project conversation and I want to support that.

I want projects and discussions to be fluid, but we do not have a defined line between development, community discussions, and feedback right now. So, I'd like to discuss how we can build text channels that are specific to projects, where they belong, and how early we include the community.

#

cc @rich trench @flint wraith

#

Also cc @exotic arch @true rivet

bleak drum
#

regular users shouldn't weigh in on the actual development of the projects
Why not? (If this is something that someone has written about previously, I must have missed it and a link will suffice)

glacial drift
#

That's mostly been the general reaction when talking about pushing things like Home page out of this category.

bleak drum
#

I would rather have users weigh in on the development as we're deciding going for A or B, rather than going for B and having to revisit that decision later.

glacial drift
#

Same!

#

The line blurs when figuring out, well, is development happening in the Discussion channel or is it happening in here.

#

And my goal of this category is that we build the future of Home Assistant, but shape it in Discussions.

bleak drum
glacial drift
#

This category overall. So, like, architecture things don't belong in this channel.

#

Frontend changes are a weird in between of this channel and #frontend

bleak drum
#

Yeah, hmm

#

Because also, loads of discussions on ongoing developments are happening in #core for example

glacial drift
bleak drum
#

Do we just need a "projects" category, with channels for ongoing projects that we close once the projects are done?

glacial drift
#

Projects often crossover, which is where a thread in #1346914401508392980 comes in handy. But in the case of #1351529028112224359 there are so many moving pieces that having it siloed in a single thread has proven messy.

glacial drift
bleak drum
#

I mean, it would solve my issues with the current projects setup 😬

glacial drift
#

Let's see how others feel about this. I know product is just coming back from the in person meetup and catching up. But I do not hate the idea of framing discussions as projects and having it as the space where the collaboration happens crossorg and with the community.

rich trench
#

but I also get the argument against it, so I don't have any strong opinion

#

but my view is: design/behavior/ux of the triggers happens in the triggers project. implementation issues/concerns can happen in #core

glacial drift
#

I very much like that distinction.

bleak drum
#

Yeah so basically anything with user-impact goes in the project channel, anything technical (the part that's invisible to the user) goes in #core

rough crane
# bleak drum > regular users shouldn't weigh in on the actual development of the projects Why...

Things like the design system and core architecture are completely useless to have user feedback on, unless those very users are capable of understanding what the discussion is trying to accomplish.

I do think that Discord really isn't a great place for discussing large projects like Home Assistant, and Slack would definitely be a better place for it. But I can also acknowledge the fact that it's also pretty costly especially in the long term, so I imagine alternatives like Mattermost, Zulip, etc. could be considered instead, if we ever moved off of Discord to another real-time collaborative discussions platform.

I think that this could be a good step in the right direction though. But I'd also imagine that it might not be as big of an improvement as taking things off the platform and moving someplace else that is actually concerned with collaboration of large-scale open source projects.

glacial drift
#

Those platforms have been considered.

#

It's not in the cards to move yet, but I do agree that Discord's functionality is not suited for what we are trying to do.

bleak drum
#

Terminology might be confusing here but in this context a "project" would be something that's on our current roadmap and that we're actively developing

rough crane
#

I've been keeping a close eye on Roomy, which is supposed to essentially be a Discord but with a lot of collaborative tools built for businesses and group organizers. It's being built on top of Bluesky, which is why I'm so interested in it

rough crane
glacial drift
#

That would be really cool, though.

rough crane
glacial drift
#

I love what atproto is doing for open source.

#

How most people currently feel Bluesky devs aside, the open source community seems much more open to the idea of how atproto supports decentralization.

#

I haven't seen Roomy, so I'll look more into that, too.

rough crane
#

It has been really cool, though it's almost certainly not built for real-time discussions (... yet?) but Roomy got around that by specifically architecting their own "event stream" that basically acts as a layer that sits on top of the AT Protocol and handles the data, especially since private state isn't possible yet

rough crane
glacial drift
#

I dug into this while on the flight home. I really like it's potential, but it's nowhere near primetime. The sidebar is nearly identical, but they have chat and threads as options immediately in the top right of each channel. There's an index 'channel' that shows all of the threads in the Space from every channel. The channel organization could be a possible solution to our current pain points.

The one thing that is clearly broken in the sidebar but DOES work: you can create threads in threads.

#

They're working on a Discord bridge, too.

#

I'm actually trying to not actively lose my shit at this (I may be a bit loopy trying to stay up through this flight) but I made a thread in a thread in a thread. 😂

image.png
#

So the chain goes lobby > Shitposting for realsies > Creating a thread in a thread? > Threadception.

#

The subthreads are only visible in the Index channel, though.

glacial drift
# rough crane https://a.roomy.space

@eternal vigil You may be interested in this since we were talking more about Discord Tuesday during dinner. I've been digging into it a lot the past couple hours.

rough crane
#

😳 Exciting. I think right now, some features like private channels are waiting on the ATProto permissioned data implementation, and once that's finally complete it means they'll be able to do all that

#

But I do just love how you log into the AT Protocol, and so much of your identity comes with you. And the potential for integration with other things, e.g. Tangled, Bluesky, Streamplace, Atmos.RSVP and so much more

glacial drift
#

I've spent a little bit talking with the devs on Bluesky during my flight. I'm gonna write up a feature request to limit the thread nesting, it's intentional!!

#

I also basically cloned this server into a Space to see how I can optimize things using Roomy.

I'm kind of obsessed. 🤩

eternal vigil
eternal vigil
gloomy sand
#

If theres a working bridge for them it would make the jump super easy (if reliable of course)

bleak drum
eternal vigil
bleak drum
#

Right so then that's what the split should be right? Get anything user-facing or with user-facing impact/ implications in one spot and keep the technical discussions somewhere else?

glacial drift
# eternal vigil Yeah, it means ditching Discord for development… splitting the community

Yes and no. I think, like Aidan says, a bridge will help.

But I also think it may be a smoother transition than if we went to, say, Matrix. If we can get it mirrored (and they told me they have a bot for this already), showing support for an open source project that isn't trying to take data, can be indexed because of the nature of how data works on atproto, and the "no new account" (as long as they have a Bluesky account now) will all be positives for the move.