SoylentNews is people
SoylentNews
The Open Source Survey asked a broad array of questions. One that caught my eye was about problems people encounter when working with, or contributing to, open source projects. An incredible 93 percent of people reported being frustrated with “incomplete or confusing documentation”.
That’s hardly a surprise. There are a lot of projects on Github with the sparsest of descriptions, and scant instruction on how to use them. If you aren’t clever enough to figure it out for yourself, tough.
[...] According to the Github Open Source Survey, 60 percent of contributors rarely or never contribute to documentation. And that’s fine.
Documenting software is extremely difficult. People go to university to learn to become technical writers, spending thousands of dollars, and several years of their life. It’s not really reasonable to expect every developer to know how to do it, and do it well.
-- submitted from IRC
(Score: 3, Interesting) by JoeMerchant on Monday June 05 2017, @01:18PM (3 children)
A proper install guide may be intellectually rewarding (to some) but it's socially thankless.
In essence, documentation is "programming the users" - which is orders of magnitude more difficult than computer code. You can "get it right" for one set of people and completely wrong for the next batch, not because what you wrote is incorrect, but because the next batch interprets it differently. Expand your verbosity to cover multiple target audiences and they all lose interest: TLDR... no win.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday June 05 2017, @03:10PM
What we need is a high level language for documentation, something that lets you write it once and then compile it for all users, instead of writing our documentation in "user level" code.
(Score: 2) by DannyB on Monday June 05 2017, @03:40PM (1 child)
I tend to think that if you need much of an install guide, you're doing it wrong.
The development team, or perhaps a separate installation team should do the heavy lifting of doing the install. How difficult is it to install Firefox? Chrome? Both of these are extremely complex pieces of software. Extremely complex.
Try to turn installation issues into configuration issues.
Use standard installer mechanisms for the OS, platform, language, environment, etc.
An example of a commercial web application I developed, that, at one time, the customer could host on the customer's own equipment. Installed by their own IT people. Installation is like this:
1. run setup.exe
2. Next, I agree, Next, Next, (wait), Finish
3. Server is now running. No reboot required. (Service can be seen in Windows Services control panel.)
4. Point web browser to server. Get "Out of service" page. Use special URL to get to initial web based control panel.
5. Use web based control panel to enter activation code, database connection information, and other very basic configuration.
6. End result, the server is up and running, presents normal login page, ready to log in and start creating other user accounts.
Now that sounds easy. But the development was not so easy. It was a hurdle to make the installation and set up process so easy.
Now the above could be edited to replace "setup.exe" with "deb install file". Replace "Windows Service control panel" with "service" command. Etc.
One further thing I learned (but have not yet done) is from a Mozilla video I saw some years back. Summary: don't build a product, build a pipeline. After the user installs it, it should be able to phone the mother ship and update itself. As easily as a TiVo does. Or Firefox. Or Chrome.
Satin worshipers are obsessed with high thread counts because they have so many daemons.
(Score: 2) by JoeMerchant on Monday June 05 2017, @07:23PM
I agree, install guide is a bad example, software literally should install itself properly with zero intervention in all systems that even resemble a standard configuration. Maaaaybe have a few options for "advanced" users as to how invasively it integrates into handling certain file types or how many launcher shortcuts you want auto-created.
However, the principle still applies to all forms of documentation: you're giving instructions or explanations to people, not machines - and people are much more difficult to communicate a precise set of information to. One set just needs to see: "BSD standard implementation." anything more is wasting their time, another set needs every single feature spelled out step by step with examples.
🌻🌻 [google.com]