unofficial mirror of guix-devel@gnu.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 16:26:06 +0100	[thread overview]
Message-ID: <CAJ3okZ0p87bD9OB-d2A2j3BSzGzkQRw1AbHoGixyttHh_n=29g@mail.gmail.com> (raw)
In-Reply-To: <E1A2761F-1E5F-4866-99BD-3F4E44280258@lepiller.eu>

I break the usual rules of reply. Hope that will be ok. :-)


On Wed, 27 Nov 2019 at 13:14, Julien Lepiller <julien@lepiller.eu> wrote:

> Le 27 novembre 2019 12:08:00 GMT+01:00, zimoun <zimon.toutoune@gmail.com> a écrit :

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


> >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. :-)
>
> So, following the structure I propose, the cookbook would only contain tutorials and how-tos. Then we would need another place for deeper explanations.

[...]

> >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.
>
> [...] I think a clearer editorial policy will help us see what's needed and bring in more contributions.

I agree that a clearer editorial policy will help us.

It is what I am trying to point too. :-)

However, I disagree on the structure you propose because I find it too
strong, with too much boundary.


> >To me this structure is nice but too strong. I do not see what is the
> >difference between "how-tos" and "tutorials".
>
> A tutorial does not have a particular goal other than giving a tour of the tools and main functionalities. So it's more a what-is than a how-to. Not how to program in scheme, but what is it like to program in scheme.

To me, it is too arbitrary.

Non-related example, but maybe it underlines my point. Recently, I
discovered that we can generate Docker images on foreign distro using
"guix system docker-image". But because of the structure, I have never
carefully read the section "System Configuration". I have always
thought that this section was about "Guix System" and I am not
currently using it. Well, I am not saying that the Reference Manual is
doomed; in this case, I am too lazy to correctly search. And for sure,
we have to put somewhere somestuff.

My point is: what naturally makes sense to you does not necessary make
sense to me, and vice-versa. And decide if this or that belongs to
that or this is often arbitrary. That's why I think the structure
needs only 2 levels and a good index.


> >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.
>
> I think it's not too nice to mix all of this together: I'm already a packager, so I don't need a tutorial on packaging or scheme. I could still learn something, but I'll skip most of this document. I think it's best to split it for different readers: a tutorial, how-tos for some difficult points that can arrise and explanations of the packaging architecture for instance.

In my (real) cookbook, I have 2 different recipes of the same meal
(say galette [sarrasin] ;-)).
And they are not written on pages close to each selfes but contrary
one is on the beginning of the cookbook, the other at the end.
One comes from a friend -- student time.
One comes from a guest -- couch surfing or related.
Now, I could write my own recipe, kind of adaptation of the two
previous ones. However, my sister find easier the first one and my dad
the last one. See what I mean? :-) It depends on the flavour, how you
read, etc.

Well, we disagree on what should be the Cookbook because it lacks a
clear editorial policy. ;-)
Are not we trying to define one right now? :-)

To me, the cookbook is a collection of recipes. And different recipes
can overlap. To me, a recipe is a story about a topic; the same
explanations can be detailed twice if they are important to the story.
And because they are worded differently, Alice will prefer the story 1
and Bob the 2. Some story can be short, other lengthy. One key point
is a good index: an index where a "concept" that points to several
entries.


> > Right, but we're not writing a lot either way…

Yes! I agree. Because 1. it is relatively new 2. it is hard to know
what is the editorial policy (aim of the cookbook) so 3. the blog post
has been revamped.

For example, I have a draft (needs a lot of polishing) about "My first
steps to contribute" and I do not know what to do with.



I am happy that you have opened the discussion. And I think that
writing a recipe should be a good way to attract new contributors.



Cheers,
simon

  reply	other threads:[~2019-11-27 15:26 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
2019-11-27 12:14   ` Julien Lepiller
2019-11-27 15:26     ` zimoun [this message]
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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to='CAJ3okZ0p87bD9OB-d2A2j3BSzGzkQRw1AbHoGixyttHh_n=29g@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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).