Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

[RMLL2017] le guide du connard du logiciel libre

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 29 Publicité
Publicité

Plus De Contenu Connexe

Publicité

Plus par Clément OUDOT (20)

Plus récents (20)

Publicité

[RMLL2017] le guide du connard du logiciel libre

  1. 1. @CreativeConnard Le Guide du Connard du Logiciel Libre
  2. 2. ~ 2 ~@CreativeConnard HOW TO être un connard ~ Utilisateur ~ ~ Développeur ~ ~ Entreprise ~
  3. 3. ~ 3 ~@CreativeConnard ~ Utilisateur ~
  4. 4. ~ 4 ~@CreativeConnard Chapitre #1 [ Les listes de diffusion ]
  5. 5. ~ 5 ~@CreativeConnard Ne pas utiliser les listes Envoyer des mails directement aux développeurs※ Aller sur un canal IRC et y copier les piles de logs (<3 Java)※ Envoyer des demandes d'aide sur Twitter et Facebook, ne pas oublier les smileys※ ※ Ouvrir des bugs pour poser des questions
  6. 6. ~ 6 ~@CreativeConnard Quelques exemples Hi Clem-  I found your email on openldap.org community - I need an urgent help.  Can you please help me with steps, migration plan and document to do the complete migration from Sun DSEE 5.2 to 389 DS? I would really appreciate your quick response. Looking forward.
  7. 7. ~ 7 ~@CreativeConnard Utiliser les listes Ne pas s'inscrire sur les listes et forcer les responsables des projets à modérer les messages (et si possible les insulter si les messages ne sont pas transmis à la liste) ※ Bien positionner son message d'absence pour informer tout le monde qu'on est en vacances※ Ne pas inclure la liste dans les réponses, ça pourrait aider les autres※
  8. 8. ~ 8 ~@CreativeConnard Inviter la liste sur des réseaux sociaux
  9. 9. ~ 9 ~@CreativeConnard Écrire sur les listes ※ Répondre en dehors du fil de discussion ou changer de sujet dans le fil de discussion Inclure une grosse signature HTML Avertir de la confidentialité du message envoyé sur une liste publique ※ ※ Ne jamais donner la réponse quand vous l’avez trouvée
  10. 10. ~ 10 ~@CreativeConnard Et surtout FEED THE TROLL
  11. 11. ~ 11 ~@CreativeConnard Chapitre #2 [ Les bugs ]
  12. 12. ~ 12 ~@CreativeConnard Trouver des bugs ※ Utiliser des versions préhistoriques (plus de 2 ans) ※ Utiliser des patchs non officiels ※ Utiliser des systèmes d'exploitation improbables ※ Laisser votre enfant utiliser le logiciel
  13. 13. ~ 13 ~@CreativeConnard Rapporter des bugs ※ Surtout ne pas chercher si le bug existe déjà, ne pas hésiter à créer des doublons ※ Mettre en description du bug « ça ne marche pas » ※ Donner le moins de détails possibles pour garder une part de mystère ※ Exiger une solution immédiatement (ASAP), mais bien entendu ne pas tester les correctifs proposés
  14. 14. ~ 14 ~@CreativeConnard
  15. 15. ~ 15 ~@CreativeConnard ~ Développeur ~
  16. 16. ~ 16 ~@CreativeConnard Chapitre #3 [ La documentation ]
  17. 17. ~ 17 ~@CreativeConnard Révisez vos acronymes ※ RTFM (Read The Fucking Manual) ※ WITFM (Where Is The Fucking Manual) ※ TODO (Too Old DOcument) ※ RTS (Read The Source)
  18. 18. ~ 18 ~@CreativeConnard Multiplier la documentation ※ Créer des fichiers dans la racine du projet (README, INSTALL), éviter des les mettre à jour ※ Mettre un wiki ouvert sur le site Web ※ Passer des heures à expliquer des choses par mail sur la liste de diffusion, mais ne jamais le documenter ailleurs
  19. 19. ~ 19 ~@CreativeConnard Chapitre #4 [ Assurance qualité ]
  20. 20. ~ 20 ~@CreativeConnard TESTER C'EST DOUTER
  21. 21. ~ 21 ~@CreativeConnard
  22. 22. ~ 22 ~@CreativeConnard Chapitre #5 [ Relations avec les utilisateurs ]
  23. 23. ~ 23 ~@CreativeConnard (ex-)communication ※ Insulter ceux qui posent des questions, mais aussi ceux qui répondent aux questions ※ Ne pas croire les utilisateurs qui rencontrent des problèmes (appelée aussi technique du « ça marche sur ma machine ») ※ Faire son site Web avec les technologies du siècle dernier
  24. 24. ~ 24 ~@CreativeConnard Pourquoi faire simple ? ※ Les paquets c'est pour les mauviettes ※ Forcer l'utilisateur à s'inscrire pour tout : voir un bug, télécharger du code, consulter les archives de la liste ※ Pas de feuille de route, pas de référentiel de bugs, pas de notes de version, tout doit être dans sa tête
  25. 25. ~ 25 ~@CreativeConnard ~ Entreprise ~
  26. 26. ~ 26 ~@CreativeConnard Utiliser des logiciels libres ※ Les licences c'est trop compliqué, personne ne va vérifier ※ On s'en fout si ça marche pas très bien, c'est gratuit ※ On reverse déjà la TVA, on va pas en plus reverser du code ※ Rien à faire de la communauté, on n’est pas communistes
  27. 27. ~ 27 ~@CreativeConnard Faire des logiciels libres ※ Fourcher plutôt que contribuer (Fork as a Service) ※ Privilégier l'open core/freemium pour forcer l'achat d'une version « entreprise » ※ Faire rédiger une nouvelle licence par son service juridique, car il n'y a pas de licence existante qui convienne ※ Surtout ne pas faciliter la contribution des personnes extérieures à la société (c'est nous qu'on fait tout)
  28. 28. ~ 28 ~@CreativeConnard ~ Fin ~
  29. 29. ~ 29 ~@CreativeConnard @CreativeConnard @DonJon_Legacy http://donjonlegacy.com/

×