I Insist People Use the Forums and Issue Trackers
stoutner.com
stoutner.com
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.
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?
Of course as a user the calculus runs in the other direction: every new account I have to create increases my attack surface.
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.
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.
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.)
It may take some time to migrate a project with a history like Privacy Browser, but it's certainly beneficial in the long run.
I still believe it makes sense to use sourcehut as a basis rather than Gogs/gitea or even gitlab
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...
(One of the biggest practical divisions I've seen between millennials / xennials and gen z developers.)
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?
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.
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.
This is why oauth was invented.