There’s an interesting gap between the interest of the dev and the user here.
The user wants a human to understand their sometimes multi-layered requests. The dev wants these requests to be de-layered and broken into separate issues for tracking and documentation.
There really isn’t a good system today (that I know of) that would facilitate this process with both the user and the dev in mind.
From a perspective of information structuring and prioritization, tickets are perfect (for the dev), yet they lack a “natural” (e.g. email, phone or chat) support exchange where an issue is several issues rolled into one. Or once an issue is resolved there’s the “oh btw while I have your attention” moment where an unrelated issue is discussed but the interaction between the same people is ongoing.
To handle this properly in an email-to-ticket-system the dev would need to ask the user to resend the request in a different mail or themselves open a new issue, which is exactly the overhead the system tries to avoid in the first place. Or either party would need to remember the issue ids to keep a running list, all of which seems undesirable.
In the case of a small team/single dev product it’s that human interaction that’s not paid for so the burden is put on the user, at the cost of a reduced interactive experience.
Is there any better way of solving this? Or are systems being built to support this a bit better than how the Jiras/Redmines of this world are (not) handling it today?
Losing the original customer voice and statements and context and breaking them down in to stories plays a large part as a condition leading to software that overall lacks a baseline level of polish and coherence, and which pits individual changes against each other at a micro level instead of caring for overall experiences or ever letting polish-level quality jump ahead of other pressing work
"sometimes multi-layered requests" are fundamentally a human problem, not a technology problem. I suppose ideally you'd have a human triage the incoming request into whatever de-layered channels are convenient for the dev. It's always going to require a human who understands both sides, unless you get an AGI that understands both sides.
Not related to the author of this or any of the software that they've done but I was messing around with the Haiku operating system and one of their updates broke the trackpad for a laptop that I had it installed on. I went on the IRC for them and reported the bug they told me to open up a bug report on their issue tracker they immediately responded to the bug report I opened and I did some extra testing for them and by the time the next update was pushed out like the next day the issue is fixed. I thanked them a whole bunch they thanked me a whole bunch and we both went on our merry way.
I just had to recover some luggage that went astray within an airline's handling of missed flights. I didn't open a case. They had tracking numbers, which I had to find out and use. There was a place where notes were being appended, but I did not learn what the tracking number for the document that accumulated the notes was. Perhaps this works fine for "where's my luggage, give me my luggage" use cases.
> all the server software I use to support the project must also be open source and I must be able to host it on my own hardware. This is part of my efforts to minimize my attack surface
Of course as a user the calculus runs in the other direction: every new account I have to create increases my attack surface.
I believe it's the opposite. Every shared account increases my exposure as the user. If I have 500 accounts across 500 sites, and one is compromised, 499 are not. If I have 1 account across 500 sites, and that one account is compromised, all 500 sites and the data I have there, is at risk.
Though real world evidence suggests that the more accounts you use the less likely you are to use strong passwords and the more likely you are to reuse passwords.
It's not a big difference if because someone has 500 accounts they have 1 password across all 500 and a breach of one account is still a breach of all of them. With the added fun that dealing with that breach requires 500 touch points to change passwords.
You may not personally be in that situation. If you read HN you probably use a password manager. The average user generally is in this situation. Consolidating accounts decreases their exposure of weak passwords. It's a different conversation if we are using something stronger than passwords, but today 500 passwords is inhumane and increases the attack surface of average users.
If you're just going to enforce MFA on weak passwords anyway, what do you need the weak passwords for exactly?
This is almost the exact line of reasoning why Microsoft, Apple, and Google have (finally) all agreed to work together to eliminate passwords altogether. Which probably is the only way that we can solve this: eliminate passwords, use proper keys and attestations instead of passwords, and try to make the user experience as nice as possible and at least no worse than yesterday's TOTP 2FA.
(And yes, there are lots of valid complaints for power users that know how to use a password manager today that any such key management platforms would be a worse single point of failure than their existing password manager because it would be more opaque and harder to user-manage/export. It's an interesting trade off for average user security, at least.)
Use sourcehut. People send questions through emails only so there's no account to create. It's all centralized into a public mailing list and searchable just like a forum. it is self-hostable and entirely free software.
It may take some time to migrate a project with a history like Privacy Browser, but it's certainly beneficial in the long run.
It looks like he wants to self-host all his infrastructure. That's possible with Sourcehut, but last time I looked, it seemed pretty complicated to set up and operate.
I haven't tried but it's probably true, if only because sourcehut is aimed towards multi users, multi repo, multi projects. Which is far more than what self hosting people need.
I still believe it makes sense to use sourcehut as a basis rather than Gogs/gitea or even gitlab
> I have been quite surprised to encounter a number of people who resist using the forums or the issue trackers to ask questions, file bug reports, or make feature requests. Usually their reasoning boils down to it being too inconvenient to create an account on redmine.stoutner.com.
Joel Spolsky had a solution to this issue in 2003: Eliminate the registration requirement on support forums. Quoting him:
—-
Q. Why don’t you have a registration scheme to eliminate rude posters?
A. As I explained earlier, the goal of the forum is to make it easy to post. (Remember, the software was written for tech support.) Registration schemes eliminate at least 90% of the people who might have posted, and in a tech support scenario, those 90% are going to call my toll free number.
Besides, I don’t think registration would help. If somebody is being abusive, it doesn’t help to ban them, they can trivially reregister. The idea of improving the community by requiring registration is an old one, and it’s appropriate, I think, for the Echo/Well type of conferences where you’re creating a network of people as much as you’re discussing a topic, and you charge people cash money to belong.
But requiring registration does NOT improve the quality of the conversation or the average quality of the participants. If you look closely at the signal-to-noise ratio on the Joel on Software forum, you might start to notice that the noisiest people (i.e. the people who post the most words while contributing the fewest ideas) are often the long time, hard core members who visit the forum every ten minutes. These are the people who feel the need to chime in with a “I agree with that” and replies to Every Single Topic even when they haven’t got an original thought to contribute. And they would certainly register.
Hum... Issue trackers are dedicated tools for software issues, bugs, design issues etc to be more precise, I doubt they can be really useful for casual users. Ubuntu LaunchPad have tried that "a bit" with the mostly disable automated reported tool and it does not have worked well.
Forums works mostly well but have two kind of important issues:
- for the user they normally need an account, one in nth, with a registration process and an easy push to "extended SSO" services like "sign-in with $GAFAM_name";
- for the project side they need resources and efforts.
Long story short: ** wedamnneedUsenet **: for the user it's just a local application, locally searchable for saved contents at least, so the "available records" is fair being potentially be for anyone involved, subscribing a group does not require new accounts, tools, different UIs etc. For the project there is very little to maintain.
Or: just think what we have, because usenet is still there even if almost abandoned, and what we lost choosing to "mock-solve" forums issues with proprietary platforms from Reddit to semi-proprietary ones like Discourse. All for what? A damn WebUI full of JS crap?
Why I hate support being done on Slack and Discord. You can't do a Google search for problems and solutions.
That said, I think Slack and Discord have an opportunity to create search engine indexable HTML pages for problems and solutions discussed in channels.
For example, they could have some sort of Github Issue like system inside Slack but still enable live chat. Then they could push each issue into a URL indexable by a search engine.
That's a feature. If people wanted those discussions to be public/indexable they would post on stackexchange or similar.
Often people are asked to post their issue on stackexchange or github anyways.
> If people wanted those discussions to be public/indexable they would post on stackexchange or similar.
I don't think this is true. Plenty of support is being done on general chat channels that organizations have set up. These aren't private problems and solutions. The reason why Slack and Discord are often used for support is because live chat can be superior to Github and Stackoverflow in response time.
> they can’t be bothered to create an account on another site. One of my fundamental guiding principles in developing security and privacy focused open source software is that all the server software I use to support the project must also be open source and I must be able to host it on my own hardware.
I'm not sure it's fair to blame user apathy/laziness. More likely, user burnout.
I don't think I've ever had a single thing resolved by 'opening a case.' To me, I hear 'go fight with our offshore cs team until you give up.'
This case seems starkly different, as the author just wants accountability and tracking, which is great. But I imagine most users are weary.
There’s an interesting gap between the interest of the dev and the user here.
The user wants a human to understand their sometimes multi-layered requests. The dev wants these requests to be de-layered and broken into separate issues for tracking and documentation.
There really isn’t a good system today (that I know of) that would facilitate this process with both the user and the dev in mind.
From a perspective of information structuring and prioritization, tickets are perfect (for the dev), yet they lack a “natural” (e.g. email, phone or chat) support exchange where an issue is several issues rolled into one. Or once an issue is resolved there’s the “oh btw while I have your attention” moment where an unrelated issue is discussed but the interaction between the same people is ongoing.
To handle this properly in an email-to-ticket-system the dev would need to ask the user to resend the request in a different mail or themselves open a new issue, which is exactly the overhead the system tries to avoid in the first place. Or either party would need to remember the issue ids to keep a running list, all of which seems undesirable.
In the case of a small team/single dev product it’s that human interaction that’s not paid for so the burden is put on the user, at the cost of a reduced interactive experience.
Is there any better way of solving this? Or are systems being built to support this a bit better than how the Jiras/Redmines of this world are (not) handling it today?
Losing the original customer voice and statements and context and breaking them down in to stories plays a large part as a condition leading to software that overall lacks a baseline level of polish and coherence, and which pits individual changes against each other at a micro level instead of caring for overall experiences or ever letting polish-level quality jump ahead of other pressing work
"sometimes multi-layered requests" are fundamentally a human problem, not a technology problem. I suppose ideally you'd have a human triage the incoming request into whatever de-layered channels are convenient for the dev. It's always going to require a human who understands both sides, unless you get an AGI that understands both sides.
Not related to the author of this or any of the software that they've done but I was messing around with the Haiku operating system and one of their updates broke the trackpad for a laptop that I had it installed on. I went on the IRC for them and reported the bug they told me to open up a bug report on their issue tracker they immediately responded to the bug report I opened and I did some extra testing for them and by the time the next update was pushed out like the next day the issue is fixed. I thanked them a whole bunch they thanked me a whole bunch and we both went on our merry way.
I just had to recover some luggage that went astray within an airline's handling of missed flights. I didn't open a case. They had tracking numbers, which I had to find out and use. There was a place where notes were being appended, but I did not learn what the tracking number for the document that accumulated the notes was. Perhaps this works fine for "where's my luggage, give me my luggage" use cases.
> all the server software I use to support the project must also be open source and I must be able to host it on my own hardware. This is part of my efforts to minimize my attack surface
Of course as a user the calculus runs in the other direction: every new account I have to create increases my attack surface.
I believe it's the opposite. Every shared account increases my exposure as the user. If I have 500 accounts across 500 sites, and one is compromised, 499 are not. If I have 1 account across 500 sites, and that one account is compromised, all 500 sites and the data I have there, is at risk.
Though real world evidence suggests that the more accounts you use the less likely you are to use strong passwords and the more likely you are to reuse passwords.
It's not a big difference if because someone has 500 accounts they have 1 password across all 500 and a breach of one account is still a breach of all of them. With the added fun that dealing with that breach requires 500 touch points to change passwords.
You may not personally be in that situation. If you read HN you probably use a password manager. The average user generally is in this situation. Consolidating accounts decreases their exposure of weak passwords. It's a different conversation if we are using something stronger than passwords, but today 500 passwords is inhumane and increases the attack surface of average users.
Then we need to encourage more users to use password managers.
I propose registration screens should recommend at least bitwarden.
Website password complexity rules should warn and enforce that MFA will be required for passwords less than 72 characters.
If you're just going to enforce MFA on weak passwords anyway, what do you need the weak passwords for exactly?
This is almost the exact line of reasoning why Microsoft, Apple, and Google have (finally) all agreed to work together to eliminate passwords altogether. Which probably is the only way that we can solve this: eliminate passwords, use proper keys and attestations instead of passwords, and try to make the user experience as nice as possible and at least no worse than yesterday's TOTP 2FA.
(And yes, there are lots of valid complaints for power users that know how to use a password manager today that any such key management platforms would be a worse single point of failure than their existing password manager because it would be more opaque and harder to user-manage/export. It's an interesting trade off for average user security, at least.)
Use sourcehut. People send questions through emails only so there's no account to create. It's all centralized into a public mailing list and searchable just like a forum. it is self-hostable and entirely free software.
It may take some time to migrate a project with a history like Privacy Browser, but it's certainly beneficial in the long run.
It looks like he wants to self-host all his infrastructure. That's possible with Sourcehut, but last time I looked, it seemed pretty complicated to set up and operate.
I haven't tried but it's probably true, if only because sourcehut is aimed towards multi users, multi repo, multi projects. Which is far more than what self hosting people need.
I still believe it makes sense to use sourcehut as a basis rather than Gogs/gitea or even gitlab
> I have been quite surprised to encounter a number of people who resist using the forums or the issue trackers to ask questions, file bug reports, or make feature requests. Usually their reasoning boils down to it being too inconvenient to create an account on redmine.stoutner.com.
Joel Spolsky had a solution to this issue in 2003: Eliminate the registration requirement on support forums. Quoting him:
—-
Q. Why don’t you have a registration scheme to eliminate rude posters?
A. As I explained earlier, the goal of the forum is to make it easy to post. (Remember, the software was written for tech support.) Registration schemes eliminate at least 90% of the people who might have posted, and in a tech support scenario, those 90% are going to call my toll free number.
Besides, I don’t think registration would help. If somebody is being abusive, it doesn’t help to ban them, they can trivially reregister. The idea of improving the community by requiring registration is an old one, and it’s appropriate, I think, for the Echo/Well type of conferences where you’re creating a network of people as much as you’re discussing a topic, and you charge people cash money to belong.
But requiring registration does NOT improve the quality of the conversation or the average quality of the participants. If you look closely at the signal-to-noise ratio on the Joel on Software forum, you might start to notice that the noisiest people (i.e. the people who post the most words while contributing the fewest ideas) are often the long time, hard core members who visit the forum every ten minutes. These are the people who feel the need to chime in with a “I agree with that” and replies to Every Single Topic even when they haven’t got an original thought to contribute. And they would certainly register.
https://www.joelonsoftware.com/2003/03/03/building-communiti...
This, but for "please ask in the jira ticket, not a private message."
(One of the biggest practical divisions I've seen between millennials / xennials and gen z developers.)
Hum... Issue trackers are dedicated tools for software issues, bugs, design issues etc to be more precise, I doubt they can be really useful for casual users. Ubuntu LaunchPad have tried that "a bit" with the mostly disable automated reported tool and it does not have worked well.
Forums works mostly well but have two kind of important issues:
- for the user they normally need an account, one in nth, with a registration process and an easy push to "extended SSO" services like "sign-in with $GAFAM_name";
- for the project side they need resources and efforts.
Long story short: ** we damn need Usenet **: for the user it's just a local application, locally searchable for saved contents at least, so the "available records" is fair being potentially be for anyone involved, subscribing a group does not require new accounts, tools, different UIs etc. For the project there is very little to maintain.
Or: just think what we have, because usenet is still there even if almost abandoned, and what we lost choosing to "mock-solve" forums issues with proprietary platforms from Reddit to semi-proprietary ones like Discourse. All for what? A damn WebUI full of JS crap?
Why I hate support being done on Slack and Discord. You can't do a Google search for problems and solutions.
That said, I think Slack and Discord have an opportunity to create search engine indexable HTML pages for problems and solutions discussed in channels.
For example, they could have some sort of Github Issue like system inside Slack but still enable live chat. Then they could push each issue into a URL indexable by a search engine.
That's a feature. If people wanted those discussions to be public/indexable they would post on stackexchange or similar. Often people are asked to post their issue on stackexchange or github anyways.
> If people wanted those discussions to be public/indexable they would post on stackexchange or similar.
I don't think this is true. Plenty of support is being done on general chat channels that organizations have set up. These aren't private problems and solutions. The reason why Slack and Discord are often used for support is because live chat can be superior to Github and Stackoverflow in response time.
instant messaging is less formal with all that implies therefore the need for privacy
Except that it's not private. Anyone in the channel can read it. Anyone joining can read anything if they scroll far enough and has Slack premium.
you can export your slack and discord content already with services like this: https://www.linen.dev/ i think this is exactly what you are asking for.
> they can’t be bothered to create an account on another site. One of my fundamental guiding principles in developing security and privacy focused open source software is that all the server software I use to support the project must also be open source and I must be able to host it on my own hardware.
This is why oauth was invented.
Or allow them to optionally log in using their Google, Facebook and Apple accounts.
I'm not sure the author of Privacy Browser would like to implement "Sign in with Google/Facebook/Apple"
Google and Facebook both use Oauth for that. Apple does not I guess.
Automatic title editing doesn't work well in this case.
The title mangler never works well and should be removed.
Automatically create an issue with such emails. You’re welcome.