gasche a écrit 1151 commentaires

J'ai conservé le plus possible les corrections que j'ai effectuées pendant l'installation et elles sont sur mon dépôt gitorious. En particulier j'avais modifié le README en y ajoutant ce que j'ai fait (par exemple quelles étapes j'ai dû lancer en root pour que ça marche bien, et, dans le cas de Redis, le fait que le paquet Debian¹ suffit au lieu de compiler les sources)

¹: sous testing; j'ai oublié de le mettre mais c'est peut-être important car en cherchant sur internet pour un bug que j'avais j'ai découvert qu'une ancienne version de redis avait un problème. Si Nono conseille de compiler les sources c'est peut-être juste pour s'assurer que les gens ont une version récente. Mais je trouve qu'il aurait dû expliquer ce choix peu orthodoxe.

Attention au fait que ce sont des modifications faites "à la rache" dans le but d'avoir un truc qui marchotte en le moins de temps possible. Bruno a repris certaines des modifications proposées, mais pas les autres. J'imagine que ce n'était pas la bonne façon de faire; par contre j'ai l'impression qu'il a oublié/négligé/ignoré un bug et une modification un peu plus importante pour le corriger en profondeur. Je ne sais pas si c'est parce que ce n'était pas bien, ou qu'il a jugé ça peu clair ou inutile, mais je n'ai pas eu de retours là-dessus.

Edit: merci pour tes félicitations.

Quand on veut modifier le code, on clone le dépôt et on commence à hacker. On ne vient pas chercher sur le wiki de LinuxFR si par hasard il y aurait de la documentation sur le code.

Ce document devrait être dans le dépôt des sources, tout comme le README actuel; à la racine ou dans un sous-répertoire doc/.

Après un petit intermède publicitaire, la discussion reprend dans le journal créé à cet effet. Merci pour votre participation !

Je peux reformuler l'argument "pouvoir corriger quand on veut est la façon la plus pratique de faire" ainsi : le principe d'un site de discussion est de supposer que quand les membres créent du contenu, c'est positif, ils apportent quelque chose.

Permettre d'éditer leur permet de créer du contenu de façon un peu plus incrémentale; il y a des gens qui n'ont pas besoin de cette flexibilité supérieure, ils écrivent une fois, se relisent, et n'ont jamais envie de retoucher ensuite, mais il y a aussi des gens que ça aide, car ils pensent après-coup à des façon de simplifier, mieux structure leur propos (sans changer le sens de l'ensemble pour ne pas perturber la conversation; c'est du bon sens).

Si tu supposes que laisser les gens apporter leur contenu (dans les commentaires) est positif, il me semble naturel de considérer que les laisser en améliorer la forme à volonté est positif aussi.

Celui-ci a été intégré quasiment immédiatement, en l'adaptant un peu à la culture et la philosophie générale du site.

Je te pose la même question qu'à 'moules' : en quoi le fait de ne pas pouvoir éditer ferait partie de la "culture" et de "la philosophie générale" d'un site, plutôt qu'une simple limitation technique qui n'a jamais été levée par manque de temps ou de motivation ?

Je ne comprends pas l'argument "c'est bien parce que c'est vieux", "c'est bien parce qu'on a toujours fait comme ça". En quoi est-ce bien de ne pas pouvoir éditer ses messages ?

Par ailleurs je trouve que ta lecture de la situation est un peu simpliste : le changement n'a pas été "intégré en adaptant ...". Il a été intégré, et ensuite des gens sont venus râler pour demander de l'adapter pour des raisons qui ne me semblent pas tenir debout : on parle de risques d'abus, mais comme je l'ai dit il n'y a eu aucun abus constaté, et d'ailleurs vous passez votre temps à me dire que cette fonctionnalité n'a jamais été disponible, comment alors pouvez-vous savoir à l'avance qu'il y aura des abus ?

Contrairement à beaucoup d'autres, tu as le mérite de ne pas avoir juste gueulé.

Rassure-toi, j'ai commencé par juste gueuler :)

Je suis d'accord sur le fait qu'un code n'a pas nécessairement à être adopté tel quel. Ce que je dis ce n'est pas qu'il doit être adopté par principe, mais que le comportement qu'il mettait en place était meilleur que celui qui a été ajouté ensuite.

Que tu considères l'édition des commentaires comme une bonne chose sur d'autres sites parce qu'ils ont choisi ce fonctionnement, pourquoi pas, mais sur DLFP le mode de fonctionnement a toujours été que les contenus soient statiques une fois publiés.

Oui, mais pourquoi ? Ce n'était pas juste une limitation technique du site ? Je ne vois pas d'argument de fond.

Et dans ce cas, comment pouvez-vous être si sûrs qu'il va y avoir plein d'abus ?

Je ne saisi pas l'intérêt, autant faire un commentaire à la fin qui regroupe ça, c'est plus clair pour tout le monde.

L'intérêt c'est de mettre à jour régulièrement pour que les nouvelles personnes sur le thread aient accès à un condensé. Dans mon exemple ça permet par exemple aux gens de savoir facilement si le lien auxquels ils pensaient a déjà été posté.

La notion de "à la fin" n'a pas de sens sur une discussion internet où des gens peuvent rajouter un message à tout moment. Techniquement je crois que sur LinuxFR on ne peut pas commenter le vieux contenu (ce que je trouve assez discutable comme choix mais c'est un autre débat), mais ton idée d'attendre de s'assurer que plus personne ne va participer à une discussion pour aller poster un récapitulatif est assez curieuse : à qui servira-t-il ?

Pourquoi vouloir absolument attendre qu'il y ait des problèmes pour lutter contre alors qu'il n'y a pas vraiment de bonne raison pour laisser l'édition libre.

Pourquoi attendre qu'il y ait des problèmes ? Parce qu'avant de s'embêter à faire des changements dans le code, il faut s'assurer que les besoins sont réels. Personnellement je doute qu'ils le soient : tous les sites de discussion que je fréquente à part LinuxFR permettent l'édition des commentaire, à ma connaissance aucun d'entre eux n'implémente d'historique compliqué, et je n'ai jamais rencontré de situation où ce soit vraiment problématique¹.

Il n'y a pas de bonne raison ? Bien sûr qu'il y a une bonne raison. C'est la façon la plus pratique de faire (on peut corriger quand on veut). En plus ça me fait plaisir.

¹: un jour un gars est parti d'un site en claquant la porte et a balancé un script web pour effacer tous ses commentaires en les éditant avec un message vide. Je n'ai vu ça qu'une seule fois, et sur le moment je me suis plutôt dit "Bon débarras" (indépendamment du fait qu'il était convaincu qu'en raison de la loi sur les œuvres de l'esprit blabla on n'avait pas le droit de l'empêcher de retirer ses commentaires; je ne pense pas que ce soit légalement valide mais moi s'il veut supprimer son propre contenu, du moment que tout le monde n'est pas caractériel à ce point...).

Je trouve ça assez fort de café quand même, je me fatigue à implémenter une fonctionnalité que je trouve importante et, sous prétexte que vous imaginez tous les abus possibles et imaginables, on se retrouve à la mutiler en la rendant nettement moins utile.

La meilleure solution parmi les solutions proposées est clairement d'avoir un historique complet des commentaires. Je pense que nous sommes d'accord là-dessus et ça ne me dérangerait pas du tout que ce soit mis en place. Mais je pense que la solution précédente (édition libre sans historique) est meilleure que la solution actuelle (édition bridée de façon arbitraire).

Je pense que ça en dit long sur la communauté de LinuxFR : je fait des efforts pour que soit rendue disponible une fonctionnalité permettant d'améliorer le contenu du site, en permettant aux gens de corriger leurs fautes, de changer leur formulation etc., et tout ce que les gens y voient c'est les possibilités d'en abuser pour emmerder les autres participants...

Edit: et zut aux gens qui ont moinssé mon premier post.

Je ne comprends pas l'intérêt de restreindre une fonctionnalité utile en raisons d'abus imaginaires. Est-ce que l'un de vous a déjà observé un comportement abusif tel que décrié ici ?

Pour ma part il m'arrive relativement fréquemment de relire un commentaire après qu'on y ait répondu (en vrai c'est souvent le moment où j'ai le plus tendance à le relire) et cette restriction limite donc l'usage de l'édition.

Elle ne permet pas non plus certains modes d'utilisation très utiles de l'édition, tels que : "proposez moi des liens vers 'truc' en réponse à mon commentaire, j'éditerais le commentaire principal pour montrer une liste bien structurée des propositions vérifiant 'tel critère'".

Je pense qu'avant d'ajouter des restrictions arbitraires, il faudrait s'assurer que les hypothèses conduisant à leur mise en place sont belles et bien vérifiées. J'attends vos liens vers un commentaire édité abusivement.

PS: sur les forums n'ayant pas d'historique, quand quelqu'un dit quelque chose de limite, il est souvent quoté par d'autres gens qui lui répondent sur ce point. Ça limite beaucoup la possibilité d'éditer pour cacher la chose.

Je ne suis pas du tout d'accord. Une preuve mécanisée c'est exactement comme du code source; prouver en Coq ou en Isabelle, c'est programmer. Par ailleurs publier un résultat scientifique sans en donner la preuve, c'est extrêmement discutable ne serait-ce que du point de vue de la rigueur et de la méthodologie scientifique.

D'un point de vue de logiciel ça correspondrait à distribuer un exécutable en refusant de donner les sources : tu as le résultat mais pas la façon de faire. On pourrait donc utiliser la même argumentation pour dire que "le code doit exister quelque part mais ne donnera pas plus de valeur à l'application; l'exécutable est suffisant". Je ne suis pas d'accord dans le cas logiciel, je ne suis pas non plus d'accord pour une preuve.

D'ailleurs c'est encore pire parce qu'au moins un logiciel on peut le tester pour vérifier qu'il a bien les fonctionnalités demandées. Ici c'est encore pire parce que sans la preuve on n'a aucune garantie que la preuve a bien été réalisée. À la rigueur ils pourraient dire "on a prouvé" alors que la spec. est inconsistante et on n'aurait aucun moyen de le savoir. On fait confiance aux gens qui le disent donc on ne pense pas ça, mais fondamentalement ça reste un choix de croire les gens aveuglément (sans voir la preuve), ce n'est pas une démarche scientifique respectable.

Je pense qu'on a eu tort d'accepter de publier leur résultat avant qu'ils ne donnent la preuve.

C'est pas un peu compliqué tout ça ? Je ne vois pas trop l'intérêt de mettre en place une machinerie compliquée et de forcer tout le monde à être présent de façon synchrone alors qu'on peut déjà poser des questions et y répondre sur le site lui-même.

Pourquoi ne pas simplement créer une dépêche ou un journal "méta" "discussion de l'espace de rédaction" ?

Dans cette comparaison, le plus "horrible" des trucs fermé est GitHub, faut d'alternative compatible avec son API, mais chut, hein, GitHub est forcément plus sympa avec les libristes que Windows... euh... Non, quand on regarde, en fait. Mais ce n'est pas un mal, on choisi en fonction de ses priorités, c'est tout.

En pratique les gens de Github sont assez cools, ils libèrent une partie des trucs qu'ils développent en interne, et proposent des outils pour migrer ses données (bugs, wiki) pour ne pas être enfermé chez eux (par contre effectivement ça ne rend pas portable les outils développés pour leur API; mais ça me semble être difficilement de leur faute).

Si j'évite d'utiliser github et si j'encourage les gens à envisager une alternative libre ce n'est pas parce que je trouve le service proposé de mauvaise qualité ou que je n'aime pas les gens qui le développent, c'est parce qu'il est propriétaire.

(Ça ne contredit bien-sûr pas ton argumentation d'ensemble que je soutiens.)

Une remarque au sujet de Github, un peu hors-sujet mais qui peut intéresser des gens. Il y a une différence entre créer un projet soi-même (on est libre de choisir l'hébergement qu'on veut) et participer à un projet avec d'autres gens qui ont déjà fait un choix d'hébergement (par exemple Github).

Au début j'avais fait le choix suivant : créer mes projets persos sur un hébergeur libre qui me convient, Gitorious, et par contre quand je participe à un projet commun utiliser le service déjà en place pour ne pas incommoder les autres contributeurs (l'idée étant que c'est plus pratique pour eux d'utiliser la fonction de pull local plutôt que de se fatiguer à comprendre comment obtenir mon répertoire sur Gitorious qu'ils ne connaissent pas). Je me suis donc retrouvé à utiliser Github pour certains projets, Bitbucket pour d'autres, etc.

C'est un choix que je regrette aujourd'hui. À chaque fois que je donne l'adresse d'une de mes branches de ces logiciels sur Github ou Bitbucket, j'ai l'impression de faire malgré moi la promotion d'un outil qui est en désaccord avec mes principes de développement. Ces outils se construisant sur l'effet réseau, les utiliser et en parler leur donne effectivement plus de poids par rapport aux services libres correspondant.

Dorénavant j'essaierai d'héberger systématiquement mes forks sur un outil libre, en essayant de minimiser l'inconfort pour les membres du projet utilisant un autre outil (en théorie avec les CVS décentralisés l'inconfort peut être réduit à un coût négligeable).

Ça pose par ailleurs une question très gênante dans le cas de Bitbucket. Pour Git, Gitorious est une bonne alternative à Github, mais pour Mercurial il n'y a pas à ma connaissance de service d'hébergement public facile d'accès et de qualité. C'est la raison pour laquelle j'évite d'utiliser Mercurial, qui par ailleurs est un très bon outil que j'aurais tendance à conseiller aux débutants car il est réputé plus facile à prendre en main que Git. (Pour darcs il y a patch-tag qui est libre.)

Pour moi tu mélanges aussi développement et exécution : quand je dis qu'on peut utiliser Windows pour le développement et GNU/Linux (ou BSD ou quoi) pour l'exécution tu me réponds "oui mais on est parti du présupposé qu'on utilisait un seul système". Or utiliser un système pour le développement et utiliser un système pour l'utilisation c'est très différent.

Bref je suis moi aussi un peu perdu dans ton argumentation et je ne vois pas où tu veux en venir. Pour moi utiliser un OS propriétaire pendant le développement, et un hébergeur de code propriétaire, c'est du même ordre d'idée. Tu semblais penser que seul Zenitram avait cet avis et qu'il était borné et ne lisait pas ce que tu dis; j'apporte un témoignage du fait que son opinion est partagée, et que même avec de la bonne foi et en lisant tes messages avec soin je ne suis pas convaincu par ton argumentation.

L'aspect "je vais te pourrir" était en fait humoristique, mais l'humour ou l'ironie passe très mal par écrit (et en plus c'était pas drôle, ok) donc je comprends que ça ait été pris au premier degré.

J'aurais dû dire un truc "ça te va si je t'offre une bière si tu le fais ?" qui est moins sujet à mésinterprétation. D'ailleurs l'offre tient.

Tu auras donc besoin de Windows chaque fois que tu veux utiliser le programme.

Je ne comprends pas. On pourrait développer un programme portable sous Windows et l'utiliser sous GNU/Linux, non ?

Ce que je voulais dire par "il n'en dépendent pas" c'est qu'ils pourraient tout aussi bien (s'ils sont portables, bien sûr) tourner sur un OS libre.

Je ne fais pas l'apologie du développement sous Windows, je trouve que c'est pas terrible (après si les gens en ont envie hein ils ont le droit), mais il me semble que pendant l'acte de développement l'OS sous-jacent est un outil comme les autres, tout comme l'éditeur de texte, le logiciel qui implémente le langage (compilateur etc.), le gestionnaire de version, et les services webs utiles au développement (dont l'hébergeur de code source). C'est certainement un outil qui est plus fondamental, c'est peut-être un outil qui a plus d'importance pendant le développement (que l'hébergement sans doute, que l'éditeur de code source et l'environnement de développement sans doute pas), mais tout cela est bien subjectif.

C'est pas à prendre comme une menace ou quoi (tout le monde s'en fout et tout le monde a bien raison) mais ouais, je l'ai déjà envisagé. Pour l'instant la pulsion de troller est plus forte que la contrariété provoquée par l'interface, donc il n'y a pas trop de danger.

Par contre je trouverai un moyen de continuer à lire tes dépêches de sortie de noyau, qui sauf exception (troll juteux sur les langages de programmation) sont les seules qui me retiennent vraiment sur LinuxFR ces derniers temps. J'en apprends un peu moins depuis que je me suis payé un abonnement à LWN.Net et que donc je me force à lire la newsletter, mais c'est toujours un régal (et en vrai il y a beaucoup de choses traitées sur LWN et pas dans tes dépêches ou inversement).

Pour autant que je sache, gitorious ne propose absolument pas de mode décentralisé. Si un projet est sur une instance A, je ne peux pas proposer de pull requests depuis une instance B. Ai-je tord ?

Je ne pensais pas à ça, mais plutôt à fragmenter selon les projets. Par exemple Qt et tous ses forks sur un serveur, mes projets sur un autre serveur, etc.

Ceci dit si l'utilisation de gitorious "en mode décentralisé" venait à se répandre, on pourrait ajouter une fonctionnalité pour faire ce genre de choses.

Edit : j'ai oublié de mettre le lien vers l'entrée du suivi

Concrètement comment faire monter le nombre de votes pour cette entrée de suivi ? Il faut donner le lien dès que j'en ai l'occasion pour encourager les gens à voter, et si possible lancer une discussion pour attirer l'attention.

C'est ce que je suis en train de faire.

Je peux faire ça. La raison pour laquelle je ne l'ai pas fait est que je pense que ça nous prendrait moins de temps à tous les deux si Bruno s'en occupait lui-même. Par exemple rédiger une doc sur l'ensemble de gitorious est beaucoup plus coûteux en effort que répondre à des questions ciblées sur l'interface.

Pareil pour cette histoire d'édition des commentaires, je pourrais coder cette fonctionnalité et soumettre le patch, et Bruno n'aurait qu'à l'accepter. La raison pour laquelle je ne l'ai pas fait est que ça me demande de déployer Rails en local, comprendre le code de LinuxFR, trouver où faire les modifications nécessaires et comment tester le résultat après-coup avant de proposer le patch. La discussion dans le suivi semble indiquer que ce serait beaucoup plus facile pour Bruno, puisqu'il sait quelles sont les modifications à faire et a déjà, j'imagine, un environnement de développement et de test déployé. Il y a donc une grande asymétrie entre moi à qui ça demanderait beaucoup de travail et lui pour qui c'est facile.

La démarche la plus économe en temps si ce qu'on essaie d'optimiser c'est notre temps à tous les deux est de lui demander de le faire. C'est ce que je fais ici. Si ça ne marche pas, j'essaierai autre chose (le faire moi-même, ou arrêter de commenter sur LinuxFR parce que je suis trop frustré par l'absence de cette fonctionnalité).

Bien sûr, je demandais seulement si les demandes insistantes d'un utilisateur faisait partie de ses sources de motivation. Ça ne s'appelle pas "être à mes ordre". Moi quand un utilisateur m'envoie un mail pour me demander d'ajouter une fonctionnalité à un de mes programmes, ça me motive pour l'ajouter. Ca ne me motive pas forcément assez pour que je l'implémente effectivement; souvent ce qui me démotive c'est le fait qu'ils demandent sans intention réelle d'utiliser le logiciel. Pour ma part j'"utilise" linuxFR depuis des années, j'ai le sentiment d'y apporter du contenu de temps en temps, et j'aurais besoin de cette fonctionnalité quotidiennement ou presque.

Bref je ne vois pas en quoi ma question était choquante.

Mais ces fonctionnalités ont déjà été développées pour le wiki et la zone d'édition. Sur le suivi, un développeur disait que les activer pour les commentaires ne serait pas très difficile techniquement.

Si je t'envoie des mails régulièrement en te demandant de t'occuper de la migration et en essayant de répondre à tes questions sur l'interface, c'est susceptible de te motiver ?

J'ai le droit d'insister lourdement sur la possibilité d'éditer des commentaires, dans ces mails de rappels ? J'ai l'impression que là aussi tu manques de motivation.

Un des très gros avantages de GitHub et Gitorious, c'est le nombre d'utilisateurs. Héberger son projet sur ce genre de site permet d'avoir plus de contributeurs potentiels (la facilité de faire un fork/clone, meilleure visibilité…). Sur ce point, GitHub a -- il me semble -- une plus grande communauté.

Beaucoup d'utilisateurs ne veut pas dire beaucoup de gens qui n'ont rien à faire d'autre de leur temps que de contribuer à tes projets parce que leur présence sur Github leur donne soi-disant plus de visibilité. C'est comme dire qu'un skyblog sera plus lu qu'un blog perso parce que la plateforme a plus d'utilisateurs. Bof.

En pratique est-ce que des gens qui ne viennent pas de LinuxFR ont contribué au code du site ?

Justifier l'utilisation d'outils propriétaires par un effet réseau peut être compréhensible ("tous mes amis utilisent MSN"), mais je ne pense pas que ce soit tellement vrai dans ce cas. Et je trouve dommage que les libristes se disent ça et contribuent à créer un monopole par cette pratique...

Par contre, pour faire revivre le site, il faut déjà des serveurs assez puissants, une très bonne bande passante, etc.

Tu dis ça parce que tu as essayé ou parce que tu l'imagines ? Pour proposer gratuitement à tout le monde d'héberger son projet, il faut de la bande passante, mais si on avait un réseau de serveurs gitorious décentralisés gérant chacun un petit nombre de projets, ça me semble très raisonnable.

En pratique il y a des gens qui font tourner un serveur Jabber chez eux pour leurs potes, et il y a aussi des gens qui utilisent gitorious en local.

Est-ce que Gitorious explique vraiment comment leur infrastructure est organisée, les scripts qu'ils ont écris pour la maintenance, et tout ce genre de choses ?

La doc est assez mauvaise paraît-il mais ouais, c'est fait pour qu'on puisse déployer chez soi, et des gens l'ont fait. Il suffit de chercher sur google "install gitorious" pour trouver un certains nombre de retours d'expérience.

Je suis tout à fait d'accord avec Zenitram ici : pour moi utiliser Windows pour développer son programme et utiliser Github pour héberger son programme c'est du même ordre d'idée. Dans les deux cas il s'agit d'outils propriétaires utilisés pendant le développement.

Nous sommes d'accord mais nous conclusions sont différentes en raison de priorités différentes : il choisit de maximiser la qualité technique (en tout cas telle qu'il la perçoit) de ses outils aux dépends de leur liberté, et moi je choisis de prendre en compte la liberté de façon très importante, déterminante (mais la qualité technique entre aussi en compte, il y a un seuil d'acceptation). Lui trouve Windows et Github acceptables et moi je trouve Windows ainsi que Github discutables, à partir du moment où il existe une alternative "raisonnable" (c'est à dire "au moins presque aussi bien"). GNU/Linux (ou un BSD) et gitorious me paraissent entrer dans ce cadre.

Xavier, tu fais une différence subtile entre "utiliser pendant le développement" et "utiliser à l'exécution". Mais pour moi ça n'a pas d'importance dans le sens où :
- Il me semble discutable de dire que les programmes d'un langage portable "utilisent" l'OS sous-jacent pendant l'exécution. En tout cas ils n'en dépendent pas.
- Quand on développe un logiciel destiné à l'ensemble des utilisateurs (donc pas strictement à ses besoins personnels), exécuter le programme sur sa machine entre souvent dans le cadre du développement. Si j'écris un logiciel sous windows qui est surtout utilisé par des GNU/Linuxiens, le programme est développé (et testé) sous windows mais au final il est utilisé sur une plateforme libre.

Je ne vois pas l'intérêt de cette différence, qui me semble bien faiblarde, et à mon avis elle n'excuse en rien l'utilisation d'outils propriétaires quand on peut s'en passer, surtout dans le cadre d'un développement qui a aussi une portée symbolique (un site sur le libre).

J'ai lu l'argumentaire de Karl Fogel (quatrième question) et il ne me convainc pas. Ses arguments :
- "Vous utilisez aussi le moteur de recherche de Google qui est propriétaire"; oui mais si je connaissais une alternative libre répondant à mes besoins ("raisonnable") je l'utiliserais. Et l'utilisation d'un outil propriétaire ne justifie pas l'utilisation d'outils propriétaires supplémentaires ! Au contraire il faudrait limiter leur nombre tant que possible/raisonnable.
- "si le code de Google Code était disponible, vous n'auriez pas l'infrastructure pour le faire tourner chez vous de toute façon"; l'argument classique du "oui mais on ne lit pas le code de toute façon donc on s'en fout", tout aussi mauvais que d'habitude. D'ailleurs de nombreuses personnes hébergent un gitorious sur leur serveur.
- "Ok launchpad permet de leur envoyer des patches mais il est soumis à leur approbation avant d'être mis en production"; j'ai vraiment besoin de préciser que cet argument est nullissime ?
- "Tout ça c'est trop compliqué, admettez votre défaite, choisissez un service qui est bon techniquement et fermez votre gueule, on est à l'ère de l'agriculture et de l'urbanisation ma bonne dame"; toi tu manquais vraiment d'arguments...

Bref, une attitude défaitiste : "oui mais tout le monde utilise github alors on l'utilise, tant pis si c'est propriétaire". Lesquels des outils libres que l'on utilise quotidiennement aujourd'hui existeraient si une telle mentalité avait toujours été appliquée ?

Oui. Je ne vois pas trop le problème que ça peut poser. Je sais qu'il y a plein de paranoïaques qui croient que c'est la porte ouverte aux éditions malicieuses (dire le contraire de ce qu'on a dit, etc.) (je ne dis pas que c'est ton cas, juste que ça revient souvent dans la discussion) mais en pratique sur tous les sites que je connais ou presque c'est comme ça et le problème ne se pose jamais.

Le mieux c'est d'avoir accès à l'historique d'édition complet pour chaque message, comme sur wikipédia; c'est la transparence garantie. Mais en pratique pour les commentaires c'est un peu gadget alors une simple fonction "éditer" sans historique suffit (et éventuellement mettre en bas un petit message "message édité à telle heure" peut être utile).