Libre en cadeau

	Bienvenue sur une campagne
	du groupe de travail Sensibilisation

---

/!\ Travail en cours /!\

Cette page présente une campagne de libre en cadeau en cours de réalisation.

Si vous souhaitez participer, n'hésitez pas à laisser votre avis sur la page de discussion en suivant au mieux ces recommandations.

Présentation

Libre en cadeau est un nom provisoire pour un projet de campagne visant à favoriser le financement de logiciels libres.

L'idée est de proposer un site qui s'adresse aux libristes et qui lui permette d'inciter ses amis à lui offrir des logiciels libres, c'est à dire à verser une contribution financières à ces projets en guise de cadeau au libriste dont c'est, par exemple, l'anniversaire.

Cpm (discussion) : à chaque fois que je relis le mail suivant, j'ai l'impression d'avoir tout compris sur ce qu'il faut faire, pourquoi et comment.

Le 20/07/2015 17:55, sur april@april.org, sujet « Re: [April] Dons au LL. », Luc Fievet a écrit :

L'idée m'est venue lors d'un anniversaire. J'avais constaté l'année précédente que les cadeaux qu'on m'offraient pour mon anniversaire étaient souvent superflus. Beaucoup de gagdets rigolos mais inutiles, des livres pas toujours intéressants... À vrai dire, je n'ai pas réellement besoin de cadeaux, c'est une tradition pourtant incontournable (j'ai tenté le "pas de cadeaux", mes invités ne sont pas obéissants). C'est donc à chaque fois des dizaines d'euros qui passent dans des trucs superflus généralement produits dans des usines à l'autre bout de la planète. Ça fait plaisir sur l'instant mais le lendemain, j'ai souvent un sentiment de gâchis.

J'ai donc demandé à ce qu'on m'offre des logiciels libres. J'ai précisé la liste des logiciels que j'apprécie et que j'utilise. Mes amis ont fait des dons (certains on peut-être menti) à ces projets.

Mon idée est donc d'essayer de favoriser la démarche en incitant les libristes à demander à leurs amis et leur famille de leur offrir du logiciel libre.

Des outils permettraient de rendre les choses plus faciles : créer un compte sur un site où on puisse dresser sa wishlist, proposer des services de mailing/fourniture de template pour expliquer tout ça à ses amis (et le cas échéant leur donner la date le lieux etc...) et fournir toutes les infos pour savoir où donner et finalement permettre aux amis de déclarer leur cadeau (j'ai donné x euros à tel projet) en l'échange du télécharger une petite illustration à imprimer qu'ils puissent remettre à la personne dont c'est l'anniversaire (parce que la remise physique, c'est important.

Le montant des dons resterait secret bien sûr mais on pourrait ensuite communiquer sur la somme totale réunie pour ces logiciels.

Intérêts potentiels de "Libre en cadeau"

• Attirer des non-libristes
• Utiliser de l'argent déjà dépensé à meilleur escient
• Ne pas demander aux projets de s'inscrire

Historique

• Projet lancé au printemps 2015
• Fin de la phase de brainstorming fin septembre 2015
• Début de la phase d'architecture n°1 octobre 2015

Cas d'utilisation

Déroulement de scénarios illustrant comment ça peut pouvoir se passer.

Schéma Premier jet

premier jet de schéma (le wiki de l'april n'accepte pas le format, je n'ai pas pu l'y adjoindre

Point de vue du destinataire :

Point de vue du donneur :

Simple visiteur anonyme

Cas 1

• Arrivée sur la page d'accueil
• Voit une explication rapide de l'objectif du site avec :
  • Un cas "je veux organiser mon anniversaire" => renvoi vers fonction adhoc
  • Un cas "Je veux faire un cadeau" => renvoi vers une page howto expliquant qu'il a dû recevoir une invitation de son ami
• Voit les déclaration d'amour d'utilisateurs à leur logiciel favoris
• Voit les chiffres de dons générés par le site (nb d'anniversaire organisés, total des dons, projet le plus soutenu...)

Libriste désirant recevoir un beau cadeau

Cas 1

• Arrivée sur la page d'accueil
  • Un texte explique le principe du site
  • Un lien "je veux qu'on m'offre du libre"
  • Un lien "je voudrai offrir du libre"
  • Des liens institutionnels/technique (contact, plan du site, faq, qui sommes nous, disclaimer, raccourci identification etc...)
• L'utilisateur clique "je veux qu'on m'offre du libre"
• L'utilisateur est invité à créer un compte
  • mail, mot de passe obligatoire
  • Date de naissance, prénom facultatifs
• L'utilisateur accède à son interface avec des liens
  • Changer mes données personnelles/mdp
  • Créer une nouvelle invitation
• L'utilisateur crée une nouvelle invitation
• La wishlist s'affiche elle propose un nombre de projet limité (5 par exemple à renseigner)
• Un champ de recherche permet de chercher dans la base des projets disponibles, un bouton permet de rajouter un nouveau projet
• L'utilisateur sélectionne 4 projets.
• A chaque projet sélectionné, l'url de la page de don s'affiche, les modes de paiement et la langue de la page sont indiqués. Un bouton "vérifier l'url" et un bouton "signaler une erreur sur un projet" sont disponibles pour chaque projet
• L'utilisateur clique sur le bouton vérifier l'URL de ses projets. Les pages de paiement des projets s'ouvrent dans un nouvel onglet.
• L'utilisateur clique ensuite sur le bouton"ajouter un nouveau projet".
• Un formulaire lui permet de décrire le nouveau projet. Il contient notamment :
  • Nom du projet
  • Licence du projet
  • URL vers la licence du projet
  • URL vers la page de paiement du projet
  • Liste des moyens de paiement acceptés
  • Langue de la page
  • Bouton : proposer le projet à la modération pour ajout à la liste des projets
• L'utilisateur renseigne le formulaire et ajoute le projet à sa wishlist. Il rajoute s'il le souhaite une déclaration d'amour pour chacun des logiciels qu'il a sélectionné. Il peut soumettre sa déclaration à la modération en optin.
• Un formulaire lui demande de préciser la date de l'événement ou l'URL d'un sondage (lien proposé vers Framadate) pour trouver une date ou un champ texte libre. Il demande aussi l'horaire avec possibilité de rentrer une plage horaire. L'utilisateur le renseigne et valide
• Un formulaire lui demande de préciser le lieu et les accès de l'événément :
  • Adresse, l'adresse est géolocalisée par OSM. Les coordonnées sont automatiquement indiquées en complément de l'adresse. Elles sont manuellement modifiables
  • champ texte pour les codes, étages et autres
• Un formulaire de texte d'accompagnement permet de rédiger le texte d'accompagnement. Des paragraphes types pour expliquer la démarche de se faire offrir un logiciel libre sont proposés.
• Un formulaire permet de rentrer l'URL d'un sondage classique (confirmation de présence). Un raccourci permet d'en créer un rapidement
• Des illustrations d'accompagnement sont sélectionnables.
• L'utilisateur valide son invitation. Il obtient un template de mail et une URL en téléchargement.
• Annonce sa liste à ses amis en partageant le lien ou en envoyant le template (sa liste est visible par une url avec un hash type : projet/liste/29R99CN9ZEN9EFND9DV9UNC9EF467

Ami désirant acheter un beau cadeau au libriste

• L'ami reçoit un mail avec toutes les informations sur l'événement, un texte d'invitation, les liens vers les éventuels sondages de date et/ou de confirmation de présence. Un texte suggère à l'ami de lui offrir un logiciel libre dont il trouvera la liste en cliquant sur un lien.
• L'ami clique sur le lien, une page s'ouvre avec chacun des x projets (max ?) choisis par l'utilisateur. Chaque projet est accompagné d'information de description la langue de la page, de moyens de paiement acceptés par le projet et le cas échéant de la déclaration d'amour rédigée par l'utilisateur.
• Sélection d'un montant à donner (montant minimal ?). Il est facultatif et invite l'ami à déclarer le montant qu'il compte donner. Il est précisé que le montant ne sera pas communiqué à l'utilisateur dont c'est l'anniversaire et qu'il n'est pas obligatoire de l'indiquer.
• Sélection d'un projet
• Sélection de l'affichage du montant pour le libriste ou pas
• Paiement du cadeau
  • Passage par le site du projet offert et paiement selon modalités locales.
• Obtention un truc à imprimer par l'ami aussi pour un cadeau physique.

Libriste ayant un projet à ajouter

• Même scénario que précédemment, mais lors de l'ajout d'un projet, il décide d'en ajouter un plutôt que de sélectionner un existant.
  • Rien n'empêche le libriste de coller son propre projet
  • Un nouveau projet peut être proposé à la modération pour être ajouté à la liste des projets dispos
  • Le nouveau projet est directement utilisable par la personne qui l'a créé. Il n'est pas persistant sauf si la modération l'ajoute à la liste.

Ateliers/Débats

Faut-il permettre d'envoyer un message à son ami quand on lui a fait un cadeau ?

CONCLUSION : le site n'est pas conçu comme un outil de communication/anniversaire virtuel.

Options

Plusieurs options sont envisageables :

• Proposer une carte postale de soutien sur le site en vente libre et proposer à un maximum de projet de faire la même chose
• Monter un site spécifique qui permette de choisir des projets à soutenir et de les proposer à ses amis. Soit :
  • En regroupant un maximum de projets dans un réseau qui permette de leur redistribuer l'argent qui a été collecté en cadeaux.
  • En redirigeant les utilisateurs vers les pages de don de leur site web
    • intégrant un formulaire permettant au libriste de déclarer n'importe quel projet de son choix, qui sera modéré à posteriori pour être ensuite sélectionnable par d'autres utilisateurs.
    • Sur une liste de logiciels maintenue par les administrateurs du site.

Un projet doit-il être enregistré pour pouvoir être destinataire d'un don ?

Mindiell : « permettre de lister les projets auxquels ils souhaitent donner (plus simple, les libristes ajoutent des projets (à modérer) eux-mêmes) »

Cpm : peut-on envisager des projets non avalisés par le site ? Comment le trésorier remet-il l'argent ?

Pour moi, il faut penser le site sans manipulation d'argent pour sa première version en tout cas. Trop compliqué, trop casse gueule pour un démarrage je pense. LucFievet (discussion)

Je ne comprends pas ce que tu veux dire pas "sans manipulation d'argent" car c'est le concept même du projet "Libre en cadeau" (donner de l'argent). Par contre oui, il faut que chaque projet soit validé. Certains projets n'ont pas de page de don, ou c'est compliqué (j'ai eu la problématique pour donner de l'argent à un projet pour le "Calendrier du Libre"), voire ne veulent pas de dons (ça arrive). Par contre il ne faut pas que cela soit pas trop rébarbatif pour un utilisateur. Imaginons que j'ai mon anniv demain et qu'à la dernière seconde je veux m'enregistrer pour demander aux gens de donner au Libre. Mais mes projets cibles n'ont pas déjà été validés => je ne peux pas utiliser "Libre en cadeau"? Je pense que la validation ne doit pas bloquer les donations. Simplement celles-ci ne seront distribuées effectivement qu'après validation. Et si on se rend compte à ce moment là que le projet n'est pas valide (pour une raison ou une autre), on en avertit l'utilisateur qui peut alors décider de redistribuer la part destinée à ce projet ailleurs par exemple. Jehan (discussion) 5 août 2015 à 16:39 (CEST)

La version simple à mon sens consiste à laisser les donneurs et les projets se débrouiller entre eux. Pour le donneur, mettre son n° de CB sur paypal ou sur un site de l'April ne fait pas une grosse différence en terme de complexité. Pour ce qui est des projets inexistants dans le site, j'imaginais qu'un utilisateur puisse rajouter les projets de son choix, sans modération au travers d'un formulaire type pour son propre anniversaire. La modération n'interviendrai qu'à posteriori pour valider l'entrée de ce projet dans la liste. C'est l'utilisateur qui fait le boulot de description et de listage des projets. Ce qui m'ennuie avec le rôle d'intermédiaire, c'est le nombre et la complexité des tâches potentielles, l'exigence que représente la manipulation d'argent. Je redoute le projet beau techniquement mais associativement trop lourd à gérer.LucFievet (discussion) 6 août 2015 à 12:55 (CEST)

A mes yeux, le donneur risque de se perdre si on lui donne une liste de projet sur laquelle il faudra qu'il aille pour trouver la page de don, d'ou l’intérêt de centraliser les paiements, le donneur paye sur le site "LibreEnCadeau" puis nous on dispatche, effectivement cela rajouter de la complexité tant en ressource humaine qu'en technique, maintenant, c'est le plus simple pour l'utilisateur lambda (et surement le plus clair aussi). Cela dis, dans un premier temps on peux peut être essayer sans et voir les premiers retours utilisateurs de ceux qui ne vont pas jusqu'au bout de la procédure dans l'optique dans tirer des conclusions ? :) Rbataille (discussion) 6 août 2015 à 15:43 (CEST)

L'idée est de lui mettre un lien direct vers la page de don du projet à soutenir. Je ne vois rien d'insurmontable à dire à quelqu'un : si tu veux fait un don à Inkscape. A charge pour l'utilisateur d'indiquer l'URL de la page de don quand il crée une nouvelle description de projet. S'il estime que les choix de moyen de paiement sont trop compliqués pour ses amis (imaginons par exemple un projet qui ne prendrait que le bitcoin), c'est lui qui fait ses choix, connait les capacités et la motivation de ses amis LucFievet (discussion) 6 août 2015 à 17:14 (CEST)

Mindiell : Je dirais non, les projets, pour être avalisés doivent avoir un moyen (simple) de leur fournir de l'argent: Paypal, virement, don, etc... Sinon, ça va être super galère.

Luk : Ca ne devrait pas être une obligation. Essentiellement pour ne pas contraindre l'utilisateur à attendre une modération pour pouvoir poursuivre.

CONCLUSION : il n'est pas obligatoire de faire valider un projet par la modération avant de pouvoir l'utiliser dans son anniversaire. En revanche, seuls les projets validés sont disponibles à la sélection. Du coup, il est possible d'intégrer un projet non libre mais sous la seule responsabilité de l'utilisateur et de ses amis. Les dons à ces projets non validés sont consolidés dans les stats sous une même catégorie autre. L'intérêt est de retirer un frein à l'utilisation.

Monolingue vs multilingue ?

Possibilités :

• monolingue :
  • français,
  • anglais,
  • esperanto,
• multilingue :
  • français + anglais
  • français + anglais + esperanto

Jehan (23/072015) : pour moi, le multilingue, avec anglais et français pour commencer, est un minimum par défaut. Tout projet franco-français ne pourra jamais se faire une place.

CONCLUSION : français + anglais au minimum

Quel est le périmètre géographie ?

Plusieurs possibilités :

• France ;
• francophone européen ;
• EU ;
• autres.

Jehan (23/07/2015) : au minimum UE d'après moi.

LucFievet (discussion) 27 juillet 2015 à 11:54 (CEST) Quel sens donnez-vous au périmètre géographique ? Par rapport à quelles fonctionnalités ?

Je pense que la question était: en faveur de projets dans quels pays (comme ça que je l'ai compris en tous cas). En fait je crois que c'est surtout une question d'échange de monnaies. L'APRIL reçoit de l'argent en EUR. Or si on donne à une fondation aux US par exemple, surtout pour les petites sommes, on peut facilement se retrouver à donner plus aux banques qu'au projet destinataire (surtout pour les pays qui n'ont pas IBAN. J'ai déjà eu à envoyer des sous vers de tels pays, ce n'est valable que pour des grosses sommes). En UE, l'avantage est qu'on est (presque) tous à l'EUR. Par contre beaucoup de projets ont leur base légale aux US (même quand les dévs sont quasi tous en Europe, c'est le cas par exemple de GIMP sous parapluie de la fondaton GNOME). Est-ce que ça veut dire qu'on s'interdit de donner à ces pays?

Plutôt que faire cela, on peut probablement établir des règles du type "l'argent est bloqué tant qu'une certaine somme n'est pas atteinte". Si l'argent reste bloqué trop longtemps, alors on peut proposer aux utilisateurs (ceux qui "reçoivent du libre en cadeau") s'ils souhaitent rediriger les fonds vers un autre projet. En outre, l'avantage est que beaucoup de projets étant sous des projets parapluies, on peut atteindre les sommes requises rapidement (une donation peut être destiné à GIMP + GNOME + GTK+ en une seule fois à la fondation GNOME avec commentaire expliquant quel pourcentage pour quel projet).

Un dernier point: je ne suis absolument pas fan de paypal, mais force est de constater que c'est avantageux pour les transferts internationaux. Par exemple il permet de garder des comptes dans d'autres monnaies. Par exemple en USD, ce qui éviterait de devoir faire se taper 2 taux de change de monnaies si un habitant aux US donne (change USD -> EUR) en destination d'un projet US (change EUR -> USD). En outre pour les virements internationaux, ils ont souvent de plus petits frais (alors qu'à l'inverse, en inter-Europe, il est bien plus intéressant de faire un virement bancaire, en général sans frais!).

Au final, cela fait beaucoup de questions et de travail pour trouver les meilleurs compromis (et éviter que le projet devienne juste un projet pour enrichir les banques seulement), mais ce sont des questions à se poser et un travail à faire, selon moi.

Jehan (discussion) 5 août 2015 à 16:58 (CEST)

Ca renvoie pour moi à cette complexité à gérer l'argent nous même. Faire de la simple organisation de l'info / mise en relation / fourniture de service permet de s'épargner toutes ces questions complexes et exigentes.LucFievet (discussion) 6 août 2015 à 12:58 (CEST)

Conclusion : pas de fonctionnalité financière dans la v1 donc pas de limite géographique

Faut-il un support physique pour le cadeau ?

• idées de supports physiques pour accompagner son cadeau
  • imprimer une carte : d'anniversaire, de joyeux noël, de bonne année, autre...
  • imprimer un origami,
  • imprimer un diplôme,
  • imprimer une maquette en papier
  • imprimer un "bon du trésor en Logiciel Libre" avec un beau tampon dessus

Je suis absolument contre le concept de cadeau physique car cela invalide énormément le concept qui est de limiter le gâchis. Cette carte/maquette/diplôme (?!), on va en faire quoi? Le mette dans un tiroir pour le retrouver qques mois plus tard et le jeter. Or ça coûte de l'argent à créer, produire, emballer, livrer sans compter le temps humain. Sur les petites donations (nos potes ne donnent pas tous des cadeaux d'anniv de 100 EUR; beaucoup, surtout chez les jeunes, c'est 10 EUR!), cela peut faire 50% du prix parti en intermédiaires, tout ça pour un truc inutile. Jehan (discussion) 5 août 2015 à 16:43 (CEST)

On parle ici d'un truc à imprimer soi-même à la maison. L'idée est de conjurer la difficulté qu'ont les gens de venir les mains vides.LucFievet (discussion) 6 août 2015 à 13:07 (CEST)

CONCLUSION : Le support physique est très important pour ne pas arriver les mains vides, ce qui est socialement intenable. C'est en revanche un cadeau auto-administré (une page à imprimer, pas un goodie produit et envoyé par la poste au détriment du projet soutenu

Faut-il gérer l'argent des dons ?

Pour moi, occuper une place d'intermédiaire est trop compliquée pour un démarrage.C'est beaucoup de travail de mise en place, de modération et ça limite le droit à l'erreur.

Il faudrait pour bien faire pouvoir faire évoluer le service dans ce sens mais je trouve plus raisonnable de commencer sur un simple service de mise en relation. Les donneurs se débrouillant avec les systèmes de dons des projets qu'ils soutiennent. A nous de les orienter sur les bonnes pages. LucFievet (discussion)

Un autre problème se posera si on ne gère pas les dons, comment fait-on pour être sûr que l'utilisateur a bien donné au projet ? Rbataille

Si on ne gère pas nous même, je ne pense pas que ça puisse marcher. Comme Rbataille le mentionne, déjà on ne peut plus savoir si quelqu'un a donné (et on ne peut donc pas envoyer d'email au réceptionneur du don). Ensuite cela complexifie la tâche pour les donateurs, ce qui réduit énormément l'intérêt du projet. On parlait de "wishlist". Or à part si les donateurs vont d'eux même sur chaque item de la liste, ils iront tous juste sur le premier (ou seulement le prétenderont). En outre, je sais pas pour vos contacts, mais s'ils arrivent sur une page en anglais, ils vont même pas chercher à lire. Les geeks, c'est différent. Mais justement on cible les contacts non-geek des geeks, non? Or la plupart des projets ont leur page web en anglais seulement. L'intérêt de Libre en Cadeau était justement de proposer une interface dans les diverses langues locales. Enfin bon, oui je suis d'accord, ce sera plus compliqué et cela donne un poids supplémentaire sur les épaules de l'APRIL. Mais je pense que c'est nécessaire si on veut que le site marche. Jehan (discussion) 5 août 2015 à 17:06 (CEST)

Conclusion : voir ci-dessous.

Faut-il/Peut-on accepter les dons par virement bancaire ?

Yannig38 : Pourquoi refuser cette possibilité ? Mettre le RIB du compte centralisateur est possible?

Cpm : parce-que ça fait faire une opération manuelle de pointage au trésorier, donc du temps ou des frais supplémentaires... Est-ce une suffisamment bonne raison ???

Mindiell : Il ne faut pas laisser le RIB visible mais le distribuer à la demande. Certains utilisent le RIB pour prendre des forfaits téléphoniques par exemple :o/ ...

Analyses comparative :

• + : pratique pour les gens
• + : moyen généralisé via la gestion en ligne de son compte bancaire
• - : nécessite une opération manuelle de pointage par le trésorier => temps et/ou frais
• ? : possibilité d'automatiser ?

Conclusion : voir ci-dessous.

Faut-il/Peut-on accepter les dons par Bitcoin / PayPal / Autre ?

Jehan (23/07/2015) : autant je ne suis pas adepte de l'idée de passer par Paypal, autant pour des virements internationaux (hors EU) les frais peuvent être considérablement amoindris comparé à des virements bancaires (dépend des pays)

Mindiell : Je pense que ça dépend surtout ce que peut accepter le projet, non ?

CONCLUSION : La V1 exclue la fonctionnalité monétaire. Il faut toutefois se ménager la possibilité de l'intégrer en V2. Les différentes questions posées soulèvent des questions très complexes qu'il faudra traiter au moment d'intégrer le paiement.

Faut-il avoir des statistiques de visites ?

Dans les fonctionnalités, on a « administration du site > consultation de statistiques de visites ».

Mindiell : vraiment nécessaire ? Un piwik alors, non ?

CONCLUSION : toujours utile mais ne doit pas être trop compliqué. Ce sont surtout les stats d'anniversaire et de don qui sont intéressantes

Un projet inscrit peut-il être supprimé ?

Dans les fonctionnalités, on a « Supprimer un projet »

Mindiell : Pour quelle raison ? Soit il est abandonné, soit obsolète, mais il y a peut-êtr eeu des dons dessus => Pas de suppression, mais désactivation plutôt.

On peut aussi imaginer qu'un projet tourne mal, se mette à faire du proprio ou des choses comme ça ou bien encore qu'il refuse absolument d'être sur notre site. LucFievet (discussion)

CONCLUSION : Désactivation d'un projet est la bonne solution.

Un évènement où offrir doit-il être nécessairement public ?

Dans les fonctionnalités, on a « page publiques > la liste des évènements en cours où offrir »

Mindiell : pas d'accord, je tiens à ma vie privée, et à ma liste privée. Si je veux faire un évènement public, je distribuerai l'url spécifique à tout le monde.

Cpm : c'est ton choix, d'autre doivent pouvoir faire un autre choix => ajouter une notion de visibilité à l'évènement. Proposition : rajout d'un statut à l'évènement (public, privé, anonyme) et retrait de « publique » dans « début de l'annonce ».

LucFievet (discussion) : A mon sens les événements sont nécessairement privés. On peut communiquer en disant qu'on en gère tant pour tant d'€ de dons mais à chacun de faire la publicité de son événement. C'est sans doute plus une logique de financement participatif que de lister des projets pour demander des sous. Le promoteur du libre est dans ce cas l'utilisateur. Le site n'est qu'un outil. C'est peut-être une vision un peu figée mais je crains qu'on brouille le message en faisant du site un outil de promotion et d'appel à financement.

CONCLUSION : Les événements restent privés.

Catégorisation et/ou tag des projets ?

Les projets doivent-ils avoir une catégorisation imposée ou libre ?

Y-a-t-il une différence entre catégorie et tag ?

Usage de tag plutôt que de catégories ?

CONCLUSION : fonctionnalité présente au niveau de la sélection des projets quand on crée sa wishlist. Les catégories (hiérarchiques) et les tag doivent être prédéfinis par l'administration de telle sorte que les soumission de projets soient homogènes dans leur catégorisation. Le choix catégories/et/ou tag reste à faire.

La relation trésorier/projet doit-elle être gérée par le site ?

Possibilités :

• peuvent être destinataire des dons, seulement les projets dont un référent officiel est déclaré sur le site à condition que celui-ci ait renseigné les bonnes infos pour le transfert des dons :
  • + : facilite la vie du trésorier,
  • - : implique le développement d'une gestion dédiée => lourd investissement,
  • - : nécessite la coopération des projets soutenus
  • - : Frais de gestion, besoin de main d'oeuvre

• tout offreur peut citer un projet et charge au trésorier de se débrouiller pour contacter le projet :
  • + : moins de fonctionnalités à développer => plus grande probabilité de réussite de concrétisation de LibreEnCadeau,
  • - : le trésorier doit se débrouiller pour entrer en contact avec chaque projet,
  • - : comment gérer les doublons de nommage dans les actions de consolidation ? (page publiques, pages comptables)
  • - : Frais de gestion, besoin de main d'oeuvre

Il est vrai que :

• dans un premier temps, ne pas coder une fonctionnalité aussi complexe, ça aiderait à la réussite de la concrétisation de LibreEnCadeau ;
• on peut penser que le trésorier peut gérer de lui-même quelques dizaines de contacts sans avoir besoin d'un outil spécifique dans le site.

Solution simple : assurer la mise en relation entre le donneur et le site sans toucher à l'argent. Ca me semble une option raisonnable pour rester simple et limiter le travail d'administration/animation. Par ailleurs servir d'intermédiaire peut également générer de la méfiance auprès des gens qui ne nous connaissent pas, notamment les projets étrangers. Il faudrait conserver la possibilité d'une évolution qui nous permettrait d'être des intermédiaires mais ça me paraît casse gueule de commencer par un aussi gros morceau.LucFievet (discussion) 27 juillet 2015 à 11:59 (CEST)

Donc, on pourrait partir sur l'idée que pas besoin de déclaration de LL obligatoire.

CONCLUSION : La V1 exclue la fonctionnalité monétaire. Il faut toutefois se ménager la possibilité de l'intégrer en V2. Les différentes questions posées soulèvent des questions très complexes qu'il faudra traiter au moment d'intégrer le paiement.

Le site doit-il faire référence aux sites des projets ?

Les pages du site LibreEnCadeau vont contenir des références à des noms de projets de LL. Ces références doivent-elles systématiquement pointer vers le site web officiel de chaque projet ?

RB: Je pense que oui, ça permet aux éventuels curieux d'aller voir pour plus d'information.

• Absolument oui. A mon sens, les pages devraient pointer aussi vers la page de paiement des projets et laisser les gens se débrouiller avec le projet. LucFievet (discussion)

Conclusion : <?>

Comment déclarer un projet de LL pour aller dans la liste des cadeaux offrables ?

Dans « Fonctionnalités > gestion de pages publiques > comment je propose un projet pour son ajout dans la liste des LL offrables », il y a deux entrées, une pour l'acteur « auteur d'un LL » et l'autre pour « utilisateur d'un LL ».

Mindiell : deux fois la même chose, donc, non ?

Cpm : nan, dans un cas, c'est l'auteur du LL qui veut proposer son LL, dans l'autre cas c'est un utilisateur du LL qui voudrait le voir inscrit. Suivant comment sont gérés les inscriptions de projet, ça peut être différent.

Luc : pour moi l'auteur de logiciel libre qui veut proposer son projet peut créer un compte, déclarer un projet et le soumettre à modération comme n'importe quel utilisateur. Cela évite de générer deux processus de soumission de projet différents.

Cpm : absolument d'accord. Là, on parle des pages rédactionnelles, qui donnent de l'information aux utilisateurs du site. Le fait de faire une page par profil d'utilisateur permet de mieux accompagner les différents types d'utilisateurs. Oui, c'est du marketing.

Faut-il des statistiques de visites ?

Dans « administration du site », on peut lire « consultation de statistiques de visites ».

Mindiell : vraiment nécessaire ? Un piwik alors, non ?

Cpm : quand tu administres un site web, c'est toujours bien de pouvoir répondre aux questions « Combien de visites ? », « Combien de clics », « Des erreurs ? », etc.

Faut-il pouvoir supprimer un projet ?

Mindiell : Pour quelle raison ? Soit il est abandonné, soit obsolète, mais il y a peut-être eu des dons dessus => Pas de suppression, mais désactivation plutôt.

LucFievet (discussion) : On peut aussi imaginer que le projet passe sous licence proprio ou vaguement ouverte et qu'il ne soit plus considéré comme libre. Ceci-dit, on risque d'avoir besoin de conserver la trace des dons. Il faudrait à minima pouvoir anonymiser un projet.

Vision

Je vois plus ça, personnellement (Mindiell) :

• Monter un site spécifique qui permette
  • aux libristes de s'inscrire
  • de lister les projets auxquels ils souhaitent donner (plus simple, les libristes ajoutent des projets (à modérer) eux-mêmes)
    • les projets déjà ajoutés sont alors sélectionnables simplement par n'importe quel libriste bien entendu...
  • à un utilisateur de venir et d'offrir XX€ à un libriste (sélection possible des projets ou pas (et donc libre au libriste de le faire)) avec la possibilité de choisir la date d'envoi du donc (et donc d'envoi du mail)
  • Le libriste recevra alors un mail à la date sélectionnée (si date sélectionnée) et est capable de voir tous les dons qu'il a permis

Cahier des charges (« Quoi faire ? »)

Contexte

Pour son anniversaire (ou tout autre évènement) demander à ses amis de nous offrir un logiciel libre. Dans la forme, faire un don à projet de logiciel libre mais au nom d'une autre personne, en synchronisation/liaison/lien avec un évènement particulier.

Rôles :

• visiteur : webonaute non identifié par sa connexion au site ;
• utilisateur : webonaute s'étant identifié via la page de login/mode de passe ;
  • offreur : utilisateur qui a offert un LL,
  • receveur : utilisateur à qui on a offert un LL,
• contact projet : utilisateur responsable d'un projet par rapport au site LibreEnCadeau,
• trésorier : responsable des validations et transferts d'argents vers les projets de LL ;
• webmaster : fait fonctionner le site uniquement via le site ;
• administrateur : fait fonctionner le site par tout moyen technique possible ;

Fonctionnalités

Arbre fonctionnel :

• gestion de pages institutionnelles :
  • À propos
  • Qui sommes-nous ?
  • Mentions légales
  • Contact
  • Données personnelles
  • Licence
  • FAQ

• gestion de pages rédactionnelles (tutoriels, howto, etc.) :
  • je suis offreur d'un LL, comment je propose un projet pour son ajout dans la liste des LL offrables,
  • je suis l'auteur d'un LL, comment je propose un projet pour son ajout dans la liste des LL offrables,
  • comment supprimer un projet, #Faut-il pouvoir supprimer un projet ?
  • présentation des supports cadeaux,

• gestion de pages publiques automatiques :
  • la liste des projets,
  • la liste des dons :
    • par projets, par donateurs, par receveur (de cadeaux), LucFievet (discussion) : Attention à ne pas permettre de savoir publiquement que telle personne a donné tant d'argent. On ne donne pas le prix d'un cadeau.
    • du jour, de la semaine, du mois, depuis le début du site,
  • la liste des évènements en cours où offrir, #Un évènement où offrir doit-il être nécessairement public ?

• gestion de news
  • création, édition, publication
  • flux RSS

• gestion de compte :
  • création : inscription, confirmation d'inscription => données pseudo + mail et c'est tout
  • fermeture,
  • gestion du mot de passe : mot de passe perdu, changement de mot de passe
  • édition du compte

• gestion de mes cadeaux offerts :
  • création :
    • choix du LL : un seul, une sélection manuelle, une sélection proposée, tous ceux disponibles,
    • intégration d'un framadate/sondage classique (pour confirmer qui vient ou pas etc), éventuellement sauvegarde des sondages d'une année sur l'autre
    • choix du montant, (trop limitatif pour les offreurs, non ?)
    • choix du mode de paiement, (trop limitatif pour les offreurs, non ?)
    • choix de la publicité (comment prévenir le destinataire du cadeau) :
      • mail,
      • SMS,
      • carte-postale web,
    • rédaction d'un message de l'offrant à l'offreur,
    • rédaction d'un message de l'offrant au projet du LL, (?)
    • rédaction d'un message du receveur vers le projet de LL, (?)
  • consultation,

• gestion de mes cadeaux reçus,
  • consultation de mes cadeaux reçus,=> La fonction peut-être superflue. Le cadeau physique devrait faire office de notification de cadeau reçu. LucFievet (discussion)
  • gestion de mes évènements pour recevoir des cadeaux :
    • création :
      • type de l'évènement : anniversaire, autre (?),
      • titre de l'évènement,
      • date de l'évènement,
      • statut de l'évènement : public, privé, anonyme
      • début de l'annonce de l'évènement, Mindiell : Contre une visu publique... Cpm rajout du statut de l'évènement et retrait de « publique » dans « début de l'annonce ».
      • liste des personnes à prévenir, Mindiell : Pas top d'utiliser des mails pour un envoi non demandé, c'est pas LinkedIn...
    • consultation :
    • relance des personnes à qui inviter à me faire un cadeau (?)
    • envoi de remerciements aux donneurs de cadeau (?)

• gestion de mes projets de LL qui peuvent être des cadeaux
  • création :
    • nom du projet,
    • catégorie du projet, tags ?
    • site web du projet,
    • rôle du contact : représentant légal, salarié, bénévole, autre (?) ???
    • mode de règlement : comment LibreEnCadeau transfert l'argent, (admin, pas à gérer par le libriste pour moi) Cpm si le libriste est le référent du LL alors c'est lui qui est le mieux placé pour indiquer au trésorier comment transférer l'argent.
    • statut de confiance : validation du projet par LibreEnCadeau,
  • transfert à un autre compte du site, (???)
  • édition,
  • suppression
  • rédaction de la page de présentation du projet => Déclaration d'amour au projet
  • consultation des cadeaux associés :
    • nombre de cadeau, montants, totaux,
    • par jour, par semaine, par mois, par semaine, par année,
    • visualisation des transferts d'argent :
      • déjà transférés,
      • restant à transférer,
      • liste des transferts,

• gestion financière : par le trésorier de LibreEnCadeau
  • consultation du compte comptable des projets ;
  • consultation des projets :
    • en attente de validation,
    • déjà validés,
    • rejetés,
  • consultation des transferts :
    • déjà transférés,
    • restant à transférer,
    • liste des transferts,

• administration du site :
  • gestion des comptes : consultation, bannissement, suppression,
  • gestion des projets : consultation, bannissement, suppression,
  • sauvegardes,
  • consultation de statistiques de visites,
  • détection automatique de transferts louches (!),
  • ...

Contraintes

Contraintes fonctionnelles :

• Ne pas donner le prix d'un cadeau : attention à ne pas permettre de savoir publiquement que telle personne a donné tant d'argent.
• langues : monolingue ou multilingue ? multilingue
  • français
  • anglais

Note: pour moi, le multilingue, avec anglais et français pour commencer, est un minimum par défaut. Tout projet franco-français ne pourra jamais se faire une place. Jehan (discussion) 23 juillet 2015 à 18:57 (CEST)

• monnaies :
  • euro,
  • bisous (note : fait toujours plaisir et pratique pour les tests)
  • bitcoin ?
• moyens de paiement :
  • Carte Bleue,
  • E-carte,
  • PayPal ?
  • virement bancaire ? (voir ateliers/débat ci-dessus)
  • chèque,
  • espèce,
• mode de règlement des projets :
  • virement bancaire,
  • Paypal,

Note: autant je ne suis pas adepte de l'idée de passer par Paypal, autant pour des virements internationaux (hors EU) les frais peuvent être considérablement amoindris comparé à des virements bancaires (dépend des pays) Jehan (discussion) 23 juillet 2015 à 18:57 (CEST)

• accessibilité
• ergonomique : adapté à un public non expert en informatique ;
• valorisation des projets, des donateurs et des receveurs de cadeaux ;
• respect des fuseaux horaires des utilisateurs ;
• pérennité des informations (dons).

Contraintes techniques :

• indépendance du système d'exploitation installé sur le poste client (GNU/Linux..., MAC-OS, Microsoft Windows) ;
• respect des normes web ;
• compatibilité multi-navigateur ;
• pays où être opérationnel :
  • France,
  • UE,
  • autre ?

Note: au minimum UE d'après moi. Jehan (discussion) 23 juillet 2015 à 18:57 (CEST)

• sécurité :
  • authentification forte,
• utilisation obligatoire de logiciels libres (8*>).

Au niveau des technos, on as une idée ? Cpm : dans un cahier des charges on décrit le « quoi faire », pas le « comment le faire » ;-)

Contrainte administratives :

• utilisation obligatoire de licences « libres » pour ce qui est produit :
  • pour le code du site web et des outils à côté : GNU AGPL,
  • pour les photos, triple licence : GFDL version 1.3 ou ultérieure, Creative Commons By Sa version 2.0 ou ultérieure, Licence Art Libre version 1.3 ou ultérieure,
  • pour le contenu : <?>
  • pour la marque du site (« Libre Cadeau ») : <?>
  • pour le logo de la marque du site : <?>

Exemple d'utilisation

Exemple de courrier d'anniversaire

Pour tester une version "légère" du concept de Libre en cadeau voici un exemple de courrier envoyé pour l'anniversaire de Lionel Allorge (discussion) :

---

Bonjour,

J'ai le plaisir de vous inviter à mon anniversaire que nous fêterons le samedi 12 novembre à partir de 20 heures à mon domicile.

Je ne souhaite pas de cadeaux, votre présence me suffira; toutefois, si vous souhaitez me faire plaisir, vous pouvez faire un don à un projet libre que j’apprécie dans la liste ci-dessous :

• L'association April : https://boutique.april.org/?fond=rubrique&id_rubrique=3
• Le navigateur internet Mozilla Firefox : https://sendto.mozilla.org/page/contribute/givenow-seq?source=base_url#page-1
• Le logiciel de dessin vectoriel Inkscape : https://inkscape.org/fr/nous-soutenir/faire-un-don/
• ...

Merci d'avance.

Lionel Allorge

Producteurs de contenu (blog...)

Pour les producteurs de contenus (musique, blog, vidéo), on peut imaginer que l'auteur propose à son public de donner à une sélection de LL. Pour cela, un "bouton" serait intéressant. François ^{[Pour me parler]}

Projets voisins

L'idée est-elle originale ? Des projets existent-ils déjà ? Des évènements voisins ont-ils déjà eu lieu ?

Hackadon

Le 24/07/2015 08:36, sur sensibilisation@april.org, sujet « Re: [SENSIBILISATION] Dons au LL », Bastien Guerry a écrit :

J'en profite pour vous donner une exclu : la troisième édition du hackadon aura lieu le 11 décembre 2015 dans un lieu encore inconnu.

Le hackadon c'est une soirée pendant laquelle des porteurs de projets libres (software, hardware, communs) présentent leur projet, et où on donne de l'argent aux participants pour qu'ils le donnent aux projets.

Ça marche très bien -- depuis deux ans, ~5000€ ont été distribués à des projets libres comme ça.

On remet ça avec plus d'argent, plus de projets, plus de donateurs.

Une super occasion pour présenter votre site, même si la deadline est un peu courte :-)

Informations :

• liens :
  • http://hackadon.org/
  • http://linuxfr.org/news/hackadon-donnez-au-libre
• organisateur : LibreFunding

Différence avec LibreEnCadeau : évènement ponctuel (~3 jours) et physique.

Libre Funding

Informations :

• lien : http://librefunding.org/
• lancement : 11 décembre 2014
• sujet : « Our mission is simple: bringing information on how to use free software for your fundraising campaigns. »

Différence avec LibreEnCadeau : du conseil, pas de gestion de transaction.

KickHub

Informations :

• sujet : « kickhub.com will help free software developers and free culture contributors raise more money. »
• liens :
  • http://kickhub.com/

Différence avec LibreEnCadeau :

• "I will release an early prototype in April 2014"
• Semble être un projet de crowfunding + donations à utiliser par les logiciels libres
• Ne fait pas vraiment appel à des non-libristes

Open Funding

Informations :

• sujet : « La plate-forme de cofinancement du logiciel libre »
• liens :
  • http://funding.openinitiative.com/
• Business Model : prennent 5% de chaque don

Différence avec LibreEnCadeau :

• Les projets doivent s'inscrire
• Les devs doivent fournir des fonctionnalités avec une somme, c'est ce qui est acheté par les utilisateurs
• site non libre

En Vente Libre

Informations :

• sujet : « Une boutique en ligne pour des produits libres »
• liens :
  • http://enventelibre.org/
• Business Model : association à but non lucratif, 100 % des bénéfices servent à faire fonctionner la boutique.

Différence avec LibreEnCadeau :

• permet des dons à des assocs (surtout) et des LL, et est orienté « boutique ».

Liens utiles

Modèles en papier Avions en papier