Tickets et ses possibilités de collaboration

Préambule

Je pense qu’un mode de boite à idées serait pas mal. Cette boîte à idées pourra être utilisée par toutes personnes inscrites. Eh bien, oui, c’est plus simple pour savoir qui à créer quoi et pouvoir discuter avec cette personne si nécessaire.

RastaPopoulos avait soumis l’idée de cette boîte il y a un an. J’y ai adhéré fortement. Faute de temps, le projet n’a pu avancer.
Mais, ce concept pourrait nous servir aujourd’hui avec quelques améliorations.

Le concept

Avec la boite à idées, une personne poste un message, une amélioration d’un plugin, une idée de création de plugin, de squelettes, de fonctions, etc. Bien entendu, restons respectueux : si c’est pour revendre ce plugin ou cette fonction, payer un prestataire pour vous le réaliser.
Cette boite à idées peut servir aussi pour poster des idées sur la thématique du graphisme : un nouveau logo, une amélioration de visuels déjà présents, etc.
L’idée créée, on peut discuter de cette idée par un forum (= commentaire) attaché.
Puis, on en fait un ticket (on clique sur "créer un ticket" ou "transformer en ticket").
Des personnes s’y inscrivent pour la réalisation. Et hop ! Une équipe constituée, le groupe de travail démarre.

Comme l’a suggéré Fil sur la liste de SPIP-Dev, on pourrait donner une date limite de 6 mois à un groupe de travail constitué. Cela permet à une équipe de se renouveler soit dans les délais, soit pour les membres du groupe.

Passons à l’aspect technique de tout ça maintenant que le décor est posé.

Existant

Il existe des plugins sur la zone qui pourraient nous aider à mettre ce système en place. Le premier auquel on pense, c’est Tickets. C’est vrai que son utilisation initiale est le suivi de bugs. Mais il peut tout aussi bien gérer des tâches à réaliser, de todo list.
Actuellement, il assigne un seul auteur à la réalisation du ticket. Ce qui enlève l’aspect de collaboration. Ceci peut être palier en surchargeant le fichier tickets/prive/squelettes/contenu/ticket.html avec :

#FORMULAIRE_EDITER_LIENS{auteurs,ticket,#ID_TICKET}

On aura ainsi un groupe de travail autour du ticket. Il faut savoir que la table tickets possède un champ #ID_ASSIGNE qui est le #ID_AUTEUR de l’auteur à qui on attribut le ticket.
On peut imaginer que cet auteur-ci est le "chef de projet". Et les auteurs liés au ticket seront les membres du groupe de travail.

Bon, ça c’est fait. Maintenant, il faudrait attribuer une date… Car Tickets n’offre pas cette possibilité. Il faudrait lui ajouter 2 champs : "date" et "date_fin".

• date : la date de début du ticket pour le groupe de travail ;
• date-fin : eh bien c’est la date où théoriquement prendra fin le ticket et le groupe de travail.

Petit rappel : Fil avait proposé une date limite pour le sujet d’un groupe de travail.
De ce fait, on pourrait donner quelques petites règles à cette date de fin. Lorsqu’on crée une date de début, SPIP vérifie si la date de fin est inconnue. Si oui, alors, on insère la date de début + 6 mois en tant que date de fin.
Si le groupe de travail a besoin de plus de temps, alors le chef de projet change la date de fin…
Avantage aussi, on versionne les champs date et date_fin. On aura une info complémentaire sur l’évolution et un petit historique.

Mais il manque quelque chose. On ne va pas créer un ticket à chaque fois pour chaque idée alors que cela n’aboutira pas forcement sur un groupe de travail.
Donc, il faudrait avoir une table "idees".

Proposer une idée

Pour le concept, revenir au paragraphe plus haut.

Pour cela, on imagine la table "idees" avec les champs suivant :

• id_champ
• id_auteur
• titre
• descriptif
• date

Les champs sont suffisamment parlant. Du fait du champ "id_auteur" dans cette table, cela sous entend qu’on aura qu’un seul auteur à l’idée… A voir en pratique.

Sur la partie publique, on attache un forum à l’idée pour que l’on puisse discuter et ainsi constituer un petit cahier des charges. Histoire de savoir si on se comprend bien sur l’idée et savoir où on va.

Et hop, ça fait, on a un bouton "Créer un ticket" ou plutôt "Transformer en ticket" pour et bien oui, créer un nouveau ticket.
Sur cette nouvelle page, on aura repris le champ descriptif de la table idees pour la transmettre au champ texte du ticket.
Premier "cron" effectué par cette méthode donc.
Un autre est d’avoir l’idée liée à notre nouveau ticket. Là aussi, principe de la table spip_idees_liens classique à la méthode spipienne.

Voilà voilà.

Aller plus loin

On pourrait créer un formulaire d’inscription des auteurs à un ticket. Ça sera ainsi sur la base du volontariat. Le chef de projet validera les inscriptions pour la constitution du groupe de travail.

"Conclusion"

On a quasiment tous les outils qu’il faut pour créer cette environnement de collaboration dans la communauté. Il faut s’y atteler.

L’avantage certain est de pouvoir mieux communiquer sur les chantiers. On restera ouvert aux avis de tout le monde. C’est un projet opensource, il ne faut pas l’oublier ;-)

Avez-vous des suggestions ? Des points devant être précisés ? Un avis autre sur ce concept ?