Email or username:

Password:

Forgot your password?
Top-level
jr conlin

@hyc @mhoye

OR maybe the docs are terrible.

Perhaps they're written for experts instead of users.
Maybe they focus on minor details instead of general function.
They might forget that folk have lives and that a library or app is just a tiny, annoying part of that instead of the central aspect.

Maybe present a few example commands at the top instead of at the bottom of 20 pages of man output.

It's like saying "To code, you need to know ancient Sumerian."

37 comments
Howard Chu @ Symas

@jrconlin @mhoye fulltext search, regexp search are well established features. If all you want is an example it doesn't matter that it's at the end of a 20page document, all that matters is that it's present.

Howard Chu @ Symas

@jrconlin @mhoye there's definitely a difference between a technical reference manual and a user guide. General function belongs in the latter. But by its very nature, it's going to be lengthy, particularly if a lot of basic concepts need to be introduced. Complaining "tl;dr" is bogus if the necessary information is present and concisely delivered.

mhoye

@hyc @jrconlin

If you're telling people that the solution to navigating bad documentation is to learn regular expressions, then I don't even know what to say. That's like telling somebody who's struggling to climb a mountain that why don't you just learn how to fly?

Anyway, here's what you get when you use gcc to compile Hello World, with single quotes instead of double quotes. Not, please: those are warnings, not errors. The compile actually finishes and produces an executable.

Howard Chu @ Symas

@mhoye I'm not sure what you're trying to illustrate with that example. You seem to be suggesting that compilers should be friendly enough to be usable by people who don't know the programming language. A C programmer has to know the difference between a character constant and a string literal, and what a multicharacter constant is. It's not the tool's job to teach the language syntax.

Anthony Sorace

@hyc @mhoye It’s not the tools’s job to teach the language, but that’s not what’s being asked for here. It *is* the tool’s job to provide meaningful errors, and it has failed here.

Howard Chu @ Symas

@a @mhoye The tool can't read the programmer's mind. Perhaps the "not a string literal" message should have been an error instead of a warning, since it clearly doesn't conform to the function signature. But beyond that, the programmer should know the difference between a string literal and any other data type. That's basic knowledge of the language. Knowing printf's signature is too, that's part of the language spec.

Matt Live in HD™

@hyc @a @mhoye it's warning about a multi-character character string, which means it basically does know that this is probably supposed to be double quotes. The programmers designed it to produce this warning here and for this reason, but then phrased the warning in a less coherent way

technomancy (turbonerd aspect)

@a @hyc @mhoye "treat the string as an argument to avoid this"

is gcc from mars??

Yancy Burns

@mhoye @hyc Then why does clang and llvm give better, more meaningful error messages than gcc?

jr conlin

@hyc @mhoye

Ancient Sumerian is the oldest form of written language, and there are numerous translation texts available. Surely, it's no challenge to the modern reader.

To presume that someone has skill or knowledge is to exclude a large number of people. Everyone has their own skill sets. Your skills are not as important to others.
Excluding people is not a great way to help them understand or use something.

Howard Chu @ Symas

@jrconlin @mhoye French is a widely used modern language, with many active speakers and plentiful learning resources. Why should I have to spend more than 30 seconds to learn to understand it?

"Tl;dr" is a copout.

jr conlin

@hyc @mhoye

True, but you're also far more likely to find someone translate from French than Sumerian. Thus why we now have TL;DR and Stack Overflow.

If I found out more people read someone else's summary of a tool or library that I wrote, I'd do my best to work that summary in as my documentation. Maybe even take a few pointers about how to present information better as well.

Howard Chu @ Symas

@jrconlin @mhoye that latter makes sense, but there's copyright issues to consider. Will the author of that summary grant you permission to incorporate their text into your docs? If so, why didn't they just contribute it to your project in the first place?

jr conlin

@hyc @mhoye

Uhm, maybe they wrote it because they don't understand how to submit a PR? (Again, different skill sets and not wanting to learn Sumerian. That's why requiring knowledge from someone can make your life harder.)

Maybe just reaching out to them would be enough, and a courteous thing to do anyway so that they get proper credit? Heck, even if they say "No", there are still lessons to be learned.

Howard Chu @ Symas

@jrconlin @mhoye not everything revolves around github PRs. A simple email "hey I wrote this summary for you" is all it would take to get the ball rolling.

Putting the onus on the developer to reach out to the user for this is unsustainable and unrealistic. It would require constantly sifting the web to find these useful snippets.

Whoever wrote the summary just has to hit Send on one email.

jr conlin

@hyc @mhoye

Heh, and all the original doc writer had to do was get one editor. Which is pretty common and not difficult at all for any professional writer. Asking the audience to do that for him is unsustainable and unrealistic.

The author wrote that up because they don't believe that the original source sufficiently solved their problem, nor would the be able to.

Kinda damning, if you think about it.

Howard Chu @ Symas replied to jr

@jrconlin @mhoye so now you seem to be demanding that developers be professional writers.

I suppose it's fair to expect professional writers to be employed by commercial software providers. Not fair to demand anything of open source; if no one steps up and volunteers then the audience has no one to blame but themselves.

jr conlin replied to Howard Chu @ Symas

@hyc @mhoye

I'm asking that developers be aware of skills that may not be code based, yes.
I'm asking that developers recognize a failure state and work to find solutions for it, yes.
I'm asking that the industry generally get over itself and understand that they may need help in certain things instead of presuming that they're good at it.

Shauna GM replied to jr

@jrconlin @hyc @mhoye the solution to "there is a big gap between what maintainers provide and what users need" is not to ask overworked/underpaid FOSS maintainers to take on more responsibility. nor is it to deny the need exists.

the solution is for the broader community to recognize the value of user-facing, newcomer-friendly docs and dedicated user support, and to help maintainers provide them. that requires investment. it's part of the broader open source collective action problem.

Ed W8EMV replied to Shauna

@shauna @jrconlin @hyc @mhoye

I can think of a couple of categories of things beyond the core code itself that are needed for the long-term health of a project:

- an accurate and detailed man page
- a "getting started" guide that deals with building, installing, and running some kind of "hello world" code to validate the install
- architecture documents that describe how and when to use the code
- a conference presentation aimed at a knowledgable audience
- full-length book

Rare to get all.

@shauna @jrconlin @hyc @mhoye

I can think of a couple of categories of things beyond the core code itself that are needed for the long-term health of a project:

- an accurate and detailed man page
- a "getting started" guide that deals with building, installing, and running some kind of "hello world" code to validate the install
- architecture documents that describe how and when to use the code
- a conference presentation aimed at a knowledgable audience
- full-length book

jr conlin replied to Ed

@w8emv @shauna @hyc @mhoye

I think it's also somewhat important to note scale. A tiny package used by a few folk probably doesn't need much more than what folk already do. This would probably not overburden that one guy in Nebraska.

Once a project "graduates", takes on devs, and grows in use, then documentation becomes more important, just like security updates. Large projects should help by reaching down to smaller ones that they depend on.

robertmx replied to jr

@jrconlin

@hyc @mhoye

It would be more appropriate if you stopped asking and started doing, at least in the context of open source.

The developers of any OS software have exactly zero obligation to fulfill random wishes of random dudes who happened to find their software useful. If you want to get it done, do it yourself or pay somebody to do it instead of wasting time to whine about it on the public internet instead of using a bug tracker.

#dramaqueen

mhoye replied to Howard Chu @ Symas

@hyc @jrconlin

My dude you have gone from "the problem is that people are stupid and illiterate" past "just learn regexes" straight to "asking developers to be competent at communicating in writing is bad", and you can fuck right off with all of that. You don't want to write docs, we get it. Just own the fact that you'd rather sneer at people than rub two synapses together to think about usability and leave it at that.

Howard Chu @ Symas replied to mhoye

@mhoye @jrconlin people write open source code because they saw a need and decided to address it. The fact that tech writers haven't also seen a similar need and stepped up to address it isn't the open source devs' fault. Demanding that someone who gave you a gift give it to you in a particular shape, size, and color is just being greedy.

Howard Chu @ Symas replied to Howard Chu @ Symas

@mhoye @jrconlin to accuse me personally of not wanting to write docs is baseless. My LMDB project is thoroughly documented. Not only are the docs complete and easily accessible lmdb.tech/doc they're written in Doxygen, embedded in the source code and header files and always kept up to date with code changes.

jr conlin replied to Howard Chu @ Symas

@hyc @mhoye

I feel like we're closing the circle here.
You wrote documents, possibly good ones, possibly not. I don't know if you had anyone edit them or if you thought about the audience. Maybe you did, maybe there are guides out there that people read instead and you don't know or care.

I know that I am not a good enough writer or editor to presume that my docs are perfect. I also don't presume my audience is lazy or stupid.
It's communication.
It's hard.
We can do better.

Howard Chu @ Symas replied to jr

@jrconlin @mhoye The original audience for LMDB was developers who already used BerkeleyDB. Particularly relevant to this conversation, the Getting Started guide, for people unfamiliar with either LMDB or BDB, was written by a user and contributed to the project.

Howard Chu @ Symas replied to mhoye

@mhoye @jrconlin it's working at this moment. It was timing out for me too, right after I posted.

also note

mastodon.social/@hyc/111178941

Colby Russell replied to Howard Chu @ Symas

@hyc it reads like the basis of the disagreement here is not even your opinion/position, but your (incredibly frustrating) attempts to move the goalposts.

If your immediate reaction to someone trying to call attention about how much something sucks had just involved you saying, "Yeah, that does suck. It's just that no one has put the time in to making it not suck yet," instead of what you actually did—engage in dithering apologetics—then you and @mhoye wouldn't be having this conversation.

Colby Russell replied to Colby

@hyc the goalpost moving comes across as worse than disinterest in fixing the problem. It's flak that has to be dodged by anyone on the path towards trying to get the problem fixed.

Nobody in open source owes anyone else perfect jewels. But if lack of time/energy to put together a proper fix is at the root of the problem, questions remain about all the time and energy put into denying the problem existed and fervently arguing that everyone is just "illiterate and stupid".

Peter Kraus

@hyc @jrconlin @mhoye oh I strongly disagree. Just like The Wall is not the same on shuffle, order of things matters. It's not the readers fault that the writer is incoherent. Fix your docs.

Howard Chu @ Symas

@pkraus @jrconlin @mhoye that's a red herring. A document might be structured to present information in a logical order, but that's not relevant to the person who just wants to find a particular example.

jr conlin

@hyc @pkraus @mhoye

It also presumes that there is only one logical path for information to take, when that's seldom the case. It's also why books have tables of contents and indexes.

(I'll also note that the most popular track on that album comes fifth, and it's not like folk are always listening to everything that comes before it.)

Tom Walker

@jrconlin @hyc @mhoye Yes, open source documentation *loves* enumerating minor obscure details instead of telling me what the damn thing is or does

Go Up