GNU Guix Video Documentation

GNU Guix Video Documentation

[Gábor Boskovits]

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

Hello Guix,

I've prepared a preliminary version of the graph of minimal
requirements of this project,
it is mostly abstract for now, but I would like to hear the opinions,
or possible additions to this.
So here it is. WDYT?

Best regards,
g_bor

[-- Attachment #2: artifactmap.dot --]
[-- Type: application/msword-template, Size: 883 bytes --]

Re: GNU Guix Video Documentation

[Björn Höfling]

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

On Thu, 25 Oct 2018 14:39:40 +0200
Gábor Boskovits <boskovits@gmail.com> wrote:

> Hello Guix,
> 
> I've prepared a preliminary version of the graph of minimal
> requirements of this project,
> it is mostly abstract for now, but I would like to hear the opinions,
> or possible additions to this.
> So here it is. WDYT?

Hi Gábor,

since I first heard from the realization of the Video/Outreachy
project, I found this procedure a bit abstract and I fear that the
outcome would be a bit boring when done like that. Especially the part
"images" is what I find suspicious, maybe I understand it wrong and I
have to convinced into some direction: Do you mean by that still
images/screenshots that will then be shown some duration (in the range
of seconds), like slideshows with text-slides and screenshots
intermixed? That is then mixed with subtitles and/or audio recordings.

I expected more like a screen cast: A life hacking session with
comments on what's going on, why doing a step, opening a brower and
show where to find docs. Of cause this has to be well prepared and some
parts have to be cut out in order to be not too tedious (half an hour
gcc log output during compilation is not so interesting for some
people).

[I thought of maybe combining it with someone moderating, i.e. a person
filmed who is explaining what they are doing. Though we need to be
careful to not push anyone into that direction who doesn't want. Maybe
it's better to drop that idea.]

What I'm next missing is a set of tasks that we want to be
video-documented. Or should that be part of the internship? I think it
is more on our side to define the requirements.

How and on which platform should the final result be presented?
This includes freedom, privacy and technical aspects and is a
question of acceptence/broadness of people watching it. Depending on the
choice, could that affect the preparation process (for example,
subtitle format, video-container format, audio-channels/translations,
automatic text2subtitle conversation)?

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: GNU Guix Video Documentation

[Ricardo Wurmus]

Hi Björn,

> I expected more like a screen cast: A life hacking session with
> comments on what's going on, why doing a step, opening a brower and
> show where to find docs. Of cause this has to be well prepared and some
> parts have to be cut out in order to be not too tedious (half an hour
> gcc log output during compilation is not so interesting for some
> people).

While screencasts can be useful, I don’t think they are the most useful
tool to convey ideas.  Much of what’s special about Guix is not the
command line user interface, but the underlying ideas.  These are better
illustrated, I think, with the help of graphics as we have been doing
for years when introducing Guix to new audiences.

One concern is also translations and future updates.  Recording a
terminal session with screencasting software makes it impossible for us
to easily translate the video.  When command line interactions are to be
shown I’d prefer to have a way to reproduce / regenerate the output in a
different locale automatically, i.e. using scripts.

We can easily mix what amounts to a narrated slideshow with scripted
command line sessions (cf asciicasts).  This can easily be automated, so
that we can rebuild the video and update it with minimal effort to
prevent it from getting stale.

Setting up this automation to some degree is part of the project, in my
opinion.  This could be done via scripts or tied together with a
Makefile.

The big advantages I see over a recorded live session are as follows:

- no need to get it all right in one take
- prepared narration can result in much more effective communication of
  ideas
- easy to rebuild
- easy to translate
- no need for manual video editing to cut out irrelevant parts
- separate treatment of audio and video portions; audio portions can be
  recorded by native speakers.

I really think that we should make an effort to keep the sources of the
videos and make sure that we can generate them from source without too
much effort.  To me this means that we should avoid traditional plain
video recording or screencasting.

> What I'm next missing is a set of tasks that we want to be
> video-documented. Or should that be part of the internship? I think it
> is more on our side to define the requirements.

Yes, I think we should provide more guidance here.  We should have a
minimum set of concepts that we’d like to see covered.  This also makes
it easier for us to determine if the internship progresses as planned.

Beyond the minimum, I’d like to leave it up to the intern to come up
with more ideas for videos.  It’s possible, though, that the minimum
already takes up more time than we currently anticipate, so lets just
focus on the first three videos.

> How and on which platform should the final result be presented?
> This includes freedom, privacy and technical aspects and is a
> question of acceptence/broadness of people watching it. Depending on the
> choice, could that affect the preparation process (for example,
> subtitle format, video-container format, audio-channels/translations,
> automatic text2subtitle conversation)?

We can host the videos on http://audio-video.gnu.org/ and embed them on
the Guix website, but the sources should be added to the guix-artwork
repository, I think.

The videos could also be published on Mediagoblin instances, but I don’t
know if there’s an instance for GNU packages.  GNU Guix does not
currently have its own Mediagoblin instance.

--
Ricardo

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Hello,

Ricardo Wurmus <rekado@elephly.net> ezt írta (időpont: 2018. okt. 26., P, 6:14):
>
>
> Hi Björn,
>
> > I expected more like a screen cast: A life hacking session with
> > comments on what's going on, why doing a step, opening a brower and
> > show where to find docs. Of cause this has to be well prepared and some
> > parts have to be cut out in order to be not too tedious (half an hour
> > gcc log output during compilation is not so interesting for some
> > people).
>
> While screencasts can be useful, I don’t think they are the most useful
> tool to convey ideas.  Much of what’s special about Guix is not the
> command line user interface, but the underlying ideas.  These are better
> illustrated, I think, with the help of graphics as we have been doing
> for years when introducing Guix to new audiences.
>
> One concern is also translations and future updates.  Recording a
> terminal session with screencasting software makes it impossible for us
> to easily translate the video.  When command line interactions are to be
> shown I’d prefer to have a way to reproduce / regenerate the output in a
> different locale automatically, i.e. using scripts.
>
> We can easily mix what amounts to a narrated slideshow with scripted
> command line sessions (cf asciicasts).  This can easily be automated, so
> that we can rebuild the video and update it with minimal effort to
> prevent it from getting stale.
>

I have been also thinking along the same lines, and I came up with a
more concrete and detailed version of the graph I've sent. I will send it
later.

> Setting up this automation to some degree is part of the project, in my
> opinion.  This could be done via scripts or tied together with a
> Makefile.
>
> The big advantages I see over a recorded live session are as follows:
>
> - no need to get it all right in one take
> - prepared narration can result in much more effective communication of
>   ideas
> - easy to rebuild
> - easy to translate
> - no need for manual video editing to cut out irrelevant parts
> - separate treatment of audio and video portions; audio portions can be
>   recorded by native speakers.
>
> I really think that we should make an effort to keep the sources of the
> videos and make sure that we can generate them from source without too
> much effort.  To me this means that we should avoid traditional plain
> video recording or screencasting.
>
> > What I'm next missing is a set of tasks that we want to be
> > video-documented. Or should that be part of the internship? I think it
> > is more on our side to define the requirements.
>
> Yes, I think we should provide more guidance here.  We should have a
> minimum set of concepts that we’d like to see covered.  This also makes
> it easier for us to determine if the internship progresses as planned.
>

Yes, although I wrote up some ideas on the project page, but this will need
discussion.

> Beyond the minimum, I’d like to leave it up to the intern to come up
> with more ideas for videos.  It’s possible, though, that the minimum
> already takes up more time than we currently anticipate, so lets just
> focus on the first three videos.
>
> > How and on which platform should the final result be presented?
> > This includes freedom, privacy and technical aspects and is a
> > question of acceptence/broadness of people watching it. Depending on the
> > choice, could that affect the preparation process (for example,
> > subtitle format, video-container format, audio-channels/translations,
> > automatic text2subtitle conversation)?
>
> We can host the videos on http://audio-video.gnu.org/ and embed them on
> the Guix website, but the sources should be added to the guix-artwork
> repository, I think.
>
> The videos could also be published on Mediagoblin instances, but I don’t
> know if there’s an instance for GNU packages.  GNU Guix does not
> currently have its own Mediagoblin instance.
>

Ok, then we should focus on to get a working version on these platforms,
and to beable to regenerate from sources at the repository.

> --
> Ricardo
>

g_bor

Re: GNU Guix Video Documentation

[Giovanni Biscuolo]

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

two cents from a GuixSD newbie... (I'll skip presentations, forgive me)

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

> While screencasts can be useful, I don’t think they are the most useful
> tool to convey ideas.  Much of what’s special about Guix is not the
> command line user interface, but the underlying ideas.  These are better
> illustrated, I think, with the help of graphics as we have been doing
> for years when introducing Guix to new audiences.

this applies to **a lot** of other video documentation material, from
application user guides to presentations

> One concern is also translations and future updates.  Recording a
> terminal session with screencasting software makes it impossible for us
> to easily translate the video.  When command line interactions are to be
> shown I’d prefer to have a way to reproduce / regenerate the output in a
> different locale automatically, i.e. using scripts.

the same holds for GUI interaction (when a GUI video-doc is needed); I'm
not an expert in GUI "scripting" but I guess something like xdotool
script executed in a "classical" screencast application could do the job
(maybe https://github.com/rprichard/x11-canvas-screencast is
interesting, too)

> We can easily mix what amounts to a narrated slideshow with scripted
> command line sessions (cf asciicasts).  This can easily be automated, so
> that we can rebuild the video and update it with minimal effort to
> prevent it from getting stale.
>
> Setting up this automation to some degree is part of the project, in my
> opinion.  This could be done via scripts or tied together with a
> Makefile.

this would be simply great :-)

if I had money to invest I would _pay_ for such an automation system

> The big advantages I see over a recorded live session are as follows:
>
> - no need to get it all right in one take
> - prepared narration can result in much more effective communication of
>   ideas
> - easy to rebuild
> - easy to translate
> - no need for manual video editing to cut out irrelevant parts
> - separate treatment of audio and video portions; audio portions can be
>   recorded by native speakers.

great, simply *great*: thank you for sharing this useful ideas!

[...]

ciao
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: GNU Guix Video Documentation

[Björn Höfling]

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

On Fri, 26 Oct 2018 06:13:52 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> While screencasts can be useful, I don’t think they are the most
> useful tool to convey ideas.  Much of what’s special about Guix is
> not the command line user interface, but the underlying ideas.  These
> are better illustrated, I think, with the help of graphics as we have
> been doing for years when introducing Guix to new audiences.

I thought the videos are not for transporting general ideas, but to
show the daily usage of guix. And that is using the command line. By
showing common tasks the general idea gets transported (i.e. while
showing guix package -i, guix package --list-generations, guix package
--roll-back the idea of transactional package management is conveyed,
without much abstract words).

> One concern is also translations and future updates.  Recording a
> terminal session with screencasting software makes it impossible for
> us to easily translate the video.  When command line interactions are
> to be shown I’d prefer to have a way to reproduce / regenerate the
> output in a different locale automatically, i.e. using scripts.

When I thought about translations, I thought only about the speech and
subtitles. Of cause you are right, the command line should be localized
too!
 
> We can easily mix what amounts to a narrated slideshow with scripted
> command line sessions (cf asciicasts).  This can easily be automated,
> so that we can rebuild the video and update it with minimal effort to
> prevent it from getting stale.

When I said screencasts I first thought of handmade ones within well
prepared (and documented) environments and a script/stage
directions and script for automatic cutouts from the raw recordings.

Then I thought of this puppet we have for qemu-tests: Is it possible to
use it in order to controll the virtual machine, screencast it and get
back certain events like terminal keywords in order to start/stop/pause
the cast?

This is my first time I heard of asciicasts. You mean the program
asciinema and it's protocol asciicasts (https://asciinema.org/)? That
looks cool. Can it be used to produce rendered films too?

Automating the process as much as possible is a good idea. Can we get
that bitwise reproducible? :-)

[..]

> We can host the videos on http://audio-video.gnu.org/ and embed
them
> on the Guix website, but the sources should be added to the
> guix-artwork repository, I think.

Yes, that site looks good, I watched videos from it in the past.

> The videos could also be published on Mediagoblin instances, but I
> don’t know if there’s an instance for GNU packages.  GNU Guix does not
> currently have its own Mediagoblin instance.

We don't have a Mediagoblin package yet :-)

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: GNU Guix Video Documentation

[Gábor Boskovits]

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

Hello guix,

Here is a revised version of the graph I came up with. It is not
styled yet, because it is much bigger, and had no time to do that yet.
I believe it catches the concepts well, however I will add some notes here:

in the screen_recording_cutting_information we can specify to create
an imageset first, then recompose that to get the slideshow like video
instead.
We can simply shortcut the overlayer then to produce a video without
narration video overlay. We can shortcut the compositor to get a
version without audio, and so on.

Most of these transformers are only a few-liners, so don't get overwhelmed :)

Also, we could use a makefile, or some other dependency resolution
mechanisms to control the whole stuff, a

g_bor

[-- Attachment #2: artifactmap-extended.dot --]
[-- Type: application/msword-template, Size: 6095 bytes --]

Re: GNU Guix Video Documentation

[Laura Lazzati]

Hi!
I have some ideas, suggestions and questions, based on this two videos
that someone replied in one thread of mails when I was first getting
in touch with the community.
[1] https://media.libreplanet.org/u/libreplanet/m/practical-verifiable-software-freedom-with-guixsd/
[2] https://archive.fosdem.org/2018/schedule/event/usingguix/
I don't know much about video editing in the technical aspect of if,
but maybe my ideas could help. I have been reading about some
concepts, however.
On Fri, Oct 26, 2018 at 7:02 AM Björn Höfling
<bjoern.hoefling@bjoernhoefling.de> wrote:
>
> On Fri, 26 Oct 2018 06:13:52 +0200
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
> > While screencasts can be useful, I don’t think they are the most
> > useful tool to convey ideas.  Much of what’s special about Guix is
> > not the command line user interface, but the underlying ideas.  These
> > are better illustrated, I think, with the help of graphics as we have
> > been doing for years when introducing Guix to new audiences.
Here, the first question, I would ask myself is: what is the purpose
of the video and who the audience of the video is?
It is not the same making a general video promoting guix with it's
features and conveying ideas  to users/sysadmins/contributors - even
different kind of contributors - than doing so to people that are
already interested in using, applying guix, or contributing and want
to know the technical aspects because they prefer to have a first
approach with them and then read the documentation.
> I thought the videos are not for transporting general ideas, but to
> show the daily usage of guix. And that is using the command line. By
> showing common tasks the general idea gets transported (i.e. while
> showing guix package -i, guix package --list-generations, guix package
> --roll-back the idea of transactional package management is conveyed,
> without much abstract words).
When I first read the Ourteachy project, I thought that the videos had
to be technical, showing howtos, as Bjorn mentioned.
But for the first case (promoting, conveying ideas, to any of the
people the audience involves) maybe screencasting is more appealing to
the person that is watching them. It comes to my mind having someone
speaking, and showing graphics, diagrams, something like [1] - now I
realize that I have always watched screencasted tutorials and courses
and most of them in English. Translation in this case is more
difficult, it is true.
> > One concern is also translations and future updates.  Recording a
> > terminal session with screencasting software makes it impossible for
> > us to easily translate the video.  When command line interactions are
> > to be shown I’d prefer to have a way to reproduce / regenerate the
> > output in a different locale automatically, i.e. using scripts.
>
> When I thought about translations, I thought only about the speech and
> subtitles. Of cause you are right, the command line should be localized
> too!
Yes, I was thinking at first
Are you planning to translate them to specific languages, or to as
many as  possible, even on demand, in the future?
> > We can easily mix what amounts to a narrated slideshow with scripted
> > command line sessions (cf asciicasts).  This can easily be automated,
> > so that we can rebuild the video and update it with minimal effort to
> > prevent it from getting stale.
As regards the technical/howto ones, I was thinking also of something
like this. Some slides for the concepts with then cli sessions.
>
> When I said screencasts I first thought of handmade ones within well
> prepared (and documented) environments and a script/stage
> directions and script for automatic cutouts from the raw recordings.
>
> Then I thought of this puppet we have for qemu-tests: Is it possible to
> use it in order to controll the virtual machine, screencast it and get
> back certain events like terminal keywords in order to start/stop/pause
> the cast?
>
> This is my first time I heard of asciicasts. You mean the program
> asciinema and it's protocol asciicasts (https://asciinema.org/)? That
> looks cool. Can it be used to produce rendered films too?
>
> Automating the process as much as possible is a good idea. Can we get
> that bitwise reproducible? :-)
>
> [..]
>
> > We can host the videos on http://audio-video.gnu.org/ and embed
> them
> > on the Guix website, but the sources should be added to the
> > guix-artwork repository, I think.
>
> Yes, that site looks good, I watched videos from it in the past.
Where are all the videos already created for guix and guixSD, apart
from [1] and [2]  and the one on the official site?  Having this
answered, maybe it is clearer which videos are needed the most, the
ones conveying ideas, the technical ones, or if both, which ones are
more important.
> > The videos could also be published on Mediagoblin instances, but I
> > don’t know if there’s an instance for GNU packages.  GNU Guix does not
> > currently have its own Mediagoblin instance.
>
> We don't have a Mediagoblin package yet :-)
>
> Björn
Regards!
Laura

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Hello Laura,

Laura Lazzati <laura.lazzati.15@gmail.com> ezt írta (időpont: 2018.
okt. 28., V, 2:33):
>
> Hi!
> I have some ideas, suggestions and questions, based on this two videos
> that someone replied in one thread of mails when I was first getting
> in touch with the community.
> [1] https://media.libreplanet.org/u/libreplanet/m/practical-verifiable-software-freedom-with-guixsd/
> [2] https://archive.fosdem.org/2018/schedule/event/usingguix/
> I don't know much about video editing in the technical aspect of if,
> but maybe my ideas could help. I have been reading about some
> concepts, however.
> On Fri, Oct 26, 2018 at 7:02 AM Björn Höfling
> <bjoern.hoefling@bjoernhoefling.de> wrote:
> >
> > On Fri, 26 Oct 2018 06:13:52 +0200
> > Ricardo Wurmus <rekado@elephly.net> wrote:
> >
> > > While screencasts can be useful, I don’t think they are the most
> > > useful tool to convey ideas.  Much of what’s special about Guix is
> > > not the command line user interface, but the underlying ideas.  These
> > > are better illustrated, I think, with the help of graphics as we have
> > > been doing for years when introducing Guix to new audiences.
> Here, the first question, I would ask myself is: what is the purpose
> of the video and who the audience of the video is?

This is a very important point to discuss.

> It is not the same making a general video promoting guix with it's
> features and conveying ideas  to users/sysadmins/contributors - even
> different kind of contributors - than doing so to people that are
> already interested in using, applying guix, or contributing and want
> to know the technical aspects because they prefer to have a first
> approach with them and then read the documentation.

I believe, there is a demand for both types of documentation, but
uncertain about the priorities. The current project description reflects
the technical aspects type instead, or rather a hybrid approach, like:
introduce a concept, then show how that concept can be applied.
I can think of a solution, where videos are grouped around the concepts,
one (or more, targeted to different audiences) video to introduce a
concept/feature/idea, and then a few more to show the technical apects/
implementation. WDYT?

> > I thought the videos are not for transporting general ideas, but to
> > show the daily usage of guix. And that is using the command line. By
> > showing common tasks the general idea gets transported (i.e. while
> > showing guix package -i, guix package --list-generations, guix package
> > --roll-back the idea of transactional package management is conveyed,
> > without much abstract words).
> When I first read the Ourteachy project, I thought that the videos had
> to be technical, showing howtos, as Bjorn mentioned.
> But for the first case (promoting, conveying ideas, to any of the
> people the audience involves) maybe screencasting is more appealing to
> the person that is watching them. It comes to my mind having someone
> speaking, and showing graphics, diagrams, something like [1] - now I
> realize that I have always watched screencasted tutorials and courses
> and most of them in English. Translation in this case is more
> difficult, it is true.

I guess you mean something like [2] here. Yes, my ideas are similar.
If you could have a look at the second version of the graph I attached here,
you can see, that the screen recording and the narration aspects are completely
separated, and the narration is not necessarily a single video, but
instead a set
videos. That makes both recording and translation more tractable. WDYT?

> > > One concern is also translations and future updates.  Recording a
> > > terminal session with screencasting software makes it impossible for
> > > us to easily translate the video.  When command line interactions are
> > > to be shown I’d prefer to have a way to reproduce / regenerate the
> > > output in a different locale automatically, i.e. using scripts.
> >
> > When I thought about translations, I thought only about the speech and
> > subtitles. Of cause you are right, the command line should be localized
> > too!
> Yes, I was thinking at first
> Are you planning to translate them to specific languages, or to as
> many as  possible, even on demand, in the future?

It would be nice to have the ability to translate on demand in the future.
The second version of the graph I have posted is created with keeping
that in mind, that is one of the reasons why it has so many selection and
composition steps. (Another reason is to have a versitality of outputs).

> > > We can easily mix what amounts to a narrated slideshow with scripted
> > > command line sessions (cf asciicasts).  This can easily be automated,
> > > so that we can rebuild the video and update it with minimal effort to
> > > prevent it from getting stale.
> As regards the technical/howto ones, I was thinking also of something
> like this. Some slides for the concepts with then cli sessions.
> >
> > When I said screencasts I first thought of handmade ones within well
> > prepared (and documented) environments and a script/stage
> > directions and script for automatic cutouts from the raw recordings.
> >
> > Then I thought of this puppet we have for qemu-tests: Is it possible to
> > use it in order to controll the virtual machine, screencast it and get
> > back certain events like terminal keywords in order to start/stop/pause
> > the cast?
> >
> > This is my first time I heard of asciicasts. You mean the program
> > asciinema and it's protocol asciicasts (https://asciinema.org/)? That
> > looks cool. Can it be used to produce rendered films too?
> >

I have the same question here :-)

> > Automating the process as much as possible is a good idea. Can we get
> > that bitwise reproducible? :-)
> >

Actually I believe we can :-)

> > [..]
> >
> > > We can host the videos on http://audio-video.gnu.org/ and embed
> > them
> > > on the Guix website, but the sources should be added to the
> > > guix-artwork repository, I think.
> >
> > Yes, that site looks good, I watched videos from it in the past.
> Where are all the videos already created for guix and guixSD, apart
> from [1] and [2]  and the one on the official site?  Having this
> answered, maybe it is clearer which videos are needed the most, the
> ones conveying ideas, the technical ones, or if both, which ones are
> more important.

Do we have any more? Maybe some conference recordings, or from the
last guix day? Do we have a place where links are collected?

> > > The videos could also be published on Mediagoblin instances, but I
> > > don’t know if there’s an instance for GNU packages.  GNU Guix does not
> > > currently have its own Mediagoblin instance.
> >
> > We don't have a Mediagoblin package yet :-)
> >
> > Björn
> Regards!
> Laura
>

Best regards,
g_bor

Re: GNU Guix Video Documentation

[Laura Lazzati]

On Sun, Oct 28, 2018 at 6:13 AM Gábor Boskovits <boskovits@gmail.com> wrote:
>
> Hello Laura,
>
> Laura Lazzati <laura.lazzati.15@gmail.com> ezt írta (időpont: 2018.
> okt. 28., V, 2:33):
> >
> > Hi!
> > I have some ideas, suggestions and questions, based on this two videos
> > that someone replied in one thread of mails when I was first getting
> > in touch with the community.
> > [1] https://media.libreplanet.org/u/libreplanet/m/practical-verifiable-software-freedom-with-guixsd/
> > [2] https://archive.fosdem.org/2018/schedule/event/usingguix/
> > I don't know much about video editing in the technical aspect of if,
> > but maybe my ideas could help. I have been reading about some
> > concepts, however.
> > On Fri, Oct 26, 2018 at 7:02 AM Björn Höfling
> > <bjoern.hoefling@bjoernhoefling.de> wrote:
> > >
> > > On Fri, 26 Oct 2018 06:13:52 +0200
> > > Ricardo Wurmus <rekado@elephly.net> wrote:
> > >
> > > > While screencasts can be useful, I don’t think they are the most
> > > > useful tool to convey ideas.  Much of what’s special about Guix is
> > > > not the command line user interface, but the underlying ideas.  These
> > > > are better illustrated, I think, with the help of graphics as we have
> > > > been doing for years when introducing Guix to new audiences.
> > Here, the first question, I would ask myself is: what is the purpose
> > of the video and who the audience of the video is?
>
> This is a very important point to discuss.
>
> > It is not the same making a general video promoting guix with it's
> > features and conveying ideas  to users/sysadmins/contributors - even
> > different kind of contributors - than doing so to people that are
> > already interested in using, applying guix, or contributing and want
> > to know the technical aspects because they prefer to have a first
> > approach with them and then read the documentation.
>
> I believe, there is a demand for both types of documentation, but
> uncertain about the priorities. The current project description reflects
> the technical aspects type instead, or rather a hybrid approach, like:
> introduce a concept, then show how that concept can be applied.
> I can think of a solution, where videos are grouped around the concepts,
> one (or more, targeted to different audiences) video to introduce a
> concept/feature/idea, and then a few more to show the technical apects/
> implementation. WDYT?
I agree with your approach.
First, we need to know which have the highest priorities, the
promoting, the howtos, and belonging to which topic(s). And in case
both (the ones "promoting" as well as the "howtos" are equally needed,
I believe that maybe the screencasted one is more appealing, even
taking into account that they are difficult to translate or update if
they get stale, but it also implies in the worst case creating only
one 3 minutes lenght video again on each topic.
And then, for the "howtos", I don't know how many 3 minutes length
videos will be required for each topic, or the depth of them but the
non-screencasted I believe is better, as most of you mentioned.
But I kind need to know which are more important at least for now.
Recall I am new to Guix :)
> > > I thought the videos are not for transporting general ideas, but to
> > > show the daily usage of guix. And that is using the command line. By
> > > showing common tasks the general idea gets transported (i.e. while
> > > showing guix package -i, guix package --list-generations, guix package
> > > --roll-back the idea of transactional package management is conveyed,
> > > without much abstract words).
> > When I first read the Ourteachy project, I thought that the videos had
> > to be technical, showing howtos, as Bjorn mentioned.
> > But for the first case (promoting, conveying ideas, to any of the
> > people the audience involves) maybe screencasting is more appealing to
> > the person that is watching them. It comes to my mind having someone
> > speaking, and showing graphics, diagrams, something like [1] - now I
> > realize that I have always watched screencasted tutorials and courses
> > and most of them in English. Translation in this case is more
> > difficult, it is true.
>
> I guess you mean something like [2] here. Yes, my ideas are similar.
> If you could have a look at the second version of the graph I attached here,
> you can see, that the screen recording and the narration aspects are completely
> separated, and the narration is not necessarily a single video, but
> instead a set
> videos. That makes both recording and translation more tractable. WDYT?
Yes, I saw the graph, but as I am not into video recording rather than
home made ones, I got a little bit lost, I understood the point in the
end, about how to mix everything, but not very well the intermediate
steps.
But I still agree with you about being non-screencasted.
I still have to do more research on texinfo, I read the Reference
Guide,  but maybe even the slides can be generated with it -LaTex has
Beamer, for instance, there has to be something similar to it.
>
> > > > One concern is also translations and future updates.  Recording a
> > > > terminal session with screencasting software makes it impossible for
> > > > us to easily translate the video.  When command line interactions are
> > > > to be shown I’d prefer to have a way to reproduce / regenerate the
> > > > output in a different locale automatically, i.e. using scripts.
> > >
> > > When I thought about translations, I thought only about the speech and
> > > subtitles. Of cause you are right, the command line should be localized
> > > too!
> > Yes, I was thinking at first
> > Are you planning to translate them to specific languages, or to as
> > many as  possible, even on demand, in the future?
>
> It would be nice to have the ability to translate on demand in the future.
> The second version of the graph I have posted is created with keeping
> that in mind, that is one of the reasons why it has so many selection and
> composition steps. (Another reason is to have a versitality of outputs).
Great. I don't know if the translations will be automated and with
which tools - Ricardo mentioned that the non screencasted had, among
the benefits, easier translations, but I don't know up to which point
they will be automated.  I read about the tools for the localization
of the command line commands, but the audios and text (both subtitles
and the slides) will be that easy to translate with scripts? That's
why I though about texinfo- i don't know if by slideshow you mean the
non-GNU slideshow or any other tool.
 >
> > > > We can easily mix what amounts to a narrated slideshow with scripted
> > > > command line sessions (cf asciicasts).  This can easily be automated,
> > > > so that we can rebuild the video and update it with minimal effort to
> > > > prevent it from getting stale.
> > As regards the technical/howto ones, I was thinking also of something
> > like this. Some slides for the concepts with then cli sessions.
> > >
> > > When I said screencasts I first thought of handmade ones within well
> > > prepared (and documented) environments and a script/stage
> > > directions and script for automatic cutouts from the raw recordings.
> > >
> > > Then I thought of this puppet we have for qemu-tests: Is it possible to
> > > use it in order to controll the virtual machine, screencast it and get
> > > back certain events like terminal keywords in order to start/stop/pause
> > > the cast?
> > >
> > > This is my first time I heard of asciicasts. You mean the program
> > > asciinema and it's protocol asciicasts (https://asciinema.org/)? That
> > > looks cool. Can it be used to produce rendered films too?
> > >
>
> I have the same question here :-)
>
> > > Automating the process as much as possible is a good idea. Can we get
> > > that bitwise reproducible? :-)
> > >
>
> Actually I believe we can :-)
>
> > > [..]
> > >
> > > > We can host the videos on http://audio-video.gnu.org/ and embed
> > > them
> > > > on the Guix website, but the sources should be added to the
> > > > guix-artwork repository, I think.
> > >
> > > Yes, that site looks good, I watched videos from it in the past.
> > Where are all the videos already created for guix and guixSD, apart
> > from [1] and [2]  and the one on the official site?  Having this
> > answered, maybe it is clearer which videos are needed the most, the
> > ones conveying ideas, the technical ones, or if both, which ones are
> > more important.
>
> Do we have any more? Maybe some conference recordings, or from the
> last guix day? Do we have a place where links are collected?
>
> > > > The videos could also be published on Mediagoblin instances, but I
> > > > don’t know if there’s an instance for GNU packages.  GNU Guix does not
> > > > currently have its own Mediagoblin instance.
> > >
> > > We don't have a Mediagoblin package yet :-)
> > >
> > > Björn
> > Regards!
> > Laura
> >
>
> Best regards,
> g_bor

Regards!
Laura

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Hello Laura,

Laura Lazzati <laura.lazzati.15@gmail.com> ezt írta (időpont: 2018.
okt. 28., V, 20:15):

> First, we need to know which have the highest priorities, the
> promoting, the howtos, and belonging to which topic(s). And in case
> both (the ones "promoting" as well as the "howtos" are equally needed,
> I believe that maybe the screencasted one is more appealing, even
> taking into account that they are difficult to translate or update if
> they get stale, but it also implies in the worst case creating only
> one 3 minutes lenght video again on each topic.
> And then, for the "howtos", I don't know how many 3 minutes length
> videos will be required for each topic, or the depth of them but the
> non-screencasted I believe is better, as most of you mentioned.
> But I kind need to know which are more important at least for now.
> Recall I am new to Guix :)

I believe one of the most important part of this discussion is to set
these priorities. It might worth to start a new thread for explicitly
this, but we can also keep the discussion here. What do you think
would be preferable?

> I still have to do more research on texinfo, I read the Reference
> Guide,  but maybe even the slides can be generated with it -LaTex has
> Beamer, for instance, there has to be something similar to it.

LaTex and Beamer are prefectly acceptable, especially if you are already
familiar with them. (You will need texinfo to work with the manual) Also,
currently texinfo lacks some translation capabilities,
you can ask Julien Lepiller (a.k.a. roptat) on the status of these, but as we
control the whole process here, these might be ignored. I am think about
generating code, tests and documentation from the same source for a
while, but that is a whole new story :-)

> > It would be nice to have the ability to translate on demand in the future.
> > The second version of the graph I have posted is created with keeping
> > that in mind, that is one of the reasons why it has so many selection and
> > composition steps. (Another reason is to have a versitality of outputs).
> Great. I don't know if the translations will be automated and with
> which tools - Ricardo mentioned that the non screencasted had, among
> the benefits, easier translations, but I don't know up to which point
> they will be automated.  I read about the tools for the localization
> of the command line commands, but the audios and text (both subtitles
> and the slides) will be that easy to translate with scripts? That's
> why I though about texinfo- i don't know if by slideshow you mean the
> non-GNU slideshow or any other tool.

The audio translation would have to be done using a recording,
video+audio of a narrator, we can't actually do any better :-)
The only thing I propose here, is to break down the recoding to
short cuts, so that we can do this in smaller parts. That's why I
presented this part as a 'set of clips' in my description.

The subtitles translation can be done using a base subtitle file/
subttile database and a separate set of translation files. That
way the translations can simply be sent to translators, and
work can be parallelized, like it is done for guix, and the manual.

Best regards,
g_bor

Re: GNU Guix Video Documentation

[Laura Lazzati]

On Sun, Oct 28, 2018 at 5:20 PM Gábor Boskovits <boskovits@gmail.com> wrote:
>
> Hello Laura,
>
> Laura Lazzati <laura.lazzati.15@gmail.com> ezt írta (időpont: 2018.
> okt. 28., V, 20:15):
>
> > First, we need to know which have the highest priorities, the
> > promoting, the howtos, and belonging to which topic(s). And in case
> > both (the ones "promoting" as well as the "howtos" are equally needed,
> > I believe that maybe the screencasted one is more appealing, even
> > taking into account that they are difficult to translate or update if
> > they get stale, but it also implies in the worst case creating only
> > one 3 minutes lenght video again on each topic.
> > And then, for the "howtos", I don't know how many 3 minutes length
> > videos will be required for each topic, or the depth of them but the
> > non-screencasted I believe is better, as most of you mentioned.
> > But I kind need to know which are more important at least for now.
> > Recall I am new to Guix :)
>
> I believe one of the most important part of this discussion is to set
> these priorities. It might worth to start a new thread for explicitly
> this, but we can also keep the discussion here. What do you think
> would be preferable?
Yes, please, because based on that I will send you the timeline :) And
I would like to show you the first version ASAP.
Sometimes threads get too long and messy. Because when we end up
replying to a certain part then at least I miss what was before, and
need to read the whole thread to end up writing "X said...". We could
write like a summary of all this thread of mails and start from that
point, WDYT?
>
> > I still have to do more research on texinfo, I read the Reference
> > Guide,  but maybe even the slides can be generated with it -LaTex has
> > Beamer, for instance, there has to be something similar to it.
>
> LaTex and Beamer are prefectly acceptable, especially if you are already
> familiar with them. (You will need texinfo to work with the manual) Also,
> currently texinfo lacks some translation capabilities,
> you can ask Julien Lepiller (a.k.a. roptat) on the status of these, but as we
> control the whole process here, these might be ignored. I am think about
> generating code, tests and documentation from the same source for a
> while, but that is a whole new story :-)

Great! Yes I need more explanation on this last part. But let's open
another thread if possible :) Maybe I could contact Julien on IRC
channel.

>
> > > It would be nice to have the ability to translate on demand in the future.
> > > The second version of the graph I have posted is created with keeping
> > > that in mind, that is one of the reasons why it has so many selection and
> > > composition steps. (Another reason is to have a versitality of outputs).
> > Great. I don't know if the translations will be automated and with
> > which tools - Ricardo mentioned that the non screencasted had, among
> > the benefits, easier translations, but I don't know up to which point
> > they will be automated.  I read about the tools for the localization
> > of the command line commands, but the audios and text (both subtitles
> > and the slides) will be that easy to translate with scripts? That's
> > why I though about texinfo- i don't know if by slideshow you mean the
> > non-GNU slideshow or any other tool.
>
> The audio translation would have to be done using a recording,
> video+audio of a narrator, we can't actually do any better :-)
> The only thing I propose here, is to break down the recoding to
> short cuts, so that we can do this in smaller parts. That's why I
> presented this part as a 'set of clips' in my description.
>
> The subtitles translation can be done using a base subtitle file/
> subttile database and a separate set of translation files. That
> way the translations can simply be sent to translators, and
> work can be parallelized, like it is done for guix, and the manual.

Ok,let me see if I am understanding. For the audio, some people will
have to say "I speak X language" and  narrate that part, By video you
mean for screencasted, like changing the people that appear? I thought
that maybe only replacing the audio was OK. When I did my little
research about concepts for videos, I read that you can mute the
original video, and add another voice, even if the lips don't match,
and even add the options of choosing subtitles (For example: have the
video with English speaker and choose not to add the subtitles, or add
english/spanish/french/choose whatever language you like, too, even
some of them are made with extra comments like [writing on a board] -
I don't remember the name of that - or have the video in Spanish and
do the same. For non-screencasted translating the slides and CLI
comands I thought it was easier. I could do the spanish translations,
at least for the subtitles, but if we can parallelize that, the
better.
>
> Best regards,
> g_bor

Regards!
Laura

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Laura Lazzati <laura.lazzati.15@gmail.com> ezt írta (időpont: 2018.
okt. 29., H, 0:27):

> Ok,let me see if I am understanding. For the audio, some people will
> have to say "I speak X language" and  narrate that part, By video you
> mean for screencasted, like changing the people that appear?

This would be optimal, as this way the lips do match.

I thought that maybe only replacing the audio was OK.

In certain cases it is. One option would be to retain the
original screencast, or we could even decide to not show
the person speaking. I proposed to have the narrator
video overlayed onto the screen recording to have
this flexibility

> When I did my little
> research about concepts for videos, I read that you can mute the
> original video, and add another voice, even if the lips don't match,
> and even add the options of choosing subtitles (For example: have the
> video with English speaker and choose not to add the subtitles, or add
> english/spanish/french/choose whatever language you like, too, even
> some of them are made with extra comments like [writing on a board] -
> I don't remember the name of that - or have the video in Spanish and
> do the same.

This is partially the reason that I proposed to decompose the narration
video into a separate audio and video stream from the start. A lot of
containers support multiple subtitle and multiple audio tracks, and it
is even possible for a player to autoselect them, for example based on
locale. This way we could provide an output, where narration video is
not overlayed, but an unlocalized screen recoding is available with
all the translated audio and subtitles. The extra comments and clarification
information is represented by the screen recording subtitles in my setup,
as these are most likely to connect to what you see on screen, rather than
what the narrator says, but it is perfectly possible to have a third set of
subtitles, independent of the recordings.

> For non-screencasted translating the slides and CLI
> comands I thought it was easier. I could do the spanish translations,
> at least for the subtitles, but if we can parallelize that, the
> better.

I think this one is for a later time, but it would be nice if you could help
with translations. One great benefit would be if we could translate at
least a few videos, that we could test the video translation infrastructure
and write up a workflow for further translators.

Best regards,
g_bor

Re: GNU Guix Video Documentation

[Laura Lazzati]

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

On Mon, Oct 29, 2018 at 5:17 AM Gábor Boskovits <boskovits@gmail.com> wrote:

> Laura Lazzati <laura.lazzati.15@gmail.com> ezt írta (időpont: 2018.
> okt. 29., H, 0:27):
>
> > Ok,let me see if I am understanding. For the audio, some people will
> > have to say "I speak X language" and  narrate that part, By video you
> > mean for screencasted, like changing the people that appear?
>
> This would be optimal, as this way the lips do match.
>
> I thought that maybe only replacing the audio was OK.
>
> In certain cases it is. One option would be to retain the
> original screencast, or we could even decide to not show
> the person speaking. I proposed to have the narrator
> video overlayed onto the screen recording to have
> this flexibility
>
> > When I did my little
> > research about concepts for videos, I read that you can mute the
> > original video, and add another voice, even if the lips don't match,
> > and even add the options of choosing subtitles (For example: have the
> > video with English speaker and choose not to add the subtitles, or add
> > english/spanish/french/choose whatever language you like, too, even
> > some of them are made with extra comments like [writing on a board] -
> > I don't remember the name of that - or have the video in Spanish and
> > do the same.
>
> This is partially the reason that I proposed to decompose the narration
> video into a separate audio and video stream from the start. A lot of
> containers support multiple subtitle and multiple audio tracks, and it
> is even possible for a player to autoselect them, for example based on
> locale. This way we could provide an output, where narration video is
> not overlayed, but an unlocalized screen recoding is available with
> all the translated audio and subtitles. The extra comments and
> clarification
> information is represented by the screen recording subtitles in my setup,
> as these are most likely to connect to what you see on screen, rather than
> what the narrator says, but it is perfectly possible to have a third set of
> subtitles, independent of the recordings.
>
> > For non-screencasted translating the slides and CLI
> > comands I thought it was easier. I could do the spanish translations,
> > at least for the subtitles, but if we can parallelize that, the
> > better.
>
> I think this one is for a later time, but it would be nice if you could
> help
> with translations. One great benefit would be if we could translate at
> least a few videos, that we could test the video translation infrastructure
> and write up a workflow for further translators.

Sure! I mentioned the subtitles because of my accent - I speak Spanish, but
the spanish from Buenos Aires, Argentina. I can write in neutral latin
american spanish, but my spoken accent is different to the latin american
audios from movies, and much more different to spanish from Spain. Even to
different places of Argentina. But we could give it a try and make is as
neutral as possible :) Or at least have a prototype for later.

> I believe that at least for the subtitles part
>

> Best regards,
> g_bor
>

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

Re: GNU Guix Video Documentation

[Björn Höfling]

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

On Sun, 28 Oct 2018 20:26:31 -0300
Laura Lazzati <laura.lazzati.15@gmail.com> wrote:

> Sometimes threads get too long and messy. Because when we end up
> replying to a certain part then at least I miss what was before, and
> need to read the whole thread to end up writing "X said...". We could
> write like a summary of all this thread of mails and start from that
> point, WDYT?

I'm also getting sometimes lost in threads, that's also a reason why
I'm a bit quited in this one. I have the feeling everything was already
said somewhere. I have two suggestions:

1) Would it make sense to prepare the timeline and decision which
videos go first in a wiki? Is the librplanet place appropriate?

https://libreplanet.org/wiki/Group:Guix

2) Laura, when you reply could you stop quoting the whole original
mail, but better delete the unrelevant parts?

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: GNU Guix Video Documentation

[Laura Lazzati]

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

On Mon, Oct 29, 2018 at 6:10 AM Björn Höfling <
bjoern.hoefling@bjoernhoefling.de> wrote:

> On Sun, 28 Oct 2018 20:26:31 -0300
> Laura Lazzati <laura.lazzati.15@gmail.com> wrote:
>
> > Sometimes threads get too long and messy. Because when we end up
> > replying to a certain part then at least I miss what was before, and
> > need to read the whole thread to end up writing "X said...". We could
> > write like a summary of all this thread of mails and start from that
> > point, WDYT?
>
> I'm also getting sometimes lost in threads, that's also a reason why
> I'm a bit quited in this one. I have the feeling everything was already
> said somewhere. I have two suggestions:
>
> 1) Would it make sense to prepare the timeline and decision which
> videos go first in a wiki? Is the librplanet place appropriate?
>
> https://libreplanet.org/wiki/Group:Guix

Great, I am having a loook!

>
>
> 2) Laura, when you reply could you stop quoting the whole original
> mail, but better delete the unrelevant parts?
>
Sorry, I guess this was because of the plain text mode. Hope now works :)

>
> Björn
>

Regards!

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

Re: GNU Guix Video Documentation

[Björn Höfling]

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

Hi Larissa,

welcome to Guix!

I'm putting the other Mentors/Coordinators and the developer list on
CC. Please answer to the mailing list, so others can help you out too.

On Wed, 24 Oct 2018 17:51:56 +0100
Larissa Leite <lari.leite88@gmail.com> wrote:

> Hello,
> 
> My name is Larissa and I would love to contribute to the project.
> I am having some trouble finding where to start, so I have decided,
> after reading the reccommendations, to e-mail one of the mentors and
> introduce myself.
> I'm currently studying Media Production as an exchange student at the
> University of Lincoln, this project resonated with me the most,
> considering video editing is my passion and I love every opportunity
> to develop my editing skills.
> Besides editing, I would also enjoy helping with translation. I am
> Brazilian, so Portuguese is my native language, and I speak both
> English and Spanish fluently.
> If you could help me start my contribution, it would be great, I'm
> really excited to be a part of this project.

That sounds great. The first step would be to get familiar with Guix
and to make a contribution, that you can formally declare on the
Outreachy website.

To contribute, you can either prepare a package or update
documentation, though we would recommend packaging to get first
familiar with the system.

So your first step would be to install Guix or GuixSD and get into
it. You can either install Guix on top of another distro or you can
install GuixSD, the GNU/Linux-Distribution alone, either in a virtual
machine or a standalone hardware.

I think there is a link for both types from the Guix Outreachy site. I
will post them here too:

https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation

https://www.gnu.org/software/guix/manual/en/html_node/System-Installation.html#System-Installation

You can pack whatever software you like and is missing in Guix, though
it could get hard depending on your choice :-) So in general for a
beginner are R-packages recommended, we have also importers for that.


If you have any questions, ask on the mailing list or on IRC. The
community is very welcoming and willing to help.

Yours,

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Hello Larissa,

Welcome to Guix!

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> ezt írta (időpont:
2018. okt. 25., Cs, 8:17):
>
> Hi Larissa,
>
> welcome to Guix!
>
> I'm putting the other Mentors/Coordinators and the developer list on
> CC. Please answer to the mailing list, so others can help you out too.
>
> On Wed, 24 Oct 2018 17:51:56 +0100
> Larissa Leite <lari.leite88@gmail.com> wrote:
>
> > Hello,
> >
> > My name is Larissa and I would love to contribute to the project.
> > I am having some trouble finding where to start, so I have decided,
> > after reading the reccommendations, to e-mail one of the mentors and
> > introduce myself.
> > I'm currently studying Media Production as an exchange student at the
> > University of Lincoln, this project resonated with me the most,
> > considering video editing is my passion and I love every opportunity
> > to develop my editing skills.
> > Besides editing, I would also enjoy helping with translation. I am
> > Brazilian, so Portuguese is my native language, and I speak both
> > English and Spanish fluently.
> > If you could help me start my contribution, it would be great, I'm
> > really excited to be a part of this project.
>

That's great!

> That sounds great. The first step would be to get familiar with Guix
> and to make a contribution, that you can formally declare on the
> Outreachy website.
>
> To contribute, you can either prepare a package or update
> documentation, though we would recommend packaging to get first
> familiar with the system.
>
> So your first step would be to install Guix or GuixSD and get into
> it. You can either install Guix on top of another distro or you can
> install GuixSD, the GNU/Linux-Distribution alone, either in a virtual
> machine or a standalone hardware.
>
> I think there is a link for both types from the Guix Outreachy site. I
> will post them here too:
>
> https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation
>
> https://www.gnu.org/software/guix/manual/en/html_node/System-Installation.html#System-Installation
>

Yes, any of these would do.

> You can pack whatever software you like and is missing in Guix, though
> it could get hard depending on your choice :-) So in general for a
> beginner are R-packages recommended, we have also importers for that.
>

Yes, packaging something from the CRAN repository using guix import
would be a good first contibution. For more information about importers
see the invoking guix import section of the manual.

>
> If you have any questions, ask on the mailing list or on IRC. The
> community is very welcoming and willing to help.
>
> Yours,
>
> Björn

Best regards,
g_bor

Re: GNU Guix Video Documentation

[Larissa Leite]

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

Hello,

Thank you for your help.
Is programming the only way of contributing?
I would like to contribute through documentation, video or translation, if
possible.

Thank you,
Larissa Leite

Em qui, 25 de out de 2018 às 10:19, Gábor Boskovits <boskovits@gmail.com>
escreveu:

> Hello Larissa,
>
> Welcome to Guix!
>
> Björn Höfling <bjoern.hoefling@bjoernhoefling.de> ezt írta (időpont:
> 2018. okt. 25., Cs, 8:17):
> >
> > Hi Larissa,
> >
> > welcome to Guix!
> >
> > I'm putting the other Mentors/Coordinators and the developer list on
> > CC. Please answer to the mailing list, so others can help you out too.
> >
> > On Wed, 24 Oct 2018 17:51:56 +0100
> > Larissa Leite <lari.leite88@gmail.com> wrote:
> >
> > > Hello,
> > >
> > > My name is Larissa and I would love to contribute to the project.
> > > I am having some trouble finding where to start, so I have decided,
> > > after reading the reccommendations, to e-mail one of the mentors and
> > > introduce myself.
> > > I'm currently studying Media Production as an exchange student at the
> > > University of Lincoln, this project resonated with me the most,
> > > considering video editing is my passion and I love every opportunity
> > > to develop my editing skills.
> > > Besides editing, I would also enjoy helping with translation. I am
> > > Brazilian, so Portuguese is my native language, and I speak both
> > > English and Spanish fluently.
> > > If you could help me start my contribution, it would be great, I'm
> > > really excited to be a part of this project.
> >
>
> That's great!
>
> > That sounds great. The first step would be to get familiar with Guix
> > and to make a contribution, that you can formally declare on the
> > Outreachy website.
> >
> > To contribute, you can either prepare a package or update
> > documentation, though we would recommend packaging to get first
> > familiar with the system.
> >
> > So your first step would be to install Guix or GuixSD and get into
> > it. You can either install Guix on top of another distro or you can
> > install GuixSD, the GNU/Linux-Distribution alone, either in a virtual
> > machine or a standalone hardware.
> >
> > I think there is a link for both types from the Guix Outreachy site. I
> > will post them here too:
> >
> >
> https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation
> >
> >
> https://www.gnu.org/software/guix/manual/en/html_node/System-Installation.html#System-Installation
> >
>
> Yes, any of these would do.
>
> > You can pack whatever software you like and is missing in Guix, though
> > it could get hard depending on your choice :-) So in general for a
> > beginner are R-packages recommended, we have also importers for that.
> >
>
> Yes, packaging something from the CRAN repository using guix import
> would be a good first contibution. For more information about importers
> see the invoking guix import section of the manual.
>
> >
> > If you have any questions, ask on the mailing list or on IRC. The
> > community is very welcoming and willing to help.
> >
> > Yours,
> >
> > Björn
>
> Best regards,
> g_bor
>

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

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Hello Larissa,

Larissa Leite <lari.leite88@gmail.com> ezt írta (időpont: 2018. okt.
25., Cs, 18:26):
>
> Hello,
>
> Thank you for your help.
> Is programming the only way of contributing?
> I would like to contribute through documentation, video or translation, if possible.
>

No, documentation improvements are considered contribution for this project.

However, it is really hard to document something that you are not familiar with.

At least installing Guix or GuixSD is a hard requirement.

We recommend packaging something easy, as this will be one of the things that
will have to be documented, and usually these type of contributions
are faster to
make. Also note, that in case of these simple CRAN packages this is rather a
data recording like task, than programming. (Consider that we would
like to create
a 3 minutes tutorial video to have this covered.)

With all that said, you can modify the texinfo documentation of guix,
it is located at
doc/guix.texi in the source. These type of contributions tend to take longer, as
community consensus is needed on the sytle and wording. A recommended way to
create a documentation contribution is to add some @cindex entires to
the manual.

All the contribution guidelines apply, like for all other patches.

Translation is delegated to the Translation Project, and is
coordianted by their per
language communities, and outside the scope of this project right now. However
you are welcome to provide translated verisons of the videos, once the
internship
begins.

> Thank you,
> Larissa Leite
>
> Em qui, 25 de out de 2018 às 10:19, Gábor Boskovits <boskovits@gmail.com> escreveu:

Best regards,
g_bor

Re: GNU Guix Video Documentation

[Gábor Boskovits]

Hello Larissa,

Could you give us a status update?

There is only one week left until the deadline, and it usually takes
about 3-4 day to get
in a contribution.

Should you need any help, please contact me.

Best regards,
g_bor