Les illustrations doivent être en 16:9, au format 1280 ⨉ 720 pixels, optimisées au préalable avec un outil du type ImageOptim - choisir des réglages "lossy" donnant en général plus de 50% de gains à la compression, mais ne pas supprimer les métadonnées d'images.
Sinon, offline : dupliquer un fichier de description dans le dossier
/content/_startupset suivre les instructions ci-dessous sur l'édition.
Pour le titre de la startup, s'en tenir aux règles usuelles, c'est-à-dire sauf cas particuliers : le premier mot prend une majuscule, les autres non. (Ce n'est pas grave de se tromper, mais il faut s'attendre à ce que ça soit corrigé plus tard.)
Pour l'énoncé de mission, utiliser une phrase à l'infinitif, qui complète « En investissant dans ce produit, l'État cherche à… » ou « l'État cherche à rendre plus facile de… ».
Modifier le fichier $id_startup.md de description de la Startup dans le dossier content/_startups.
La documentation des différentes propriétés à renseigner est accessible en cliquant sur le lien de création d'une nouvelle Startup dans la section précédente.
Ajouter un image $id_startup.jpgou .png dans le dossier img/startups
En complétant, le formulaire d'onboarding : https://secretariat.incubateur.net/onboarding , une PR sera créé et une fois validé, l'adresse email est créé.
Cette interface permet à toutes les personnes de la communauté modifier des fiches.
Le nom du fichier est important : il doit correspondre au nom de la personne, selon le schéma prenom.nom.md. Les parties prenom et nom sont en minuscules et sans accents. Les espaces des noms propres sont remplacés par _ et les tirets restent. Il faut garder .md à la fin du nom du fichier. Il est important que cet identifiant et celui du mail @beta.gouv.fr correspondent. Cela nous permet de traiter automatiquement divers sujets liés à la gestion RH tels que abonnement et désabonnement des listes de diffusion, anticipation des fins de contrat, etc.
Sinon, offline : créer un nouveau fichier de description dans le dossier
content/_authorset renseigner les informations en prenant exemple sur un fichier de description existant déjà dans ce dossier.
Tu peux fournir un fichier avec ta photo si tu n'as pas de compte Github, ou si tu es à l'aise avec la manip (qui est un peu plus pénible que juste modifier un fichier Markdown). Attention, l'image doit être carrée et de préférence à une résolution supérieure à 512 ⨉ 512 pixels, optimisée au préalable avec un outil du type ImageOptim - choisir des réglages "lossy" donnant en général plus de 50% de gains à la compression, mais ne pas supprimer les métadonnées d'images.
Une fois l'offre pourvue, bien penser à changer la valeur du flag
openet de la mettre àfalse.
S'il s'agit d'une offre dev, merci d'ajouter le flag
techno.
Pour un premier recrutement (le CTO de la Startup), la valeur conseillée de ce champ est "Choix technologiques ouverts parmi les solutions libres du marché."
Pour les recrutements ultérieurs, vous pouvez préciser s'ils sont ouverts aux juniors. Le recrutement de ces profils "juniors" est un élément important pour augmenter la diversité au sein de notre collectif ; prenez le temps de réfléchir à vos besoins pour ce recrutement avant d'écarter cette possibilité.
Rechercher le contenu à modifier et éditer le fichier correspondant.
Ce site est construit avec Jekyll, un générateur de sites statiques. La version utilisée est celle actuellement en production.
Pour initialiser votre environnement de développement, commencez par installer Ruby dans la version spécifiée par le fichier .ruby-version.
Si vous utilisez RVM pour isoler votre environnement, vous pouvez le faire avec la commande suivante:
rvm install `cat .ruby-version`Toujours avec RVM, vous pouvez créer un fichier .ruby-gemset contenant un nom de gemset à utiliser en local.
Il vous suffit alors de sortir puis revenir du répertoire pour que le gemset soit créé correctement si votre shell est bien configuré.
Ensuite, exécutez les commandes suivantes :
git clone https://github.com/betagouv/beta.gouv.fr.git
cd beta.gouv.fr
gem install bundler --no-ri --no-rdoc
npm install
bundle install
bundle exec jekyll serveLes fichiers pertinents pour une modification de la présentation sont probablement dans les dossiers assets\additional et layout.
Afin de minimiser les écarts entre les versions de développement et les versions de production, ce dépôt contient un fichier Gemfile (spécification des versions minimum des dépendances), comme beaucoup de dépôts Ruby.
Pour encourager les contributions, éviter les erreurs d'inattention, et se mettre d'accord collectivement sur le contenu publié au nom de l'incubateur, chaque modification doit être relue et approuvée par une autre personne que l'auteur avant d’être intégrée.
Pour les relectures de code, il vaut mieux choisir une personne ayant un peu l'habitude de Jekyll, de Ruby ou du développement web. En revanche, en cas d'urgence sur une relecture éditoriale, toute personne de l'incubateur est légitime à approuver les modifications.
L'auteur d'une modification est responsable de pousser pour obtenir une relecture, en relançant les gens périodiquement. Pour demander une relecture :
- Ouvrir une pull request, sans mentionner de relecteur explicitement. Les relecteurs potentiels vont recevoir une notification, et peuvent s'auto-assigner la relecture.
- Si plusieurs jours s'écoulent sans relecture (entre 2 et 5 jours, à la louche), ajouter un commentaire à la pull request, en demandant explicitement une relecture à un relecteur potentiel.
- Si plusieurs jours s'écoulent à nouveau, contacter directement un relecteur potentiel (par exemple par message privé sur le Slack de l'incubateur, ou en présentiel dans les locaux de beta.gouv.fr).
- Commentez le code ou le texte – pas l'auteur : on ne cherche pas à assigner de responsabilités ou à critiquer l'auteur ; mais juste à voir comment un bout de code ou de texte pourrait être plus pertinent.
- Si vous critiquez, proposez : si quelque chose ne vous plait pas, expliquez comment vous proposeriez de l'améliorer.
- Soyez souple : si vous avez une remarque mineure, ne bloquez pas la pull request avec une revue négative. Il vaut mieux approuver la pull request, en laissant l'auteur responsable de prendre en compte (ou pas) vos remarques.
Chaque pull request est déployée dans Netlify, une fois le build passé. Vous pouvez la retrouver dans la partie des "Checks" au nom de deploy/netlify. Vous pouvez suivre le lien associé pour accéder à la version de l'application correspondant à la pull request.
Ce site est déployé en continu avec Netlify. La branche qui reflète la production est master.
Pousser sur master, c’est partager avec le monde… ce qui signifie donc qu'il faut être très prudent avec ce pouvoir et privilégier l'usage de pull requests 😉
C'est pourquoi la branche master est protégée : il est impossible de mettre en production sans que les tests automatisés n'aient validé que le site pouvait être généré correctement et qu'au moins un pair humain ait revu les modifications proposées.