Re: [libertempo] Dev LiberTempo

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 ;)

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