Différences entre les versions de « Discussion:Cahier des charges pour le GDA de nos rêves... »

De April MediaWiki
Aller à la navigationAller à la recherche
(Nouvelle page : Sans entrer dans la guerre des langages informatiques, la question du choix technologique se pose. S'il s'agit d'installer facilement le logiciel à peu près n'importe où, le choix...)
 
 
Ligne 4 : Ligne 4 :
  
 
[[Utilisateur:Vic|Vic]] 13 novembre 2008 à 18:02 (CET)
 
[[Utilisateur:Vic|Vic]] 13 novembre 2008 à 18:02 (CET)
 +
 +
== oui un logiciel est le bienvenu pour la gestion autonome et coopérative des associés ==
 +
 +
Bonjour, ça me fait plaisir de lire cette page, car j'avais cherché un logiciel pour la gestion d'une association de jardinage (à savoir http://burthecourt.com) et j'avais été surpris qu'il n'existe pas une catégorie framasoft pour la gestion des personnes, je pensais naïvement qu'il existait plein de ''People (Co-operative) Management System''.
 +
 +
(je suis allé voir http://www.agora-project.net/ grisbi gDTC et gallette mais je ne crois qu'ils répondent à nos besoins, je ne connais pas les solutions proposées [[Logiciels de Gestion D'Association (GDA)|ici]], sans doute aurais-je pu construire ce dont j'ai besoin si je savais coder. Je regarde http://demo1.dolibarr.org et peut-être saurait-il me satisfaire)
 +
 +
Le pourquoi du besoin :
 +
 +
Burthecourt-aux-Chênes est un petit village à 10 km de Nancy. Gabriel possède une petite maison, retape une ferme et cultive un champs. Ceux qui le veulent sont invités à venir cultiver le champ et à se partager ses récoltes. Humainement, c'étaient un noyau (Gabriel + 1 personne), un coeur (moins de cinq personnes), une enveloppe (quelques citadins et une poignée de villageois (car ils ont chacun leur jardin)) et les électrons plus ou moins libres (plusieurs dizaine de citadins) qui gravitaient sur ces terres.
 +
 +
En pratique il y a 3 choses à co-gérer :
 +
*les personnes  (coordonnées, disponibilités, degrés d'investissement (''casquettes'' qu'on veut porter, rôles qu'on veut jouer et mandats qu'on éxécute), listes mail)
 +
*les tâches (nature (évènement, labeur..), calendrier (étapes et régularité), participants, besoins de participation et importance (avec mailing selon))
 +
*les monnaies ([http://www.sol-reseau.org au] [http://isosel.free.fr/ pluriel], avec plusieurs comptes)
 +
 +
selon 3 impératifs :
 +
* autoriser les procurations multiples (j'ai untel au téléphone qui me communique sa disponibilité, je dois pouvoir la signaler à sa place, quitte à ce qu'un mail lui demande confirmation à posteriori, et quitte à ce qu'il m'interdise de le faire s'il le souhaite.)
 +
* transparence (qui a quels droits et qui a ajouté quelles données quand, ''timeline'')
 +
* rapidité d'utilisation : les champs à remplir sont pré-remplis. (exemple: la tâche est de base à échéance infinie, de priorité nulle et sans étape)
 +
 +
Enfin, pour l'accessibilité de cet outil, ce serait bien qu'un de vos serveurs permette son utilisation immédiate, puis son exportation lorsque un des associés (ou l'association) aura un serveur.
 +
 +
 +
 +
 +
A défaut de réaliser tout ce travail de développement, un simple serveur de listes en libre accès serait '''très''' utile. (exemple: les co-opérateurs de [http://lanef.com notre banque] sont 360 [http://nef.marcelet.com en Lorraine], presque un tiers ont une adresse mail et le correspondant lorrain les gère en les ajoutant dans un groupe de contact gmail, à défaut d'avoir su où créer une liste invitant chacun à gérer lui-même son inscription) Mais peut-être votre service http://www.april.org/wws/create_list_request est-il déjà ouvert ?
 +
 +
Cordialement, [[Utilisateur:Gourgandin|Gourgandin]]

Dernière version du 25 novembre 2008 à 02:16

Sans entrer dans la guerre des langages informatiques, la question du choix technologique se pose. S'il s'agit d'installer facilement le logiciel à peu près n'importe où, le choix php/MySql s'impose car il est le plus répandu voire le seul disponible chez les hébergeurs. Cependant, si le logiciel prend de l'ampleur, il risque de toute façon de manquer de ressources dans le cadre d'un hébergement mutualisé : si le logiciel nécessite son propre serveur ou un serveur virtuel (ce qui complexifie évidemment l'installation), on peut envisager d'utiliser d'autres langages. L'idéal de mon point de vue, ce serait de définir des formats d'échange XML robustes entre les différents modules afin de permettre des échanges entre des outils programmés dans des langages différents. Autrement dit, les différents module seraient susceptible de fonctionner comme des webservices par rapport aux autres.

Par exemple, on pourrait imaginer un module « lettre d'information » écrit en Python qui irait récupérer les noms et les courriels des adhérents dans le module « Gestion des adhérents » qui serait lui écrit en Php et qui fournirait ces informations au format XML. Ce qui est fondamental ici, ce n'est pas la programmation du module lui-même mais bien la définition des protocoles d'échanges.

Vic 13 novembre 2008 à 18:02 (CET)

oui un logiciel est le bienvenu pour la gestion autonome et coopérative des associés[modifier]

Bonjour, ça me fait plaisir de lire cette page, car j'avais cherché un logiciel pour la gestion d'une association de jardinage (à savoir http://burthecourt.com) et j'avais été surpris qu'il n'existe pas une catégorie framasoft pour la gestion des personnes, je pensais naïvement qu'il existait plein de People (Co-operative) Management System.

(je suis allé voir http://www.agora-project.net/ grisbi gDTC et gallette mais je ne crois qu'ils répondent à nos besoins, je ne connais pas les solutions proposées ici, sans doute aurais-je pu construire ce dont j'ai besoin si je savais coder. Je regarde http://demo1.dolibarr.org et peut-être saurait-il me satisfaire)

Le pourquoi du besoin :

Burthecourt-aux-Chênes est un petit village à 10 km de Nancy. Gabriel possède une petite maison, retape une ferme et cultive un champs. Ceux qui le veulent sont invités à venir cultiver le champ et à se partager ses récoltes. Humainement, c'étaient un noyau (Gabriel + 1 personne), un coeur (moins de cinq personnes), une enveloppe (quelques citadins et une poignée de villageois (car ils ont chacun leur jardin)) et les électrons plus ou moins libres (plusieurs dizaine de citadins) qui gravitaient sur ces terres.

En pratique il y a 3 choses à co-gérer :

  • les personnes (coordonnées, disponibilités, degrés d'investissement (casquettes qu'on veut porter, rôles qu'on veut jouer et mandats qu'on éxécute), listes mail)
  • les tâches (nature (évènement, labeur..), calendrier (étapes et régularité), participants, besoins de participation et importance (avec mailing selon))
  • les monnaies (au pluriel, avec plusieurs comptes)

selon 3 impératifs :

  • autoriser les procurations multiples (j'ai untel au téléphone qui me communique sa disponibilité, je dois pouvoir la signaler à sa place, quitte à ce qu'un mail lui demande confirmation à posteriori, et quitte à ce qu'il m'interdise de le faire s'il le souhaite.)
  • transparence (qui a quels droits et qui a ajouté quelles données quand, timeline)
  • rapidité d'utilisation : les champs à remplir sont pré-remplis. (exemple: la tâche est de base à échéance infinie, de priorité nulle et sans étape)

Enfin, pour l'accessibilité de cet outil, ce serait bien qu'un de vos serveurs permette son utilisation immédiate, puis son exportation lorsque un des associés (ou l'association) aura un serveur.



A défaut de réaliser tout ce travail de développement, un simple serveur de listes en libre accès serait très utile. (exemple: les co-opérateurs de notre banque sont 360 en Lorraine, presque un tiers ont une adresse mail et le correspondant lorrain les gère en les ajoutant dans un groupe de contact gmail, à défaut d'avoir su où créer une liste invitant chacun à gérer lui-même son inscription) Mais peut-être votre service http://www.april.org/wws/create_list_request est-il déjà ouvert ?

Cordialement, Gourgandin