Quick reminder (or clarification) about the workflow on SourceHut
GitHub has trained you to open issues for *everything*, including support requests, asking questions, feature requests, bug reports, and so on.
On SourceHut, you should not do this. We have mailing lists, and your first stop should be a project-discuss or project-users mailing list. Only when you have confirmed that you have a new bug or accepted feature request should you file a ticket on the bug tracker. This prevents clogging up the bug tracker with duplicate or poorly thought-out tickets, and usually gets you better support for your problem too.
Thinking about changing the default permissions for trackers to prohibit public posting to re-enforce this.
At last, a service that gets it right!
@sir Would I be correct in interpreting "...the default permissions" to mean that the repository owner could enable public posting if (s)he really likes working that way?
I am all for sane defaults, but I also see the value of options.
> GitHub has trained you to open issues for *everything*, including support requests, asking questions, feature requests, bug reports, and so on.
> On SourceHut, you should not do this. We have mailing lists, and your first stop should be a project-discuss or project-users mailing list.
Maybe I've been brainwashed by the GitHub model, but using mailing lists for many of those strikes me as really sub-optimal, not only for the user but also the project/maintainers
When I'm on project mailing list, I don't want people asking the same dozen questions all the time, because they didn't search list archives or because they don't know if the bug in question has been fixed since someone last asked about it.
(ime, people basically never send replies to old mailing list emails saying that something has been fixed, but they usually do close issues)
I'd rather have an issue tracker where search is obvious and where issues are closed as duplicates.
The search is less obvious, because questions and bugs and feature requests and so on are all piled in together. Searching mail archives is usually easier imo
And opening a ticket is more expensive than starting an email thread. It burns a ticket number and requires the maintainers to explicitly close it, then clogs up search results with duplicates and poor quality tickets. Moving those to the mailing list makes searching through tickets easier, and increases the signal:noise ratio for tickets.
@codesections I would agree that your take seems to be mostly based on cognative dissonance arising from the questioning of your ingrained understanding of the GitHub model
> opening a ticket is more expensive than starting an email thread.
Interesting take. I follow several projects' issue trackers and am subscribed to a similar number of project mailing lists. For me, a user starting an email thread feels more "expensive" – it lacks meta data to easily sort (e.g., tags), it doesn't have a good way to unsubscribe from the thread without leaving the list, and it clogs my inbox.
But maybe all that would be solvable if I really invested in my email setup
@codesections also consider that a ticket tracker is much more effective for a maintainer if they can treat it like a list of action items. Every open ticket is actionable in the code. Every closed ticket has been acted upon in the code.
If it's a discussion forum in addition to that, it's a lot less managable for that purpose. Additionally, moving discussions, support requests, et al to the mailing list makes it easier for the community to participate in self-organized support, leaving the maintainers free to focus on maintenance, and makes the ticket tracker a more useful tool for doing so.
@sir @codesections That really depends a lot on the community; there are a lot that operate in different ways - some ticket trackers work fine for it - as long as the comments are public. It's quite tricky to follow very very long discussions on a mailing list (ones that are many years old), but can be quite easy on a ticket tracker.
I've been the one going through hundreds of issues trying to close fixed, duplicate, or no longer relevant issues. It takes hours and hours to go through and so much of it is just feature requests and questions. And I didn't even make anything.
@sir Maybe the UI should have a warning about this. Early on in the process of learning to use sourcehut I misapplied my Github experience and used todo.sr.ht to submit a feature request. I didn't realize I had done something wrong until several weeks later when I saw a Mastodon post by you reminding people not to do this.
@emacsomancer mailing list archvies can also be searched
@emacsomancer yes, in my experience it works
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!