Le protocole est beaucoup moins puissant que WebDAV à ma connaissance, mais aussi beaucoup plus simple à exploiter.
WebDAV a le défaut d'être implementable de différentes façons, ce qui fait qu'on peut difficilement faire reposer des process dessus.
Exemple : dans Tracim on historique les contenus, y compris quand on déplace un fichier (tu gardes l'historique du fichier). L'interface WebDAV propose aussi ce mécanisme. Mais certains clients ont eu la bonne idée d'implémenter le couper-coller comme une suppression-création et d'autres font un "move", ce qui engendre des comportements inattendus et surtout hétérogènes.
C'est pas la faute du protocole fondamentalement, mais qqchose de pas assez cadré laisse la porte ouverte …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
T'es un business, ton but c'est d'être viable, de générer du revenu, de payer tes employers, de payer ta direction. Bref, le but d'un business c'est de faire de la thune.
Avec le temps, je me suis rendu compte pour faire de l'argent avec du libre, il faut…. de l'argent, beaucoup d'argent.
Tu peux faire du business autour du libre assez facilement sans argent : tu fais de la prestation.
Être éditeur c'est plus difficile car la stratégie c'est d'avoir un avantage concurrentiel et si ton soft est vraiment libre, il faut trouver autre chose que la R&D (cf le fil que j'ai avec Zenitram)
Tu peux être sur une niche aussi. Ça se fait plutôt bien.
Tu parles de grosses boîtes qui font de l'argent avec du libre, mais ce n'est pas ça qu'ils vendent. Ni Google ni Amazon n'ont un modèle économique basé sur le logiciel libre. C'est une des composantes de leur activité mais ce n'est pas ça qu'ils vendent.
Si tu veux vraiment tirer ton épingle du jeu avec du libre, il me semble que la seule solution est que le libre soit un moyen et non une finalité.
Par exemple en ciblant exclusivement les collectivités - voir la scope entrouvert. Par exemple en ayant une stratégie de mutualisation des développements (cf la boîte de l'ancien associé de Cozy qui trainait pas mal dans le coin). Par exemple en développant une image de marque, en montrant la qualité de ton travail, en développant une philosophie en phase avec ta clientèle (ce qu'on fait à Algoo)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ce que je dis c'est que pour vendre du service sur des logiciels libres, il faut déjà des logiciels. Et développer des logiciels a un coût, qu'il faut encaisser d'une manière ou d'une autre.
Je ne défend aucun modèle je dis juste que si une boîte fait toute la R&D et que les autres se contentent d'exploiter le logiciel, c'est pas "à armes égales".
Vendre des livrables ça se fait. Collabora le fait. Vendre du service ça se fait. XWiki, Algoo, ta boîte le font. Ne pas pouvoir faire face à la concurrence, ça existe aussi : quand Amazon "attaque" Elastic, c'est compliqué.
J'ai l'impression que dès que les enjeux sont très forts, le modèle éditeur de logiciels libres est très délicat à gérer.
de profiter d'un monopole sous excuse qu'elle a investit dans la R&D avant. Le passé est le passé
Sur ce point je suis en désaccord. Faire de la R&D c'est pas du passé, c'est dans la durée : il faut maintenir une équipe car un logiciel qui n'évolue plus est un logiciel mort.
Je ne connais pas le modèle économique de sentry ; un éditeur est généralement le plus à même de maintenir le logiciel et le faire évoluer. Mais pour cela il faut que des clients acceptent l'idée de miser dans la durée.
Pour revenir au sujet de la R&D, il faut qu'elle soit faite, et dans la durée. C'est un centre de coût qu'il faut intégrer dans l'équation de la gestion de l'entreprise, au même titre que la comptabilité, les RH, etc. Ne pas le vendre en tant que tel n'est pas un problème, mais il faut le financer.
À chacun de trouver la manière de faire qui lui convient le mieux ; à chacun de décider de ce qui est le plus pertinent compte tenu de son environnement économique (concurrence, typologie de clientèle, capacité à fédérer les efforts, etc)
Et je reste assez convaincu que certains écosystèmes sont nettement plus sauvages que d'autres (et que donc y faire du libre est d'autant plus difficile)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
les libertés du libre, la compétition à armes égales
Si une boîte finance la R&D et les autres ne font que récupérer ce n'est pas à armes égales.
Le modèle dolibarr ou postgresql, je pense qu'on peut parler de libre à armes égales.
D'autres modèles ne sont pas à armes égales (sans dire que c'est dans un sens ou dans l'autre) : l'éditeur a l'inconvénient des frais de R&D et l'avantage de maîtrise produit et roadmap.
Je connais peu de boîtes qui font vraiment du libre car c'est compliqué et ça dépend beaucoup de la typologie de clientèle.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Si tu es ok pour nous aider à travers tes retours et qu'on puisse les exploiter facilement , je te mets en contact avec les 2 personne qui bossent sur l'interface et l'ux. Ça permettrait de faire des échanges potentiellement en partage d'écran, de vive voix et ça évitera les intermédiaires (ce que je fais ici si je partage tes retours ;).
Si tu es ok, envoie moi un email : Damien point Accorsi arobase Algoo point fr. Ensuite je te mettrai en relation directe avec les bonnes personnes
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
les utilisateurs d'outils bureautique veulent des solutions simples à utiliser plus que des solutions rigoureuses et puissantes
Pourquoi utilisent-ils Word et Excel qui sont tous sauf simples ? :-)
Parce que tout le monde l'utilise. Tu trouveras toujours quelqu'un pour t'aider (y compris les fans de libreOffice;)
La complexité du concept de branches et révisions, etc sont au delà de ce qu'on recherche dans un outil collaboratif bureautique.
Moi aussi je voudrais construire moi même une maison sans formation en maçonnerie, plomberie et électricité, mais comment faire ?
On ne parle pas de rédiger une publication scientifique ou un livre où les règles à respecter sont nombreuses et complexes mais de rédiger des documents de travail - CR d'intervention, courrier, réponse à appel d'offre. La qualité technique de construction n'est pas critique car ces documents ne sont pas amenés à évoluer dans la durée.
Si je reprends ton exemple dans le domaine de la construction : qui n'a jamais bricolé lui même une étagère, une salle de bain, une dalle ou encore un muret. On apprend les rudiments et on arrive au niveau de qualité attendu - qui pourra être critiqué par un professionnel, mais si ça fait le boulot, ça fait le boulot.
Je dis pas que c'est bien (ni que c'est mal) ; c'est plutôt un constat.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Travailler ensemble n'est pas naturel pour beaucoup de personnes. Souvent c'est vu comme je fais ma partie et je la livre, processus dans lequel il est exclu d'intervenir. Cela peut d'ailleurs se comprendre pour des raisons d'efficacité. Mais il y a également la notion de transparence qui est souvent rejetée, type : "non je te montre pas c'est pas terminé. Je te montrerai une fois que j'ai résolu les derniers points ".
On retrouve ça très souvent aussi dans le domaine du développement.
La collaboration encapsule la production d'information, mais également sa diffusion, la recherche, les sollicitations.
La valeur ajoutée de Tracim devient évidente lorsqu'on exploite ces différents aspects :
un évènement n'est pas mis dans son agenda perso puis dans l'agenda partagé mais directement dans l'agenda partagé (que chacun intègre avec son agenda perso)
on documente les nouvelles révisions de document
on considère le travail comme appartenant à l'équipe et non à l'individu
on veut affecter des tâches à des personnes (y compris associées à des documents précis) et en suivre l'exécution
on communique avec l'équipe
on veut garder trace de l'histoire pour permettre aux nouveaux venus d'entrer dans le sujet le plus rapidement possible avec toutes les informations en main
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
D'ailleurs au sujet de l'édition en ligne, je serais très curieux de connaître le nombre de personnes qui l'utilise vraiment pour de la collaboration. Mon ressenti est surtout que c'est utilisé comme un confort d'utilisation : mon document est toujours disponible et la dernière version, quel que soit l'appareil à partir duquel j'y accède.
Les développeurs qui n'ont pas de PC pour télétravailler ou qui télétravaillent avec un ordinateur personnel ont forcément été confrontés à un moment ou à un autre à une version de leur code qui est malheureusement sur l'autre machine.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
C'est un sujet super intéressant sur lequel on a passé du temps sur Tracim :
les gestionnaires de version pourraient s'appuyer sur le souce XML, mais le contenu est fortement structuré et faire des diff d'arbres est complexe et pas de résolution unique
En conséquence du point ci-dessus, les diff de documents bureautique c'est compliqué, ça marchotte quand ça existe mais rien de très abouti
Je n'ai jamais regardé les outils de fusion existant, mais logiquement vu 1 et 2, ça ne peut pas se résoudre simplement
Je rajouterai aussi :
les utilisateurs d'outils bureautique veulent des solutions simples à utiliser plus que des solutions rigoureuses et puissantes
La complexité du concept de branches et révisions, etc sont au delà de ce qu'on recherche dans un outil collaboratif bureautique.
Pour des gens dont le quotidien est fait de rédaction collaborative, ça serait sûrement le pied - mais ceux-là utilisent souvent déjà des outils à base de fichiers source textuels.
Par exemple les documents embarquent des solutions de commentaires, de révision, etc, mais qui les utilise ? Peu de personnes (y compris les gens au fait tels que les développeurs).
Dans ce contexte, l'édition collaborative en ligne est la seule solution qui réponde. C'est pas l'idéal mais ça marche - en tout cas sur des documents modestes.
La rédaction de longs documents reste dans tous les cas plus confortable sur son ordinateur, avec une suite bureautique native.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Le retour "dans Tracim on ne passe pas facilement d'une application à une autre alors que les autres solutions le permettent" me semble inapproprié : le paradigme de Tracim, c'est basé sur les espaces de collaboration, pas sur les applications.
Je ne connais pas odoo, je connais un peu nextcloud. Dans Nextcloud, par exemple, il me semble pas que tu retrouves en un clic les notes du projet courant : tu bascules d'une application à une autre, toutes données comprises.
Le paradigme Tracim est plutôt une forge de collaboration. Dans gitlab par exemple, tu ne bascules pas de "tous les codes sources à tous les tickets" : tu es dans un contexte projet.
Ça ne veut pas dire qu'il n'y a pas des choses à améliorer ; mais prendre Tracim comme une somme d'applications c'est voué à la déception car ce n'est pas ça qui le définit.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Tracim s'installe facilement avec l'image docker ; il faut un serveur dédié ceci dit.
Nextcloud, si je ne me trompe pas, c'est du PHP donc + classique comme Starck technique.
Par contre, aujourd'hui souvent on s'attend à avoir de l'édition collaborative type collabora online, et la la complexité technique de Tracim n'est plus un sujet : c'est pas plus compliqué que Collabora Online.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ça fait probablement 5 ans qu'on voulait faire un client de synchronisation et qu'on a creusé et abandonné des pistes. Et qu'on avait fini par laisser tomber, faute de priorité et de financement (on n'a pas d'investisseurs à Algoo, on développe ce que nos clients demandent et financent).
Quand bux m'a montré son projet, j'ai été emballé et d'autant plus que le projet trsync s'est développé sans nécessité de faire évoluer le cœur de Tracim : trsync s'appuie sur les APIs et sur le websocket pour établir la communication bidirectionnelle. Comme l'interface utilisateur en fait - mais du coup l'API est largement suffisante pour traiter le sujet.
En finançant une partie du travail sur trsync, j'ai voulu rendre l'outil utilisable par le grand public - installeur Windows, icône visible dans le bureau, etc.
Trsync est composé de plusieurs briques et est donc + facilement accessible à un contributeur. Trsync est un projet indépendant de Algoo et de Tracim.
Je suis content que Algoo ait contribué à un projet indépendant, et ce d'autant plus qu'on utilise trsync en production en interne chez Algoo, notamment pour les personnes administratives qui s'affranchissent naturellement de la problématique fichier local vs fichier distant.
Prochaine contribution financière ? Probablement qqchose autour des notifications, mentions ou tâches pour interagir avec Tracim directement depuis son bureau. J'imagine bien trsync devenir le client officiel natif (et contrairement à beaucoup de solutions, ce n'est pas un navigateur internet embarqué mais bien une application native)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
C'est un sujet de réflexion assez vaste. Ne serait-ce que dans les bugs : il y a les bugs en cours de documentation (on a constaté une anomalie, on souhaiterait la corriger mais il faut encore clarifier le problème) et un bug "prêt" qui est auto-suffisant pour être pris en charge par un développeur. Le fait d'avoir tout au même endroit simplifie la recherche d'information et le suivi mais génère du "bruit" lorsqu'on veut une vue d'ensemble.
Sur Tracim on s'est posé la question et aujourd'hui on a 3 "inputs" :
les demandes utilisateur / client qui arrivent par tout un tas de chemins (email, discussion, ticket, chat, espace communautaire, etc). Ces demandes sont "regroupées en vrac" dans un espace Tracim interne
une fois suffisamment claires, ces demandes sont introduites dans un doc de suivi (tableur) qui va permettre de prioriser ces demandes clients. on a environ 100 demandes aujourd'huis, bug et fonctionnalités confondues.
le travail de priorisation abouti à l'écriture de tickets (github) qui vont être pris en charge en terme de développement
Ce mode de fonctionnement permet notamment de conserver une base de travail publique (les ticket github, accessibles à tout un chacun) tout en travaillant en priorité sur les demandes faites par les clients (ceux qui paient nos salaires).
On est très loin du 0 bug (actuellement, c'est plus de 1700 tickets ouverts) ; mais c'est aussi un moyen de tracer le problèmes et de ne pas ignorer des problèmes remontés par le passé mais qu'on n'a pas (encore) eu le temps de traiter.
Cette description succinte ne prend pas en compte les bugs identifiés durant les phase de test et livraison de fin de sprint, qui sont dans un sas type "on le garde là pour le moment car si on peut le corriger dans la foulée, ça ne passera même pas par un ticket"
En écrivant ça, je me dis qu'on pourrait prévoir une conf sur le sujet du process de développement si ça intéresse des gens …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Dit autrement : comment se fait-il que le projet Flask est aussi dynamique là où la majorité des projets libres ou professionnels ne sont jamais à ce niveau d'avancement entre demandes et réponses / corrections.
C'est une vraie interrogation !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Ce n'est pas ironique, c'est mal exprimé. Ce que je veux dire c'est que là, on voit le projet complètement à jour de toutes les demandes, de toutes les remontées de bugs, sans aucune merge request ouverte. Je trouve ça super étrange :
d'un côté c'est bien et ça montre une hyper réactivité de l'équipe de dév
d'un autre côté, ça fait plus de 20 ans que je fais du développement et je n'ai jamais vu un projet aussi "à jour sur les demandes" et "sans aucuns travaux en cours" (genre tous les soirs les MR sont terminées).
Je sais pas si c'est plus clair …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Dans un certain nombre de projets, le "bug" est la particule élémentaire pour les travaux de développement. Là ce n'est pas le cas. Il n'y a pas non plus de merge requête ouverte, ni de tableau de suivi.
C'est assez étrange, je trouve. Quelqu'un en sait un peu plus ? C'est le projet de développement ultime ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
À Algoo on utilise Thunderbird pour la messagerie email et on a découvert comme certains d'entre vous la nouvelle version de Thunderbird qui est très prometteuse.
On a prévu de faire une présentation de l'outil en interne et du coup on s'est dit qu'un webinaire public serait aussi bien.
L'événement est gratuit et se déroulera sur une plateforme Big Blue Button (donc sans nécessité d'installation de logiciel)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Notepad++ est le troisième environnement de développement ? Je suis vraiment dubitatif. Certes j'ai vu quasiment tous les développeurs en environnement Windows l'utiliser … mais comme éditeur de ressources texte, pas pour éditer et coder au quotidien.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Les sociétés Algoo (éditrice du logiciel libre Tracim) et Aukfood (services, infogérance et formation autour des logiciels libres) organisent ce webinaire mardi 21/06 de 11h30 à 12h30 à destination (en particulier) des collectivités.
L'événement se déroulera +/- sous forme de table ronde avec 2 invités de marque :
Jean-Christophe ELINEAU, Responsable du cluster NAOS, le cluster Open Source de Nouvelle-Aquitaine,- Emmanuel CHOPOT DSI de la Roche-sur-Yon
La participation à l'événement est gratuite.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Websocket
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche WebDAV Manager, un client WebDAV ultra-léger en JS. Évalué à 4.
tu voulais sans doute écrire WOPI.
Le protocole est beaucoup moins puissant que WebDAV à ma connaissance, mais aussi beaucoup plus simple à exploiter.
WebDAV a le défaut d'être implementable de différentes façons, ce qui fait qu'on peut difficilement faire reposer des process dessus.
Exemple : dans Tracim on historique les contenus, y compris quand on déplace un fichier (tu gardes l'historique du fichier). L'interface WebDAV propose aussi ce mécanisme. Mais certains clients ont eu la bonne idée d'implémenter le couper-coller comme une suppression-création et d'autres font un "move", ce qui engendre des comportements inattendus et surtout hétérogènes.
C'est pas la faute du protocole fondamentalement, mais qqchose de pas assez cadré laisse la porte ouverte …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: BSL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Sentry redevient privateur. Évalué à 5.
Tu peux faire du business autour du libre assez facilement sans argent : tu fais de la prestation.
Être éditeur c'est plus difficile car la stratégie c'est d'avoir un avantage concurrentiel et si ton soft est vraiment libre, il faut trouver autre chose que la R&D (cf le fil que j'ai avec Zenitram)
Tu peux être sur une niche aussi. Ça se fait plutôt bien.
Tu parles de grosses boîtes qui font de l'argent avec du libre, mais ce n'est pas ça qu'ils vendent. Ni Google ni Amazon n'ont un modèle économique basé sur le logiciel libre. C'est une des composantes de leur activité mais ce n'est pas ça qu'ils vendent.
Si tu veux vraiment tirer ton épingle du jeu avec du libre, il me semble que la seule solution est que le libre soit un moyen et non une finalité.
Par exemple en ciblant exclusivement les collectivités - voir la scope entrouvert. Par exemple en ayant une stratégie de mutualisation des développements (cf la boîte de l'ancien associé de Cozy qui trainait pas mal dans le coin). Par exemple en développant une image de marque, en montrant la qualité de ton travail, en développant une philosophie en phase avec ta clientèle (ce qu'on fait à Algoo)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# J'ai lu...
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Une usurpation d'identité qui s'est retournée contre ses propres commanditaires. Évalué à 10.
Je ne vois pas trop où on peut dire que ça se retourne contre le commanditaire.
À l'heure du télétravail et des réseaux sociaux, et de la vie publique, c'est assez flippant.
Combien de personnes vont faire cette démarche plutôt que de juste laisser tomber ?
:-/
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: BSL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Sentry redevient privateur. Évalué à 7.
Ce que je dis c'est que pour vendre du service sur des logiciels libres, il faut déjà des logiciels. Et développer des logiciels a un coût, qu'il faut encaisser d'une manière ou d'une autre.
Je ne défend aucun modèle je dis juste que si une boîte fait toute la R&D et que les autres se contentent d'exploiter le logiciel, c'est pas "à armes égales".
Vendre des livrables ça se fait. Collabora le fait. Vendre du service ça se fait. XWiki, Algoo, ta boîte le font. Ne pas pouvoir faire face à la concurrence, ça existe aussi : quand Amazon "attaque" Elastic, c'est compliqué.
J'ai l'impression que dès que les enjeux sont très forts, le modèle éditeur de logiciels libres est très délicat à gérer.
Sur ce point je suis en désaccord. Faire de la R&D c'est pas du passé, c'est dans la durée : il faut maintenir une équipe car un logiciel qui n'évolue plus est un logiciel mort.
Je ne connais pas le modèle économique de sentry ; un éditeur est généralement le plus à même de maintenir le logiciel et le faire évoluer. Mais pour cela il faut que des clients acceptent l'idée de miser dans la durée.
Pour revenir au sujet de la R&D, il faut qu'elle soit faite, et dans la durée. C'est un centre de coût qu'il faut intégrer dans l'équation de la gestion de l'entreprise, au même titre que la comptabilité, les RH, etc. Ne pas le vendre en tant que tel n'est pas un problème, mais il faut le financer.
À chacun de trouver la manière de faire qui lui convient le mieux ; à chacun de décider de ce qui est le plus pertinent compte tenu de son environnement économique (concurrence, typologie de clientèle, capacité à fédérer les efforts, etc)
Et je reste assez convaincu que certains écosystèmes sont nettement plus sauvages que d'autres (et que donc y faire du libre est d'autant plus difficile)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: BSL
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Sentry redevient privateur. Évalué à 6.
Si une boîte finance la R&D et les autres ne font que récupérer ce n'est pas à armes égales.
Le modèle dolibarr ou postgresql, je pense qu'on peut parler de libre à armes égales.
D'autres modèles ne sont pas à armes égales (sans dire que c'est dans un sens ou dans l'autre) : l'éditeur a l'inconvénient des frais de R&D et l'avantage de maîtrise produit et roadmap.
Je connais peu de boîtes qui font vraiment du libre car c'est compliqué et ça dépend beaucoup de la typologie de clientèle.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 3.
Je transmets ça demain 👍
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 4.
Si tu es ok pour nous aider à travers tes retours et qu'on puisse les exploiter facilement , je te mets en contact avec les 2 personne qui bossent sur l'interface et l'ux. Ça permettrait de faire des échanges potentiellement en partage d'écran, de vive voix et ça évitera les intermédiaires (ce que je fais ici si je partage tes retours ;).
Si tu es ok, envoie moi un email : Damien point Accorsi arobase Algoo point fr. Ensuite je te mettrai en relation directe avec les bonnes personnes
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pot pourri
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 4.
Parce que tout le monde l'utilise. Tu trouveras toujours quelqu'un pour t'aider (y compris les fans de libreOffice;)
On ne parle pas de rédiger une publication scientifique ou un livre où les règles à respecter sont nombreuses et complexes mais de rédiger des documents de travail - CR d'intervention, courrier, réponse à appel d'offre. La qualité technique de construction n'est pas critique car ces documents ne sont pas amenés à évoluer dans la durée.
Si je reprends ton exemple dans le domaine de la construction : qui n'a jamais bricolé lui même une étagère, une salle de bain, une dalle ou encore un muret. On apprend les rudiments et on arrive au niveau de qualité attendu - qui pourra être critiqué par un professionnel, mais si ça fait le boulot, ça fait le boulot.
Je dis pas que c'est bien (ni que c'est mal) ; c'est plutôt un constat.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 4.
Merci pour le retour en tout cas.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 7.
Travailler ensemble n'est pas naturel pour beaucoup de personnes. Souvent c'est vu comme je fais ma partie et je la livre, processus dans lequel il est exclu d'intervenir. Cela peut d'ailleurs se comprendre pour des raisons d'efficacité. Mais il y a également la notion de transparence qui est souvent rejetée, type : "non je te montre pas c'est pas terminé. Je te montrerai une fois que j'ai résolu les derniers points ".
On retrouve ça très souvent aussi dans le domaine du développement.
La collaboration encapsule la production d'information, mais également sa diffusion, la recherche, les sollicitations.
La valeur ajoutée de Tracim devient évidente lorsqu'on exploite ces différents aspects :
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pot pourri
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 9.
D'ailleurs au sujet de l'édition en ligne, je serais très curieux de connaître le nombre de personnes qui l'utilise vraiment pour de la collaboration. Mon ressenti est surtout que c'est utilisé comme un confort d'utilisation : mon document est toujours disponible et la dernière version, quel que soit l'appareil à partir duquel j'y accède.
Les développeurs qui n'ont pas de PC pour télétravailler ou qui télétravaillent avec un ordinateur personnel ont forcément été confrontés à un moment ou à un autre à une version de leur code qui est malheureusement sur l'autre machine.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pot pourri
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 10.
C'est un sujet super intéressant sur lequel on a passé du temps sur Tracim :
Je rajouterai aussi :
Pour des gens dont le quotidien est fait de rédaction collaborative, ça serait sûrement le pied - mais ceux-là utilisent souvent déjà des outils à base de fichiers source textuels.
Par exemple les documents embarquent des solutions de commentaires, de révision, etc, mais qui les utilise ? Peu de personnes (y compris les gens au fait tels que les développeurs).
Dans ce contexte, l'édition collaborative en ligne est la seule solution qui réponde. C'est pas l'idéal mais ça marche - en tout cas sur des documents modestes.
La rédaction de longs documents reste dans tous les cas plus confortable sur son ordinateur, avec une suite bureautique native.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 5.
Merci pour tous ces retours.
Le retour "dans Tracim on ne passe pas facilement d'une application à une autre alors que les autres solutions le permettent" me semble inapproprié : le paradigme de Tracim, c'est basé sur les espaces de collaboration, pas sur les applications.
Je ne connais pas odoo, je connais un peu nextcloud. Dans Nextcloud, par exemple, il me semble pas que tu retrouves en un clic les notes du projet courant : tu bascules d'une application à une autre, toutes données comprises.
Le paradigme Tracim est plutôt une forge de collaboration. Dans gitlab par exemple, tu ne bascules pas de "tous les codes sources à tous les tickets" : tu es dans un contexte projet.
Ça ne veut pas dire qu'il n'y a pas des choses à améliorer ; mais prendre Tracim comme une somme d'applications c'est voué à la déception car ce n'est pas ça qui le définit.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 2.
Tracim s'installe facilement avec l'image docker ; il faut un serveur dédié ceci dit.
Nextcloud, si je ne me trompe pas, c'est du PHP donc + classique comme Starck technique.
Par contre, aujourd'hui souvent on s'attend à avoir de l'édition collaborative type collabora online, et la la complexité technique de Tracim n'est plus un sujet : c'est pas plus compliqué que Collabora Online.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: manque de moyens ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal LibreOffice boude le cloud ?. Évalué à 2.
Ah c'est intéressant ça. Quelles ont été les objections ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Réaction en tant que créateur de Tracim et dirigeant Algoo
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal 1ʳᵉ version "grand public" de TrSync. Évalué à 10.
Ça fait probablement 5 ans qu'on voulait faire un client de synchronisation et qu'on a creusé et abandonné des pistes. Et qu'on avait fini par laisser tomber, faute de priorité et de financement (on n'a pas d'investisseurs à Algoo, on développe ce que nos clients demandent et financent).
Quand bux m'a montré son projet, j'ai été emballé et d'autant plus que le projet trsync s'est développé sans nécessité de faire évoluer le cœur de Tracim : trsync s'appuie sur les APIs et sur le websocket pour établir la communication bidirectionnelle. Comme l'interface utilisateur en fait - mais du coup l'API est largement suffisante pour traiter le sujet.
En finançant une partie du travail sur trsync, j'ai voulu rendre l'outil utilisable par le grand public - installeur Windows, icône visible dans le bureau, etc.
Trsync est composé de plusieurs briques et est donc + facilement accessible à un contributeur. Trsync est un projet indépendant de Algoo et de Tracim.
Je suis content que Algoo ait contribué à un projet indépendant, et ce d'autant plus qu'on utilise trsync en production en interne chez Algoo, notamment pour les personnes administratives qui s'affranchissent naturellement de la problématique fichier local vs fichier distant.
Prochaine contribution financière ? Probablement qqchose autour des notifications, mentions ou tâches pour interagir avec Tracim directement depuis son bureau. J'imagine bien trsync devenir le client officiel natif (et contrairement à beaucoup de solutions, ce n'est pas un navigateur internet embarqué mais bien une application native)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Question de choix
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Flask: ~4K commits, ~2.5K bugs fermés, 0 bugs ouverts. Évalué à 2. Dernière modification le 08 juillet 2022 à 06:57.
Oui on est bien d'accord :-)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Question de choix
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Flask: ~4K commits, ~2.5K bugs fermés, 0 bugs ouverts. Évalué à 2.
C'est un sujet de réflexion assez vaste. Ne serait-ce que dans les bugs : il y a les bugs en cours de documentation (on a constaté une anomalie, on souhaiterait la corriger mais il faut encore clarifier le problème) et un bug "prêt" qui est auto-suffisant pour être pris en charge par un développeur. Le fait d'avoir tout au même endroit simplifie la recherche d'information et le suivi mais génère du "bruit" lorsqu'on veut une vue d'ensemble.
Sur Tracim on s'est posé la question et aujourd'hui on a 3 "inputs" :
Ce mode de fonctionnement permet notamment de conserver une base de travail publique (les ticket github, accessibles à tout un chacun) tout en travaillant en priorité sur les demandes faites par les clients (ceux qui paient nos salaires).
On est très loin du 0 bug (actuellement, c'est plus de 1700 tickets ouverts) ; mais c'est aussi un moyen de tracer le problèmes et de ne pas ignorer des problèmes remontés par le passé mais qu'on n'a pas (encore) eu le temps de traiter.
Cette description succinte ne prend pas en compte les bugs identifiés durant les phase de test et livraison de fin de sprint, qui sont dans un sas type "on le garde là pour le moment car si on peut le corriger dans la foulée, ça ne passera même pas par un ticket"
En écrivant ça, je me dis qu'on pourrait prévoir une conf sur le sujet du process de développement si ça intéresse des gens …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Flask: ~4K commits, ~2.5K bugs fermés, 0 bugs ouverts. Évalué à 2.
:-D
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Flask: ~4K commits, ~2.5K bugs fermés, 0 bugs ouverts. Évalué à 4.
Dit autrement : comment se fait-il que le projet Flask est aussi dynamique là où la majorité des projets libres ou professionnels ne sont jamais à ce niveau d'avancement entre demandes et réponses / corrections.
C'est une vraie interrogation !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Flask: ~4K commits, ~2.5K bugs fermés, 0 bugs ouverts. Évalué à 2.
Ce n'est pas ironique, c'est mal exprimé. Ce que je veux dire c'est que là, on voit le projet complètement à jour de toutes les demandes, de toutes les remontées de bugs, sans aucune merge request ouverte. Je trouve ça super étrange :
Je sais pas si c'est plus clair …
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Flask: ~4K commits, ~2.5K bugs fermés, 0 bugs ouverts. Évalué à 3.
Dans un certain nombre de projets, le "bug" est la particule élémentaire pour les travaux de développement. Là ce n'est pas le cas. Il n'y a pas non plus de merge requête ouverte, ni de tableau de suivi.
C'est assez étrange, je trouve. Quelqu'un en sait un peu plus ? C'est le projet de développement ultime ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Pourquoi ce webinaire ?
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Webinaire de présentation de Thunderbird 102. Évalué à 6.
À Algoo on utilise Thunderbird pour la messagerie email et on a découvert comme certains d'entre vous la nouvelle version de Thunderbird qui est très prometteuse.
On a prévu de faire une présentation de l'outil en interne et du coup on s'est dit qu'un webinaire public serait aussi bien.
L'événement est gratuit et se déroulera sur une plateforme Big Blue Button (donc sans nécessité d'installation de logiciel)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Moi qui croyait qu'il était libre
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Adieu Atom :(. Évalué à 7.
Notepad++ est le troisième environnement de développement ? Je suis vraiment dubitatif. Certes j'ai vu quasiment tous les développeurs en environnement Windows l'utiliser … mais comme éditeur de ressources texte, pas pour éditer et coder au quotidien.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Un peu plus d'informations
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Webinaire "Pourquoi l’open source est une réponse aux enjeux des collectivités ?" mardi 21/06. Évalué à 4.
Les sociétés Algoo (éditrice du logiciel libre Tracim) et Aukfood (services, infogérance et formation autour des logiciels libres) organisent ce webinaire mardi 21/06 de 11h30 à 12h30 à destination (en particulier) des collectivités.
L'événement se déroulera +/- sous forme de table ronde avec 2 invités de marque :
La participation à l'événement est gratuite.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo