unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Matt <matt@excalamus.com>
To: "Josua Stingelin" <josuast@hotmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Guix wiki
Date: Tue, 11 Jan 2022 20:57:43 -0500	[thread overview]
Message-ID: <17e4c0157b1.10c0ebd9d367025.4850987542317518993@excalamus.com> (raw)
In-Reply-To: <DB9PR06MB7657EC001252CC14DB83D15FAA509@DB9PR06MB7657.eurprd06.prod.outlook.com>

 ---- On Mon, 10 Jan 2022 03:29:35 -0500 Josua Stingelin <josuast@hotmail.com> wrote ----

 > I've been following the gnunet for a while so I felt qualified to comment.
 > 
 > > Concern 1: guix will be soon be distributed over gnunet
 > Guix could provide an endpoint in the gnunet network for users that prefer to
 > use it. However there's no reason to prevent it from being accessible using the
 > current TCP/IP stack.
 > 
 > The goal of gnunet is to replace the TCP/IP stack. It is built as an overlay
 > and underlay network. It can run on TCP/IP but could also replace it. Every
 > application using TCP/IP would have to be converted to use gnunet or
 > gnunet would have to emulate TCP/IP. Until then they'll run in parallel.

Thanks for explaining.  

 > > Concern 5: having a wiki may confuse what the primary source of documentation is (i.e. the manual)
 > > 
 > >   I'm not sure I understand why this is a problem. Of course,
 > >   confusion should be minimized.  But the primary source of
 > >   documentation should be the one that best helps the user.  Ideally,
 > >   that is the manual.  Is there a negative consequence for the primary
 > >   source not being the manual?  For example, how many of you have used
 > >   the Arch wiki to solve problems for something other than the Arch
 > >   system?  Is that a problem?
 > 
 > I suppose that depends on the user. As a new linux user I tended to only use
 > the information available for my distro. Only after knowing the differences
 > from the distros have I started to use a wider spectrum for information.
 > 
 > That may primarily be a question of the target audience for guix?

My guess, as Guix is a package manager, there are two audiences: package users (end users) and package maintainers. I'm curious what degree of separation between those should exist for Guix. 

 > > Concern 8: the manual should have all the examples necessary for people to understand how to tweak things
 > > 
 > >   Agreed.  Contributing to documentation also shouldn't be as
 > >   difficult as it currently is, but here we are.  Let's figure it out
 > >   together. :)
 > 
 > What about an online editing interface (analogous to Wikipedia) where everyone
 > can make edit suggestions.  Optimally directly converted to a patch by the
 > software.  Changes to the cookbook would have to be merged by the maintainers
 > and the community based wiki could either have a group of editors or a
 > consensus based workflow.
 > 
 > 
 > Personally I believe having one resource for information to be the preferred
 > solution. Maybe the Gentoo wiki could be a source of inspiration on what we'd
 > like to achieve?  (https://wiki.gentoo.org/wiki/Main_Page)

There is currently a wiki.  I could see it being a sandbox for what the manual may need.  But I also see disdain towards wikis by some here that's not unreasonable.


  reply	other threads:[~2022-01-12  1:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-09 21:14 Guix wiki Matt
2022-01-09 21:32 ` Vagrant Cascadian
2022-01-11 13:02   ` Matt
2022-01-11 18:29   ` Jonathan McHugh
2022-04-13 14:46   ` Aurora
2022-01-09 23:55 ` Vincent Legoll
2022-01-11 13:31   ` Matt
2022-01-11 15:17     ` Ricardo Wurmus
2022-01-12  2:52       ` Matt
2022-01-11 15:30     ` Tobias Geerinckx-Rice
2022-01-11 17:15       ` zimoun
2022-01-11 17:27         ` Tobias Geerinckx-Rice
2022-01-11 18:21           ` André A. Gomes
2022-01-11 18:50           ` zimoun
2022-01-12  2:06             ` Tobias Geerinckx-Rice
2022-01-12  8:55               ` zimoun
2022-01-12  9:22                 ` André A. Gomes
2022-01-12  3:51       ` Matt
2022-01-12 15:26         ` Luis Felipe
2022-01-11 16:48     ` Luis Felipe
2022-01-11 21:03     ` Attila Lendvai
2022-01-11 23:18       ` Ricardo Wurmus
2022-01-12  3:28         ` Matt
2022-01-18 14:34           ` Ludovic Courtès
2022-04-11  6:49             ` Attila Lendvai
2022-04-11  8:42               ` Maxime Devos
2022-04-13 15:01                 ` Attila Lendvai
2022-04-11  8:47               ` Maxime Devos
2022-01-12 11:19         ` Attila Lendvai
2022-01-12 11:52           ` Ricardo Wurmus
2022-01-12 12:00           ` André A. Gomes
2022-01-10  8:29 ` Josua Stingelin
2022-01-12  1:57   ` Matt [this message]
2022-01-12  9:19     ` Ricardo Wurmus
2024-01-10  9:55 ` Attila Lendvai
2024-01-17 19:17   ` Maxim Cournoyer

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=17e4c0157b1.10c0ebd9d367025.4850987542317518993@excalamus.com \
    --to=matt@excalamus.com \
    --cc=guix-devel@gnu.org \
    --cc=josuast@hotmail.com \
    /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).