unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Should we start a Guix users wiki?
@ 2015-09-07 22:08 Craig Barnes
  2015-09-08  8:01 ` Amirouche Boubekki
  2015-09-08  9:54 ` Ludovic Courtès
  0 siblings, 2 replies; 8+ messages in thread
From: Craig Barnes @ 2015-09-07 22:08 UTC (permalink / raw)
  To: guix-devel

Hi Guix,

Some time ago I asked on IRC about a guix users wiki.  Someone suggest
that I propose one here (sorry it's taken so long).

I think that a wiki would be a good complement to the manual, which
while quite complete, lacks exhaustive examples (which would be
impractical).

I have found myself searching through the mailing list archives for
solutions, and trawling through relevant threads on a number of
occasions.  If this information was organized in a dedicated wiki it
would be much more accessible and would make it maintainable.

As an example, Arch(Gnu)Linux's wiki is one of it's stronger points.  I
often end up there when searching for answers to application questions
for other distros.

I would be more than happy to help maintain a Guix(SD) wiki, if needed I
would be happy to host it somewhere.

What do you think?


Cheers

Craig

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Should we start a Guix users wiki?
  2015-09-07 22:08 Should we start a Guix users wiki? Craig Barnes
@ 2015-09-08  8:01 ` Amirouche Boubekki
  2015-09-08  9:54 ` Ludovic Courtès
  1 sibling, 0 replies; 8+ messages in thread
From: Amirouche Boubekki @ 2015-09-08  8:01 UTC (permalink / raw)
  To: Craig Barnes; +Cc: guix-devel, guix-devel-bounces+amirouche=hypermove.net

Le 2015-09-08 00:08, Craig Barnes a écrit :
> Hi Guix,
> 
> Some time ago I asked on IRC about a guix users wiki.  Someone suggest
> that I propose one here (sorry it's taken so long).
> 
> I think that a wiki would be a good complement to the manual, which
> while quite complete, lacks exhaustive examples (which would be
> impractical).
> 
> I have found myself searching through the mailing list archives for
> solutions, and trawling through relevant threads on a number of
> occasions.  If this information was organized in a dedicated wiki it
> would be much more accessible and would make it maintainable.

And it will make the community more visible.


> As an example, Arch(Gnu)Linux's wiki is one of it's stronger points.  I
> often end up there when searching for answers to application questions
> for other distros.

Same over the gentoo/emacs wiki.

> I would be more than happy to help maintain a Guix(SD) wiki, if needed 
> I
> would be happy to host it somewhere.

It seems to me that it was kind of some trouble that the wiki was hosted
by a third party at gentoo.

> 
> What do you think?
> 

The only thing that I can think of, is that given the fact that guix 
will be soon distributed over gnunet. It makes more sens to have the 
official wiki also hosted on gnunet and make a copy of it available for 
reading on the www. Sure it's not done yet, and it needs to be coded. I 
think that we have all the pieces to make something like that happen.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Should we start a Guix users wiki?
  2015-09-07 22:08 Should we start a Guix users wiki? Craig Barnes
  2015-09-08  8:01 ` Amirouche Boubekki
@ 2015-09-08  9:54 ` Ludovic Courtès
  2015-09-08 12:40   ` Thompson, David
  2015-09-08 14:37   ` Mark H Weaver
  1 sibling, 2 replies; 8+ messages in thread
From: Ludovic Courtès @ 2015-09-08  9:54 UTC (permalink / raw)
  To: Craig Barnes; +Cc: guix-devel

Hi,

Craig Barnes <cjbarnes18@gmail.com> skribis:

> Some time ago I asked on IRC about a guix users wiki.  Someone suggest
> that I propose one here (sorry it's taken so long).
>
> I think that a wiki would be a good complement to the manual, which
> while quite complete, lacks exhaustive examples (which would be
> impractical).

I have mixed feelings.  There are several issues with a Wiki: one can
hardly know which version of the software it’s talking about (whereas
the installed Info pages of PDFs necessarily match the installed
version), and more importantly, it tends to be disorganized,
unmaintained, and often misleading.

I would strongly encourage people to help fix the manual as a first
step.  If information that a user deems useful is missing from the
manual, then it’s a bug.  I’m willing to make it as simple as possible
to fix the manual.  But really, the manual should have all the examples
necessary for people to understand how to tweak things.

There might be cases where specific information doesn’t quite fit in the
manual, like, say, instructions for a specific laptop model.  These
could go in a wiki.

Overall, I think it’s fine to have stuff at
<https://libreplanet.org/wiki/Group:Guix/> for instance, but the manual
should clearly remain the primary source of documentation, without any
ambiguity.

So, what would you like to add to the manual?  :-)

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Should we start a Guix users wiki?
  2015-09-08  9:54 ` Ludovic Courtès
@ 2015-09-08 12:40   ` Thompson, David
  2015-09-08 14:37   ` Mark H Weaver
  1 sibling, 0 replies; 8+ messages in thread
From: Thompson, David @ 2015-09-08 12:40 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Craig Barnes

On Tue, Sep 8, 2015 at 5:54 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi,
>
> Craig Barnes <cjbarnes18@gmail.com> skribis:
>
>> Some time ago I asked on IRC about a guix users wiki.  Someone suggest
>> that I propose one here (sorry it's taken so long).
>>
>> I think that a wiki would be a good complement to the manual, which
>> while quite complete, lacks exhaustive examples (which would be
>> impractical).
>
> I have mixed feelings.  There are several issues with a Wiki: one can
> hardly know which version of the software it’s talking about (whereas
> the installed Info pages of PDFs necessarily match the installed
> version), and more importantly, it tends to be disorganized,
> unmaintained, and often misleading.
>
> I would strongly encourage people to help fix the manual as a first
> step.  If information that a user deems useful is missing from the
> manual, then it’s a bug.  I’m willing to make it as simple as possible
> to fix the manual.  But really, the manual should have all the examples
> necessary for people to understand how to tweak things.

+1

- Dave

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Should we start a Guix users wiki?
  2015-09-08  9:54 ` Ludovic Courtès
  2015-09-08 12:40   ` Thompson, David
@ 2015-09-08 14:37   ` Mark H Weaver
  2015-09-10 10:47     ` Craig Barnes
  1 sibling, 1 reply; 8+ messages in thread
From: Mark H Weaver @ 2015-09-08 14:37 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Craig Barnes

ludo@gnu.org (Ludovic Courtès) writes:

> Craig Barnes <cjbarnes18@gmail.com> skribis:
>
>> Some time ago I asked on IRC about a guix users wiki.  Someone suggest
>> that I propose one here (sorry it's taken so long).
>>
>> I think that a wiki would be a good complement to the manual, which
>> while quite complete, lacks exhaustive examples (which would be
>> impractical).
>
> I have mixed feelings.  There are several issues with a Wiki: one can
> hardly know which version of the software it’s talking about (whereas
> the installed Info pages of PDFs necessarily match the installed
> version), and more importantly, it tends to be disorganized,
> unmaintained, and often misleading.

Agreed.  There are a small handful of highly successful wikis, but most
of them are as Ludovic describes.  Maintaining a good wiki requires a
great deal of work by experts to monitor changes, fix things up, and to
update the wiki as needed when Guix is updated to avoid giving users
outdated advice.  I suspect it only makes sense when the scale of the
documentation and the number of people involved is at least two, maybe
three orders of magnitude greater than the Guix project.

> I would strongly encourage people to help fix the manual as a first
> step.  If information that a user deems useful is missing from the
> manual, then it’s a bug.  I’m willing to make it as simple as possible
> to fix the manual.  But really, the manual should have all the examples
> necessary for people to understand how to tweak things.

I agree with Ludovic.  The manual would require far less work from our
small pool of experts to maintain than a wiki, and has a couple of
inherent advantages:

* the manual is stored in the same git repository as Guix itself, so
  they can be kept in sync at all times.

* the manual can easily be read and modified while offline.

> There might be cases where specific information doesn’t quite fit in the
> manual, like, say, instructions for a specific laptop model.  These
> could go in a wiki.
>
> Overall, I think it’s fine to have stuff at
> <https://libreplanet.org/wiki/Group:Guix/> for instance, but the manual
> should clearly remain the primary source of documentation, without any
> ambiguity.

+1

     Mark

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Should we start a Guix users wiki?
  2015-09-08 14:37   ` Mark H Weaver
@ 2015-09-10 10:47     ` Craig Barnes
  2015-09-10 13:58       ` Ludovic Courtès
  2015-09-10 15:35       ` Cook, Malcolm
  0 siblings, 2 replies; 8+ messages in thread
From: Craig Barnes @ 2015-09-10 10:47 UTC (permalink / raw)
  To: guix-devel

On 08/09/15 15:37, Mark H Weaver wrote:
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Craig Barnes <cjbarnes18@gmail.com> skribis:
>>
>>> Some time ago I asked on IRC about a guix users wiki.  Someone suggest
>>> that I propose one here (sorry it's taken so long).
>>>
>>> I think that a wiki would be a good complement to the manual, which
>>> while quite complete, lacks exhaustive examples (which would be
>>> impractical).
>> I have mixed feelings.  There are several issues with a Wiki: one can
>> hardly know which version of the software it’s talking about (whereas
>> the installed Info pages of PDFs necessarily match the installed
>> version), and more importantly, it tends to be disorganized,
>> unmaintained, and often misleading.
In order to make sure that examples in the manual aren't broken,
wouldn't something equivalent to python doctests be necessary to ensure
this? I think it would be worse to have a broken example in the manual
than somewhere else.  If the number of examples grow this could be
equally unmaintainable.
> Agreed.  There are a small handful of highly successful wikis, but most
> of them are as Ludovic describes.  Maintaining a good wiki requires a
> great deal of work by experts to monitor changes, fix things up, and to
> update the wiki as needed when Guix is updated to avoid giving users
> outdated advice.  I suspect it only makes sense when the scale of the
> documentation and the number of people involved is at least two, maybe
> three orders of magnitude greater than the Guix project.
>
>> I would strongly encourage people to help fix the manual as a first
>> step.  If information that a user deems useful is missing from the
>> manual, then it’s a bug.  I’m willing to make it as simple as possible
>> to fix the manual.  But really, the manual should have all the examples
>> necessary for people to understand how to tweak things.
> I agree with Ludovic.  The manual would require far less work from our
> small pool of experts to maintain than a wiki, and has a couple of
> inherent advantages:
>
> * the manual is stored in the same git repository as Guix itself, so
>   they can be kept in sync at all times.
>
> * the manual can easily be read and modified while offline.
>
>> There might be cases where specific information doesn’t quite fit in the
>> manual, like, say, instructions for a specific laptop model.  These
>> could go in a wiki.
>>
>> Overall, I think it’s fine to have stuff at
>> <https://libreplanet.org/wiki/Group:Guix/> for instance, but the manual
>> should clearly remain the primary source of documentation, without any
>> ambiguity.
Thank you for your feedback on this, I agree with your points, and that
in this case the manual is the better place for this information.

Going back to my original problem of finding information that isn't
currently in the manual, it would be great if there where an easier way
to search / browse the mailing list archives.  This would make
extracting great examples to add to the manual easier.  Any suggestions
would be appreciated.


Cheers

Craig

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Should we start a Guix users wiki?
  2015-09-10 10:47     ` Craig Barnes
@ 2015-09-10 13:58       ` Ludovic Courtès
  2015-09-10 15:35       ` Cook, Malcolm
  1 sibling, 0 replies; 8+ messages in thread
From: Ludovic Courtès @ 2015-09-10 13:58 UTC (permalink / raw)
  To: Craig Barnes; +Cc: guix-devel

Craig Barnes <cjbarnes18@gmail.com> skribis:

> On 08/09/15 15:37, Mark H Weaver wrote:
>> ludo@gnu.org (Ludovic Courtès) writes:

[...]

>>> I have mixed feelings.  There are several issues with a Wiki: one can
>>> hardly know which version of the software it’s talking about (whereas
>>> the installed Info pages of PDFs necessarily match the installed
>>> version), and more importantly, it tends to be disorganized,
>>> unmaintained, and often misleading.
> In order to make sure that examples in the manual aren't broken,
> wouldn't something equivalent to python doctests be necessary to ensure
> this? I think it would be worse to have a broken example in the manual
> than somewhere else.  If the number of examples grow this could be
> equally unmaintainable.

Good point.  Examples that were added lately have been put in separate
files so that we can at least manually test that they work as
advertised.

Now, I think it would be good to add targets in ‘doc.am’ to
automatically check the examples.  I think these wouldn’t be in-depth
tests.  For example, for OS declarations, we could simply make sure that
‘guix system build EXAMPLE --dry-run’ passes.  Likewise for the ‘guix
environment --load’ example.

WDYT?

I could add a couple of rules in ‘doc.am’ so that people have a template
to reuse when they add new examples.

(I do think we need VM- or container-based tests of complete systems,
but that’s a separate issue IMO.)

> Going back to my original problem of finding information that isn't
> currently in the manual, it would be great if there where an easier way
> to search / browse the mailing list archives.  This would make
> extracting great examples to add to the manual easier.  Any suggestions
> would be appreciated.

There’s a search facility at
<https://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=guix-devel>
that is not perfect, but a good start.

Alternately there’s the GMane mirror at
<http://dir.gmane.org/gmane.comp.gnu.guix.devel>, which supports both
searching and browsing.

The email client that I use, Gnus, also provides handy search facility
and the ability to browse the complete history of a GMane group over
NNTP.

HTH,
Ludo’.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Should we start a Guix users wiki?
  2015-09-10 10:47     ` Craig Barnes
  2015-09-10 13:58       ` Ludovic Courtès
@ 2015-09-10 15:35       ` Cook, Malcolm
  1 sibling, 0 replies; 8+ messages in thread
From: Cook, Malcolm @ 2015-09-10 15:35 UTC (permalink / raw)
  To: 'Craig Barnes', guix-devel@gnu.org


 > -----Original Message-----
 > From: guix-devel-bounces+mec=stowers.org@gnu.org [mailto:guix-devel-
 > bounces+mec=stowers.org@gnu.org] On Behalf Of Craig Barnes
 > Sent: Thursday, September 10, 2015 5:47 AM
 > To: guix-devel@gnu.org
 > Subject: Re: Should we start a Guix users wiki?
 > 
 > On 08/09/15 15:37, Mark H Weaver wrote:
 > > ludo@gnu.org (Ludovic Courtès) writes:
 > >
 > >> Craig Barnes <cjbarnes18@gmail.com> skribis:
 > >>
 > >>> Some time ago I asked on IRC about a guix users wiki.  Someone
 > >>> suggest that I propose one here (sorry it's taken so long).
 > >>>
 > >>> I think that a wiki would be a good complement to the manual, which
 > >>> while quite complete, lacks exhaustive examples (which would be
 > >>> impractical).
 > >> I have mixed feelings.  There are several issues with a Wiki: one can
 > >> hardly know which version of the software it’s talking about (whereas
 > >> the installed Info pages of PDFs necessarily match the installed
 > >> version), and more importantly, it tends to be disorganized,
 > >> unmaintained, and often misleading.
 > In order to make sure that examples in the manual aren't broken, wouldn't
 > something equivalent to python doctests be necessary to ensure this? I think it
 > would be worse to have a broken example in the manual than somewhere
 > else.  If the number of examples grow this could be equally unmaintainable.
 > > Agreed.  There are a small handful of highly successful wikis, but
 > > most of them are as Ludovic describes.  Maintaining a good wiki
 > > requires a great deal of work by experts to monitor changes, fix
 > > things up, and to update the wiki as needed when Guix is updated to
 > > avoid giving users outdated advice.  I suspect it only makes sense
 > > when the scale of the documentation and the number of people involved
 > > is at least two, maybe three orders of magnitude greater than the Guix
 > project.
 > >
 > >> I would strongly encourage people to help fix the manual as a first
 > >> step.  If information that a user deems useful is missing from the
 > >> manual, then it’s a bug.  I’m willing to make it as simple as
 > >> possible to fix the manual.  But really, the manual should have all
 > >> the examples necessary for people to understand how to tweak things.
 > > I agree with Ludovic.  The manual would require far less work from our
 > > small pool of experts to maintain than a wiki, and has a couple of
 > > inherent advantages:
 > >
 > > * the manual is stored in the same git repository as Guix itself, so
 > >   they can be kept in sync at all times.
 > >
 > > * the manual can easily be read and modified while offline.
 > >
 > >> There might be cases where specific information doesn’t quite fit in
 > >> the manual, like, say, instructions for a specific laptop model.
 > >> These could go in a wiki.
 > >>
 > >> Overall, I think it’s fine to have stuff at
 > >> <https://libreplanet.org/wiki/Group:Guix/> for instance, but the
 > >> manual should clearly remain the primary source of documentation,
 > >> without any ambiguity.
 > Thank you for your feedback on this, I agree with your points, and that in this
 > case the manual is the better place for this information.
 > 
 > Going back to my original problem of finding information that isn't currently
 > in the manual, it would be great if there where an easier way to search /
 > browse the mailing list archives.  This would make extracting great examples
 > to add to the manual easier.  Any suggestions would be appreciated.
 > 
[Cook, Malcolm] 

The mailing list archives are searchable per http://savannah.gnu.org/mail/?group=guix

But, even better, they are also indexed at gmane, which I find to provide excellent sweet-spot for providing both search and browse - for example this discussion: http://thread.gmane.org/gmane.comp.gnu.guix.devel/11294/focus=11305 

Plus, for any old-school usenet afficianados, gmane provides access via nntp.   (anyone reading this in emacs gnus via nntp)

This being a GNU oriented project I expect moving this to google groups is a non-starter.  "Feh"s and "harrumph"s all around!

 > 
 > Cheers
 > 
 > Craig


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-09-10 15:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-07 22:08 Should we start a Guix users wiki? Craig Barnes
2015-09-08  8:01 ` Amirouche Boubekki
2015-09-08  9:54 ` Ludovic Courtès
2015-09-08 12:40   ` Thompson, David
2015-09-08 14:37   ` Mark H Weaver
2015-09-10 10:47     ` Craig Barnes
2015-09-10 13:58       ` Ludovic Courtès
2015-09-10 15:35       ` Cook, Malcolm

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).