all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Julien Lepiller <julien@lepiller.eu>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Reworking the cookbook layout
Date: Wed, 27 Nov 2019 12:08:00 +0100	[thread overview]
Message-ID: <CAJ3okZ0agT4SQYO-SNYjr7WeHBmKGsbkoGHc3hOUrEARG3PRUQ@mail.gmail.com> (raw)
In-Reply-To: <20191126231136.212ff31e@sybil.lepiller.eu>

Hi,

Thank you to open the discussion about the Cookbook.

The first thing is: what is the purpose of the Cookbook? I mean I am
not sure we all define the same object with the same goal.

Currently, it is all what cannot be included in the Reference Manual.
So do we need to organize all this material with an strong hierarchy?
A cookbook is a collection of recipes and it not generally well
organized. I am mean the one of my Grand-Mother is not. :-)


On Tue, 26 Nov 2019 at 23:12, Julien Lepiller <julien@lepiller.eu> wrote:

> Today I have been reading https://www.divio.com/blog/documentation/
> which makes some good points on how to write good documentation. They
> suggest to divide documentation into four categories, depending on
> their purpose:

I was reading similar elsewhere with the idea to prepare what we could
propose for the next round of the Google Seasons of Doc [1] (if any).

[1] https://developers.google.com/season-of-docs


> - tutorials, written for newcomers. They should be to the point and
>   guide a new user through every step of using the new system.
> - how-tos. They should be "goal-oriented" and allow
>   a user who knows what they want to do, to learn how to do it.
> - explanations. They are more theoretical and should give more
>   knowledge on how it all works.
> - reference. It should contain all the technical details of the code.

To me this structure is nice but too strong. I do not see what is the
difference between "how-tos" and "tutorials".

And for example, the blog "Packaging" entry is in the same time:

 - a tutorial because it is written for newcomers
 - "goal-oriented" because it explains "how to package"
 - explicative because it provides how it all works (scheme explanations, etc.)

So I feel an arbitrary boundary.

Then it is some work to revamp the blog entries and we should reduce
the workload because when we are revamping we are not writing other
materials.


> Following these principles, I propose the attached patch, that changes
> the layout a bit. Instead of grouping articles by topic, I suggest
> grouping them by one of the first three categories above (the guix
> manual is the reference, and it's excellent, so we don't need a
> reference documentation in the cookbook).

I propose to group in 2 categories:

 - How To / Tutorial
 - Blog post

And the both can overlap. I mean it is not an issue that a blog post
entry explains Scheme for the beginners and in the time there is an
entry "My first steps with Scheme" in the "How To/Tutorial".

The issue is that the Blog part could not be synchronise. But let warn
the reader and to me it is not an issue. The Blog part can be amended
when something wrong is reported.

Concerning deeper explanations (for example relationship between
Docker and Guix), I consider that as a "tutorial": a method of
transferring knowledge (wikipedia) or the tutor teaches/discusses
particular point (Collins dic.).


What do you think?


All the best,
simon

  parent reply	other threads:[~2019-11-27 11:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 22:11 Reworking the cookbook layout Julien Lepiller
2019-11-27 10:21 ` Pierre Neidhardt
2019-11-27 14:21   ` sirgazil
2019-11-27 11:08 ` zimoun [this message]
2019-11-27 12:14   ` Julien Lepiller
2019-11-27 15:26     ` zimoun
2019-11-27 17:47       ` Julien Lepiller
2019-11-28  0:43   ` Bengt Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ3okZ0agT4SQYO-SNYjr7WeHBmKGsbkoGHc3hOUrEARG3PRUQ@mail.gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.