Re: [libertempo] Dev LiberTempo

Hello,

je comprends et partage la majeure partie de ton point de vue.

Pour le moment, je n'ai pas encore été officiellement sollicité par un élève ingé, et ce que je propose n'est que de l'ordre de l'idée.

Nous pourrions bien sûr "forker" : des collègues d'un site parisien l'ont fait, sur la base de Php_congés 1.5.1, pour obtenir un produit capable de gérer leur tour de service complexe.

A priori, je ne suis pas dans cette optique.

Au jour d'aujourd'hui, LT me convient, et conserver un produit officiel est en effet bien plus commode, pour les raisons que tu évoques.

Cependant, il y a des bugs, effets de bords, cas non gérés qui gênent ma Direction. Des discussions sont en cours pour estimer le potentiel de différents autres produits, la quasi totalité étant propriétaire (un fort pourcentage se rangeant dans la catégorie "usine à gaz").

Quant au rythme de dév d'un stagiaire à temps plein, fatalement, oui, il sera plus rapide qu'une petite équipe sur temps libre.

Cependant, en visant des expérimentations modulaires, activables ou non par le backoffice, cela lui permettrait de tracer sa route, et à vous de valider ou non ses apports.

Néanmoins, une fois encore, je comprends vos réticences et doutes sur ce modèle de fonctionnement.

Ce que je peux au mieux proposer pour poursuivre la réflexion, c'est de sonder les responsables de services et subdivisions pour connaître leurs besoins en terme d'évolution pour obtenir un large accord au maintien de LT sur le site (une question de base pourrait être : que vous manque-t-il pour que le produit soit définitivement et durablement utilisé ?). Je n'imagine pas que nos attentes sont éloignés d'un socle assez large d'utilisateurs de ce type d'application, mais je peux me bercer d'illusions.

En fonction des retours, je vous en adresse la liste.

Là, vous saurez me dire si cela correspond avec la "vision" que vous avez des développements prévus ou acceptables de LT.

Merci d'avoir pris le temps de réfléchir à mes élucubrations et de répondre à mon mail :)

ciao

Loïc

Le 1 septembre 2016 à 21:27, wouldsmina <wouldsmina@xxxxxxxxx> a écrit :

hello,

Prytoegrian, tout y est, je suis 100% d'accord. Je met loicrichard.lr@xxxxxxxxx en copie pour qu'il puisse profiter de ta réponse ;)

a+

Le 1 septembre 2016 à 19:38, Prytoegrian <prytoegrian@xxxxxxxxxxxxxx> a écrit :
Hello,

il est évident que nous avons besoin de bras pour avancer plus vite, donc non, ça ne nous pose pas de problème que tu nous proposes cela. Le seul point que je tiens vraiment à conserver comme cap, c'est le fait qu'on fasse un logiciel métier monolithique, dans le sens où il n'y a pas de développement à la carte. Ce serait un suicide technique, en plus d'un nid à bugs.
Pour cela, nous mettons tout en œuvre pour trouver des besoins communs entre tous nos utilisateurs, suffisamment large pour être utiles à tous, tout en étant assez précis pour avoir un vrai apport métier et nous distinguer.

De ton côté, ça se traduit simplement : il est évident que sommes dispo pour échanger au sujet d'améliorations et fonctionnalités à mettre dans l'appli et si ces besoins métiers se trouvent être des besoins globaux, nous les mettrons dans LT.
Si par contre cela rentre en collision avec les intérêts du plus grand nombre, les droits de la licence te permettent de développer les éléments de ton côté dans un fork pour coller parfaitement à tes besoins.

Pour autant, je pense que participer à l'effort commun de développer le logiciel officiel peut t'être profitable :
* tu profites des tests globaux et des cas d'utilisation sur toutes les instances de LT, sur tous nos clients, le logiciel s'en retrouve plus robuste,
* tu profites du support « officiel »,
* tu n'as pas le risque qu'un jour, du code à nous rentre en collision avec ta version, que ce soit lors d'un rebase de ta version, ou un truc plus insidieux,
* tu ne prends pas le risque de finir par développer ton logiciel de ton côté, avec tous les inconvénients que ça engendre.

Le seul point de doute que j'ai, serait au niveau de la vitesse. Si tu mets un dev à dispo pour travailler sur Libertempo alors que nous, nous travaillons dessus sur notre temps libre, tu vas te sentir frustré par une certaine forme de lenteur de notre part. Et je ne pense qu'au niveau de la production du code ; la fréquence des releases et le contenu pourraient aussi te ralentir (je ne connais pas la structure de ton entreprise et tes besoins donc j'en sais pas davantage).

Sans qu'elle soit parfaitement définie via un Gantt ou un autre truc du genre, nous avons réalisé une Roadmap sur Github, où le technique en défaut doit pouvoir être remis sur de bons rails pour préparer une meilleure gestion du métier et de toutes les particularités du système de congés français. Vu notre équipe réduite, des jalons et autres cahiers de charge nous poseraient des contraintes intenables à mon sens.

Pour les points réguliers, Woulds pourra confirmer qu'on a une mailing-list technique, ça pourrait nous servir. L'asynchrone a l'avantage de permettre à tous de participer sans être obligés de trouver des créneaux communs. Un cas de besoin de contact synchrone, nous avons IRC qui a l'air de remplir son rôle.

Évidemment, je suis pas le seul dans l'histoire, alors je laisserais Woulds avoir le dernier mot.

Pryto.

Sent from ProtonMail, encrypted email based in Switzerland.

-------- Original Message --------
Subject: [libertempo] Dev LiberTempo
Local Time: 30 août 2016 5:32 PM
UTC Time: 30 août 2016 15:32
From: loicrichard.lr@xxxxxxxxx
To: libertempo@xxxxxxxxxxxxxxxxxxx

Hello,

dans le service où je travaille, nous recevons très régulièrement des stagiaires (Bac Pro à Ingé).
Nous avions dans notre listing de projets l'idée d'atteler l'un des futurs candidats développeurs "longue durée" (trois ou quatre mois) sur Php_Congés 1.5 pour coller mieux à nos attentes (cf discussion sur IRC avec Wouldsmina concernant différentes populations d'employés ayant des contraintes horaires et des calendriers différents).

Depuis, on a migré à LT, mais les interrogations concernant les possibilités du produit à prendre en charge nos contraintes restent vives.
Du coup, je me pose la question de persévérer dans cette idée d'y coller un stagiaire.
J'estime bien sûr nécessaire que son code soit rendu à la communauté.

Si cela se faisait, 1er semestre 2017 au plus tôt, est-ce que cela vous pose un problème ?
Seriez-vous ok pour qu'on bosse en commun, avec des points réguliers par hangout ou visioconf ou tout moyen qu'on arrivera à mettre en oeuvre ?
Qu'on fixe en avance de phase un cahier des charges, des jalons, etc etc....

ciao