Very recognizable. I've used Hugo for exactly one website, as a first introduction to static site generators. The site still runs, and if I need to change something running the `hugo` CLI still works. But it wasn't easy to get started, with all these new concepts, and this site explains clearly the trouble I had. Perhaps it's expected that when you use Hugo, you already recognize most concepts from other static site…
No, even with past static site generator experience, it can still be a struggle. I had extremely extensive experience with Movable Type, which was a once-hugely-popular blogging platform / CMS / static site generator. And by "extremely extensive", I mean I worked for the company that made the software, in their Services org which built Movable Type-driven sites for major media partners. Despite this, and also already…
Hugo is awesome, its documentation is not
101–110 of 128 posts
Re: Hugo is awesome, its documentation is not
#102Earlier quoted context omitted.
I'm working a bit with GCP infrastructure lately and I find Google's docs very well-written, but suffering from a bit of the opposite problem. Many docs are written as how-tos for very specific scenarios, often the most basic setup thinkable (which makes sense!). If you're trying to understand the abstractions in order to see what will make sense for your own project, it's a difficult way to get the full picture. :D…
The problem Google runs into is a lot of the systems they build in GCP are written that way too: with a specific set of user-stories in mind, and an "I guess we'll see what the community does with it" attitude for any use cases they didn't anticipate. This might be a symptom of the problem domain itself.
Look at the fancy load balancer, it can do traffic splitting and you can attach a security policy (waf) to it! Oh wait, you can't do traffic management stuff with the "classic" (legacy) LB, switch to the new one that's still in "preview" (beta). Oh wait, it doesn't support the waf yet. Etc etc.
Another one is some sort of hard-coded service users that must be in place to run things, for example in App Engine. If you delete it, you can't just create a new one with the same permissions, you must undelete it... but only if less than 30 days have passed (!).
All of this is documented of course, but spread out all over the place. The thing about deleting service users isn't (as far as I know) made clear in the IAM docs, for example. The only place I found it was in a howto for the App Engine Python environment: "Using the Default App Engine Service Account".
I share the author's frustration, if it isn't obvious :)
Re: Hugo is awesome, its documentation is not
#103Re: Hugo is awesome, its documentation is not
#104Earlier quoted context omitted.
Instead of "sucks", how about any of these: * My Frustrations with Hugo's Documentation * How Hugo's Documentation Confuses Me and How to Improve It * Why I Don't Like Hugo's Documentation The key thing I've done here in the first three is to reframe the criticism as an _opinion_ ("I", "me", "my") rather than an absolute ("it sucks"). I don't think it's too much to ask people to state their opinions _as opinions_ in…
As written it seems to me the intent of the article is to publicly shame the open source devs who contribute their time and effort into doing more work for free. It's typical open source toxicity.
In project like Hugo that has no "user interface" to speak of, tools for which you can't reasonably be expected to just look at the UI screens and figure things out if they're nicely done because there are no UI screens to look at, the documentation is the user interface. Full stop.
The article lays out exactly what its author doesn't like about the documentation and makes suggestions for improvement. The "your documentation sucks" title is the harshest thing about it, and if it was truly a rant I could see getting prickly about it, but it absolutely is not. This is constructive criticism. And that's just as important for an open source project as it is for any other project.
I get bristling at the "if you can't stand having your suggestions torn apart, then don't contribute to open source" weird macho mindset some projects have historically have. Yes, it's toxic. But "if your suggestion is not sufficiently deferential, away with you" goes too far in the other direction.
Re: Hugo is awesome, its documentation is not
#105Add ability to generate per-{year, month, day} archives: https://github.com/gohugoio/hugo/issues/448
Re: Hugo is awesome, its documentation is not
#106Earlier quoted context omitted.
I tried to start a discussion about documentation as reference vs. tutorials on the forums too: https://discourse.gohugo.io/t/discussion-of-hugo-theme-from-... I think the problem is just that no one wants to bell the cat. :-(
> no one wants to bell the cat. :-( Never heard this refrain before! What does it mean? No one wants to get on leadership's bad side?
> Belling the Cat is a fable ... In the story, a group of mice agree to attach a bell to a cat's neck to warn of its approach in the future, but they fail to find a volunteer to perform the job. The term has become an idiom describing a group agreeing to perform an impossibly difficult task.
Re: Hugo is awesome, its documentation is not
#107Earlier quoted context omitted.
I tried to start a discussion about documentation as reference vs. tutorials on the forums too: https://discourse.gohugo.io/t/discussion-of-hugo-theme-from-... I think the problem is just that no one wants to bell the cat. :-(
> no one wants to bell the cat. :-( Never heard this refrain before! What does it mean? No one wants to get on leadership's bad side?
Re: Hugo is awesome, its documentation is not
#108another one is vitepress(vue3 based but you don't need know vue3 to use vitepress) that you can have multiple 'books' under one site.
Re: Hugo is awesome, its documentation is not
#109Earlier quoted context omitted.
No, even with past static site generator experience, it can still be a struggle. I had extremely extensive experience with Movable Type, which was a once-hugely-popular blogging platform / CMS / static site generator. And by "extremely extensive", I mean I worked for the company that made the software, in their Services org which built Movable Type-driven sites for major media partners. Despite this, and also already…
Almost off-topic, but I continue to be mildly surprised that there's so few "modern" blogging platform/site generators that use Movable Type's model: a full user-friendly publishing/admin back end, backed by a database rather than flat files, but still basically generating static files for output. The SSGs that Jekyll arguably led the rise of have still largely stayed in the realm of developer tooling -- edit a direc…
There is a space that I'd like to explore, though, and that's having a static site generator that is built into a desktop-based GUI. My dream is to get the brain-dead security of an SSG without having to fiddle about with files and folder structures.