all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Catonano <catonano@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: Customize GuixSD: Use Stock SSH Agent Everywhere!
Date: Tue, 29 May 2018 16:35:38 +0200	[thread overview]
Message-ID: <CAJ98PDzXBG+92iU=+uDncQVThi+v3rZpK9zwwzbfqaEV+BpMrA@mail.gmail.com> (raw)
In-Reply-To: <87lgc2r31y.fsf@elephly.net>

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

2018-05-29 15:42 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Hi Catonano,
>
> > In this regard, I'd lie to suggest this talk, I think it's relevant
> > https://archive.fosdem.org/2017/schedule/event/legacy_docs/
> >
> > It'd be very useful for Guile too and God knows for how many more GNU
> > projects
>
> Could you please summarize the key points and how they apply to this
> discussion?
>


Sure ! Thanks for asking ! 😃

I think a good starting point is this picture
https://files.mastodon.social/media_attachments/files/003/855/604/original/b02a794729c184ad.png

The key point of the talk is that the documentation usually illustrates the
technical features of a project

And the process of envisioning solutions for use cases is left to the reader

Instead, the documentation should start from specific use cases. It should
be an anthology of use cases

As for Guile, for example, Thomas Dankaert recently posted a question on
the guile user mailing list about how to use string as ports in calling
external commands; he wanted the error port of an external command to be a
string

The manual deals with input output in several locations scattered all around

Drawing a working solution for reading/writing is not exactly immediate

A bunch of examples would be more funcional, at least for some kinds of
readers/users

And input output is only one kind of use cases

Regarding Guix, having examples of use cases of using packages could be a
good starting point

So, finally, I think your idea of having a separate document providing a
different angle to using Guix is a good one

Other categories of use cases could be envisioned

It could cover not only the usage of specific packages but also some GuixSD
functionalities such as updating, setting up specific desktop environments,
services, reconfiguring

Those things are quite different from the common usage patterns of
mainstream distros and some reading-phobic people could use some quick
general examples to draw a general picture of Guix on their own

Maybe the traditional manual could be a further resource for those who want
to deepen their knowledge of Guix

How much am I ready to contribute to such a document ?

I don't know

I chimed in because I found interesting that a similar idea to that
illustrated in the talk came afloat here

[-- Attachment #2: Type: text/html, Size: 3339 bytes --]

  reply	other threads:[~2018-05-29 14:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-26 15:23 Customize GuixSD: Use Stock SSH Agent Everywhere! Ludovic Courtès
2018-05-28 11:16 ` Pierre Neidhardt
2018-05-28 11:28   ` Ricardo Wurmus
2018-05-28 15:28     ` Joshua Branson
2018-05-28 15:31       ` Pierre Neidhardt
2018-05-29 12:51     ` Catonano
2018-05-29 13:42       ` Ricardo Wurmus
2018-05-29 14:35         ` Catonano [this message]
2018-05-29 14:57           ` Reference manual + tutorials (was: Customize GuixSD: Use Stock SSH Agent Everywhere!) Ricardo Wurmus
2018-05-29 15:14             ` Catonano
2018-05-29 15:19               ` Reference manual + tutorials Julien Lepiller
2018-05-29 15:30                 ` Ricardo Wurmus
2018-05-29 19:38             ` Ludovic Courtès
2018-05-29 21:53               ` Ricardo Wurmus
2018-06-03 20:40                 ` Ludovic Courtès
2018-05-28 20:11 ` Customize GuixSD: Use Stock SSH Agent Everywhere! Divan Santana
2018-05-31 10:47   ` Divan Santana

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='CAJ98PDzXBG+92iU=+uDncQVThi+v3rZpK9zwwzbfqaEV+BpMrA@mail.gmail.com' \
    --to=catonano@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /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.