From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: GNU Guix Video Documentation Date: Fri, 26 Oct 2018 06:13:52 +0200 Message-ID: <87efcd5oqn.fsf@elephly.net> References: <20181025235334.7ebf5970@alma-ubu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gFtds-0007Ha-Q5 for guix-devel@gnu.org; Fri, 26 Oct 2018 00:22:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gFtW2-0001p7-Vc for guix-devel@gnu.org; Fri, 26 Oct 2018 00:14:35 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21049) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gFtW0-0001lW-Hr for guix-devel@gnu.org; Fri, 26 Oct 2018 00:14:30 -0400 In-reply-to: <20181025235334.7ebf5970@alma-ubu> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?utf-8?Q?Bj=C3=B6rn_H=C3=B6fling?= Cc: Guix-devel , Ricardo Wurmus Hi Bj=C3=B6rn, > 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=E2=80=99t think they are the most us= eful tool to convey ideas. Much of what=E2=80=99s 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=E2=80=99d 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=E2=80=99d like to see covered. This also m= akes it easier for us to determine if the internship progresses as planned. Beyond the minimum, I=E2=80=99d like to leave it up to the intern to come up with more ideas for videos. It=E2=80=99s 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=E2= =80=99t know if there=E2=80=99s an instance for GNU packages. GNU Guix does not currently have its own Mediagoblin instance. -- Ricardo