you need to think more abstractly about what a person might want to be notified about

an issue is a post, that is tied to an event that you created the root of, it tags the event and thus you would set up a filter that looks for events that tag roots (repos) that you want to monitor, and possibly, not ones of people you have muted

and mutes, they are so broad, you may not want to read someone's war and peace posts on demand in your issues but usually enjoy their long form posts, for example

so, notification engines need to be complex by nature, highly configurable, with sensible defaults that don't give you notification fatigue too quickly... and temporary ignores that can quickly be set up when you need to focus, generally, or just not see some particular thing

Reply to this note

Please Login to reply.

Discussion

Yeah, it is a repo-tagging note, that are commonly used to file bug reports or feature requests. So, I find it sort of annoying that I'm currently not being interrupted in my chit-chat about lasagne recipes by

~~~

User npubbunchofnumbers just posted the issue on your GitCitadel repo:

"Hey, help! Tried to use Alexandria and all I see is a 404 error! My colleagues all see the same error!"

~~~

Like. That might be important. Please interrupt me with that. Please. Please.

Whereas a feature request like "Would be nifty if Alexandria automatically generated a clickable index for every longer collection. 🤔 " is interesting, but right now I want to talk about lasagna.

Letting users decide usually ends up with everything being labeled a bug, since those get instant responses. So, you'd need AI to analyze and auto-label the content.

btw, repo posts in UI should render markdown

but also put render markdown over normie ui at compose post

devs are definitely not normie level - almost everyone who can write code can write markdown

and if you can't, plaintext renders just fine as markdown too, so long as you put double line breaks

its lacking at highlighters and yakihonne as far as i could tell

yes, for code fences and code and preformatted blocks, these are staples of coder comments

Wow, good point.

Should it be "for issues and proposal cover letters"?

at least for issue threads and gists

gists?