I have been pondering about reducing back and forth walls of text required for finding faults or reason(s) for issues reported at Ask Fedora. And how can we ask right questions back to the requester if information shared in a post is not enough to find faults?
Considering a fast paced environment of Ask Fedora, I see a pattern of known issues and new issues. Let’s focus on known issues. New issues could go to bug reporting like bugzilla.
Known issues are often combined with multiple issues and solutions. You have to examine where it went wrong. For example, when built-in camera is not turned on during Jitsi conference, there could be multiple components to look at;
Browser compatibility
Device firmware compatibility or conflict (if one installed a non-standard firmware)
Known issues are not necessarily resolved by a single wiki or how to guide.
I see a range of methods used in Ask Fedora like log analysis or cause elimination, which is tried and tested in software debugging. It’s important to note that debugging and troubleshooting are related—but not synonymous—processes in finding faults. Sometimes, I see logs were not necessary.
It would be great to learn from helpers in Ask Fedora.
Individual issues may not be solved the same due to the wide variety of hardware/installed software that may be encountered and rapid pace of software development. User experience and understanding also varies widely.
Users do not always post the needed info.
Users seldom respond the same even when a guide and/or a template is provided.
I have years of experience with support and to me it seems that direct questioning with the way topics are managed is best rather than trying to fit everyone into the same mold and expecting them to comply with (somewhat) rigid expectations. It takes the back and forth of a conversation to ensure parties at both ends understand each other.
Disagree, the templates used on many git forges are really really handy. Embracing these could be a huge advantage.
Afaik Fedora has little templates overall, in contrast to many single software projects.
Githum has yaml support where even on a phone you have nice input fields. There can be a placeholder text telling you what to put there, a title, a description telling you what command to run.
It should have a way to skip some steps, to avoid useless data bloat. Kinda like when people add intelnvidia to a gpu problem
Many people don’t even know where the problem resides. This is true also for people trying to help. And we discover that step by step.
So, if a template asks i.e. to attach inxi results, but the problem is totally unrelated to hardware, what we have is just noise.
A Linux distribution is more complex than a single software hosted on github. There it is simple to have a template asking for i.e. version, architecture, steps to reproduce the issue. But here?
If I’m unable to reproduce a video on Firefox, it could be Firefox itself, a FF extension, codecs, hardware, the network, whatever.
The template could become huge. And we know, the more you write, the less people will read.
To be honest, I have mixed feelings about template or without it at user forums. Template is less rigid than a form. For many users, they seem to like free flow of writing with no structure. I know email/forum post can be structured to the best of problem identification.
Issue template in GitLab could be a halfway solutions between bug reporting and free-flow reporting of issues. It is hard to distinguish bugs from issues unless one knows troubleshooting, replication of issues and debugging.
For a single package the expectations and information is widely different than for an entire OS that contains many discrete app software packages.
Users , as can be seen by simply perusing the topics here, have varying experience ranging from a first time user to those with many years experience.
Users have differing troubles.
Users have hardware problems. Users have software problems. Users have user problems (pebcak).
Some users are so paranoid about security they do not even want to share the output of inxi (and many other commands as well). Some give us a ton of irrelevant data. Some claim the problem is one place but troubleshooting reveals they are not even in the ballpark.
I don’t see how forcing them into a rigid (or even semi-rigid) template for reporting problems can do anything more than cause frustration for both the user with the problem and those of us attempting to assist.
We are volunteers, not a paid staff and as such this is about our own experiences and not the rigid structure of help that comes from a support line at a business.
I think this is the single biggest key…even thinking outside of programming/coding/OSes, across various jobs I’ve had, forms/templates were successful for extremely narrow and well-defined request categories, and ended up sadly negatively impacting engagement with our teams when we tried to apply them to more open-ended processes.
For example, in jobs I held involving management of price lists and customer invoicing, we were very successful in implementing forms when submitting requests for price changes to the team that managed the core database - things like “item price to change”, “price list on which to change it”, “new price”, “effective date”…all of those things benefitted from tightly controlling the input quality.
When it came to customer invoice questions, though, we tried to go all-in on asking for “what item are you asking about”, “what price did you get”, “what price are you claiming”, etc. and we found that because the systems involved were complex, and many different causes could produce perceived issues, we were actually mis-directed more often than not by the forced selections that our customers ended up making on the form (because, understandably, they didn’t know enough to really understand what type of issue they were facing, the best that they could do is describe what they observed and then we had to guide the next steps).
Open-ended things that suggest the types of information that are often helpful could be a middle ground, but I’d be cautious of the work that gets created when trying to implement input controls in this setting, since it’s all too often easy to focus only on the work that you can hypothesize will be saved.
My question is about how Ask Fedora supporters could respond to the requester (user who asks a question in the first place) to identify problems with probing questions and ask relevant information (not necessarily logs).
In my years of support, the only thng I have EVER received from handing a form and asking a User to comply with rigid processes and SOP is Vitriol.
The User Engagement I did with a team and noted here in 2021 was successful because we engaged the study around engagement and conversation.
Had I handed out forms it would have been the end of the project, and I would not have contributed anything of value.
Forms are condescending to many folks. Their experiences with Healthcare and other practices is a factor in this.
I tailor my questions based on the post, I ask for feedback ranging from the actual post and what I believe I can interpret from the question. Let’s face it Post titles, and questions are mostly terrible.
Many users place their question in the title bar, and post “What the title says”. Engaging them with a form or prefilled Q/A is deterring and condescending.
Most people don’t want to engage with their computers like most NERDS do, they want it to do the thing and move on. Having Tech related problems for most people is annoying.
If Logs, Hardware info, available Software is not useful feedback, then the issue could be the User. Letting them know that it is their mistake is ok, but not through a form.
Alternative idea: have a link to a guide and a checklist. Users write a question, and we just tell them "please answer question 1, 4, 6, 7, 10) and we have good outputs without annoying duplicated questions.
This would be way more loose and can be adapted to the question
Please consider the way “helpers” here post answers. Some are on tangents, some are spot on, some ask for additional information.
Forms and templates would severely impact the usefulness and friendliness of direct communication since it could also restrict the free thinking of how to respond.
Anything that impacts users freedom to ask or “helpers” thinking on responses may easily be overall negative to the purpose of this forum.
Helpers in Ask Fedora are really helpful and polite when ruling out irrelevant information and narrowing down the affected modules or configurations. When someone is in trouble with system fault (or user fault, later found), empathy works well compared with rigid guidelines that scare away many users in trouble.
Troubleshooting skills are learned with experience and patience.
But I understand if people are exhausted of needing to ask detailed questions with commands all the time, so having a checklist with commands to run would be great!
Each helper can create the checklist they find useful. Having it as a form for reference may be helpful but limiting the free thinking with a How-To can be negative.
I cannot count the number of times where some other helper made a comment that triggered my remembering something that led directly to the solution.
Yet a How-To cannot possibly cover all the situations that may be encountered. It can be a broad overview but not possibly detailed enough for every problem we encounter.
