Roadmap et priorités à moyen terme

Salut,

Avec le lancement de la bêta, je pense qu'il est vraiment nécessaire qu'on adopte une stratégie claire pour le traitement des issues (suggestions, rapports de bugs et régressions), et qu'on le fasse très vite, parce qu'à compter de ce jour, nous n'allons plus avoir de répit jusqu'à ce que la V1 soit stable.

Ça veut dire qu'il faut qu'on décide de trois choses :

1. des guidelines pour définir la priorité des issues lorsque l'on va y répondre sur le forum Suggestions,

2. d'autres guidelines, cette fois pour classifier les tickets dans trois grosses catégories :
   Bloquant bêta publique : à réaliser impérativement avant le reset de la BDD et le lancement de la bêta publique ;
   Bloquant V1 : à réaliser impérativement avant la fin de la bêta publique et le lancement de la V1 ;
   Post-V1 : à faire, mais pas avant la sortie de la V1

3. Les priorités relatives des nouvelles features et des évolutions.

Voilà ce que je vous propose :

Freeze!

Concernant le point 1., je vais certainement énoncer une évidence que tout le monde pense tout bas et tient comme acquise, mais il faut qu'elle soit écrite clairement quelque part :

Plus aucune nouvelle feature/évolution ne doit être implémentée. Le gros de l'effort doit être concentré sur la correction des bugs et des régressions, pour essayer de sortir la V1 la plus stable possible. Toute nouvelle fonctionnalité est donc à classer automatiquement en Post-V1.

Du coup, la classification des issues concerne exclusivement les bugs et les régressions.

Le "Rush bêta"

Étant donné que nous sommes en bêta, tout le monde est déjà en ébullition et il est évident que les devs s'occupent des issues non-coûteuses à la volée au fur et à mesure qu'elles se présentent, avec une forte réactivité : c'est génial, profitez de cette vague de motivation, ne changez rien, mais attention toutefois à bien différencier les bugs et régressions des nouvelles fonctionnalités, et à ne pas clasher avec le principe du freeze.

En dehors de cette déferlante naturelle de productivité, je propose la classif suivante :

• Le bug rend une fonctionnalité vraiment inutilisable, ou pose un problème de sécurité : Bloquant bêta publique
• Le bug n'est pas exceptionnellement handicapant, mais il est fréquent et "trop" visible : Bloquant V1
• Les autres bugs : Post-V1

L'après-bêta : la roadmap

Enfin, je propose que l'on se serve de ce thread pour établir une liste des nouvelles fonctionnalités que l'on souhaite particulièrement voir venir peu après la sortie de la V1, et qu'on les classe par priorité. Je les consignerai dans un joli tableau sur ce post au fur et à mesure de la discussion pour les rendre visible au-delà du GH.

Qu'en dites-vous ?

Pluzain

Pour classifier les tickets, on pourrait faire 3 milestones, et tout classer, depuis le début

C'est justement ce que je comptais faire ce week-end.

Merci Kje.

Si je résume, pour le markdown ça nous fait :

• 2 bugs Bloquant Bêta
• 2 tâches Bloquant V1 (Travis pour toi c'est "pour la v1", donc avant la milestone, c'est bien ça ?)
• 3 tâches Post-V1

Je mettrai le PO à jour avec un tableau ce soir.

Oui :

• La majorité des prob de légendes et citations et plantage avec les vidéo a faire rapidement.
• les légendes sur les figures en V1. J'avais mis test et travis aussi mais je vais peut etre te proposer de le mettre en premiere tache post v1 (voir plus bas).
• les mentions, la refonte des exports et le refacto du code, en post v1.

En réalité il y a une autre tâche. Pour éviter des conflits, en particulier sur le forum, il va falloir que le site fournisse un id/prefix pour chaque parsing. Celui-ci sera utilisé pour pré-fixer les éléments de référence. Par exemple les notes de bas de pages (et éventuellement ajouter des ancres sur les titres). Car actuellement si deux postes ont les mêmes note de bas de page, les références sont identique et c'est pas top. Donc ça serait bien que ce soit fait avant la v1 pour éviter des invalidations de liens qui seront difficiles à détecter et corriger une fois le site sorti.

Puisque je me rajoute une tache en bloquant v1, je prefere repousser travis en post v1. Car il est possible que d'autres bugs chiant viennent apparaitre pendant les beta. Or je n'ai pas beaucoup de temps en ce moment. Par contre ce sera la premiere tache en post v1, les tests serviront de références pour éviter les regressions lors des futurs changements.

Concernant citation, code et tableau, il y a peut-être un impact sur le md généré à partir du zCode, donc j'aimerais que ce passage soit éclairci :

Est-ce qu'il faut un saut de ligne entre un bloc et sa légende, ou pas ?

Si oui, et que c'est bloquant V1, je dois le savoir dès maintenant (je vais me ballader en Italie et dans le sud de la France du 15 au 29 juin, aucune connexion internet fiable).

@Kje, ok, ça se tient.

Le plus simple ça va être qu'on tagge les issues qui vont bien sur le repo zmarkdown et qu'on les classe dans les bonnes milestones, puis qu'on résume la situation ici.

@Coyote : Depuis le changement sur les sauts de lignes (= ils ne provoquent plus de <br>), les légendes et citations se sont mises à déconner. En gros avant il y avait deux façons de faire :

1
2

> blabla
Source: Machin

et

1
2
3

> blabla

Source: Machin

Actuellement, en prod, la première ne marche plus. Et ça affecte tous les éléments "légendés" au sens de l'implémentation (Citation, Figure, Code, Tableau et Vidéos).

Perso je considère ça comme vraiment bloquant et j'ai déjà corrigé ça pour 5 des 6 éléments (tous sauf les figures). Donc pour ces 5 là, pas de soucis, on va retrouver d'ici quelques jours le fonctionnement précédent (en réalité j'ai pas tout vérifié encore, c'est pour ça que ce n'est pas encore poussé, mais architecturalement parlant ces 5 éléments fonctionnent pareils, seule la figure est un cas à part).

Pour les figures, le prob est encore présent car contrairement aux éléments précédent ce n'est pas un élément de type "block" au sens markdown, c'est un élément inline. Or quand les légendes sont traitées, ces éléments ne sont pas encore transformés. Je vais devoir faire un cas particulier pour elles. Mais comme je l'ai dis, je compte de toute façon le faire avant la v1 car c'est une régression.

En attendant, on peut passer outre en mettant juste une image isolée (donc sans la ligne Figure:...). Ce qui sert de href pour le inline est alors utilisé pour la légende. Et ça ça marche :

1

![Notre super logo](http://zestedesavoir.com/static/images/logo.png)

Comme il est encore possible de faire des image légendées, je considère que c'est moins urgent que le reste. Mais tout sera fait pour la v1.

Ok. Donc côté contenu md généré par le parseur zCode, aucun impact, c'est parfait !

Mea culpa : je n'avais pas vu ce topic. J'ai donc ajouté une feature tout à l'heure qui est le label "Auteur du sujet".

Perso ça m'aide vraiment à suivre les topics des bugs et tout en sachant à qui je parle.

Voilà, désolé j'ai violé le freeze mais promis c'était la dernière fois

Sinon, tout d'accord !

Bon, concernant markdown, le prob de lignes vides sur les légendes et citation est en PR. Le bug sur les vidéos, je n'arrive pas à le reproduire et il est possible que les dernières modifs l'ai corrigé au passage.

Je vais donc m'attaquer maintenant aux issues pour v1, histoire d'etre tranquille. D'ailleurs la beta public, elle est censé sortir quand ?

Date initiale : le 28 juin.

Une bonne date c'est sûrs !

Ce sera ton anniv Kje ?

Hello,

Juste pour vous prévenir que j'ai installé SSL sur la prod'. On fera la demande de certificat une fois le site lancé, du coup ?

Pour rappel, on peut en obtenir un gratuitement ici : https://www.globalsign.com/ssl/ssl-open-source/

Une fois le site accessible en bêta publique, oui.

Ge0 pourquoi ton gratuitement est en italique ? Il y a anguille sous roche ou des contraintes trop tricky ?

Parce qu'en général tu paies pour avoir un certificat, mais comme on est un projet open source on aura un certificat gratuit !

Mise à jour concernant le zmarkdown : Toutes les issues récemment rapportées ont été ajoutés au projet github. Elles sont toutes taguées (bug/enhancement) avec un niveau de difficulté/temps nécessaire indiquées. Pour tous les bugs et certains enhancement j'ai indiqué comment ça pouvait être corrigé.

Il n'y a rien de vraiment bloquant pour la sortie.

Si quelqu'un veut s'en occuper, il peut demander les droits sur le dépôts à Talus. Perso je ne pense pas dégager du temps pour zds/zmarkdown avant un moment.

Hmmm, OK. Merci d'avoir prévenu.

Puisque le markdown est une feature critique et qu'il faut absolument que quelqu'un soit là pour réagir au cas où des issues tomberaient pendant la bêta publique, je vais reprendre le flambeau, au moins temporairement.

Si quelqu'un d'autre est intéressé, je peux également lui filer les droits.