[RFC] New avent page

[Nek-]

For 2019 it could be awesome to not have to commit HTML as always. For that we have 2 solutions:

1. Using markdown files, this way it's easy to upload files aside, but also to review thanks to pull usage of pull request. But this need somebody to release everyday the application. (but thanks to the migration to SymfonyCloud, it should be easy...)
2. Creating a new backend for avent-articles (markdown based) but also following features: draft, comments on drafts (with status new/fixed and eventually a related line), upload files feature (media manager) and roles management (so we allow only avent-members to write on their year and their own article).

Please vote 👍for 1 or 🚀 for 2. (if you add why in a comment, it helps)

It would be also nice to have a comment section this year, please give suggestions for a solution, and why you recommend this one.

J'ai écris ce post en anglais mais ça n'a aucun sens; sentez vous libre d'y répondre en français. >.>'

Note: la situation a changé, historiquement nous avons voté 1. Etant la personne qui va gérer les articles, il est hors de question de refaire une année sur l'ancien système. D'un façon ou d'une autre, on va arriver au second point.

[pimolo]

tl;dr: à mon avis ni l'un ni l'autre, on s'intègre à un outil externe ou au pire on upload son article.

Ayant fait des review pour le calendrier de 2017 et publié quelques articles je vous donne un peu mon ressenti :

Pourquoi je ne suis pas pour une review sur GitHub :
Je ne suis pas super fan de la review du markdown sur une PR. Ca fonctionne mais c'est assez lourd car c'est naze en terme de lisibilité : c'est bien pour review du code mais pour des articles...
C'est assez frustrant de gérer les lignes de 150 caractères et le scroll horizontal, ou bien switch entre la vue raw (pour commenter) et la vue formattée (pour lire), avec la position du scroll vertical reset à chaque fois.
Et puis finalement, une fois que la PR est envoyée c'est que l'article est à peu près bouclé, donc l'historique (git) a peu d'intérêt à ce moment là à mon avis.

Et devinez quoi, le fait que la review soit aussi lourde à faire (sans compter les allers-retours), et bien au bout de 20 jours, ça dégoûte un peu...

Pourquoi je ne suis pas pour une édition sur backend :
En vrai ça peut faire le taf mais on a régulièrement des articles écrits en duo, donc ces auteurs là vont rapidement se diriger vers des éditeurs de markdown collaboratifs (et ça va devenir un peu plus complexe à gérer nous même). Et de toute façon des éditeurs markdown il en existe pléthore, avec une UX probablement meilleure qu'un éditeur qu'on fera nous même en 3 semaines, ce qui me fait une super transtition sur...

Ma proposition :
Je pense qu'un bon compromis serait une intégration avec un outil comme https://hackmd.io, ou Google Docs (-like), en gros :

• un outil collaboratif
• dans lequel peut faire des commentaires directement
• avec un système de versionning

Et pour la publication, là ok pour un mini backend, comme une page formulaire dans lequel on choisit entre une intégration API ou un file upload en fallback (pour ceux qui préfèrent gérer ça de leur côté) avec un champ date de publication, page gérée par les admin après s'être renseigné auprès de(s) auteur(s).

Pour la section commentaires, Disqus ça fait le taf non ?

voilà voilà, vous en pensez quoi ?

(j'allais oublier : avec SymfonyCloud c'est peut-être plus simple, mais sauf erreur ça nécessite quand même une présence physique devant son ordi tous les jours du mois en fin de soirée pour lancer le déploiement, et c'est une contrainte dont il serait bien de se passer)

[nayluge]

Je vote 1 👍 ou rester sur l'actuel :

• Il reste peu de temps mine de rien
• Github propose les outils de reviews nécessaires
• Les branches de features sur SymfonyCloud permettront de tester facilement visuellement parlant.
• On peut merger quand on veut, les articles futures sont déjà masqués.

Et pour rester sur l'actuel:

• Ca va, faire de l'HTML c'est quand même pas si contraignant ...

[Nek-]

I'm in favor of old behavior, but with markdown. So we will still write new pull requests, but with markdown.

I think this is an acceptable improvement.

[Nek-]

Note: on va développer 2 si il y a un calendrier de l'avent. Contexte : https://groups.google.com/g/asso-afsy/c/8HO2MLKJjQc/m/Sco5iY-FBgAJ