Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal

[Daniel Tornabene]

Looking forward to your talk Blake, don't worry, the gist came across the
first time I was just offering my own experience and opinions of the
documentation. Genuinely excited to see what you come up with,
documentation is one of my favorite things in free software actually

On Tue, Feb 8, 2022 at 10:59 AM Blake Shaw <blake@nonconstructivism.com>
wrote:

> Daniel Tornabene <d.t.peters777@gmail.com> writes:
>
> > just a simple guile user here, sitting next to my printed out 2.2.6
> > manual. I'm interested in this topic as well though I'd say my own
> > experience with the documentation is less a problem with it as it is
> > then with its organization. Perhaps I'm an anomaly, but I enjoy and
> > appreciate a manual with significant, bordering on completeness of
> > coverage of not simply the language, but the relevant api.  I'd also
> > add that the small examples littered throughout the text which add to
> > the length have however been quite helpful to me personally, and
> > demonstrating multiple possible paths one might take given a language
> > construct is a good thing in a lisp, especially one that attempts to
> > be as approachable as guile does. The comparisons to racket and rust
> > printed manuals are enlightening though, and I'd be very interested in
> > a "close reading", as it were, that susses out the structural and
> > stylistic details in a comparative way. Successfully done that in and
> > of itself would be both a major accomplishment for our corner of the
> > PL world and other software communities with a serious commitment to
> > documentation and even to non programmers wanting to understand how
> > such complicated endeavours such as a community developed programming
> > language effectively communicates information and practices.
> >
>
> for sure, just to clarify as a few folks have commented on this --
> & so it seems the summary i provided may have been misleading -- my
> talk will deal primarily with the structure of the docs, not what can
> be cut out. i'm really focused here on the user experience, and cutting
> out not length but instead inconsistencies: in language, layout, order,
> and style so that users can anticipate a general cadence and thus
> navigate with greater ease. in fact, i think the end result may be a
> longer manual, but one in which users will have a simplified mental
> map, so that amidst hacking you can navigate whether by paper of
> texinfo to what you're looking for, and be in and out, back to the repl
> as seamlessly as possible. the hope is to cut out downtime caused while
> consulting the docs, while also preserving the deeper more essayistic
> nuggets for when its time to take a plunge.
>
> i will offer suggestions for sets of guidelines dealing with various
> aspects of structure, that intend to both add and preserve existing
> structure. so it's kind of a 'functor' approach to structuring the
> docs. this is also where the feedback session will be key, as longtime
> users will have the knowledge of what would be *objectively bad*.
>
> so in a sense, I will offer *weak* or abstract guidelines, and for those
> that the community agrees are beneficial we should focus on collectively
> strengthening them such that they may compose as a system that is
> general, concrete, and true to the language itself.
>
> --
> “In girum imus nocte et consumimur igni”
>