Dev Zone, discussions produit ou discussions techniques ?

Je dit "pourquoi pas". Le seul inconvénient d'utiliser GitHub, c'est que la communauté aura plus de mal à venir commenter. Remarquez, si les débats pourrons être ouvert en DevZone pour discuter d'un point de la ZEP, c'est pas plus mal.

Par contre, je recommanderais d'ajouter aux profils ZDS l'option pour inscrire son compte GitHub. (Je sais que ça a déjà été refusé mais dans les circonstances, je pense que c'est une bonne idée)

@victor : je ne peux pas nier le bienfondé de la démarche, mais je crains deux choses :

• Si je prend le cas de la ZEP 11, une ZEP technique aurait été ce fichier par exemple. Sauf que pour l'écrire, j'ai besoin, un minimum de POCer ma démarche, et donc d'écrire du code. Si on me dit "faut que ta spec technique soit validée avant de commencer à dev", ça commence à devenir long comme process pour moi et me connaissant c'est le genre de chose qui fait que je ne vais même pas aller plus loin que me contenter de plussoyer l'idée.
• Si on specifie le produit sur Github, on écarte volontiers la communauté. Parce que déjà que c'est difficile d'avoir des retours de la communauté sur une fonctionnalité décrite sur le site (là ou un membre à son compte et peut facilement +1/-1 quand il est d'accord ou pas), alors si on spécifie le produit sur une autre plateforme, c'est une façon de mettre de coté la communauté (peut-être que c'est ce qu'on veut ?).

EDIT : après ce qui est valable pour moi n'est pas forcément le cas pour les autres dev, donc si la plupart sont ok, rien ne coute d'essayer

Si on specifie le produit sur Github, on écarte volontiers la communauté. Parce que déjà que c'est difficile d'avoir des retours de la communauté sur une fonctionnalité décrite sur le site (là ou un membre à son compte et peut facilement +1/-1 quand il est d'accord ou pas), alors si on spécifie le produit sur une autre plateforme, c'est une façon de mettre de coté la communauté (peut-être que c'est ce qu'on veut ?).

Pour moi on met ça sur un repo dédié (zestedesavoir/zep par exemple), ça permet à n'importe que de follow le repo comme les forums, de follow une ZEP en particulier comme un sujet dans le forum, de commenter comme pour le forum mais en mieux car non linéaire, de mettre des °1/-1 comme sur le forum et même de mettre des cœurs, SWAG que les forums n'ont pas.

Pour moi c'est là la plus grande difficulté. Ce n'est pas parce que l'on crée un dépôt sur une Github que les membres vont se crée un compte la bas pour participer. Si c'est pour que ce soit au final 3-4 personnes qui commentent les PR, ça n'a plus trop d'intérêt.

C'est un peu la question à mon avis. Est-ce qu'on préfère 12 pages de discussions triviales impliquant 15 membres, ou les commentaires précis de 3-4 personnes ?

Je confirme. Je ne me suis créé un compte GitHub que le jour où j’ai voulu effectivement coder pour ZdS. Ça ne m’a pas empêché d’écrire trois ZEP avant ça et de participer à plein d’autres. Mettre tout ou partie d’une discussion sur GitHub, c’est le meilleur moyen pour que l’essentiel de la communauté n’en entende plus parler.

Du coup on en revient à ce que disait Gabbro quelques messages plus haut

Si je met ma casquette de dev, tant que j'ai la spec produit, qu'il y ait eu what milles pages de débat avant m'importera peu. Mais si je mets ma casquette de membre de la communauté normal je trouverai ça moyen de discuter des évolutions du site sur un canal que je (ainsi que beaucoup d'autres) fréquente rarement.

Salut a tous,

Je relance le debat avec mon expérience pro. J´ai travaillé pendant plusieurs années dans une agence ou personne ne connaissait rien au web. Mais quand je dit rien, c'est rien de rien. Du genre ne pas savoir ce qu'est un serveur, une API, Python, PHP, un terminal, un cache, etc. (Et ces gens vendent des produits web). J'avais decoupé mon fonctionnement en deux etapes :

• Le reve : aucune contrainte dans le cahier des charges, specifiez ce que vous voulez meme si cela vous parrait impossible. Je participe au debat en posant des questions produits qui auront des impacts techniques importants.
• Je synthetise et dresse un CdC technique. Au besoin j'élague en retirant des fonctionnalités trés complexe a réaliser et apportant très peu au produit (décision subjective basée sur ma connaissance des produits). J'en informe les responsables du produits en expliquant ma décision.

Pourquoi avoir fonctionné comme ca ? Pour éviter que les gens qui ne connaissent rien à la technique nese limitent en pensant épargner du travail de dev, ou alors qu'ils essayent de penser a la maniere de faire un produit qui sera simple a développer.

De mon point de vue, ca serait donc discussion produit sur le forum (communauté) et discussion technique sur GitHub ou forum (dans un sujet à part)

Ciao

(Et désolé pour la typo, je n'ai qu'un clavier QWERTY sous la main…)

Je poste ici, mais je ne suis pas sûr que ce soit le meilleur endroit :

Peut-être est-ce une piste à explorer pour le développement du site ? Je précise que je participe très peu à la plateforme technique, donc je ne peux pas me baser sur mon expérience pour affirmer ça.

Dans quelle mesure serait-il faisable de former des groupes de travail (comme pour les CdS) et encadrer le travail de ces groupes, pour éviter que la motivation se perde ?

Et je me rends compte que j'aurais peut-être dû poster ici.