J'arrive après le débat, j'ai été redirigé vers cette ZEP que très récemment et j'approuve cette ZEP dans les fonctionnalités qu'elle pourra apporter. Par contre, j'aimerais faire quelques remarques :
Cette ZEP est bien trop énorme pour être développé par une personne. Plusieurs personnes doivent se mettre dessus et la ZEP doit être découpée en plusieurs ZEP. Nous ne sommes que des bénévoles qui développons ZdS sur notre temps libre. Impossible d'estimer correctement cette ZEP en terme de temps mais, à mon avis, dans le cadre d'une entreprise, elle pourrait prendre facilement 1 mois full time dessus (et je pense être gentil).
Actuellement, et le premier message de ce sujet le mentionne bien, nous utilisons Git comme un outil et non pas au coeur de la gestion des tutoriels et des articles. Un prérequis est donc de refactoriser le module des tutoriels et des articles pour centraliser l'utilisation de Git.
GitHub est l'une des plateformes de référence dans l'utilisation de Git mais cela ne veut pas dire que nous devons copier. Dans notre cas, nous ne voulons pas qu'un auteur "push" n'importe quoi. Il faut donc pensé à abstraire un certain nombre de choses pour pouvoir effectuer des vérifications lorsque l'auteur veut effectuer des vérifications. N'oubliez pas qu'un auteur n'est pas forcément développeur (aura plutôt tendance à ne pas l'être du tout). Il faut donc quelque chose d'extrêmement user friendly, pas des commandes Git brutes (selon moi).
Les "PRs" est une fonctionnalité non native à Git. C'est un mécanisme qu'il va falloir développer. Après, est-ce que nous voulons cette fonctionnalité ? Est-ce une bonne idée de lui donner le même nom ? Pour moi, non. Fonctionnellement, nous voulons qu'un utilisateur X puisse contribuer à un tutoriel Y. Techniquement, le fonctionnement sera semblable à une PR mais ça sera quelque chose de spécifique ZdS.
Globalement, ne pensons pas forcément GitHub. Discutons de ce que nous voulons fonctionnellement et nous réfléchirons après techniquement avec Git. Développer des choses autour de Git, nous n'y manquerons pas (raison pour laquelle il sera nécessaire de centraliser l'utilisation de Git).
Voilà, je viens un peu dépoussiérer ce sujet parce que cette ZEP a un potentiel énorme, malheureusement un peu trop énorme. Raison pour laquelle je pense qu'elle est restée au point mort (je n'ai pas lu tout le sujet, juste le premier message qui est censé résumé tout ce qui a été dit).
PS : Le premier message de ce sujet est difficile à lire.
PSS : Joyeux Noël au passage !
Les "PRs" est une fonctionnalité non native à Git. C'est un mécanisme qu'il va falloir développer. Après, est-ce que nous voulons cette fonctionnalité ? Est-ce une bonne idée de lui donner le même nom ? Pour moi, non. Fonctionnellement, nous voulons qu'un utilisateur X puisse contribuer à un tutoriel Y. Techniquement, le fonctionnement sera semblable à une PR mais ça sera quelque chose de spécifique ZdS.
Je suis globalement d'accord avec le message, mais je veux juste préciser un point. Une PR est "implicitement" une fonctionnalité native de git (envoyer un patch, discuter autour de ce patch, merger ou refuser un patch). Sauf que là tu as probablement la version Github, ce qui en effet est discutable (quoique… si le contributeur veut rajouter quelque chose, il peut être bon d'avoir une
discussion "publique" - ou au moins auteur + contrib + valido - autour).
Cette ZEP est bien trop énorme pour être développé par une personne.
On est d'accord, c'est pas vraiment ce qui était prévu non plus. Actuellement, c'est juste la spécification qui est complexe car personnellement je ne maîtrise plus assez la techno pour continuer à mettre à jour la rédaction de la ZEP.
En cela c'est vrai que ta proposition de faire plusieurs ZEP serait pas mal.
Un prérequis est donc de refactoriser le module des tutoriels et des articles pour centraliser l'utilisation de Git.
ALors il faut que la ZEP 12 soit développé.
En fait, il faudra que :
ZEP 12 implémentée pour factoriser/améliorer globalement le code du module de tuto/article et préparer la venue des tribunes
choix important : évolution de GitPython vers py3 ou bien on prend libgit2 (py3 par défaut)
Autoriser le "git clone" en mode publique <= SECURITE
Globalement, ne pensons pas forcément GitHub.
En fait j'ai parlé de "PR" pour que chacun ait un point de comparaison. Le but est surtout de permettre de proposer une correction.
Je suis globalement d'accord avec le message, mais je veux juste préciser un point. Une PR est "implicitement" une fonctionnalité native de git (envoyer un patch, discuter autour de ce patch, merger ou refuser un patch). Sauf que là tu as probablement la version Github, ce qui en effet est discutable (quoique… si le contributeur veut rajouter quelque chose, il peut être bon d'avoir une
discussion "publique" - ou au moins auteur + contrib + valido - autour).
Merci bien pour ses précisions ! Je les ai intégré dans une révision de la ZEP que je suis en train de préparer.
On est d'accord, c'est pas vraiment ce qui était prévu non plus. Actuellement, c'est juste la spécification qui est complexe car personnellement je ne maîtrise plus assez la techno pour continuer à mettre à jour la rédaction de la ZEP.
En cela c'est vrai que ta proposition de faire plusieurs ZEP serait pas mal.
Si ça te plait, banco. Je voudrais juste clarifier un peu la rédaction actuelle de la ZEP (ma proposition very soon).
ALors il faut que la ZEP 12 soit développé.
En fait, il faudra que :
ZEP 12 implémentée pour factoriser/améliorer globalement le code du module de tuto/article et préparer la venue des tribunes
choix important : évolution de GitPython vers py3 ou bien on prend libgit2 (py3 par défaut)
Autoriser le "git clone" en mode publique <= SECURITE
Globalement d'accord.
Sinon, je suis en train de réécrire le premier message de cette ZEP pour proposer une nouvelle révision mais je me suis heurtée à deux choses que je ne comprenais tout simplement pas :
Dans la section "Gestion des branches", à quoi correspond les différentes branches mentionnées (sachant qu'aucune branche n'est utilisée actuellement) et les solutions proposée pour chaque branche ?
Dans la section "Lier des dépôts distants", pourquoi il y a des problèmes de sécurité si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir (donc uniquement la lecture de ces dépôts) ? Pourquoi discuter du système d'authentification par SSH ?
Dès que ces deux points seront plus clairs dans ma tête, voici une proposition de révision :
Cartouche
ZEP
8
Titre
Utilisation au maximum de git pour gérer les tutos et articles
Révision
5
Date de création
17/07/2014
Dernière révision
26/10/2014
Type
~Feature
Statut
Rédaction
L'objectif de cette ZEP-8 et de donner les spécifications pour placer Git non plus comme un outil pour faire du versioning mais au centre de la gestion des articles et des tutoriels. Pour le moment, Git est utilisé pour sauvegarder les tutoriels et les articles, versionner leurs contenus, tracer les versions basé sur les commits et afficher des diff pour connaitre les modifications faites entre deux versions (donc, entre deux commits).
Git est un système de contrôle de version distribué, c'est-à-dire que chaque personne peut posséder une copie en local du dépôt, peut y faire des modifications, des branches, des patchs, etc. Puis, une copie sur un ou plusieurs dépôts distants existe et permet à chacun de se synchroniser au besoin. Cet outil a gagné ses lettres de noblesse grâce à des plateformes comme GitHub qui se veut être un "réseau social du code". Cette ZEP s'inspire de certaines fonctionnalités de GitHub pour les proposer à ZDS et à son module de rédaction.
Note : Pour obtenir l'état de ce qu'il se fait dans le module des tutoriel actuelle, allez voir ce sujet.
Donner la possibilité de faire une PR
Le besoin est de permettre à n'importe quel visiteur identifié X de pouvoir proposer des corrections à un tutoriel Y. Un scénario simple pourrait être le process suivant :
sur ZdS l'auteur publie son tutoriel ;
sur ZdS un visiteur authentifié voit une phrase mal tournée ;
sur ZdS le visiteur authentifié a la possibilité "d'éditer le tuto" pour y apporter sa correction ;
sur ZdS le visiteur authentifié appuie sur "proposer la correction" ;
sur ZdS l'auteur voit une proposition de correction, s'il l'accepte, la correction est fusionnée à son travail courant. En cas contraire, la correction est tout simplement pas appliquée.
Une première fonctionnalité intéressante serait l'utilisation des patchs pour proposer des corrections aux tutoriels ou aux articles. Cette notion des patchs est bien connue sur GitHub par les Pull Requests (PR) où le principe est simple : envoyer un patch, discuter autour de ce patch, merger ou refuser un patch.
Attention : Cette fonctionnalité ne sort pas du cadre du site. Il n'est possible de proposer des corrections que par le site.
Gestion des branches
Les PR fonctionnent avec les branches, chose qui n'est pas supportée sur Zeste de Savoir pour le moment, où du moins pas utilisée. Il faut donc intégrer les branches et permettre leurs utilisations dans les projets Git de Zeste de Savoir. Actuellement, chaque projet Git qui correspond à un tutoriel ou un article possède une seule branche, chose qui crée des problèmes :
Gestion des conflits
La gestion des conflits consiste à résoudre les zones de texte qui ont été modifiées simultanément par deux commit/PR. Actuellement, elle se manifeste lorsque deux auteurs modifient le même extrait, introduction ou conclusion en même temps. La stratégie mise en oeuvre est dite mine full ; c'est-à-dire que la dernière modification reçue écrase les modifications faites par le premier auteur. A noter qu'un premier pas a été fait pour rendre la chose moins pénible pour les auteurs avec la PR 1237 sur le projet GitHub de Zeste de Savoir en proposant une approche theirs full ; c'est-à-dire que le second auteur sera notifié des changements faits par le premier auteur et n'écrasera pas les modifications faites.
Le besoin serait de proposer une interface adaptée et claire pour résoudre les conflits d'un dépôt d'un tutoriel ou d'un article. Ce besoin pourrait être résolue par l'intégration de la commande git-mergetool qui est une commande Git pour résoudre les conflits.
Plusieurs possibilités dans sa mise en oeuvre :
En python, rediriger une entrée/sortie du shell vers le web.
Chercher un git-mergetool déjà possible en interface web.
Si aucun git-mergetool trouvé n'est intégrable dans un délai raisonable, en développer un. Un POC est déjà présent dans l'implémentation des diffs.
Lier des dépôts distants
Principe général
Lier des dépôts distants consiste dans la possibilité de cloner un dépôt distant (hébergé chez Zeste de Savoir, par exemple) et d'y apporter des modifications en mode non connecté. La fonctionnalité permettra d'éditer le contenu sans une connexion à Internet et de soumettre les modifications une fois terminée et/ou la connexion rétablie.
Pour des soucis de sécurité, Zeste de Savoir doit seulement permettre le clone du dépôt qu'il héberge afin de ne pas gérer la sécurité en écriture des tutoriels et des articles. Une modification par la liaison à des dépôts distants sera possible via des PRs.
De plus cette fonctionnalité laisse à l'auteur le choix de son dépôt distant, que cela soit GitHub, BitBucket ou un autre. Et comme nous n'utilisons que Git et non une API particulière, nous restons suffisamment souple pour même accepter un dépôt auto-hébergé.
Une solution technique possible serait celle-ci :
un des dépôts représente le tuto en cours de rédaction, il appartient à l'auteur qui peut en faire ce qu'il veut (le clôner, y pousser des changements, etc.) ; l'autre représente le tuto publié sur le site, il appartient aux validos qui peuvent accepter les pull requests des auteurs. Ça simplifie pas mal la gestion des droits, étant donné que les ownerships sont déterminées dépôt par dépôt (et non branche par branche ou tag par tag).
GuilOooo
Limites acceptables
Le dépôt devant être hébergé sur zds, il ne doit pas contenir du contenu autre que :
Des images compatibles pour le web (png, jpg (si possible avec l'encodage mozilla pour limiter la taille)) ;
du texte au format markdown ;
un et un seul manifest.json.
Une limite de taille doit aussi être imposée afin que l'hébergement ne souffre pas trop.
Gestion de la sécurité
La gestion des droits pourrait se faire à la GitHub avec des clefs ssh. D'après le commentaires, il faudrait utiliser des outils comme gerrit ou gitolite.
A propos des licenses :
il faudra bien mentionner qu'on n'accepte que des modifs mineurs ne pouvant pas être reconnues comme une œuvre originale (correction orthographique, etc…) sauf si l'auteur autorise les modifications via sa licence.
[…]
Du coup, je note qu'il ne faut pas qu'on mette en prod la gestion de pull-request tant qu'on n'aura pas notre assurance (qui couvre notamment les frais de justice). Je reparlerai de ça dans la section association.
Natalya
Un système de PR corrective est implémentable et légal, si et seulement si la licence le permet. En ce qui concerne l'ajout comme auteur, dans les deux cas, cela ne l'est pas forcément.
Si la licence autorise les modifications: L'auteur d'une PR corrective est l'auteur de ses modifications, pas de l'ensemble du tuto. De fait, à moins de spécifier quels sont ses modifications (ce qui serait pas vraiment user-friendly), ça pose un pépin vu que ça lui donne des droits sur ce qui n'est pas de lui.
Si la licence ne permet pas de modifs: il ne peut absolument pas être auteur.
Arius
Liste des objets versionnés
structure du tutoriel
titre + intro + conclusion de chaque conteneur[^zep12]
l'ordre des composants
contenu du tutoriel
le texte des extraits
l'adresse de l'icône du tutoriel
les méta données
la source du tutoriel[^canonical]
(proposition) une liste de tutoriels prérequis (non obligatoire)
Les auteurs du tutoriels ne doivent pas être versionnés.
Un auteur obtient ce titre lorsqu'il est responsable d'une création originale. Une correction orthographique ou la réorganisation d'un paragraphe ne fait pas de lui un auteur à part entière sauf si l'un des auteurs déjà présent l'ajoute à la liste.
Je up parce que je n'ai pas reçu de réponses à mes questions. Les voici :
Sinon, je suis en train de réécrire le premier message de cette ZEP pour proposer une nouvelle révision mais je me suis heurtée à deux choses que je ne comprenais tout simplement pas :
Dans la section "Gestion des branches", à quoi correspond les différentes branches mentionnées (sachant qu'aucune branche n'est utilisée actuellement) et les solutions proposée pour chaque branche ?
Dans la section "Lier des dépôts distants", pourquoi il y a des problèmes de sécurité si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir (donc uniquement la lecture de ces dépôts) ? Pourquoi discuter du système d'authentification par SSH ?
Je pense que pour les branches, etc… osef, autant juste mettre le bon hash du commit qui va bien. Libre a l'auteur / valido de choisir quel commit mettre en ligne (proposer), libre au valido de choisir quel commit utiliser (mise en prod).
Pour le fetch… Ouais osef de la limite a la rigueur. C'aurait été intéressant que le valido ait un accès ssh ceci dit (dans le cadre d'une manipulation plus complexe si besoin est)
Je pense que pour les branches, etc… osef, autant juste mettre le bon hash du commit qui va bien. Libre a l'auteur / valido de choisir quel commit mettre en ligne (proposer), libre au valido de choisir quel commit utiliser (mise en prod).
En fait ça pose problème ça… Par exemple je suis en train d’écrire une nouvelle partie, donc j'ai des commits en avance par rapport a la version en ligne, mais je veux faire une petite correction sur la version en ligne. Comment je fais ?
Dans la section "Gestion des branches", à quoi correspond les différentes branches mentionnées (sachant qu'aucune branche n'est utilisée actuellement) et les solutions proposée pour chaque branche ?
A l'époque où j'avais rédigé cette ZEP, le principe avait été celui-ci :
on a une branche "draft" puis 2 branche "prod" et "béta". A noter que plus tard dans le débat le concept de tag m'a été cité. Si la ZEP n'est pas à jour c'est simplement qu'à l'époque je ne comprenais pas vraiment ce concept, c'est un peu plus le cas aujourd'hui grâce au workflow de dev de ZDS, mais en gros, je pense que c'est clairement ce qu'il faudrait utiliser : un tag.
La notion de "branche" ne pourrait être utilisée que pour la correction communautaire : quelqu'un voit une faute, une branche est créée sur le dépôt avec la correction proposée et une sorte de "pull request" est générée.
Dans la section "Lier des dépôts distants", pourquoi il y a des problèmes de sécurité si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir (donc uniquement la lecture de ces dépôts) ? Pourquoi discuter du système d'authentification par SSH ?
parce que rien n'a été décidé quant au "si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir".
Dans la section "Gestion des branches", à quoi correspond les différentes branches mentionnées (sachant qu'aucune branche n'est utilisée actuellement) et les solutions proposée pour chaque branche ?
A différencier le boulot de l'équipe de validation de celui du (des?) auteur(s). À la base c'est ça, mais ce débat a été "empoisonné" par celui ayant lieu au même moment à l'époque sur le workflow de ZdS itself. Du coup, je pense qu'il faudrait relire les argument à tête reposée et séparer ceux qui n'avait pas forcément à voir de ceux qui on vraiment de l'intérêt (git flow ou pas, toussa).
Dans la section "Lier des dépôts distants", pourquoi il y a des problèmes de sécurité si nous n'acceptons que le clone des dépôts Git sur Zeste de Savoir (donc uniquement la lecture de ces dépôts) ? Pourquoi discuter du système d'authentification par SSH ?
Pour moi, SSH, pour des problèmes liés à ce qu'est un système UNIX. Je m'explique: pour donner un accès ssh à qui que ce soit, il faut que ladite personne aie un compte sur la machine hôte. Donc déjà, y faudrait que ça soit le cas et donner un lien compte ZdS <-> compte sur la machine. Ensuite, y'a la gestion des droits pour éviter que tout un chacun fasse n'importe quoi n'importe ou. Et quand je parle de "droits", je parle ici de la version "UNIX" de ceux-ci (écriture/lecture/exécution) : qui a le droit d'écrire quoi ou ? Alors pourquoi pas pour les validos, mais ouvrir ça à n'importe qui, ça me semble la porte ouverte à n'importe quoi (sans compter les failles de sécurité si un petit malin se met à uploader des scripts pythons exécutables).
Quand à git, ça revient à peu près au même : il faut que quelqu'un spécialisé dans la quesion ouvre le bon port pour que ça soit permis, donne les bonnes permissions au bon endroit et ainsi de suite. C'est donc faisable, mais … Est ce qu'on a les ressources/moyen ? Et pareil, il faut penser à la sécurité, ainsi qu'à l'aspect place que ça prend et qui peut pusher quoi (est ce qu'on accepte les images ? Comment?).
gitolite et gerrit font du contrôle de droits via les clefs publiques utilisées par ssh sans avoir besoin d'un compte par client, toutes lez connexions ssh appartiennent à gitolite/gerrit.
Pourquoi faut-il contrôler les droits d'accès ? A la base, l'exigence est pensée pour le push, mais c'est nécessaire même pour un clone. L'auteur d'une œuvre est le seul à pouvoir décider de sa publication, on ne peut pas permettre à n'importe qui de cloner un dépôt car ceux ci peuvent contenir du contenu inédit.
Et sinon, Pierre à raison, c'est très complexe, c'est pour ça qu'on n'envisage pas de le faire bous même et que les mots gerrit/gitolite reviennent si souvent dans la discussion.
A mon avis, cette ZEP est l'un des chantiers les plus importants à mener pour ZdS mais elle demande énormément de travail (vraiment beaucoup beaucoup). Il faudrait des ressources, des connaissances et de la motivation.
C'est dommage parce que si ZdS intègre toutes les promesses de cette ZEP, je considèrerais ZdS comme une alternative GitHub sérieuse pour tout ce qui concerne du contenu. Ca serait assez énorme.
Pourquoi des devs front ? Si on peut manipuler dans un premier temps directement les dépôts, ce serait bien. On pourrait alors travailler plus facilement via GitHub/GitLab/autre.
Si on peut manipuler dans un premier temps directement les dépôts, ce serait bien.
en soit, manipuler un dépôt on sait djéà le faire car… chaque contenu est un dépôt.
Le vrai problème c'est qu'il faut savoir :
quoi faire
quand le faire
comment le montrer à l'utilisateur
Si github a explosé gitlab ou btbucket c'est avant tout car ces gens là ont fait un front qui marche du feu de dieu. Il suffit de voir le module de diff avant et après le passage d'une personne qui sait comment montrer un diff à l'utilisateur.
Donc en fait il faudrait carrément une spec du front AVANT celle du back.
en soit le back on peut très bien le rendre sous la forme d'une API appelable en JS donc ça veut dire que le front peut être développé avec des "mock" et ensuite on branchera le truc qui va bien.
en soit le back on peut très bien le rendre sous la forme d'une API appelable en JS
ça serait même préférable.
ça laisse la possibilité à n'importe qui de développer une UI sympa si celle du site ne lui convient pas, …
C'est pas tant des dev fronts qui manquent à mon sens, mais plus une spec "concrète"/UX. L'implémenter en front, ça va être long chiant, va falloir choisir la/les bonne(s) méthode(s) et techno(s). Mais d'abord faut se représenter visuellement le truc, savoir à quoi ça pourrait ressembler concrètement.
Et là, c'est presque pas encore le boulot d'un dev front. Mais c'est vraiment (très) dur.
Comme je l'ai dit sur twitter, je vais développer cette ZEP. Par contre, son développement ne démarrera que lorsque quelqu'un aura décidé qu'il m'aidera à développer. Je ne commencerai pas cette ZEP si je suis seul.
Du reste, voici le plan d'action auquel j'ai pensé :
Ce plan d'action est immédiatement raisonné à partir des choses de la zep-12 qui ont fonctionné ou échoué.
Première étape : Amélioration du modèle et de l'interface de collaboration
Avant de passer à des intéractions complètes avec git, il faudra d'abord être clair sur ce qu'on veut versionner. De plus, il faudra être très "user friendly" dans la manière de versionner et de présenter les conflits d'édition aux gens.
Cette première Etape, appelée ZEP 8.1 donnera lieu à une PR en soit. En effet, développer la ZEP complète puis merger, a montré durant la zep-12 que c'était casse gueule et source de nombreux bugs (templates incohérents, bugfix mal mergés, demandes mal maîtrisées et surtout le code produit met 1 an à arriver en prod alors que des bugfix et features intéressantes sont codées depuis longtemps).
Cette PR ZEP 8.1 packagera :
une nouvelle version du manifest.json qui versionne ce que la zep-12 n'a pas versionné alors que c'est souhaitable qu'on le versionne comme le logo.
le bugfix de #3251, #3134 (il faut améliorer les différents chargements), 2532 (tant qu'à faire, dans la zep qui parle de git)
Faire valider le manifest.json par un schéma json
En ce qui concerne #3251, bien que le débat soit encore possible, il est selon moi nécessaire d'avoir une interface en trois blocs :
sketch interface
PS: notons que le theirs/mine est déjà codé dans un templatetag
Deuxième étape : correction par simple PR
Une faute d'orthographe? une image qui est en http? une faute factuelle passée à travers la validation? Proposez votre correction par PR !
Une nouvelle fois c'est en plusieurs bouts que nous feront ça :
première étape : faire une PR sur un extrait, une intro ou une conclusion. Pour faciliter les choses, il faudra être connecté pour cela. Un bouton apparaîtra lors d'une action spéciale (survol, click sur une roue dentée? les dev front/UX vous pouvez apporter votre expertise) et qui permettra la proposition. Une fois la proposition faite, un MP est envoyé aux auteurs, et lrosqu'ils visiteront leur version brouillon, dans la barre des actions des extraits, en plus éditer, déplacer, supprimer, ils auront droit à une page "voir l(a|es) PR" qu'ils pourront accepter ou refuser une par une. Première étape : on n'a donc que "accepter" et "refuser". La PR doit donc pouvoir être mergée automatiquement. Si elle ne peut pas l'être, le membre qui l'a faite se verra proposer une alerte du style :
Il semblerait que l'auteur ait déjà corrigé des erreurs dans cette section. De ce fait, votre correction ne peut être proposée automatiquement. Afin de faire profiter l'auteur de votre travail, désirez-vous lui envoyer vos propositions par message privé? OUI/NON
En deuxième étape, une résolution manuelle pourra être proposée mais surtout le front évoluera et on pourra au click droit sur un paragraphe avoir l'option "proposer une correction". et lorsque le champ de proposition de correction apparaîtra, il se positionnera directement sur le bon endroit !
Une nouvelle fois, une fois qu'on a ça, on fait une PR sur le dépôt principal de zds.
troisième étape : lien avec le monde
Proposer en sus de la navigation sur le site, de :
lier un contenu à un github/gitlab/bitbucket (ajouter un remote), par soucis de cohérence technique, pour l'instant, on se contente de jouer avec les dépôt git, désolé les gens qui aiment mercurial ou HG. On prend aussi ces trois services là pour l'exigence suivante :
Utiliser l'API de ces services pour que zds puisse faire des PR sur ces remotes (zds se place alors comme un dépôt décentralisé) lorsque l'utilisateur le demande (bouton à coder en AJAX)
Importer un tutoriel depuis un dépôt git existant : basiquement, on fait un clone, on check que le manifest.json existe, on fait les modifs adéquates pour que ça soit zds-compatible, on fait une PR au dépôt. Si le manifest n'est pas présent, on suppime le dépôt et on prévient l'utilisateur. Il serait d'ailleurs intéressant de proposer cette expérience via une interface ajax qui affiche des barre de progression etc.
Du coup, pour les dépôts comment va tu faire ? tu partirait sur l'idée suivante qui est sur la première page:
un des dépôts représente le tuto en cours de rédaction, il appartient à l'auteur qui peut en faire ce qu'il veut (le clôner, y pousser des changements, etc.) ; l'autre représente le tuto publié sur le site, il appartient aux validos qui peuvent accepter les pull requests des auteurs. Ça simplifie pas mal la gestion des droits, étant donné que les ownerships sont déterminées dépôt par dépôt (et non branche par branche ou tag par tag).
et pour les branches ? tu as choisis quelles options ?
un des dépôts représente le tuto en cours de rédaction, il appartient à l'auteur qui peut en faire ce qu'il veut (le clôner, y pousser des changements, etc.)
y'a ça aussi et pour l'instant c'est impossible : nos dépôts ne sont pas des dépôts bare. Donc il faudrait ajouter une nouvelle étape à la zep
et pour les branches ? tu as choisis quelles options ?0
1 pr de correction = une branche finalement.
Mais la spec initiale est outdated complètement. A l'époque je comprendais aps trop git
Excellente initiative, on voit bien que sur le plan technique ça peut apporter énormément à ZdS. On voit aussi que les possibilités sur le plan fonctionnel offertes par cette MeP sont nombreuses (PR de correction principalement). Donc c'est vraiment une excellente nouvelle.
Un truc que je me demandais et dont j'avais oubli de faire mention plus tôt (désolé :\ ) c'est : cette ZEP est intimement liée à l'API des tutos non ? Toutes les actions dont tu parles (rajouter une origine, soumettre une PR de correction, …) devraient être disponibles par API REST (ça ouvrirait la voie à des espèces de webhook, mais pourquoi pas à des éditeurs externes, etc.) ?
J'imagine que vu qu'on est à t0 c'est pas gênant (il faut coder l'API : au sens programmatique, pas REST) du machin avant d'imaginer en exposer les primitives, mais autant y penser assez tôt, non ?
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
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