Raison du rejet d'une news Human Coders

[Xenos]

Salutations,

Le système de modération avant publication d’un lien sur Human Coders News est top: on est ainsi sûr d’avoir des liens de qualité et de ne pas avoir de spam de robots.

Mais j’ai soumis une news Dimanche dernier, qui me semblait respecter les règles de soumission. Or celle-ci a été rejetée, et aucune raison n’est fournie dans l’email. Si on ne veut pas que je soumette d’autres news qui seraient de nouveau refusées pour les mêmes raisons, alors il me semble pertinent d’ajouter une raison au refus de chaque news? A terme, cela allègerait même le travail de modération, puisqu’un utilisateur (de bonne foi!) ne renverra alors plus de news qui tomberait dans la même catégorie de refus. Est-ce possible?

PS: si vous souhaitez le lien de la news pour me dire directement la raison du refus de celle-ci, je peux le faire. Mais cela me semblerait bien de généraliser le processus pour tout le monde.

[camilleroux]

Salut @Xenos,

C’est moi qui modère en général et j’ai effectivement oublié de mettre un raison de refus.
Je l’ai refusé, peut-etre à tord (on peut en parler avec plaisir), car j’avais l’impression que l’article proposait des méthodes pas très actuelles à coup de FTP, de backup à la main, de Rsync…
Je veux bien ton avis :)

[Xenos]

OK
Je ne sais pas si on en parle ici, ou ailleurs (si ailleurs, n’hésite pas à me dire où)… En fait, ces méthodes sont peut-être “simplettes”, mais elles collent parfaitement à pas mal de projets amateur (genre ceux qu’on voit sur https://jeuweb.org/). Si tu en as d’autres en tête, n’hésite pas à me les citer, que je les intègre à tout ça, en détaillant à qui elles sont adaptées.

Rsync n’est pas dans l’article, et le FTP fait justement partie de l’intro: c’est souvent ce sur quoi se reposent les créateurs amateurs (les hobbyistes, c’est pas péjoratif) et ce n’est généralement pas suffisant. Et encore, ça, c’est quand ils pensent à garder une copie de leur data (souvent, ce n’est pas le cas, et pouf, le projet disparait du jour au lendemain). D’où les pistes un peu plus automatisées, qui ne s’étendent pas forcément bien au travail d’équipe, mais qui collent impec’ au travail solo (et pas mal de monde chez les dev doit être dans cette catégorie…) D’autant que le travail d’équipe, par définition, limite les pertes (à moins que tous les membres de l’équipe ne se fassent voler/griller leur PC en même temps, il en restera bien 1 qui aura une copie du projet, du code, des plans de conception, etc) alors que le travail solo ne le limite pas. D’où un article sur les méthodes adaptées pour ces travaux solo ;)

Side note: perso, “l’âge” de la méthode m’importe peu et comme la notion de backup est probablement aussi vielle que l’informatique, cela ne m’étonne pas que ces méthodes n’aient que peu changées. Surtout que pour du backup, donc de la tenue dans le temps, je trouve plus intéressant d’avoir une “ancienne” méthode éprouvée que la dernière sortie. Après, je le répète: si t’as d’autres méthodes en tête à citer, je suis preneur.

[camilleroux]

N’arrivant pas à argumenter clairement, j’ai décidé de publier l’article. On verra s’il y a des commentaires :)

Ce que je me disais c’est que j’ai plus envie de voir des articles avec des systèmes de backup automatiques, du devops, des outils comme Github et Gitlab…
Typiquement ce forum est hébergé sur DigitalOcean, il est backupé régulièrement automatiquement et l’activation de l’option se fait en cliquant sur un bouton.