FreeAssembly

106 readers

1 users here now

this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.

in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.

some posting guidelines apply in addition to the typical awful.systems stuff:

all types of passion projects and contributions are welcome, including and especially those that aren't programming or engineering in nature
this is an explicitly noncommercial, share-alike space
don't force yourself to do work you don't enjoy, or demand it of others

(logo credit, with modifications by @dgerard@awful.systems)

founded 11 months ago

MODERATORS

self@awful.systems

thread your Philthy feature requests (awful.systems)

submitted 11 months ago by self@awful.systems to c/freeasm@awful.systems

82 comments fedilink hide all child comments

reply with features and bug fixes you'd like to see in Philthy, the lemmy fork that runs on this instance. no guarantees I'll get to any of them soon, but particularly low-hanging fruit and well-liked features can be prioritized.

you are viewing a single comment's thread
view the rest of the comments

[–] froztbyte@awful.systems 4 points 11 months ago (2 children)

I was wiped when i got home yesterday 😅

here's the ones I gathered from various thread mentions:

modtools local-posts view
user flairs (non-federated to start)
repo and docs renames (I believe these have been done)
a review of the existing containers/container build flow, to see what's in there
CI: open question as to preferred CI system, feedback welcome
button to allow auto-subbing users to new subs being created (strikes me that this would also involve user prefs work, to allow users to control that). might also open the door to an invite feature?

[–] self@awful.systems 5 points 11 months ago (1 children)

is it weird that I kind of want to start with (very limited, probably moderator-assigned) flairs? it's like the least important feature but it's one that I miss a lot

[–] dgerard@awful.systems 5 points 11 months ago* (last edited 11 months ago)

user-assigned flairs per sub are great fun, i feel like being a shill for Big Basilisk again

mod-assigned ones were useful on reddit buttcoin, whereas here we'd probably just get sick of their shiit and ban them

[–] froztbyte@awful.systems 3 points 11 months ago (2 children)

repo and docs renames (I believe these have been done)

so, taking a look at this (because it seems like a good one with which to dive into the repo and gain a broader familiarity/see all the pieces), quite a bunch of places all across the source and docs that mention lemmy and use lemmy in element/crate/resource names:

❯ rg -icI lemmy | numsum; rg -il lemmy | wc -l
3741
411

tackling it would be best in stages, I think. both because in general I'm not a big fan of gigantic branches (being a complete pain to review, and absent really really good testing it's easy for things to slip through), and because that's just this repo even

for a staged rename of things, probably makes sense to try tackle subsystems one at a time? would we want to tag versions for each stage completion?

[–] froztbyte@awful.systems 3 points 11 months ago (1 children)

even just looking at the list of places the name got used... oof. some deeeeeeply baked assumptions in here

[–] dgerard@awful.systems 3 points 11 months ago (1 children)

i mean, lib names and so on is fine really

[–] froztbyte@awful.systems 3 points 11 months ago

I was thinking more the models and such

[–] self@awful.systems 3 points 11 months ago (1 children)

I want to hold off on this for a bit since it will impact our ability to grab commits from upstream; for now I’d recommend we keep lemmy as a legacy symbol and use philthy in new development. once we’re in a good place for this, I imagine it makes sense to do it in stages, in an outside-in pattern — that is, we’d start by renaming things like the executable that’s very visible but breaks relatively little, then gradually make more internal, breaking changes

[–] froztbyte@awful.systems 3 points 11 months ago

that's a fair point too. will probably take a little while to find/develop some patterns for do now vs do later