So, I feel like I’m the model of badly reported issues - but my gift is a dogged determination to force my way through - and in the process I tend to reveal how the documentation could be clearer - and I’m actually pretty good at clarifying the documentation in language that average people understand (e.g., people who don’t code or architect networks for a living). 


You might find me useful, but the signal to noise ratio will be pretty chatty.

The text-client install is an example. You’ve got to really understand permissions, file locations, and the relationship of

How you install

where you install

Where accounts launch programs from.

And with Linux, this isn’t as cut and dry as with Windows. There are a hundred different ways it could happen, and as many different locations. I’m still wrapping my mind around this - but my basic problem was not understanding that citadel.rc is critical to the Citadel text client launching. It has to be in a path the citadel binary can find, and the account that citadel launches under has to have permissions to it. It *says* this in the text document, and I read it several times - but it was understood the way a kid from the Peanuts understands a teacher talking.

 

I’m pretty sure ALL of my issues were Operator Error and not RTFM... But part of it was RTFM but not comprehending what was said. I had the ability to comprehend it - because when the lightbulb lit up, it instantly fixed the problem - it was just that the lightbulb took a long time to warm up and glow. 

Which isn’t necessarily a documentation problem. It is an *audience* problem. The documentation is written for people who *get it* - but documentation is most successful when people can just follow the steps and succeed, even if they have no idea why. At least, that is my approach, as a Windows career professional. 

 

Sat Dec 05 2020 13:45:14 EST from IGnatius T Foobar @ Uncensored

I've created a private wiki called "Citadel Issue Tracker". It is a hidden room. In the past we've had a terrible record with bug trackers because they tend to fill up with badly reported issues, badly tested issues, and feature requests. So I'm making the audience limited for this one because I only want it to carry two types of issues:

1. Issues which have been confirmed and we intend to fix

2. Reported issues which look plausible enough to look into (and if confirmed, fix)

 

Reply via email to