Partkeepr: Meta : Trop de problèmes ouverts

donc en gros, nous créons un "backlog" de facto...
@Drachenkaetzchen êtes-vous

donc en gros, nous créons un "backlog" de facto...

Sorte de. Mais, oui, c'est l'idée de base.

@Drachenkaetzchen êtes-vous

Je serais prêt à aider ici, si vous le souhaitez.

Hé les gars, c'est une très bonne idée et nous en avons également discuté sur IRC.

J'ai récemment eu accès au github et je vais jeter un œil à la possibilité d'ajouter d'autres personnes pour m'aider à gérer les problèmes sur le plan organisationnel et j'apprécie votre offre d'aide.
(si en raison de contraintes de temps j'oublie, n'hésitez pas à m'en parler)

Ok @christianlupus, je vous ai ajouté en tant que membre de Triage à ce référentiel.
@baradhili êtes-vous également intéressé à aider avec cela?

Voici les capacités décrites ici : https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Finalement, bien sûr, nous ajouterons également d'autres personnes avec un accès par code. Pour l'instant, essayons de nous concentrer sur l'organisation des problèmes.

@dromer oui s'il vous plait

@dromer Merci pour l'ajout.

Une première suggestion est d'ajouter une étiquette needs-triage et de mettre en place une règle pour mettre chaque nouveau numéro et PR dans cette étiquette.
Raison : Le journaliste voit qu'un triage est nécessaire/va être effectué. De plus, nous pouvons trier (plus tard) pour de tels problèmes. Peut-être devrions-nous envisager de mettre chaque problème sous cette étiquette afin de voir ce qui est déjà fait et ce qui nécessite une attention particulière.

Et en plus : je suggère également les étiquettes suivantes :

• meta : Utilisé pour les problèmes non liés au code lui-même mais au référentiel, au wiki, aux normes de programmation et autres
• help-requested : Utilisé pour indiquer qu'un problème demande de l'aide lors de l'installation, de l'utilisation, etc. Cela pourrait être mieux envoyé sur un forum que conservé comme problème ici sur github.

Ça a l'air bien.. bien que je suggère que nous ne mettions pas tout sous needs-triage parce que nous finirons simplement là où nous sommes maintenant :) .. Je suggérerais également backlog , next-release et roadmap une fois les choses en revue

Comme j'ai commencé à classer quelques problèmes maintenant, j'ai trouvé qu'il était difficile d'y apposer des étiquettes à moins qu'elles ne soient clairement définies (au moins pour une partie d'entre elles).

@christianlupus comment veux-tu coordonner le triage ? je suis en UTC+8

@christianlupus On dirait que nous pourrions avoir besoin d'une autre balise "move-to-wiki"

@christianlupus comment veux-tu coordonner le triage ? je suis en UTC+8

@baradhili je suis en UTC+1 (Berlin).
Je donnais à quelques numéros des étiquettes et un jalon, le cas échéant. Cependant, j'ai le temps de me mettre au travail maintenant. Je vais donc faire une pause pour le moment.

Avez-vous de bonnes suggestions sur la coordination? Une personne le matin une personne le soir pour éviter les collisions ? Quel est votre moment préféré pour y travailler ?

Comme je ne sais pas dans quelle ville vous habitez, j'en ai pris un au hasard dans le fuseau horaire nommé : Ici vous pouvez obtenir un aperçu rapide pour gérer le décalage horaire. Vous voudrez peut-être adopter dans votre ville.

@christianlupus On dirait que nous pourrions avoir besoin d'une autre balise "move-to-wiki"

Oui, cela semble être le cas.

@christianlupus Je travaille actuellement sur d'anciens problèmes avec les balises bug .. Je pense que je peux mettre une heure vers 8 ou 9 heures du matin... J'utilise la version anglaise du même site - je Je suis à Perth - nous voulons probablement signaler les problèmes complexes avec une sorte de balise afin que l'autre puisse jeter un coup d'œil et donner son avis.

@dromer si nous vous donnons une liste de nouveaux tags pouvez-vous les ajouter ?

Oh, est-ce quelque chose que je dois faire ?

Faites le moi savoir et je vais regarder pour en ajouter d'autres.

@christianlupus Je travaille actuellement sur d'anciens problèmes avec les balises bug .. Je pense que je peux mettre une heure vers 8 ou 9 heures du matin... J'utilise la version anglaise du même site - je je suis à Perth -

OK, cela dépend entièrement de vous. Merci d'avoir aidé ici. Je travaille sur les problèmes non étiquetés pour le moment, donc nous ne nous heurtons pas.

nous voulons probablement signaler les problèmes complexes avec une sorte de balise afin que l'autre puisse jeter un œil et donner son avis.

Oui, je pense que c'est une bonne idée. Que diriez-vous de complex-triage ?

Oh, est-ce quelque chose que je dois faire ?

Faites le moi savoir et je vais regarder pour en ajouter d'autres.

Nous ne pouvons attacher que des étiquettes et des jalons aux problèmes. Mais nous ne pouvons pas ajouter de nouvelles étiquettes à la liste des étiquettes valides. Donc, oui, nous vous demandons d'ajouter les étiquettes pertinentes.

@baradhili Donc pour pas nous avons cette liste de nouveaux labels (veuillez me corriger):

• meta
• help-requested
• move-to-wiki
• complex-triage

À propos des étiquettes opportunes ( backlog , roadmap , next-release ) Je pense que c'est mieux d'avoir des jalons, vous ne pensez pas ? Cela doit également être coordonné avec toute personne fournissant du code au référentiel.

Je mettrai à jour ce commentaire dès que des besoins en nouvelles étiquettes apparaîtront. D'accord avec ça ? Si oui, n'hésitez pas à demander à dromer à ce sujet.

@dromer
Pourrions-nous avoir la configuration des étiquettes suivantes ?

• meta
• help-requested
• move-to-wiki
• complex-triage
• security-issue

Merci

@baradhili J'ai essayé d'organiser un peu les étiquettes dans un fichier MD . Je vous ai ajouté en tant que collaborateur afin que vous puissiez modifier le fichier.

Êtes-vous d'accord avec les définitions dans la mesure où je les ai écrites?

Tout bon!Documentation!

Le mardi 14 janvier 2020 à 19h36, Christian [email protected] a écrit :

@baradhili https://github.com/baradhili J'ai essayé d'organiser les étiquettes
dans un fichier MD
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
bit. Je vous ai ajouté en tant que collaborateur afin que vous puissiez modifier le fichier.

Êtes-vous d'accord avec les définitions dans la mesure où je les ai écrites?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN4LOMVXWWJ3QDN
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
Bret Watson
Réalisateur
IT Interim Management Pty Ltd T/A TICM
Tél. : +61 (0)41 33 03 840
Courriel :[email protected]
"Le contenu de cette transmission par e-mail est destiné uniquement aux personnes nommées
destinataire(s), peuvent être confidentielles, et peuvent être privilégiées ou autrement
protégé contre la divulgation dans l'intérêt public. L'utilisation, la reproduction,
divulgation ou distribution du contenu de cette transmission par e-mail par
toute personne autre que le(s) destinataire(s) nommé(s) est interdite. Si tu n'es pas
un destinataire nommé, veuillez en informer immédiatement l'expéditeur."

build system clairement à voir avec le ci/cd (voir mes 2 PRs) donc je le garderais.

J'ajouterai votre liste @baradhili et j'espère que vous pourrez au moins aller de l'avant.
Pour l'instant, je pense qu'il n'y a rien de mal à avoir 'trop' d'étiquettes que d'en avoir 'trop peu'. Nous pouvons toujours supprimer/ignorer certaines étiquettes.

Souhaitez-vous leur associer des couleurs particulières ? :)

Ok trop tard, je suis parti avec les couleurs par défaut pour l'instant :D

@dromer Pourrions-nous avoir un jalon pour la 1.5.0 ?

@christianlupus Je vais utiliser 1 - Ready pour les choses qui semblent/sont prétendues être corrigées, mais qui ont besoin d'être testées

@dromer rétrospectivement .. j'ai réalisé que je pouvais gérer des choses qui semblent devoir être faites "Bientôt" avec Must Have
@christianlupus a terminé Bug .. travaille maintenant sur d'anciens problèmes sans jalon

Je supprime les étiquettes comme Will be closed soon! et Feedback Needed dès qu'un numéro peut être fermé. Cela convient-il à notre flux de travail commun ?

@dromer pourrais-je avoir une balise supplémentaire.. low-hanging ? Je vois des problèmes de temps en temps qui devraient être des solutions faciles

@christianlupus oui .. et je devrais revenir en arrière et vérifier que je l'ai fait

Apparemment, github fournit des « hooks » automatisés si vous utilisez plutôt la balise good first issue :

Problèmes d'étiquettes et demandes d'extraction pour les nouveaux contributeurs

Désormais, GitHub aidera les contributeurs potentiels pour la première fois à découvrir les problèmes étiquetés avec good first issue

Alors dois-je l'appeler ainsi ?
Les problèmes avec cette balise apparaîtront dans d'autres aperçus censés encourager les gens à s'impliquer.

Comme sur https://github.com/partkeepr/PartKeepr/contribute

travaille pour moi! :)

@baradhili J'ai travaillé tout à l'heure sur les problèmes non étiquetés. Pour être honnête, je ne procéderai pas pour aujourd'hui, cela suffisait. Néanmoins, je voulais organiser avec vous les prochaines étapes. Dans l'attente de votre réponse.

@christianlupus oui .. j'ai découvert que je pouvais supporter environ 20/25 problèmes par jour .. après cela, mon cerveau est frit ...
Je vais m'y essayer ce matin..

@dromer prochaines étapes, nous devrions probablement commencer à examiner la hiérarchisation .. et le plus important .. affecter aux développeurs .

@baradhili Je viens de vous envoyer un e-mail à votre domaine ticm. Pouvez-vous s'il vous plaît vérifier votre compte?

avons-nous des développeurs?
Euh ... si nous le faisions, nous n'aurions pas cet arriéré :)

Je pense que vous avancez un peu plus vite que le projet ne le permet actuellement, ce qui est une bonne chose car l'organisation du backlog bloquait les choses, donc j'espère que la priorisation aidera à mettre l'accent sur ceux qui souhaitent contribuer. (les trouver, ou les faire nous trouver, est un défi différent bien sûr)

ok les gars.. nous avons maintenant une liste de problèmes avec tous les problèmes assignés à un jalon et beaucoup de problèmes fermés
Je pense que notre objectif maintenant est de faire développer quelqu'un :) Malheureusement, j'ai NFI autour d'ExtJS et Symfony donc je ne peux pas aider...

options

1. nous obtenons un sponsor et utilisons des indépendants sur guru.com ou stackexchange
2. nous essayons d'en trouver nous-mêmes
3. ?

De plus, vous devez vous assurer de ne pas donner de coups de pied dans les dents à quelqu'un en lui enlevant son dur labeur sans le contacter. Cela est arrivé à ma fonction d'impression et depuis lors, je ne regardais que de côté ce qui se passait ici. Je suis également resté avec un logiciel qui est inutile dans la nouvelle version, car aucune fonction de ce type n'a été ajoutée à nouveau.

Il devrait y avoir une structure claire sur la manière de traiter de telles choses et également sur les décisions architecturales ou sur les bonnes pratiques pour faire quelque chose. Le projet lui-même est clairement structuré et les personnes n'étant pas un expert en php (mais un expert en programmation dans d'autres langages) peuvent implémenter les choses facilement avec un peu d'aide pour les frameworks et les structures utilisés.

@Boldie Salut Sven, désolé si votre travail a été supprimé sans préavis.. les choses ont beaucoup changé dans le projet ces derniers temps et nous sommes très désireux de gagner la confiance de la communauté - _ en particulier les développeurs _

BTW - je suppose que votre fonction d'impression imprime en masse ? que faudrait-il pour que cela fonctionne à nouveau?

Il devrait y avoir une structure claire sur la manière de traiter de telles choses et également sur les décisions architecturales ou sur les bonnes pratiques pour faire quelque chose.

C'est en grande partie correct, mais parce que le projet a été principalement géré dans le cadre d'un projet à une seule personne. Il n'était pas nécessaire de définir des règles pour interagir avec la communauté . Alors que nous commençons à partager le poids du projet sur plusieurs personnes, il pourrait être avantageux de définir des règles sur la façon de procéder.

Le projet lui-même est clairement structuré et les personnes n'étant pas un expert en php (mais un expert en programmation dans d'autres langages) peuvent implémenter les choses facilement avec un peu d'aide pour les frameworks et les structures utilisés.

Je suppose que vous êtes vous-même un programmeur pour pouvoir faire une telle déclaration avec autorité. Je ne veux offenser personne mais en attendant, je pense qu'il est plus difficile de se mouiller les pieds en développant le code.

J'ai essayé mais c'était dur. Les bibliothèques sont obsolètes comme l'enfer et la documentation sur ces anciens codes se fait rare en attendant. De plus, la documentation du projet (par exemple #635) n'est pas complète.
Je ne fais pas d'intimidation ici, mais je tiens à souligner certains problèmes critiques du logiciel actuel. Comme le développeur d'origine est pour la plupart inaccessible à l'époque, nous avons besoin de personnes qui connaissent au moins une partie du code pour remettre les choses sur les rails. J'espère que les "anciens contributeurs" pourront aider ici. Il y a quelques bugs à supprimer mais le problème principal est que le logiciel n'est plus maintenu et maintenable en ce qui concerne les dépendances. Nous devons résoudre les principaux problèmes, sinon le projet échouera.

Je vous demande donc : avez-vous travaillé sur le code et avez-vous de l'expérience avec les dépendances associées ?

BTW - je suppose que votre fonction d'impression imprime en masse ? que faudrait-il pour que cela fonctionne à nouveau?

@Boldie , je vous suggère d'ouvrir un nouveau numéro pour suivre la fonctionnalité manquante. À un moment donné, ce problème ici sera archivé. En conséquence, votre demande de remise en service de la fonctionnalité d'impression sera oubliée par la plupart des gens.

BTW - je suppose que votre fonction d'impression imprime en masse ? que faudrait-il pour que cela fonctionne à nouveau?
Il se compose de 2 parties :

• L'impression en masse de StorageLocations / Parts vers un pdf
• Impression d'une seule pièce (pour les étiquettes)

Le premier était hautement intégré, mais ajoute également des dépendances problématiques. Le second peut-être encore mieux implémenté en utilisant l'API REST aujourd'hui. Il est toujours suivi dans l'un de ces 200 problèmes ouverts :)

Je viens de jeter un œil au code : j'ai quelques problèmes sur la façon dont ce truc fonctionne vraiment. Le cadre semble utiliser une sorte de couplage lâche qui est difficile à suivre. Peut-être qu'un expert utilisant ce framework dira quelque chose de différent (la plupart du temps, j'ai des contacts avec C++ et parfois python avec Django). Je viens de me rappeler qu'il était également difficile de comprendre comment ajouter des éléments lors de ma première implémentation. Le problème que je vois est de faire passer ce projet d'un one-man-show plus ou moins à un projet communautaire. Malheureusement, je ne suis pas la bonne personne pour aider avec le problème de dépendance, mais je suis d'accord, cela doit être la première chose à résoudre afin de réduire le service technique.

Pour faciliter le développement, je suggérerais de configurer une sorte d'environnement que l'on peut facilement commencer à développer sans avoir à travailler deux fois. Dans mon entreprise, nous avons configuré un conteneur docker avec le contenu et également un script pour exécuter des tests / ajouter des données de démonstration, ... pour faciliter le démarrage du développement.

Existe-t-il un moyen de contacter la communauté ? Je pense que la plupart des utilisateurs ne savent pas que nous avons besoin d'aide ici, sinon le projet sera de plus en plus obsolète et à un moment donné inutilisable. Est-il possible de mettre une déclaration sur la page d'accueil ? Comme il y a la plupart des téléchargements, les personnes ayant les connaissances appropriées ne sont pas au courant de la situation et de ce référentiel ici.

@Boldie Bonne idée ! @dromer @Drachenkaetzchen est-ce que quelqu'un a accès à la page Web principale ?

@christianlupus Y a-t-il une liste ici ou dans la vue des jalons des travaux à effectuer ensuite ? Je pense que l'une des premières choses est de passer à Symhony4 #1083 ?

@Boldie oui, il y a eu du travail sur les problèmes de priorités. voir cette liste :

https://github.com/partkeepr/PartKeepr/issues?q=is%3Aopen+is%3Aissue+label%3A%22Must+Have%22

La mise à niveau de symfony et d'autres dépendances est la plus importante et la plus importante du moment.
(même si je pense que l'étiquette « bon premier numéro » est destinée aux nouveaux arrivants, pas pour une désignation « besoins faits en premier »)

Existe-t-il un moyen de contacter la communauté ?
Nous sommes avec un certain nombre d'utilisateurs dans le canal irc #partkeepr sur irc.freenode.net
Il y a aussi les groupes google (un public et un privé), mais je pense que le suivi des problèmes + IRC sont votre meilleur pari pour parler aux gens de PartKeepr en ce moment (en termes d'activité).

De plus, vous devez vous assurer de ne pas donner de coups de pied dans les dents à quelqu'un en lui enlevant son dur labeur sans le contacter. Cela est arrivé à ma fonction d'impression et depuis lors, je ne regardais que de côté ce qui se passait ici. Je suis également resté avec un logiciel qui est inutile dans la nouvelle version, car aucune fonction de ce type n'a été ajoutée à nouveau.

La raison pour laquelle j'ai dû supprimer la fonctionnalité est documentée ici : https://github.com/partkeepr/PartKeepr/issues/622

Si vous sentez que vous avez reçu un coup de pied dans les dents, je suis désolé, mais c'était comme ça à l'époque.

De plus, je passe la majeure partie de mon temps quotidien à écrire ce logiciel. s'il vous plaît, comprenez que si je dois supprimer du code pour créer une version plus récente, alors tant pis. vous auriez pu créer un autre PR pour le rendre compatible avec la nouvelle version

oui, je suis foutrement en colère en ce moment. J'ai passé tant d'années à écrire le code gratuitement, j'ai fait la majorité du travail, fait beaucoup de travail de support, essayé de créer une entreprise et tout ce que je reçois pour les centaines, voire les milliers d'heures de travail non rémunéré, c'est ça.

si ce n'était pas mon sens des responsabilités, j'aurais fermé le site Web et tout le reste il y a 2 ans.

J'ai à peine assez d'argent ces temps-ci pour survivre un mois, j'ai plusieurs maladies dont il est peu probable que je me rétablisse bientôt et j'essaie toujours de maintenir ce projet en vie, même si j'y parviens à peine.

De plus, je passe la majeure partie de mon temps quotidien à écrire ce logiciel. s'il vous plaît, comprenez que si je dois supprimer du code pour créer une version plus récente, alors tant pis. vous auriez pu créer un autre PR pour le rendre compatible avec la nouvelle version

oui, je suis foutrement en colère en ce moment. J'ai passé tant d'années à écrire le code gratuitement, j'ai fait la majorité du travail, fait beaucoup de travail de support, essayé de créer une entreprise et tout ce que je reçois pour les centaines, voire les milliers d'heures de travail non rémunéré, c'est ça.

si ce n'était pas mon sens des responsabilités, j'aurais fermé le site Web et tout le reste il y a 2 ans.

J'ai à peine assez d'argent ces temps-ci pour survivre un mois, j'ai plusieurs maladies dont il est peu probable que je me rétablisse bientôt et j'essaie toujours de maintenir ce projet en vie, même si j'y parviens à peine.

Je sais que vous êtes dans une situation grave et ce projet incluant la communauté a une contribution à votre situation. Je respecte également votre travail et je pense également que ce projet (surtout par rapport à d'autres) a une structure bien faite, sinon je n'essaierais pas de réfléchir à ce que je peux faire pour revitaliser ce projet et comment préparer une équipe de développement à faire le travail nécessaire.
Je ne veux pas réchauffer le passé maintenant, cela ne nous aidera pas à aller plus loin avec Partkeepr.

De mon travail quotidien, je sais qu'il est parfois difficile de gérer le code d'autres personnes surtout si la personne n'est pas joignable (pour l'avenir et si c'est nécessaire, tout le monde peut me contacter par l'adresse e-mail des commits git ou en utilisant le domaine et contactez-moi via ma page d'accueil). Tout le monde a sa propre écriture lors de l'écriture du codage. À mon avis, c'est une sorte de savoir-faire pour écrire du code. J'ai aussi beaucoup d'expérience avec la complexité et combien il est difficile de traverser cela, si l'on veut faire une mise à niveau d'une bibliothèque ou d'un tas de dépendances. J'ai fait cela avec une équipe pendant des mois dans mon travail rémunéré.
Alors maintenant, nous avons à nouveau ce défi ici et nous devons penser à un moyen de le faire avec une communauté. C'est beaucoup plus difficile comme dans un environnement payant où l'on dira : On va le faire.

J'ai jeté un œil au code et depuis que j'ai fait quelque chose la dernière fois, ça a BEAUCOUP changé (quelqu'un investit beaucoup de travail ici !! :). J'ai donc dû creuser à nouveau dans le code et commencer à travailler. Mais pour cela, nous avons besoin d'une communication étroite et d'une feuille de route sur ce qu'il faut faire ensuite. Je pense que ramener la fonctionnalité d'impression est une priorité très faible par rapport aux autres choses et moi ou quelqu'un d'autre pourrai le faire plus tard. Pour moi, il est plus digne de ne pas perdre mes données avec la prochaine mise à niveau du système d'exploitation à l'avenir, car cela signifiera également BEAUCOUP de travail pour migrer vers autre chose (je ne sais pas ce que cela peut être), cela a pris un long travail dans mon temps libre pour remplir la base de données.

Merci @Boldie

@christianlupus @dromer Je pense que nous pouvons fermer celui-ci maintenant que les choses bougent à nouveau...!

Un autre point à discuter : en raison des modifications apportées au #1091, tous les nouveaux problèmes auront des balises attachées. Voulons-nous avoir un indicateur qu'aucun examen humain n'a été effectué ici ?

En dehors de cela, je suis d'accord avec la fermeture de ce problème maintenant.

en quoi ce que nous avons fait est-il différent d'un examen humain ? :)

@baradhili c'est exactement ce que nous avons fait récemment. Je veux dire ce qui suit : puisque le PR nommé a été accepté, tout nouveau problème aura soit un bogue, une demande de fonctionnalité ou un préréglage d'aide en tant qu'étiquette en fonction du type de problème sélectionné.
Cela signifie que les nouveaux problèmes (qui n'ont pas passé le tri manuel que nous avons fait récemment) ne se présenteront pas comme n'ayant pas d'étiquettes attachées. Ainsi, il n'y a pas de filtre simple dans GitHub pour sélectionner les problèmes non encore triés humainement.

Donc en bref : voulons-nous un need-triage ou similaire à indiquer.

pouvons-nous ajouter automatiquement l'étiquette needs-triage sous le système de modèles de github ?

Oui, il s'agit d'ajouter l'étiquette et de modifier une ligne dans le fichier modèle. Cela devrait suffire.

Je viens d'ouvrir le #1097 concernant le système de création de modèles de problèmes. Si l'étiquette needs-triage n'est pas souhaitée, je suggère de supprimer le commit unique.

fermer ça maintenant