Je vois qu’il y a déjà eu une discussion du staff à ce sujet.
J’y ai un peu réfléchi fraichement. On a le choix d’énumérer toutes les tâches de tous les projets de l’écosystème technique Duniter/Ğ1 et on priorise et estime tous les bounty. C’est un travail fastidieux et c’est pas spécialement l’esprit bounty. Je pense qu’il est mieux que ça soit un projet porté par quelqu’un ou quelqu’un qui souhaite avoir telle tâche d’accomplis en attente que quelqu’un se propose, car très demandé.
Des utilisateurs peuvent proposer que tel chose soit mis en place. Aux contributeurs techniques qui veulent s’en occuper de spécifier les tâches à accomplir et le montant du bounty pour lequel ils seraient prêts à accepter pour accomplir le bounty. Redite autrement : les développeurs proposent ce qu’ils souhaitent accomplir en priorité avec des spécifications et des critères d’acceptation et le montant qu’ils veulent en échange.
À titre d’exemple :
- AdminSys : mise à niveau des serveurs Debian de l’infra Duniter, immae proposerait le montant de 400 DU pour effectuer ces tâches, je voterais positif et je proposerais un montant de 600 DU
- Enseigner l’espagnol à DeathReaper pour qu’il parle sur le forum espagnol
Les contributeurs actuellement rémunérés par la caisse Duniter, nous sommes 23 actuellement, seraient en droit de voter pour ou contre donner cette promesse de bounty dans le cas où la part du contrat est rempli. On pourrait partir sur une somme de cinq votes positifs. S’il y a sept positifs et deux négatifs, ça donne cinq positifs, donc ça passe ? En plus de voter oui ou non pour donner le montant demandé contre la tâche accomplie, un montant différent pourrait être proposé (suppose un vote positif). Une moyenne pourrait être calculée à partir de ces montants suggérés.
Vote: Yes/No
Amount: X carottes (monnaie pas libre btw ;))
Après, il faudrait qu’il n’y ait pas trop de bounty en même temps, car faut faire beaucoup d’administratif et ça nous détourne du développement. Pour cela, il nous faut prendre connaissance du bounty, valider, voter pour les bounty, vérifier que la tâche a été accomplie (ça pourrait être vérifié par un pair qui a l’expérience pour juger, un reviewer en somme) puis faire les virements. Tout ça fait du boulot supplémentaire. Mais, c’est motivant avec une carotte, et ça permet de prioriser, de mettre en avant les grosses tâches aux yeux de la communauté. De trouver quelqu’un, une compétence, le temps de quelqu’un prêt à s’en occuper.
Après, il est toujours possible de faire des contributions non-rémunérées et de ne pas demander voire de refuser une rétribution en échange d’un bounty accomplis. Ça regarde l’auteur. Il ne faudrait pas que toutes les contributions soient des bounty, sinon trop d’administratif. Il faut que la tâche soit suffisamment significative pour être un bounty. La caisse Duniter sert déjà à faire des rémunérations régulières pour combler les trous de toutes les petites tâches qui sont faites.
Une clé publique pourrait être mise en place par le projet Duniter par bounty ou par le porteur du projet. Elle accueillerait/accepterait des virements sous la forme d’un financement participatif. Le projet Duniter décide le montant maximum qu’il souhaite mettre dessus via la moyenne des votes de montants, comme expliqué ci-dessus. Si ça ne suffi pas à atteindre le montant cible, avec des virements venus d’ailleurs et une fois le montant cible atteins, le travail peut être commencé ou a déjà commencé. Une fois finalisée, le virement est fait sur les adresses des auteurs en proportions souhaitées. Cette solution demande encore beaucoup d’administratif. Sinon, les bounty pourraient être financés sur la caisse Duniter avec une référence (commentaire) BOUNTY_#5, dans ce cas, il faut des outils pour filtrer les références.
Ça pourrait être une clé publique gérée par le projet Duniter dans le cas où il n’y a pas de porteur du projet. Ça pourrait être une clé publique du porteur du projet, il cumulerait les contributions au financement participatif du bounty même s’il ne le finit pas ou en partie. Il peut reverser au projet Duniter si finalement il ne souhaite pas finir le bounty. Je ne sais pas comment gérer la confiance à ce niveau, vis-à-vis du fait que la personne peut partir avec les sous récoltés sans rien faire en échange. Je propose que ça se fasse au cas par cas selon que le porteur du projet est connu, faisant déjà partie des contributeurs techniques actuels ou pas, s’il est membre de la toile Ğ1.
Un template/modèle de bounty :
Duniter Bounty number: $#
Title/Goal:
Ticket link: (With what has to be done to reach the goal)
Assignees:
Validator:
Amount requested:
Bounty Pubkey/Address:
Pour Día de Muertos 
:
Duniter Bounty number: 0
Title/Goal: Make DeathReaper run on Spanish Forum
Ticket link: https://git.duniter.org/clients/python/silkaj/-/issues/446
Assignees: Moul
Validator: ?
Amount requested: 250 DU Ğ1
Bounty Pubkey/Address: FuorSmMNh27Duufcx8anHdHaU3wAw2YmjCRh1b9UWEdP:AwG
Si l’adresse est gérée par le projet Duniter, il faudra que la personne assignée fournisse son adresse Ğ1, pour le virement final.
Est-ce que quelqu’un connaît le fonctionnement de bug bounty ? Et pourrait l’expliquer ici. Je ne sais pas quel est le site originel, il y en a plusieurs actuellement on dirait.
Voilà plein d’idées pas très bien organisées. À nous de spécifier ce qu’on souhaite mettre en place. À vos 