Le projet est-il toujours d'actualité ? OUI

[lsteelandt]

Bonjour,
Je cherche a faire vivre ce projet qui m'a l'air très intéressant pour aboutir au moyen de piloter des appareil Xiaomi et Ikea (entre autres) sans passer par la gateway des fabricants (no cloud).

Il y a eu beaucoup de travail achevé.
J'ai cependant l'impression qu'il ne vit plus (depuis le choix personnel du réseau ZWAve ? 😉 )
Est-ce le cas ?
J'essaye d'y contribuer (j'ai déjà ajouté un device Xiaomi : ht_sensor.js) mais c'est difficile sans avoir une vue globale sur la conception et sans commentaire dans le code.

Y aurait il moyen d'échanger par email ou message privé Twitter ?

[nouknouk]

Bonjour, et tout d'abord merci pour l'intérêt porté à mon p'tit projet perso :)

Je fais un petit tl;dr parce que je vais écrire un roman dans les comms qui suivent pour mieux expliquer le contexte:

• le projet est toujours d'actualité ; il évolue par 'sauts de puce' en fonction du temps que j'ai pour le faire avancer et de mes besoins ; d'où des updates (trop) irrégulières.

• un gros oui: toute contribution est évidemment la bienvenue ; c'est le sens même de la publication de ce projet sur github ; je vais faire ce qu'il faut pour aider de mon mieux.

• reste à définir la méthode et les outils pour collaborer ; les échanges privés n'ont pas ma préférence: quitte à échanger, autant que ça profite à tout le monde.

[nouknouk]

Le contexte:

Le projet node-zigate s'inscrit chez moi dans un projet plus global d'écriture d'un logiciel domotique "à la Jeedom", et qui s'appelle domonode. Dans ce cadre, node-zigate est le driver d'un plugin (parmi d'autres) zigate de mon soft domonode. Plus d'infos sur domonode

Le projet domonode s'inscrit lui-même dans le projet global de la domotisation de ma maison ; j'essaie de compiler des infos sur l'ensemble de ma solution domotique dans un wiki GitHub: ma domotique

J'imagine que tu as déjà parcouru le wiki et que c'est ça qui t'a amené à penser que j'avais délaissé le zigbee au profit du zwave ; ce n'est pas le cas, c'était mal exprimé: les deux protocoles cohabitent chez moi et le zigbee est activement utilisé (et donc node-zigate aussi). J'ai modifié la fin de cette page du wiki en conséquence

Je travaille dans l'informatique à temps plein, j'ai également une vie familiale et encore d'autres 'side projects' en parallèle. Il me manque donc du temps pour tout faire ; d'où:

• le peu de temps jusque là alloué à la documentation propre du projet (tant que j'étais seul contributeur sur le projet)

• la qualité et propreté du code qui - comme on dit - laisse beaucoup d'espace pour les améliorations futures ;)

• égoïstement, il y a un intérêt certain pour moi que d'autres personnes contribuent au projet, car cela me dégagera d'autant plus de temps pour d'autres partie du projet node-zigate et/ou pour mes autres projets.

[nouknouk]

les outils pour collaborer

Je suis néophyte en matière de tooling pour les projets rattachés à github, donc le sujet est totalement ouvert ; n'hésite(z) pas à proposer / me compléter / corriger:

Perso, je vois plusieurs besoins:

• pouvoir demander des précisions, des ajouts de documentation, etc... Pour ça, les issues github me semblent appropriées (quitte à leur ajouter des tags 'documentation' ?)

• pouvoir documenter les bugs / améliorations du code ; là aussi les issues github me semblent appropriées.

• avoir une documentation du projet, à deux niveaux:

  • une documentation globale, qui détaille l'installation, les dépendances, les principaux composants du projet, leurs interactions, etc... pour pouvoir 'entrer' plus facilement dans le code quand on commence. Le contenu sera essentiellement du blabla agrémenté de schémas, images, etc... et une hiérarchisation forte des pages entre elles. Pour cela je vois le wiki github (comme celui déjà en place mais d'autres solutions sont envisageables ? pages github ? autre ?

  • une documentation technique du code: objets, méthodes, paramètres, ... ; ce serait bien d'avoir une doc auto-générée à partir de commentaires directement écrits dans le code (à la manière d'une javadoc) ; et qui s'intègre bien avec le workflow d'un projet github ; quelle(s) solution(s) existent et serait envisageables ?

• et au-delà:

  • dans le repo lui-même comment bien organiser les commits, branches, releases ?
  • quelle langue utiliser pour les échanges et la doc: d'un côté l'anglais est la norme pour les projets informatiques et permet d'adresser un maximum de personnes ; d'un autre côté, la Zigate est un projet franco-français, donc échanger en français ne risque pas d'écarter beaucoup de monde.
  • une restriction cependant: dans tous les cas, la langue de référence dans le code lui-même doit rester l'anglais.

Bref, autant de questions ouvertes ; à nouveau: je suis néophyte dans ce domaine, j'attends donc vos propositions.

[nouknouk]

next steps:

En résumé, les prochaines actions que j'entrevois:

• choisir les outils pour collaborer
• choisir la langue de référence
• enrichir la documentation générale
• enrichir les commentaires dans le code + ajouter la doc du code
• niveau code: aligner le driver avec la dernière version du firware de la zigate, la 3.0f

[lsteelandt]

@nouknouk Je comprends cet arbitrage permanent dans la gestion de son temps 😉.

C'est notre sort à tous.

Et c'est pas égoïste d être favorable à ce que d'autres contribuent à faire avancer le projet.
C'est déjà un sacré don de mettre en ligne ce code.

C'est la vertu du collaboratif de pouvoir exploiter les laps de temps des autres.

Le développement informatique était mon métier il y a bien longtemps.
Je m'y mets occasionnellement et notamment pour mes besoins en domotique.

Compte sur moi pour apporter ma modeste contribution avec mes moyens.

Je répondrai au messages suivant en ce qui concerne le collaboratif.
À bientôt
Luc

[lsteelandt]

Concernant les tooling, mes suggestions dans tes commentaires.

Je suis néophyte en matière de tooling pour les projets rattachés à github, donc le sujet est totalement ouvert ; n'hésite(z) pas à proposer / me compléter / corriger:

Perso, je vois plusieurs besoins:

• pouvoir demander des précisions, des ajouts de documentation, etc... Pour ça, les issues github me semblent appropriées (quitte à leur ajouter des tags 'documentation' ?)

Je suis du même avis pour un début.

• pouvoir documenter les bugs / améliorations du code ; là aussi les issues github me semblent appropriées.

Aussi du même avis 😉 .

• avoir une documentation du projet, à deux niveaux:

  • une documentation globale, qui détaille l'installation, les dépendances, les principaux composants du projet, leurs interactions, etc... pour pouvoir 'entrer' plus facilement dans le code quand on commence. Le contenu sera essentiellement du blabla agrémenté de schémas, images, etc... et une hiérarchisation forte des pages entre elles. Pour cela je vois le wiki github (comme celui déjà en place mais d'autres solutions sont envisageables ? pages github ? autre ?

Le wiki à l'avantage d'être intégrer à Github, mais n'est pas trop chronophage de l'entretenir ?
Un fichier Word dans l'espace de fichier ne serait il pas plus facile ? Un simple commit mettrait à jour l'espace.

• une documentation technique du code: objets, méthodes, paramètres, ... ; ce serait bien d'avoir une doc auto-générée à partir de commentaires directement écrits dans le code (à la manière d'une javadoc) ; et qui s'intègre bien avec le workflow d'un projet github ; quelle(s) solution(s) existent et serait envisageables ?

J'ai pas plus d'expérience dans les outils d'autodoc, mais voici peut être une base de réflexion pour un choix.

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=2ahUKEwifvfqW3pbhAhXGAWMBHb1pBigQFjADegQIBxAB&url=https%3A%2F%2Fwww.slant.co%2Ftopics%2F5104%2F~javascript-documentation-tools&usg=AOvVaw2_CaMcag5aUdc6qYkl7NYO

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&ved=2ahUKEwifvfqW3pbhAhXGAWMBHb1pBigQFjAEegQIAhAB&url=https%3A%2F%2Fwww.fusioncharts.com%2Fblog%2Fjsdoc-vs-yuidoc-vs-doxx-vs-docco-choosing-a-javascript-documentation-generator%2F&usg=AOvVaw0QrrWrreAteNofIWPwTIIf

J'utilise Visual Code qui permet d'installer des plugins pour la création de commentaire de préparation pour l'auto doc.
Exemple : https://marketplace.visualstudio.com/items?itemName=stevencl.addDocComments

• et au-delà:

  • dans le repo lui-même comment bien organiser les commits, branches, releases ?

Je comprends pas bien la question. 🙄

• quelle langue utiliser pour les échanges et la doc: d'un côté l'anglais est la norme pour les projets informatiques et permet d'adresser un maximum de personnes ; d'un autre côté, la Zigate est un projet franco-français, donc échanger en français ne risque pas d'écarter beaucoup de monde.

Je suis bien d'accord. La tâche sera plus facile en Français.

• une restriction cependant: dans tous les cas, la langue de référence dans le code lui-même doit rester l'anglais.

Là aussi je suis du même avis. Anglais pour le code

Bref, autant de questions ouvertes ; à nouveau: je suis néophyte dans ce domaine, j'attends donc vos propositions.

Je reviens sur l'aspect échanges collaboratif. J'exprimais plus haut un .... "pour l'instant" dans la proposition d'utiliser les issues de Github peut
Je m'explique ...... dans l'éventualité d'un grossissement de tes disciples dans ce projet 😉, peut être faudrait il avoir recours à des outils type Slack.

[lsteelandt]

next steps:

En résumé, les prochaines actions que j'entrevois:

• choisir les outils pour collaborer
• choisir la langue de référence
• enrichir la documentation générale
• enrichir les commentaires dans le code + ajouter la doc du code
• niveau code: aligner le driver avec la dernière version du firware de la zigate, la 3.0f

@nouknouk, en exploitation de l'usage des "issues" de Github, je propose d'ouvrir un "issue" pour chacun des points que tu as mentionné ci dessus.

Ouverture au fur et à mesure du premier 'acte' de traitement de chacun d'eux.