What is an issue btw?
In terms of event kind and content? A reply with markdown or sth?
What is an issue btw?
In terms of event kind and content? A reply with markdown or sth?
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
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.
yes, don't let users dictate your feature set that much... put em on a triage until it makes sense
btw, repo posts in UI should render markdown
but also put render markdown over normie ui at compose post
Accidentally posted it under the wrong repo, at first, sorry.