Roadmap et priorités à moyen terme

Brace yourselves, V1 is coming!

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

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 :

Jusqu'à la sortie officielle du site, nous sommes en mode freeze.

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 ?

Édité par nohar

I was a llama before it was cool

+12 -0
Staff
Auteur du sujet

Pluzain

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

Sandhose

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

I was a llama before it was cool

+1 -0
Staff

Cette réponse a aidé l'auteur du sujet

Coté markdown :

  • Avec les changements de comportement niveau sauts de lignes, il y a eu des régressions. Par exemple pour les citations il faut une ligne vide entre l’élément et la ligne de Source actuellement ce qui est censé etre optionnel. C'est réglé en local pour la majorité (au moins citation, vidéo, code et tableau)
  • Il y a le même soucis avec les figure quand on veut specifier a la fois le href et la légende. En gros ces notations ne marchent pas :
1
2
![mon href](url)
Figure: la légende

ou

1
2
3
![mon href](url)

Figure: la légende
  • Par contre il est possible de mettre une légende tout de même quand on ne veut pas mettre de href. On remplie juste le premier champ qui sera utilisé. C'est ce qu'utilise le convertisseur zcode -> markdown. Donc ça ne me parait pas prioritaire, je le placerais en objectif v1.
  • Un bug avec les vidéo semble pouvoir faire planter le parsing totalement : priorité haute, bloquant pour la mise en beta publique je pense.
  • Il est necessaire de mettre en place travis et les tests. C'est commencé mais pas terminé. Prévu pour la v1.
  • Il faut réformer les outils markdown et en particulier la chaine pour les conversions vers pdf et ebook. Cela aurait été bien pour la v1 mais ça risque d'etre long quelque soit la solution. Donc pour moi c'est post v1 (ce qui est cité au dessus doit etre fait avant) mais rapidement. Mais je ferais un post en zone dev de dédié
  • A moyen terme il y a du gros netoyage a faire. Mais pas prioritaire, post v1
  • Il a été proposé de rajouter une syntaxe @pseudo mais c'est une nouvelle feature -> post v1

Voila je crois que j'ai tout dit

+1 -0
Staff
Auteur du sujet

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.

I was a llama before it was cool

+0 -0
Staff

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.

Édité par firm1

+0 -0

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 :

Avec les changements de comportement niveau sauts de lignes, il y a eu des régressions. Par exemple pour les citations il faut une ligne vide entre l’élément et la ligne de Source actuellement ce qui est censé etre optionnel. C'est réglé en local pour la majorité (au moins citation, vidéo, code et tableau)

Kje

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).

Édité par Coyote

Améliorons la validation ! - ZdS, faut bien secouer, sinon la pulpe, elle reste en bas !

+0 -0
Staff
Auteur du sujet

@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.

I was a llama before it was cool

+0 -0
Staff

@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 :

Notre super logo

source :

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.

Édité par Kje

+5 -0
Staff

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 ?

+0 -0
Staff

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.

+0 -0
Staff
Auteur du sujet

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.

Kje

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.

Édité par nohar

I was a llama before it was cool

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte