Follow

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.

@sir YES!

At last, a service that gets it right!

Thank you!

@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.

@sir

> 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

1/2

@sir

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.

2/2

@codesections
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

@sir

> 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.

@codesections @sir I could see both sides of the argument. But excessive issue usage is a huge pain. If you have 800 issues between 2-4 maintainers then they're basically just for show.

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.

@sir Does the mailing-list workflow for potential issues still lead to discoverability? I'm thinking of the case where I think of a feature or think I've found a bug in a project and I go to the project's forge and find an issue (maybe closed) which is the same feature I would have suggested or bug I would have filed and can see an explanation of why it isn't an appropriate feature (or it's not practical &c.) or why what I thought was a bug isn't really a bug.
@sir But are they *as* searchable? The potential issue might be included as part of a thread with a subject line that is not very related to the issue.

I suppose what I'm asking, as an empirical question, is how well this has worked for you in practice. Do related issues come up multiple times on the mailing lists?
@sir @emacsomancer also helpful to add an IRC channel to the mix for support, realtime coordination, and unstructured/casual communication.

Ooh, ooh! What if Sourcehut had a semi-official IRC server, running on/with software developed on Sourcehut? It would be awesome given the number of IRC-related projects on Sourcehut that can make use of all the Sourcehut services.
Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!