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 ?

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.

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 : oui, les liens doivent se trouver au niveau de la création de la wishlist pour permettre de vérifier que le site est en ligne au moment de la sélection des projets et aussi au niveau de la personne qui offre le logiciel, à la fois pour se renseigner et faire le paiement.

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.

CONCLUSION : La création d'un nouveau projet par un auteur passe par un chemin spécifique dédié qui ne nécessite pas de créer un faux événement. Il faut néanmoins créer un compte pour pouvoir le recontacter en cas de problème. Le lien figure quelque par sur une page publique du site.

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