Version actuelle en date du 18 décembre 2014 à 22:32

Discussion externe au wiki sur cet article - Discussions internes au wiki sur cet article

Discussion sur la maquette et le dépot github : https://www.facebook.com/groups/creationsitevitrineGV/permalink/274875869318272/

Infos sur bootstrap : https://www.facebook.com/groups/creationsitevitrineGV/permalink/268376666634859/

[modifier] 1 Proposition de protocole démocratique pour apporter des modifications au site web

[modifier] 1.1 Spécifications (besoins que le protocole doit remplir)

• n'importe qui peut proposer une "feature request" (= demande de fonctionnalité, spécification d'un besoin rédigée en langage humain)
• n'importe quelle personne qui a les compétences nécessaires en développement informatique peut implémenter un "patch" et le proposer à la communauté
• tous les membres de la communauté des Gentils Virus ont le pouvoir de participer de manière égale à la décision d'accepter ou pas chaque proposition de modification

[modifier] 1.2 Protocole de proposition d'une modification

• quelqu'un rédige une feature request (spécification du besoin)
• un développeur implémente cette feature request, et en crée une proposition de modification (un "patch" ou "diff"), qu'il soumet au dépôt git officiel en tant que "pull request"
• une "initiative" (au sens de Liquidfeedback, c'est à dire proposition de vote) est alors créée dans l'outil de vote de la communauté (Liquidfeedback, Loomio, sondage de forum, etc). Cette étape possède plusieurs paramètres qui sont décidés en amont par la communauté : quorum de participants (nombre de participants au vote minimum pour que la proposition puisse être acceptée), durée du vote et étapes éventuelles (cf fonctionnement de Liquidfeedback), taux de "oui" minimal pour que la proposition soit acceptée (par exemple 50%).
• la communauté peut voter sur les propositions en cours (et par exemple voir le site tel qu'il est avec et sans l'application de la proposition de modification)
• lorsque le vote est terminé, le gestionnaire du compte github (désigné par la communauté, le rôle peut tourner et l'identité du compte officiel peut tourner aussi) accepte ou rejette le pull request en fonction du résultat du vote
• l'administrateur du serveur web met à jour régulièrement le contenu du site en faisant un "pull" pour récupérer les dernières modifications du dépôt officiel

[modifier] 1.3 Inconvénients

• en ce qui concerne les modifications sur du texte uniquement, il faut tout de même des compétences en développement. TODO: trouver un protocole ou des outils qui simplifient la procédure lorsque la proposition concerne uniquement du texte
• la procédure est un peu complexe
• il faut que le dépôt git officiel (et en l'occurence le compte github) soit géré par quelqu'un de confiance, qui acceptera de céder sa place. Que faire si cette personne pose problème ? => La communauté peut décider de repartir d'une version précédente de l'historique des modifications à la base de code/contenu. Il faut pour cela que d'autres mebmres aient gardé une sauvegarde de l'historique du dépôt. Le gestionnaire de version git a été conçu dans cette optique. Ils peuvent alors désigner un autre compte github comme étant le compte officiel auquel les pull-requests devront être adressées.
• il faut un administrateur du serveur web où le site des GV est hébergé (même problématique de gestion démocratique d'un serveur que les autres services que les GV hébergent jusqu'à présent)
• les pull requests qui contiennent du code de mauvaise qualité (ou qui introduisent des régressions/dysfonctionnements) peuvent être acceptées par la communauté, puisque l'avis des développeurs qui peuvent déceler ce genre de problème compte autant que les autres. Il n'y a pas de comité de développeurs chargé de l'évaluation préalable de la qualité du code qui pourrait tuer des propositions de modifications avant leur passage au vote par la communauté. De telles entités de notation ou d'émission d'avis peuvent se constituer et mettre leur avis à disposition des membres de la communauté, mais ce seront ces derniers qui auront le choix final.
• ce protocole est peu adapté à l'utilisation d'une base de données, en particulier si le contenu textuel du site se trouve dans la base de données (exemples: les CMS Wordpress et Drupal). Il est plutôt recommandé de développer le site en documents HTML plus statiques

[modifier] 1.4 Avantages

• à part les administrateurs du serveur web (sauf si on trouve une manière démocratique d'administrer un serveur web), il n'y a pas d'entités antidémocratiques, comités ou cercles restreints ayant l'exclusivité de certaines actions ou décisions.
• ce protocole est fortement inspiré de celui de Loomio, et de nombreux projets open-source utilisent le principe du pull request (mais l'acceptation du pull request n'est en général pas faite démocratiquement), qui augmente énormément le dynamisme des projets lorsqu'il est utilisé (il facilite grandement la participation de la part de membres de la communauté qui ne font pas partie du noyau originel de contributeurs au projet)

[modifier] 1.5 Notes techniques et site de test

Voir SitePresentation:NotesTechniques_et_SiteDeTest

[modifier] 1.6 Exemples de cas d'utilisation

[modifier] 1.6.1 Modification du contenu textuel d'une page du site

TODO

[modifier] 1.6.2 Modification du design du site

TODO

[modifier] 1.7 Références

• https://github.com/loomio/loomio/wiki/2-Development-process

[modifier] 2 Groupe facebook (obsolète, remplacé par un groupe Loomio)

https://www.facebook.com/groups/creationsitevitrineGV/