02/03: doc: sif-2021: Tweak wording.

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit 05f02271670fc38ac1478d4ba18d228c4062bd31
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Tue Aug 3 15:23:35 2021 +0200

    doc: sif-2021: Tweak wording.
    
    * doc/sif-2021/article-1024.org: Tweak wording as suggested by Denis
    Pallez.
---
 doc/sif-2021/article-1024.org | 40 ++++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/doc/sif-2021/article-1024.org b/doc/sif-2021/article-1024.org
index 2410fb1..f4df863 100644
--- a/doc/sif-2021/article-1024.org
+++ b/doc/sif-2021/article-1024.org
@@ -30,7 +30,7 @@
   de recherche reproductible — un pléonasme ! — doit intégrer le
   logiciel.  Mais de quelle manière au juste ?
 
-  Le Deuxième Plan national pour la science ouverte
+  Le deuxième Plan national pour la science ouverte
   [[cite:mesri2021planscienceouverte]], publié en juillet 2021, « soutient »
   la diffusion du code source des logiciels de recherche sous licence
   libre permettant la diffusion sans restriction, mais aussi la
@@ -39,15 +39,15 @@
   critique ne peut se faire correctement que si les pairs peuvent
   étudier le code source et faire leurs propres expériences.  Le Plan
   insiste aussi sur la conservation des codes sources grâce à Software
-  Heritage sans laquelle ce travail devient vite impossible.
+  Heritage, sans quoi ce travail devient vite impossible.
 
   Que le code source soit disponible est une condition nécessaire mais
   pas suffisante.  Les sociétés savantes ont mis en place un système de
   badges pour évaluer le niveau de reproductibilité des résultats
   décrits dans leurs publications.  Celui de l'/Association for Computer
-  Machinery/ (ACM) dispose de trois niveaux selon que le code soit
-  disponible (premier niveau), utilisable (deuxième niveau), ou que les
-  résultats aient été reproduits indépendamment en faisant tourner le
+  Machinery/ (ACM) dispose de trois niveaux selon que le code est
+  disponible (premier niveau), est utilisable (deuxième niveau), ou que les
+  résultats ont été reproduits indépendamment en faisant tourner le
   code[fn:2].  La reproduction des environnements logiciels — le fait de
   pouvoir déployer précisément l’ensemble logiciel qui a servi à une
   production scientifique — est un aspect qu’on relègue volontiers au
@@ -69,14 +69,14 @@
   Malheureusement, ces outils ont deux limitations : ils requièrent les
   droits d’administration système, et ils ne permettent de déployer
   qu’un seul environnement logiciel à la fois.  Pour cette raison, en
-  particulier dans le domaine du calcul intensif (ou HPC, pour
-  /high-performance computing/), on a développé d’autres outils de
-  gestions de paquets destinés à être utilisés /par dessus/ celui du
-  système, avec l’avantage d’être utilisable sans les droits
+  particulier dans le domaine du calcul intensif (/high-performance
+  computing/ ou HPC), on a développé d’autres outils de
+  gestion de paquets destinés à être utilisés /au dessus/ celui du
+  système, avec l’avantage d’être utilisables sans les droits
   d’administration, par chaque utilisateur·ice, qui peut ainsi déployer
-  son ou ses environnements logiciels.  Les outils populaires dans cette
+  ses environnements logiciels.  Les outils populaires dans cette
   catégorie incluent CONDA, Spack et EasyBuild, ainsi que des outils
-  propres à un langage de programmation (pour Python, Julia, R, etc.).
+  dédiés à un langage de programmation (pour Python, Julia, R, etc.).
 
   L’expérience a rapidement montré que cet empilement d’outils de
   déploiement devient vite préjudiciable à la reproductibilité, car
@@ -103,7 +103,7 @@
   L’approche est séduisante : puisqu’on a tous les octets des logiciels,
   la reproductibilité est totale ; on a la garantie de pouvoir relancer
   les logiciels, et donc, de reproduire l’expérience scientifique.  Mais
-  l’inconvénient est de taille : puisque l’on a /que/ les octets des
+  l’inconvénient est de taille : puisque l’on n’a /que/ les octets des
   logiciels, comment savoir si ces octets correspondent vraiment au code
   source que l’on croit exécuter ?  Comment expérimenter avec cet
   environnement logiciel, dans le cadre d’une démarche scientifique,
@@ -161,8 +161,8 @@
 
 * Déclarer et reproduire un environnement logiciel
 
-  Guix peut s’utiliser comme une distribution à part entière, Guix
-  System, ou alors comme un outil de déploiement par dessus une
+  Guix peut s’utiliser comme une distribution à part entière avec Guix
+  System ou alors comme un outil de déploiement par dessus une
   distribution existante et donnant accès à plus de 18 000 logiciels
   libres.  Il fournit une interface en ligne de commande similaire à 
   celle des outils de gestion de paquets : la commande =guix install
@@ -177,7 +177,7 @@
   Voyons maintenant comment on peut concrètement, en tant que
   scientifique, utiliser cet outil pour que ses expériences
   calculatoires soient reproductibles.  On peut commencer par lister
-  dans un /manifeste/ les logiciels à déployer ; ce fichier peut être
+  dans un /manifeste/ les logiciels à déployer ; ce manifeste peut être
   partagé avec ses pairs et stocké en gestion de version.  L’exemple
   ci-dessous nous montre un manifeste pour les logiciels Python, SciPy
   et NumPy :
@@ -212,7 +212,7 @@
   version Git, l’identifiant de révision désigne de manière non ambiguë
   /l’ensemble du graphe de dépendance des logiciels/ — aussi bien la
   version de Python, que ses options des compilations, ses dépendances,
-  et ce récursivement jusqu’au compilateur du compilateur.  C’est la
+  et ceci récursivement jusqu’au compilateur du compilateur.  C’est la
   commande ~guix describe~ qui donne la révision actuellement utilisée :
 
   #+begin_src sh
@@ -275,7 +275,7 @@
   possible.
 
   Et si le code source de ces logiciels venait à disparaître ?  On peut
-  compter sur Software Heritage (abrégé SWH), qui a pour mission rien de
+  compter sur Software Heritage (SWH en abrégé), qui a pour mission rien de
   moins que d’archiver tout le code source public disponible[fn:6].
   Depuis quelques années, Guix est intégré à SWH de deux manières :
   d’une part Guix va automatiquement chercher le code source sur SWH
@@ -330,13 +330,13 @@
 * Adapter les pratiques scientifiques
 
   La place croissante prise par le logiciel dans les travaux
-  scientifiques avait, paradoxalement, probablement été une des causes
+  scientifiques, paradoxalement, avait probablement été une des causes
   de la « crise » de la reproductibilité en sciences expérimentales que
   beaucoup ont observée — par la perte de bonnes pratiques anciennes
   telles que les cahiers de laboratoire.  Notre souhait est qu’elle
   puisse maintenant, au contraire, permettre une /meilleure/
-  reproductibilité des résultats expérimentaux, en refusant de mettre de
-  côté la rigueur scientifique quand on arrive dans le terrain logiciel.
+  reproductibilité des résultats expérimentaux, en maintenant à tout
+  prix la rigueur scientifique quand on arrive dans le terrain logiciel.
 
   De même que les outils de gestion de version sont progressivement
   entrés dans la boîte à outils des scientifiques comme un moyen