Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Réfléchir au système de commentaires #2

Closed
MoOx opened this Issue May 29, 2013 · 24 comments

Comments

Projects
None yet
6 participants
Owner

MoOx commented May 29, 2013

(Par @mlbli+)
Choisir une interface externe ou construire un système à part entière.

Si l'on part sur un hosting GitHub, cela implique de toute façon que les commentaires soient stockés ailleurs.

Propositions :

  • Disqus
  • NodeJS + Express (hosting Heroku, ou autre ?)
Owner

MoOx commented May 29, 2013

Moi perso je me prendrais pas la tête au début et je commencerais par du Disqus (sachant qu'on peut exporter depuis leur admin si besoin, et que mr tout le monde peut se logguer).
Et sinon on peut pas via l'API Github, mettre les commentaires sur des tickets ?

Contributor

justinmarsan commented May 29, 2013

Si je suis le seul à être réticent au sujet de Disqus, on peut effectivement mettre ça en attendant d'avoir mieux/de voir si c'est utile de changer et quels sont nos besoins...

Owner

MoOx commented May 29, 2013

@justinmarsan Quel sont les problèmes que tu vois avec Disqus ?

Contributor

justinmarsan commented May 29, 2013

Le côté externalisé, mais visiblement il y a plus de fonction admin/export que je ne le pensais, l'apparence du truc relativement gerbante à mon goût, l'inscription ou la connexion via réseaux sociaux, dans l'ensemble j'aime pas en tant qu'utilisateur donc ça me gêne de le mettre en place, mais en même temps il faut rester pragmatique et coder des trucs quand ils sont nécessaires, pas pour rien.

Justin Marsan
hello@justinmarsan.com

Le 29 mai 2013 à 08:35, Maxime Thirouin notifications@github.com a écrit :

@justinmarsan Quel sont les problèmes que tu vois avec Disqus ?


Reply to this email directly or view it on GitHub.

Owner

lionelB commented May 29, 2013

Si on part sur un système externe, je trouve pas mal que les commentaires soit ajoutés au post initial et modérer en utilisant git : chaque commentaire ferai l'objet d'un commit qui serait ensuite ajouté (ou non) à l'article.

Ou sinon dans un doc à part, qui regrouperait la discussion associée à l'article, en suivant le même principe (utilisation de commit pour ajouter un comment)

L'idée étant que la phase d'envoi du commentaire via formulaire et le commit associé soit gérée via une appli node/express

ps : l'idée n'est pas de moi mais de @naholyr

Owner

MoOx commented May 29, 2013

Mouais risquer l'histoire. Si le gas veut modifier, bonjour la galère. Ne serais-ce qu'une typo.

Owner

lionelB commented May 29, 2013

pour moi les commentaire font partis de la ressource (le post), donc je
serais pour les ajouter à la suite du post, d'un moyen ou d'un autre. Et si
c'est pas possible, pourquoi pas une solution genre branch mais qui soit
aussi présent sur le repo

Contributor

naholyr commented May 29, 2013

Disqus, moins prise de tête, moins susceptible de nous poser des problèmes à l'avenir. S'il est possible d'automatiser d'une manière ou d'une autre les backups il faudra le faire pour s'épargner des larmes le jour où ils ferment boutique

Owner

MoOx commented May 29, 2013

👍 pour backup automatisé par contre. Très bonne idée @naholyr.

Owner

MoOx commented May 29, 2013

Tiens là j'ai édité 3 fois mon comment tellement je me relis pas. :)

Contributor

naholyr commented May 29, 2013

Et sinon pour l'idée dont @lionelB parlait je compte la mettre en œuvre sur mon site pro mais c'est plus un PoC qu'autre chose ;) je ne le conseillerais pas en l'état. Le principe est le suivant, et plutôt rigolo pour les techos que nous sommes :

  • Déjà, mettre en place une intégration continue du site (push sur master = rebuild + déploiement), OK facile et de toute façon on le fait toujours n'est-ce pas :P
  • Avoir un petit serveur qui tourne pour recevoir le formulaire de nouveau commentaire (un bête POST, en Ajax si JS est dispo sur le client)
  • Ce serveur va :
    • Créer un nouveau fichier dans <nom-du-post>_comments/ avec les infos du commentaire
    • Créer une nouvelle branche git avec le nom du fichier (UUID en gros)
    • Envoyer la PR sur le repo du site (avec un tag "comment")
  • Les actions d'adminsitration sont donc les suivantes :
    • Pour lister les demandes de modération je regarde les issues avec le tag "comment"
    • Pour accepter un commentaire, je merge la PR (= ça rebuild le site et publie le commentaire)
    • Pour modifier le commentaire, je modifie la PR (il y a ce qu'il faut sur github pour faire ça depuis le navigateur)
    • Pour refuser le commentaire je drop la PR

Voilà, c'est rigolo mais je ne suis pas tout-à-fait convaincu qu'il y ait assez de retour d'xp :P ou même de réflexion pour que ce soit vraiment à conseiller face à un Disqus

Owner

lionelB commented May 29, 2013

en même temps c'est aussi l'occaz d'expérimenter
et 👍 pour le backup automatisé

Contributor

naholyr commented May 29, 2013

A priori c'est possible, il y a une API "exportForum" mais je connais pas trop le vocabulaire Disqus : un forum c'est quoi ? Le site ?

Member

kud commented Jun 1, 2013

Et si on s'en foutait des commentaires ? Et si des PR sur des posts suffisaient ?

Contributor

naholyr commented Jun 1, 2013

C'est un débat à part entière mais mon avis sur le sujet est que les
commentaires (et les discussions associées, pas juste la conclusion des
échanges) portent bien plus de valeur que le contenu lui même. En ce sens
je préférerai toujours un système de commentaires, même imparfait, plutôt
que son absence ou son remplacement par un mode "wiki" bien moins adapté
aux échanges.

Member

kud commented Jun 1, 2013

Je sais pas, les commentaires sont souvent inutiles je trouve et au pire, si le mec a une bonne idée, il soumet une PR sur le post en question.

C'est à en discuter.

Owner

lionelB commented Jun 1, 2013

@naholyr 👍

Owner

MoOx commented Jun 1, 2013

Pas d'accord. Faut que ce soit accessible rapidement. A tous.

Et si on s'en foutait des commentaires ? Et si des PR sur des posts suffisaient ?


Reply to this email directly or view it on GitHub.

Owner

Nyalab commented Jun 2, 2013

Pareil, faire des PR c'est pas le truc le plus simple, niveau workflow déja, et niveau outils aussi (tous les devs ne sont pas habitués à faire une PR, et encore moins pour commenter).

@kud j'ai le même avis que toi sur les commentaires en général, mais faut avoir la foi en notre projet, et se dire que si notre but est de participer à une montée en niveau des devs, les discussions seront intéressantes au moins sur P!

Je suis pour n'importe quelle solution, du moment que ça soit pas trop contraignant pour le visiteur.

Member

kud commented Jun 2, 2013

Pour ma part, je n'ai finalement pas d'avis sur la question. Qu'on mette
des commentaires ou non, ou qu'on fasse des commentaires hébergés par
nous-même ou non.

2013/6/2 Sébastien Balayn notifications@github.com

Pareil, faire des PR c'est pas le truc le plus simple, niveau workflow
déja, et niveau outils aussi (tous les devs ne sont pas habitués à faire
une PR, et encore moins pour commenter).

@kud https://github.com/kud j'ai le même avis que toi sur les
commentaires en général, mais faut avoir la foi en notre projet, et se dire
que si notre but est de participer à une montée en niveau des devs, les
discussions seront intéressantes au moins sur P!

Je suis pour n'importe quelle solution, du moment que ça soit pas trop
contraignant pour le visiteur.


Reply to this email directly or view it on GitHubhttps://github.com/putaindecode/website/issues/2#issuecomment-18806340
.

Erwann Mest

kud.io

Contributor

naholyr commented Jun 2, 2013

Je vote pour le choix de la facilité, Disqus : on peut backuper
régulièrement (et si on voit que ce n'est pas automatisable on changera de
crèmerie avant mise en prod), c'est simple à mettre en place, et les gens
en ont l'habitude.

2013/6/2 Erwann Mest notifications@github.com

Pour ma part, je n'ai finalement pas d'avis sur la question. Qu'on mette
des commentaires ou non, ou qu'on fasse des commentaires hébergés par
nous-même ou non.

2013/6/2 Sébastien Balayn notifications@github.com

Pareil, faire des PR c'est pas le truc le plus simple, niveau workflow
déja, et niveau outils aussi (tous les devs ne sont pas habitués à faire
une PR, et encore moins pour commenter).

@kud https://github.com/kud j'ai le même avis que toi sur les
commentaires en général, mais faut avoir la foi en notre projet, et se
dire
que si notre but est de participer à une montée en niveau des devs, les
discussions seront intéressantes au moins sur P!

Je suis pour n'importe quelle solution, du moment que ça soit pas trop
contraignant pour le visiteur.


Reply to this email directly or view it on GitHub<
https://github.com/putaindecode/website/issues/2#issuecomment-18806340>
.

Erwann Mest

kud.io


Reply to this email directly or view it on GitHubhttps://github.com/putaindecode/website/issues/2#issuecomment-18808450
.

Nicolas Chambrier, aka naholyr

Blog : http://naholyr.fr
Formateur Clever Institut :
http://clever-institut.com/formateur/nicolas-chambrier

Contributor

justinmarsan commented Jun 3, 2013

👍 @MoOx L'idée de base c'est d'apporter quelque chose à la communauté Fr, si on a pas de retours déjà on saura même pas si on atteint notre objectif...

Owner

MoOx commented Jun 3, 2013

Ok donc on partira sur Disqus avec backup automatiser pour le moment.

@MoOx MoOx closed this Jun 3, 2013

Member

kud commented Jun 3, 2013

Je valide.

On 3 June 2013 08:55, Maxime Thirouin notifications@github.com wrote:

Ok donc on partira sur Disqus avec backup automatiser pour le moment.


Reply to this email directly or view it on GitHubhttps://github.com/putaindecode/website/issues/2#issuecomment-18824609
.

Erwann Mest

kud.io

@MoOx MoOx pushed a commit that referenced this issue Jun 10, 2015

@Uhsac Uhsac Merge pull request #2 from Macxim/patch-28
Post: Introduction à Docker — Fix some minor typos
bb155e9

@MoOx MoOx pushed a commit that referenced this issue Dec 1, 2015

@leoderbois leoderbois Merge pull request #2 from Macxim/patch-34
Post: Avantages diviser storyboards —Fix typos
b42975f

@Nyalab Nyalab pushed a commit that referenced this issue Feb 17, 2016

@Uhsac Uhsac Merge pull request #2 from Macxim/patch-28
Post: Introduction à Docker — Fix some minor typos
ff8bd78

@Nyalab Nyalab pushed a commit that referenced this issue Feb 17, 2016

@leoderbois leoderbois Merge pull request #2 from Macxim/patch-34
Post: Avantages diviser storyboards —Fix typos
ffd96d6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment