Normalisation des suggestions à l'aide des templates issues Github

[SirMishaa]

Hey !

Je propose qu'on essaye de normaliser les suggestions via les templates Github. L'avantage, c'est que ceux-ci permettent de mettre du texte en commentaire et donc d'indiquer ce que l'utilisateur doit expliquer, faire ou ne pas faire.

Je propose quelque chose du genre :

<!-- Ceci est la template de suggestionde NaN. Merci d'être précis sur la rédaction cette dernière. -->

### Description détaillée de votre suggestion
[...]


### Fichier multimédia
[...]


### Raison derrière cette suggestion
[...]


### Contraintes éventuelles
[...]

Ce qui donne ceci :

Description détaillée de votre suggestion

Normalisation des suggestions Github via une template par défaut. Pour écrire une suggestion, les gens peuvent (et devraient) utiliser ce modèle.

Fichier multimédia

Aucun

Raison derrière cette suggestion

Cela permet de structurer directement les suggestions et d'éviter que ce soit trop difficile à lire.

Contraintes éventuelles

Le modèle doit rester assez flexible.

[Equinox4]

ça peut être une bonne idée. Juste la partie "fichier multimédia" dont je ne vois pas trop l'intérêt, mais sinon ouai, ça aidera les gens à structurer leurs suggestions.

[SirMishaa]

ça peut être une bonne idée. Juste la partie "fichier multimédia" dont je ne vois pas trop l'intérêt, mais sinon ouai, ça aidera les gens à structurer leurs suggestions.

Afin d'éviter d'avoir les images dans la partie de l'explication.
C'est parfois le cas dans les issues et ça rend la chose difficile à lire.

[Mesteery]

ça peut être une bonne idée. Juste la partie "fichier multimédia" dont je ne vois pas trop l'intérêt, mais sinon ouai, ça aidera les gens à structurer leurs suggestions.

Afin d'éviter d'avoir les images dans la partie de l'explication.
C'est parfois le cas dans les issues et ça rend la chose difficile à lire.

Ça peut rester tout en bas, c'est pas très gênant.

[GiregL]

J'aurais bien mis la section sur la raison de la suggestion en premier. Expliquer le problème avant de proposer une solution de quelque chose.

[SirMishaa]

J'aurais bien mis la section sur la raison de la suggestion en premier. Expliquer le problème avant de proposer une solution de quelque chose.

Je pense que la suggestion devrait rester en premier. Cela permet de donner un contexte, puis d'expliquer les choix et le pourquoi.

Par contre, les images devraient être en dessous, car elles sont plutôt rares. J'ai aussi changé les titres pour qu'ils soient plus petits.
Nouvelle disposition du coup :

Description détaillée de votre suggestion

[...]

Raison(s) derrière cette suggestion

[...]

Contrainte(s) éventuelle(s)

[...]

Annexe(s) / Fichier(s)

[...]

[Mesteery]

*préambule*

## Description détaillée de votre suggestion
*<décrire cette section>*

## Raison(s) derrière cette suggestion
*<décrire cette section>*

## Contrainte(s) éventuelle(s)
*<décrire cette section>*

## Annexe(s)
*<décrire cette section>*

[SirMishaa]

Les titres sont bien trop grand en ##

Pourquoi décrire cette section ? ça équivaut à dire " Expliquer à quoi sert cette section".
Pour ma part, je n'aime pas les commentaires dans les sections ou l'utilisateur va écrire, les titres au-dessus sont déjà bien assez explicite.

Vaut mieux avoir un commentaire au-dessus de l'issue pour expliquer éventuellement des choses.

[GiregL]

J'aurais bien mis la section sur la raison de la suggestion en premier. Expliquer le problème avant de proposer une solution de quelque chose.

Je pense que la suggestion devrait rester en premier. Cela permet de donner un contexte, puis d'expliquer les choix et le pourquoi.

Par contre, les images devraient être en dessous, car elles sont plutôt rares. J'ai aussi changé les titres pour qu'ils soient plus petits.
Nouvelle disposition du coup :

Description détaillée de votre suggestion

[...]

Raison(s) derrière cette suggestion

[...]

Contrainte(s) éventuelle(s)

[...]

Annexe(s) / Fichier(s)

[...]

Bah justement, pour moi le but des suggestions est de répondre à une problématique, la mettre en premier est plus intuitif pour savoir ce a quoi on répond et par quel moyen. C'est probablement une question de goûts, c'est peut-être équivalent au final, mais de mon point de vue c'est plus intuitif comme ça.
Pour le reste, je trouve que c'est une bonne idée.

[SirMishaa]

Je trouve plus pertinent d'avoir le contexte au-début et des objectifs clairs de la suggestion, plutôt que de parler directement des raisons de cette dernière.

Quoi qu'il en soit, voilà le modèle (corrigé) que je propose :

<!-- Ceci est la template de suggestion de NaN. Merci d'être précis sur la rédaction cette dernière. -->

#### Description détaillée de votre suggestion
[...]


#### Raison(s) derrière cette suggestion
[...]


#### Contrainte(s) éventuelle(s)
[...]


#### Annexe(s) / Fichier(s)
[...]

[SirMishaa]

Si on peut avoir un label implémenté par exemple, sur l'issue, qui signifie que la suggestion est terminée et implémentée.

[GiregL]

Si on peut avoir un label implémenté par exemple, sur l'issue, qui signifie que la suggestion est terminée et implémentée.

De même qu'un label "prévu" si c'est accepté / en cours mais que ça prend son temps

[Mesteery]

H4 c'est bien trop petit. H2 est le minimum.

[GuillaumeBelz]

Pas sur de voir l'intérêt de normaliser la rédaction des issues et que cela pourrait améliorer les choses. Par exemple, si on prend les issues en cours ou fermées, est-ce qu'elles aurait été améliorées par ce template ? Bof.

Si une issue mal rédiger, on peut toujours demander des explications ou éditer l'issue.

Par contre, un template par défaut pour expliquer à ceux qui n'ont jamais écrit une issue ce qu'il faudrait indiquer, ca me semblerait plus intéressant. Par exemple :

<!-- Pour faciliter les discussions sur ta proposition, il est recommandé de suivre les instructions suivantes: -->
<!-- Mettre un titre clair et concis -->
<!-- Ajouter une description la plus précise possible sur ce que tu proposes d'améliorer, 
comment reproduire un bug rencontré, etc. -->
<!-- Provide an overview of the issue or user story -->

[SirMishaa]

Pas sur de voir l'intérêt de normaliser la rédaction des issues et que cela pourrait améliorer les choses. Par exemple, si on prend les issues en cours ou fermées, est-ce qu'elles aurait été améliorées par ce template ? Bof.

L'annone sur les issues Github vient seulement d'être faite hier, donc les anciennes issues ne sont pas représentatives.

Si une issue mal rédiger, on peut toujours demander des explications ou éditer l'issue.

Oui, on peut aussi planter son blé, le moudre pour en faire de la farine puis l'utiliser pour faire son pain et le cuire ou on peut aller l'acheter au magasin directement. Je veux dire par là que c'est mieux de le demander directement, plutôt que de devoir faire une remarque, car une suggestion est mal rédigée.

Par contre, un template par défaut pour expliquer à ceux qui n'ont jamais écrit une issue ce qu'il faudrait indiquer, ca me semblerait plus intéressant. Par exemple :

Autant directement structurer l'issue, c'est un système qui a déjà fait ses preuves et qui est beaucoup utilisé. Donc concrètement, je ne vois pas trop d'inconvénient à avoir ce système, cela va permettre d'avoir quelque chose de clean dès le début et d'avoir le même style en plus de pouvoir servir de modèle pour les débutants.

[GuillaumeBelz]

L'annone sur les issues Github vient seulement d'être faite hier, donc les anciennes issues ne sont pas représentatives.

je prenais l'exemple des anciennes issues pour illustrer l'idée qu'il n'est pas forcément nécessaire de normaliser pour que les choses se passent bien. Et que les précédentes issues ne pouvais pas respecter la structure proposée.

Oui, on peut aussi planter son blé, le moudre pour en faire de la farine puis l'utiliser pour faire son pain et le cuire ou on peut aller l'acheter au magasin directement. Je veux dire par là que c'est mieux de le demander directement, plutôt que de devoir faire une remarque, car une suggestion est mal rédigée.

Hummmm, une bonne baguette...

Cela dit, si tu relis mon message, je ne suggère pas de ne donner aucune indication à ceux qui vont créer des issues, mais simplement de ne pas donner de structure à ces issues. Des explications pour rappeler qu'il faut bien expliquer ce que l'on propose me semble suffisant, voire mieux.

Autant directement structurer l'issue, c'est un système qui a déjà fait ses preuves et qui est beaucoup utilisé. Donc concrètement, je ne vois pas trop d'inconvénient à avoir ce système, cela va permettre d'avoir quelque chose de clean dès le début et d'avoir le même style en plus de pouvoir servir de modèle pour les débutants.

Avoir un template quand on est dans un cas précis, cela peut avoir du sens. Par exemple pour des rapports de bugs d'un logiciel. Mais pour le discord ? Bof. On va se retrouver systématiquement avec des issues qui n'auront pas besoin de ces différents points et je présage que cette structure ne servira à rien.

Après, je ne m'oppose pas à ce template. Si vous voulez qu'on le mette en place, ça ne me pose pas de problème. Tant que l'on garde en tête que l'on pourra supprimer cette structure plus tard, si l'usage montre que mes prédictions étaient correctes.

[SirMishaa]

C'est toujours mieux que d'avoir des issues qui vont dans tous les sens.

Enfin pour le coup on ne tombera pas d'accord (et je n'ai pas envie d'y passer des siècles).

Je pense que la discussion a eu lieu, on attend l'implémentation (ou non) de la template.
Je ferme l'issue dès que j'ai une réponse.

[GuillaumeBelz]

C'est toujours mieux que d'avoir des issues qui vont dans tous les sens.

Il y a un gouffre entre ne pas imposer une structure (qui, a mon avis ne sera pas respectée dans le contexte de ce GH) et avoir des issues qui vont dans tous les sens. Par contre, ca serait cool de ne pas jouer à interpréter mes propos à l'extrême, ça fera gagner du temps.

Il n'y a pas a tomber d'accord, je donne juste mon estimation personnelle de ce qu'il risque de se passer. Mais comme je l'ai dit, c'est osef pour moi de mettre en place ce template.

[SirMishaa]

Je ferme l'issue, il n'y a pas eu de votes et l'équipe staff ne semble pas vouloir mettre en place ce système afin de garder une certaine flexibilité.