47 lines
2.6 KiB
Org Mode
47 lines
2.6 KiB
Org Mode
|
#+title: Promouvoir son projet open-source comme une rock star !
|
||
|
|
#+date: <2021-10-25 lun.>
|
||
|
|
#+html_link_up:../roadmap.html
|
||
|
|
|
||
|
|
* Introduction
|
||
|
|
|
||
|
|
[[https://devfest2019.gdgnantes.com/sessions/promouvoir_son_projet_open_source_comme_une_rock_star__/][Conférence DevFest 2019]] - [[https://github.com/zenika-open-source/promote-open-source-project][Slides et cheatsheet]] - [[https://twitter.com/tbetous][Twitter]] - [[https://twitter.com/FranckAbgrali][Twitter]]
|
||
|
|
|
||
|
|
Conférence résumant ce que les auteurs ont vécu pour promouvoir leur projet. (@tbetous @FranckAbgrali).
|
||
|
|
|
||
|
|
* Le README
|
||
|
|
|
||
|
|
Le nom du projet ne doit pas être trop long ou avoir trop de "buzzname" dedans.
|
||
|
|
|
||
|
|
On peut ajouter la licence à la fin du README et *le structurer avec des éléments de formatage* du Markdown (ou autre format utilisé pour le fichier). Cela permet d'avoir
|
||
|
|
un README plus attractif et jolie. *Il est aussi recommandé de faire des sections* afin de pouvoir guider facilement l'utilisateur. L'ajout d'un GIF de démo est aussi utile
|
||
|
|
pour montrer comment utiliser le logiciel.
|
||
|
|
|
||
|
|
Les badges permettent aussi d'indiquer rapidement des informations.
|
||
|
|
|
||
|
|
** La documentation
|
||
|
|
|
||
|
|
Ajouter la documentation dans le README peut s'avérer lourd sur le long terme. Il vaut mieux utiliser un service externe (wiki de GitHub, Vuepress avec Netifly, Docz, Docusaurus...).
|
||
|
|
|
||
|
|
* Les stars
|
||
|
|
|
||
|
|
Le nombre de stars influence indirectement l'avis des utilisateurs (plus de stars = bonne santé du projet).
|
||
|
|
|
||
|
|
1. Communiquer le projet aux proches / collègues afin d'avoir une première base de stars
|
||
|
|
2. Communiquer ensuite le projet aux autres via des canaux de communications comme Reddit, HackerNews, Human Coders, Decto, ProductHunt...
|
||
|
|
3. Communiquer sur toutes les plateformes d'un coup pour profiter d'un coup de buzz
|
||
|
|
4. Ne pas négliger les petits canaux de communications
|
||
|
|
|
||
|
|
La meilleure période de la semaine pour communiquer se situe entre mardi et jeudi.
|
||
|
|
|
||
|
|
Comme pour les recommandations Youtube, GitHub Trending met en avant des projets via un algorithme (qu'on ne connait pas).
|
||
|
|
|
||
|
|
* Et après ?
|
||
|
|
|
||
|
|
Pour continuer à communiquer sur le projet, il faut faire:
|
||
|
|
- faire des articles (sur les technos du projet, quel problème il résout...)
|
||
|
|
- faire des conférences dessus
|
||
|
|
- des mises à jours régulières (pour montrer que le projet est actif)
|
||
|
|
- *organiser les issues pour permettre aux personnes de voir facilement comment contribuer*
|
||
|
|
- *remercier les contributeurs (tweet, section dans le README...)*
|
||
|
|
- construire sa communauté sur Slack, Discord... pour pouvoir mieux communiquer avec les utilisateurs et contributeurs
|