Communauté, libristes et projet libre ?

je vais dire "first".

artragis

Le méta-commentaire : j’ai été pas mal de temps DTC de ZdS. Je savais que, même si je me suis parfois pris la tête avec des gens, on avait un développement avec pas mal d’intervenants par rapport à notre taille de projet.

Je crois par contre que je n’avais jamais pris conscience d’à quel point c’est exceptionnel.

Après linuxfr.org a un historique différent. Et je pense qu’ils ont fait des choix techniques assez désastreux. PHP avec Templeet (qui n’était pas super bien connu et super top) puis Ruby ne sont pas des technologies que beaucoup de monde apprécient ou maitrisent. Du coup contribuer devient difficile.

Ensuite, concernant la différence du nombre de rapports de bogues, cela peut venir également de la différence d’objectif entre les deux sites. Selon moi, Zeste de Savoir est plus complet et complexe. Linuxfr.org reste un site assez simpliste dans l’ensemble ce qui a ses avantages en terme de maintenance et de fiabilité.

Pour Ruby (ou plus exactement Ruby on Rails), je pense qu’ils sont tombés dans le piège de la mode. Si mes souvenirs sont exacts, ils ont étudié et décidé la bascule au moment où « c’était évident » que ce framework serait l’avenir du développement web, et donc que ça faciliterait la maintenance.

La réalité, c’est que RoR lui-même a influencé des zillions de frameworks parmi les meilleurs (coucou Django) mais que lui-même, s’il a bien fonctionné, n’a pas eu l’effet majeur escompté.

Il est vrai que côté développement on a une grosse force : on arrive à tourner avec une équipe qui est toujours sous cette forme :

• 3 ou 4 gros contributeurs
• 3 ou 4 contributeurs qui suivent le projet mais n’ont pas beaucoup de temps à y passer
• 3 ou 4 contributeurs ponctuels

Historiquement, on avait un problème de front-end, qui est en train de se régler grâce à motet-a mais globalement aujourd’hui c’est comme ça :

• vhf, motet-a, gcodeur et pierre (car faut pas négliger elastic et la QA) en gros contributeurs
• sandhose, amarOk, abdelazer et moi en "médian"
• anto, situphen en ponctuels

mais dans les mois à venir ça changera. A une époque c’était pierre et moi les plus gros développeurs, et j’ai été plus que ponctuels pendant casi 1 an post zep-12.

La force de zds (et qui est certainement dû à la qualité de son code, même si tout reste perfectible) c’est qu’on est capable de faire tourner les équipes et d’accueillir des gens au fil de l’eau. Plusieurs noms n’ont pas été cité ici par exemple : gustavi, emeric, andr0 (qui est passé sur irc pour setter un environnement tout neuf), vayel, Hugo…

Par contre on attend toujours que l’asso organise des meetup ou des tutothons.

Merci pour le chouette billet. (Le graphe de +/- signifie pas grand chose en terme d’effort ou de dévouement, c’est trop souvent miné par +80’000/-80’000 parce qu’on change tout de CRLF à LF et choses dans ce goût là. Idéalement faudrait pondérer avec : https://github.com/zestedesavoir/zds-site/graphs/code-frequency , ou simplement exclure les premiers commits. D’ailleurs c’est curieux mais notre repo a été créé après copie du projet PDP, pas basé sur le repo PDP !)

Pour moi la force (technique) de zds c’est la diversité d’expérience dans l’équipe technique. Pour certains le code est de qualité, pour d’autres il est moche. Pour certains c’est bien mais c’est pas du C#, pour d’autres c’est bien. Pour certains faudrait passer à Postgres, pour d’autres ça va. Pour certains coder c’est cool mais communiquer c’est pas possible. Pour certains coder c’est cool mais administrer des serveurs c’est pas possible. Pour certains le backend c’est cool mais le frontend c’est pas possible. Pour certains les serveurs c’est cool mais iptables c’est pas possible. Pour certains communiquer c’est cool mais coder c’est pas possible. Pour certains le JS c’est cool, pour d’autres le mot JS signifie "jihad contre Python et toute ta famille". Pour certains quand les membres ragent sur les forums contre de minuscules bugs c’est rigolo, pour d’autres c’est insupportable. Pour certains c’est le premier projet open-source, d’autres ont participé à des tas de projets nettement plus gros. Pour certains le développement est un métier depuis longtemps, pour d’autres pas du tout. Etc etc.

Et pour certain, devenir assez bon en Python pour pouvoir enfin participer à ZdS, c’est un objectif.

En fait je dirais qu’on devient bon en python en participant à zds

Encore un grand merci à tous les contributeurs de ZdS !

Personnellement dans ma boite il y a plusieurs gros projets sous RoR.

Après ce qui serait génial c’est d’organiser des journées/hackatons pour améliorer ZdS. Par ce que ce n’est pas forcément toujours facile de commencer seul.

Maintenant que ZdS peut gérer des billets, je me demande si ça ne serait pas une bonne chose pour la communauté de Linuxfr de forker le code de ZdS.

Je me faisais la même réflexion. Il faudrait peut-être leur proposer

Leur système de forum poutre allègrement le notre, avec un système de sous-conversation très pratique.

Pas d’accord : les nouveaux messages sont impossibles à suivre dès qu’il n’y a plus les marqueurs de messages lus/non lus.

C’est assez subjectif. Chaque système de réponse a ses avantages et ses inconvénients. Donc je ne serais pas aussi catégorique que toi sur cette question.

Par contre il y a une vrai valeur ajoutée dans le code de ZdS que tu n’as pas sur Linuxfr (quand je pense qu’ils ne sont toujours pas en https … )

EDIT : grillé en partie par Spacefox

Par contre il y a une vrai valeur ajoutée dans le code de ZdS que tu n’as pas sur Linuxfr (quand je pense qu’ils ne sont toujours pas en https … )

Par défaut non, mais tu peux naviguer en HTTPS dessus sans soucis.

Ah effectivement je viens de constater. Mais ça devrait être par défaut.

Pas tout à fait : les cookies ne sont pas correctement partagés entre HTTP et HTTPS (ne me demandez pas comment c’est possible), et selon le navigateur tu ne peux pas faire des actions (commenter, plussoyer…) en HTTP (au moins si tu as déjà été connecté en HTTPS).

Par contre ils sont passés à un certificat normal qui est reconnu par les navigateurs, ça c’est pratique.

A propos des commentaires threadés comme sur LinuxFR, c’est un système que j’adore. Mais c’est pas un bon système pour un forum. C’est idéal à mon sens pour les commentaires. Pensez HN, Lobsters, Reddit, LinuxFR. Je trouve ça top.

Ici en commentaires de billets je serais aussi en faveur d’un truc comme ça (s’il suffisait de claquer des doigts, parce qu’ajouter ça au projet technique qu’est ZdS si c’était moi qui décidais je dirais non, ça ajoute trop de complexité à un projet déjà trop complexe pour l’équipe). Par contre sur les forums non merci.

Je connais pas leur code mais le notre n’est pas très beau.

tu es plus que sévère.

Si tu entends par là « un truc autre que Let’s Encrypt », c’est pas bien. Let’s Encrypt sors de la norme de facto, certes, mais est bien reconnu par les navigateurs et n’empêche pas une très bonne sécurité. La plupart des sites prenant un certificat payant n’utilisent même pas le seul avantage à prendre ce genre de certificat.

Enfin, il y a aussi le coup des wildcards. Mais ce sera bientôt disponible avec Let’s Encrypt, donc c’est un faux problème.

Mais on sors du sujet, là

Ha non pas du tout, Let’s Encrypt c’est très bien et utilisé sur tous mes serveurs.

Je ne sais pas ce qu’ils ont maintenant, mais avant ils avaient un truc obscur qui était réellement sécurisé (il fallait rencontrer des gens IRL pour avoir le certificat) mais presque aucun navigateur ne reconnaissait le certificat. Ça a posé des tas de problèmes et des débats interminables sur le fait de le conserver ou non.

Utilisation de certificats clients ?

J’ai retrouvé : ils utilisaient CACert. Ici le sondage pour décider s’ils devaient changer ou non avec des liens vers les suivis de bugs etc.

Je suis d’accord avec artagis, toutes les boîtes que j’ai fait jusque là avaient des codes bien pire que zds, largement… Nouvelles comparaison d’ici quelques jours mais globalement, pour l’avoir consulté il y a peu, le code de zds est largement lisible et agréable pour une code base de cette taille.