dosons !    ( >>> dosing )

 alternative / complément aux votes & référendums

    brainstorming pour initier un cahier des charges

L’essentiel, en 3 points.

Do_0 (* voir note en bas de page)

L'Etat reconnaît officiellement, entretient, et archive des "cahiers de doléances" publics.
( en attendant, on fera comme si, en posant que l’Etat, c’est nous : les citoyens de bonne volonté ).

Do_1

Chacun dispose officiellement de 1000 "points de participation" politique citoyenne …
( en fait le principe c’est chacun dispose d’une voix … Mais on va passer par des chiffres, et les décimales risquent de paraître insignifiantes ... )

Do_2

Chaque citoyen peut cautionner toute "doléance" consignée dans un des ces  "cahiers de doléances" par un pourcentage (éventuellement avec décimale) de ses "points de participation".

   - - - - - - - - - - - - - - -

Table des matières :

L’essentiel, en 3 points.

réalisation :

Notes

couverture logicielle :

a priori d'architecture générale

Considérations fonctionnelles

 réalisation :

Do_2A

   Essayons d'esquisser le cahier des charges d'une proposition logicielle …

Do_2A1

* logiciel collaboratif (= logiciel libre , "open source") mais, de plus, en "paternité collective" : c'est à dire que tous sont appelés à partager l'effort de créativité et la 'paternité' du projet.

Do_2A1a

  rendre la participation au développement accessible au plus grand nombre de motivés
En utilisant des logiciels libres.  En partageant des outils logiciels non réservés à des minorités ...


 
___________________________________________________________________

Notes

(* note sur le présent repérage des objectifs)

Ce repérage simple est improvisé.  Si quelqu'un a une meilleure idée ...

 Il vise à une utilisation simple et intuitive - en évitant de contraindre d’emblée à une usine à gaz d’experts qui risquerait de refroidir les élans … '

Nota Bene :

   ceci n'est que le premier jet d'une ébauche de suggestion collaborative.

  Les mots (exemple 'curseur', 'doléance', 'curseurs-doléance' ...) se cherchent encore et devront être 'standardisés' par le fruit d'une stabilisation collective …
 ___________________________________________________________________


couverture logicielle :

Do_2A2

Do_2A2a

  -  essayer un développement susceptible de pouvoir être adapté en tout ou en partie(s) à un maximum d'équipements matériels divers ( PC, téléphones, …)

 

Do_2A2b

  - essayer un développement modulaire susceptible de permettre une certaine souplesse d'adaptation à des présentations diverses. ( Présentation concentrée des ‘curseurs’ dans un même logiciel, ou possibilité d’une gestion-présentation  éclatée …)

Do_2A2c

  - si possible, favoriser au passage la possibilité donnée aux bénévoles d'extraire des composants logiciels (rapides utilitaires pratiques) pouvant être utilisés dans des projets ou réalisations simples sans aucun rapport avec ce ‘Dosons’.

Do_2A2d

  permettre, préparer et encourager toute facilité de "reverse engineering" (rétroingénierie)  partagé, tout en privilégiant les outils et approches susceptibles d'être compréhensibles et accessibles par le plus grand nombre …


 a priori d'architecture générale

Do_2A3

 

Do_2A3a

  Envisager 3 étages de développement :

   - un ou des ensembles logiciels à disposition permanente de chaque utilisateur (pour que chacun dans son coin positionne ses propres curseurs)  : 'en live' ou pas, c'est à dire connecté ou non à un réseau numérique. (voir Do_2A4)

   - un ensemble logiciel ouvert pour collecter les données livrées par chacun des utilisateurs (voir Do_2A5 )

   - un ensemble logiciel ouvert plus dédié aux contrôles ou analyses globaux (sécurité, confidentialité, statistiques ...) (voir Do_2A6)

   ( Ceci, bien sûr, en parallèle avec les gestions de projet et services de mises à jour ...)

Do_2A4

 logiciel-utilisateur permettant à chacun de positionner ses propres curseurs

 considérations fonctionnelles

Do_2A4a1

  essayer de co-adopter un 'langage' commun (imagé, intuitif) dans la mise en place des concepts et développements. Il ne s'agit pas ici d'évoquer un langage-informatique particulier, mais des mots à inventer et à adopter pour désigner des concepts fonctionnels propres au projet.

Do_2A4a_x

   ( Dans l'élaboration des concepts ou du codage, ne pas hésiter à utiliser du 'franglais'

  ... puisque nous sommes ici dans un environnement de citoyens-utilisateurs-développeuers-bénévoles majoritairement francophones, mais qu'on le peut pas occulter l'intérêt et la quasi-nécessité d'utiliser l'anglais pour le développement et ses outils )

Do_2A4a3

   permettre une utilisation logicielle soit en autonome, déconnectée de tout réseau, soit en mode connecté, soit alternativement connecté puis déconnecté.


Considérations fonctionnelles

Do_2A4b

 

concernant la présentation des curseurs

Do_2A4b1

Les curseurs (associés à chacune des doléances retenues par chaque utilisateur-citoyen) seront très certainement nombreux et présentés selon une ou des hérarchies de classifications arborescentes

Do_2A4b2

 Permettre la mise en oeuvre de différentes classifications, y compris concernant parfois des lots conceenant les mêmes doléances (hiérarchiquement classifiées de façons différentes)

Do_2A4b3

 Permettre un affichage compact (en surface affichée) pour chaque "curseur-doléance".

voir : vision pratique => (http://www.imparfaits.webatu.com/2_1_base-D-OSONS.html#vision_pratique)


    SVP , dès maintenant  … corrigez, suggérez, proposez … à plus!

 et c’est loin d’être fini (en fait ça ne fait que commencer ) :

dès très bientôt , nous apporterons des  suggestions plus détaillées ….

 SVP  , n’hésitez pas à modifier ce texte pour y apporter vos idées ou remarques
( s’incrire  à Google document  … en attendant peut-être la proposition d’un autre outil de rédaction collaborative …)

alternative sans inscription , avec Framapad :   https://framapad.org/Ikq9SDwB6C

(si vous êtes réfractaire à Google ou trop timide pour vous y inscrire
 au prix toutefois d’une mise en page et présentation plus spartiates … )