If you look at https://todo.sr.ht/~alextee/zrythm-bug/13 for example, the ticket body only takes up the left half of the page and it's hard to read the code blocks.
I think the Status/Submitter/etc. part should go above the body
I think that ticket is kind of GitHub in its execution. SourceHut tickets are meant to be more brief and to the point, not based on some template which tries to force a pretty square-shaped ticket template into a brutalist square-shaped hole.
Does SourceHut really want to be opinionated about the size and shape of tickets its users file? That would seem very limiting to me, and personally enough to put me off using the service. Some issues are necessarily complicated and require significant detail in order to resolve.
Yes that was already apparent, and I think opinions on things like that are perfectly fine. But commitments to email workflow, a lack of JS etc. do not obviously cause friction for collaboration on complex issues. In contrast, friction is caused by having to describe all issues in a succint manner, or at least having to suffer non-succint issues being squeezed into a narrow width. https://todo.sr.ht/~alextee/zrythm-bug/13 is a good example of this. There is nothing specific to GitHub (or indeed any other issue tracker) about an issue which requires a lot of information to describe it sufficiently well. The complexity of some issues is a function of the complexity of software development in general, not of the trackers which host them.
IOW, saying something like "SourceHut aims for simplicity of interface" makes plenty of sense to me, but "SourceHut aims to host only projects which have simple issues" does not.
https://todo.sr.ht/~alextee/zrythm-bug/13 is not a good bug report. Almost all of the space is taken up by irrelevant information.
I agree to a large extent, but this does not change my point. For example, the presence of some debug logs alone is enough to justify the need for formatting the issue body wider. Currently, reading any such logs requires horizontal scrolling, which has a significant impact on usability.
You're not convinced that having to scroll horizontally backwards and forwards to read debug logs harms usability? Or you agree it does but you believe that doesn't matter for some other reason?
I also support arranging the status/submitter/etc section above the first post body.
If the first post is longer than about five lines, which is necessary for detailed bug reports or what-we-know-so-far kinds of posts, then you are wasting space. If the first post contains something wider than about 60 characters, like a stack trace, then horizontal scrolling is required.
As a developer, stack traces are about the most helpful thing I can get in an issue report. They describe what the issue is, where it is, how the execution got there, and other hints about how it happened. Stack traces are critical to allow me to fix issues. You absolutely cannot create a bug reporting website and then say "posting stack traces is not an expected use case".
This layout is not something to be opinionated about. Changing it is the logical thing to do.
You should always aim to make the user’s experience more pleasant, not more unpleasant. We should just be nice to people.
If you still will not change it for everyone, then at least add CSS classes to that part of the page so that I can add a stylesheet which changes it for myself.
FYI as a workaround, you can post log excerpts/backtraces in comments: https://todo.sr.ht/~alextee/zrythm-bug/483