Partkeepr: Мета: слишком много открытых вопросов

Созданный на 13 янв. 2020  ·  55Комментарии  ·  Источник: partkeepr/PartKeepr

Как упомянул @baradhili в этом комментарии , на данный момент у нас довольно много открытых вопросов.

Хотя я подтверждаю, что это неприятная ситуация, которая оказывает (слишком) большое давление на разработчика(ов) и возможных заинтересованных людей, я думаю, что это также полезный источник информации о том, что не работает и чего не хватает в PartKeepr. Не все из этих вопросов имеют высокий приоритет, и я должен признать, что многие из них могут оказаться недействительными.

Во-первых, я хотел создать отдельную ветку, чтобы обсудить это, вместо того, чтобы захватывать здесь какие-либо другие вопросы.

Чтобы обойти всю эту ситуацию, предлагаю не закрывать болтающиеся вопросы.
Вместо этого я предлагаю использовать внутренние функции github для управления проектами, чтобы классифицировать и систематизировать проблемы. Вот некоторые идеи, но это будет обсуждаться:

  • Добавление меток к проблемам позволяет разделить ошибки, улучшения, поиск поддержки и другие темы.
  • Добавление вех (в том числе так называемых «будущих» и т. п.) позволяет организовать их в хронологическом порядке.
  • Использование функции проектов для организации вопросов
  • Возможны несколько проектов (один для ошибок, один для улучшений)

Если проект снова начнет активно работать над кодовой базой, мы можем подумать о каком-то устаревшем боте. Но я думаю, что этого не следует делать, пока мы «офлайн».
Там могут быть некоторые открытые вопросы, которые действительно должны быть закрыты. Здесь может быть полезно предупредить пользователей один раз, если проблема все еще представляет интерес, и закрыть только те, которые

  • никто не отвечает и
  • кажутся связанными с отдельными проблемами (например, «Я не могу перейти с x.xx на y, yy»), чтобы не потерять важную информацию.

Самый полезный комментарий

работает на меня! :)

Все 55 Комментарий

так что в основном мы создаем де-факто "отставание"...
@Drachenkaetzchen , вы готовы добавить пару из нас в проект, чтобы мы могли внести какой-то порядок в проблемы?

так что в основном мы создаем де-факто "отставание"...

Вроде, как бы, что-то вроде. Но да, это основная идея.

@Drachenkaetzchen , вы готовы добавить пару из нас в проект, чтобы мы могли внести какой-то порядок в проблемы?

Я готов помочь здесь, если это необходимо.

Эй, ребята, это очень хорошая идея, и мы также обсуждали ее в IRC.

Недавно я получил доступ к github, и я рассмотрю возможность добавления еще нескольких человек, которые помогут с организационной стороной решения проблем, и ценю ваше предложение помочь с этим.
(если из-за нехватки времени я забуду, не стесняйтесь подсказать мне об этом)

Хорошо, @christianlupus, я добавил вас в качестве члена Triage в этот репозиторий.
@baradhili , тебе тоже интересно помочь с этим?

Здесь описаны возможности для этого: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Со временем, конечно, мы добавим еще несколько человек с доступом к коду. А пока давайте попробуем немного сосредоточиться на организации задач.

@dromer да пожалуйста

@dromer Спасибо за дополнение.

Первое предложение — добавить метку needs-triage и настроить правило, чтобы каждая новая проблема и PR помещались в эту метку.
Причина: Репортер видит, что необходима/будет проведена сортировка. Далее мы можем отсортировать (позже) такие вопросы. Может быть, нам следует подумать о том, чтобы поместить каждую проблему под этим ярлыком, чтобы увидеть, что уже сделано и что требует внимания.

И дополнительно: я также предлагаю следующие ярлыки:

  • meta : используется для вопросов, связанных не с самим кодом, а с репозиторием, вики, стандартами программирования и т.п.
  • help-requested : используется для обозначения того, что проблема нуждается в помощи во время установки, использования и т. д. Возможно, это лучше отправить на форум, чем оставлять как проблему здесь, на github.

Звучит неплохо.. хотя я бы посоветовал не ставить все под needs-triage потому что мы просто окажемся там, где мы сейчас :).. Я бы также предложил backlog , next-release и roadmap после проверки

Когда я начал категоризировать несколько вопросов, мне было трудно навешивать на них ярлыки, если они не определены четко (по крайней мере, для части из них).

@christianlupus, как вы хотите координировать сортировку? Я в UTC+8

@christianlupus Похоже, нам может понадобиться еще один тег "move-to-wiki"

@christianlupus, как вы хотите координировать сортировку? Я в UTC+8

@baradhili Я нахожусь в UTC+1 (Берлин).
Я давал нескольким проблемам некоторые ярлыки и вехи, когда это было применимо. Однако сейчас у меня есть время, чтобы приступить к работе. Так что пока сделаю паузу.

Есть ли у вас хорошие предложения по координации? Один человек утром один человек вечером, чтобы избежать столкновений? В какое время вы предпочитаете работать над ним?

Поскольку я не знаю, в каком городе вы живете, я наугад выбрал один из названного часового пояса: здесь вы можете получить краткий обзор, чтобы управлять сдвигом во времени. Вы могли бы хотеть принять к вам город.

@christianlupus Похоже, нам может понадобиться еще один тег "move-to-wiki"

Да, кажется, это так.

@christianlupus В данный момент я работаю над старыми проблемами с тегами bug .. Я думаю, что могу потратить час в 8 или 9 утра по моему времени ... Я использую английскую версию того же сайта - я я в Перте - мы, вероятно, хотим пометить сложные проблемы каким-то тегом, чтобы другие могли посмотреть и высказать свое мнение.

@dromer, если мы дадим вам список новых тегов, можете ли вы их добавить?

О, это то, что мне нужно сделать?

Дайте мне знать, и я посмотрю, чтобы добавить еще несколько.

@christianlupus В данный момент я работаю над старыми проблемами с тегами bug .. Я думаю, что могу потратить час в 8 или 9 утра по моему времени ... Я использую английскую версию того же сайта - я я в Перте -

Хорошо, это полностью зависит от вас. Спасибо за помощь здесь. Сейчас я работаю над непомеченными проблемами, поэтому мы не сталкиваемся.

мы, вероятно, хотим пометить сложные проблемы каким-то тегом, чтобы другой мог посмотреть и высказать свое мнение.

Да, я думаю, это хорошая идея. Как насчет complex-triage ?

О, это то, что мне нужно сделать?

Дайте мне знать, и я посмотрю, чтобы добавить еще несколько.

Мы можем только прикреплять ярлыки и вехи к задачам. Но мы не можем добавлять новые метки в список допустимых. Итак, да, мы просим вас добавить соответствующие ярлыки.

@baradhili Итак, у нас нет этого списка новых ярлыков (пожалуйста, поправьте меня):

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

Насчет своевременных меток ( backlog , roadmap , next-release ) я думаю, что это лучше улавливается вехами, не так ли? Также это должно быть согласовано со всеми, кто предоставляет код репозиторию.

Я обновлю этот комментарий, как только появятся потребности в новых ярлыках. Хорошо с этим? Если да, не стесняйтесь спрашивать об этом дромера.

@дромер
Можем ли мы установить следующие ярлыки?

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

Спасибо

@baradhili Я попытался файле MD . Я добавил вас в качестве соавтора, чтобы вы могли редактировать файл.

Вы согласны с определениями, насколько я их написал?

Все хорошо!документация!

Вт, 14 янв 2020 в 19:36, Кристиан [email protected] писал:

@baradhili https://github.com/baradhili Я пытался упорядочить ярлыки
в MD-файле
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels
немного. Я добавил вас в качестве соавтора, чтобы вы могли редактировать файл.

Вы согласны с определениями, насколько я их написал?


Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/partkeepr/PartKeepr/issues/1066?email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4JJYQ#issue#
или отписаться
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
Брет Уотсон
директор
IT Interim Management Pty Ltd T/A TICM
Моб: +61 (0)41 33 03 840
Электронная почта:[email protected]
«Содержание этого сообщения электронной почты предназначено исключительно для указанного
получатель(и), может быть конфиденциальным, а также может быть привилегированным или иным образом
защищены от разглашения в общественных интересах. Использование, воспроизведение,
разглашение или распространение содержания этого сообщения электронной почты
любое лицо, кроме указанного получателя(ей), запрещено. Если вы не
имя получателя, пожалуйста, немедленно сообщите об этом отправителю».

build system явно имеет отношение к ci/cd (см. мои 2 PR), поэтому я бы оставил его.

Я добавлю ваш список @baradhili и, надеюсь, вы, ребята, сможете хотя бы продвинуться вперед.
На данный момент я думаю, что лучше иметь «слишком много» ярлыков, чем «слишком мало». Мы всегда можем удалить/игнорировать определенные ярлыки.

Какие-то определенные цвета, которые вы хотите связать с ними? :)

Хорошо, слишком поздно, я пока выбрал цвета по умолчанию :D

@dromer Можем ли мы установить веху для 1.5.0?

@christianlupus Я собираюсь использовать 1 - Ready для вещей, которые кажутся/утверждаются исправленными, но нуждаются в тестировании.

@dromer в ретроспективе.. Я понял, что могу справиться с вещами, которые выглядят так, как будто их нужно сделать «скоро» с Must Have
@christianlupus закончил Bug .. теперь работает над старыми проблемами без контрольной точки

Я удаляю метки типа Will be closed soon! и Feedback Needed как только проблема может быть закрыта. Это нормально для нашего общего рабочего процесса?

@dromer, можно мне еще один тег.. low-hanging ? Время от времени я вижу проблемы, которые должны быть легко исправлены

@christianlupus да .. и я должен вернуться и проверить, что я сделал это

По-видимому, github предоставляет некоторые автоматические «хуки», если вместо этого вы используете тег good first issue :

Пометить проблемы и запросы на вытягивание для новых участников

Теперь GitHub поможет потенциальным новым участникам обнаруживать проблемы, помеченные good first issue

Так мне его так называть?
Проблемы с этим тегом появятся в некоторых других обзорах, которые должны побудить людей принять участие.

Нравится на https://github.com/partkeepr/PartKeepr/contribute

работает на меня! :)

@baradhili Я только что проработал непомеченные проблемы. Честно говоря, я не буду продолжать на сегодня, этого было достаточно. Тем не менее, я хотел договориться с вами о следующих шагах. Жду Вашего ответа.

@christianlupus да .. Я обнаружил, что могу выдерживать около 20/25 проблем в день .. после этого мой мозг поджаривается ...
сегодня утром побегаю..

Следующие шаги @dromer нам, вероятно, придется начать с расстановки приоритетов .. и, что наиболее важно .. назначения разработчикам .. у нас есть разработчики?

@baradhili Я только что отправил вам электронное письмо на ваш домен ticm. Не могли бы вы проверить свой аккаунт?

у нас есть разработчики?
Э... если бы мы это сделали, у нас бы не было этого отставания :)

Я думаю, что вы, ребята, движетесь немного быстрее, чем проект в настоящее время «позволяет», и это хорошо, поскольку организация невыполненной работы засоряла все, поэтому, надеюсь, расстановка приоритетов поможет сосредоточить внимание на тех, кто хочет внести свой вклад. (найти их или заставить их найти нас, конечно, другая задача)

хорошо, ребята.. теперь у нас есть список проблем со всеми задачами, назначенными вехе, и довольно много закрытых
Я думаю, что сейчас мы сосредоточены на том, чтобы заставить кого-то развиваться :) к сожалению, у меня есть NFI вокруг ExtJS и Symfony, поэтому я не могу помочь...

опции

  1. мы получаем спонсора и используем фрилансеров на guru.com или stackexchange
  2. мы пытаемся найти некоторые сами
  3. ?

Кроме того, вы должны позаботиться о том, чтобы не ударить кого-то по зубам, удалив его тяжелую работу, не связавшись с ним. Так произошло с моей функцией печати, и с тех пор я только со стороны наблюдал за тем, что здесь происходит. Я также застрял с частью программного обеспечения, которое бесполезно в более новой версии, потому что такая функция больше не добавлялась.

Должна быть четкая структура того, как поступать с такими вещами, а также с архитектурными решениями или с тем, что является хорошей практикой, чтобы что-то делать. Сам проект четко структурирован, а также люди, не являющиеся экспертами в php (но экспертами в программировании на других языках), могут легко реализовывать вещи с некоторой помощью используемых фреймворков и структур.

@Boldie Привет, Свен, приносим свои извинения, если ваша работа была удалена без предварительного уведомления. В последнее время в проекте многое изменилось, и мы очень стремимся завоевать доверие сообщества - особенно разработчиков _

Кстати, я предполагаю, что ваша функция печати выполняет массовую печать? что нужно, чтобы он снова заработал?

Должна быть четкая структура того, как поступать с такими вещами, а также с архитектурными решениями или с тем, что является хорошей практикой, чтобы что-то делать.

Это в основном правильно, но потому что проект в основном управлялся проектом с одним человеком. Не было необходимости определять правила взаимодействия с сообществом . Поскольку мы начинаем делить вес проекта на нескольких человек, может быть полезно определить правила того, как действовать дальше.

Сам проект четко структурирован, а также люди, не являющиеся экспертами в php (но экспертами в программировании на других языках), могут легко реализовывать вещи с некоторой помощью используемых фреймворков и структур.

Я предполагаю, что вы сами программист, чтобы иметь возможность сделать такое заявление авторитетно. Я не хочу никого обидеть, но в то же время я думаю, что труднее намочить ноги, разрабатывая код.

Я пробовал, но это было тяжело. Библиотеки чертовски устарели, а документация по этим старым кодам в настоящее время редка. Далее документация проекта (например, #635) не завершена.
Я не запугиваю здесь, но я хочу указать на некоторые критические проблемы текущего программного обеспечения. Поскольку первоначальный разработчик в настоящее время в основном недоступен, нам нужны люди, которые знают хотя бы часть кода, чтобы вернуть все в нужное русло. Я надеюсь, что «старые участники» смогут помочь здесь. Есть несколько ошибок, которые нужно удалить, но основная проблема заключается в том, что программное обеспечение больше не поддерживается и не ремонтируется в отношении зависимостей. Нам нужно решить основные проблемы, иначе проект НЕ СОВЕРШИТСЯ.

Поэтому я спрашиваю вас: вы работали над кодом и есть ли у вас опыт работы с соответствующими зависимостями?

Кстати, я предполагаю, что ваша функция печати выполняет массовую печать? что нужно, чтобы он снова заработал?

@Boldie , я предлагаю вам открыть новую проблему, чтобы отследить недостающую функциональность. В какой-то момент этот выпуск здесь будет заархивирован. В результате ваш запрос на восстановление работоспособности функции печати будет забыт большинством людей.

Кстати, я предполагаю, что ваша функция печати выполняет массовую печать? что нужно, чтобы он снова заработал?
Он состоит из 2 частей:

  • Массовая печать StorageLocations/Parts в pdf
  • Печать одной детали (для этикеток)

Первый был сильно интегрирован, но также добавлял некоторые проблемные зависимости. Второй вариант может быть реализован сегодня лучше с использованием REST API. Он до сих пор отслеживается в одном из этих 200 открытых выпусков :)

Я только что взглянул на код: у меня есть некоторые проблемы с тем, как это работает на самом деле. Структура, кажется, использует своего рода слабую связь, которой трудно следовать. Возможно, эксперт, использующий этот фреймворк, скажет что-то другое (большую часть дня я общаюсь с C++, а иногда с python и django). Я только что вспомнил, что это также было трудно понять, как добавить некоторые вещи, когда я сделал свою первую реализацию. Проблема, как я вижу, состоит в том, чтобы перевести этот проект из более или менее шоу одного человека в проект, управляемый сообществом. К сожалению, я не тот человек, который может помочь с проблемой зависимости, но я согласен, это нужно решить в первую очередь, чтобы сократить технический отдел.

Чтобы упростить разработку, я бы предложил настроить среду, в которой можно легко начать разработку, не выполняя работу дважды. В моей компании мы настроили док-контейнер с материалами, а также скрипт для запуска тестов / добавления демонстрационных данных, ... чтобы упростить начало разработки.

Есть ли способ связаться с сообществом? Я думаю, что большинство пользователей не знают, что здесь нам нужна помощь, иначе проект будет все более и более устаревать и в какой-то момент станет непригодным для использования. Можно ли разместить заявление на главной странице? Так как там большая часть загрузок, люди с должными знаниями не в курсе ситуации и этого репозитория здесь.

@Болди Хорошая идея! @dromer @Drachenkaetzchen у кого-нибудь есть доступ к главной веб-странице?

@christianlupus Есть ли здесь или в представлении вех список того, какую работу необходимо выполнить дальше? Я думаю, что одной из первых вещей является обновление до Symhony4 #1083?

@Boldie, да, была проделана работа по решению проблем с приоритетами. см. этот список:

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

Обновление symfony и других зависимостей является самым большим и важным на данный момент.
(хотя я думаю, что тег «хороший первый выпуск» предназначен для новичков, а не для обозначения «нужно сделать в первую очередь»)

Есть ли способ связаться с сообществом?
Мы с несколькими пользователями на irc-канале #partkeepr на irc.freenode.net.
Есть также группы Google (общедоступная и частная), но я думаю, что система отслеживания проблем + IRC — лучший способ поговорить с людьми о PartKeepr на данный момент (с точки зрения активности).

Кроме того, вы должны позаботиться о том, чтобы не ударить кого-то по зубам, удалив его тяжелую работу, не связавшись с ним. Так произошло с моей функцией печати, и с тех пор я только со стороны наблюдал за тем, что здесь происходит. Я также застрял с частью программного обеспечения, которое бесполезно в более новой версии, потому что такая функция больше не добавлялась.

Причина, по которой мне пришлось удалить эту функциональность, описана здесь: https://github.com/partkeepr/PartKeepr/issues/622.

Если вы чувствуете, что вас ударили по зубам, извините, но так было тогда.

Кроме того, я трачу большую часть своего ежедневного времени на написание этого программного обеспечения. пожалуйста, поймите, черт побери, что если мне придется удалить код, чтобы сделать более новую версию, то, черт возьми, пусть будет так. вы могли бы создать другой PR, чтобы сделать его совместимым с новой версией

да, я чертовски зол прямо сейчас. Я потратил столько лет на написание кода бесплатно, сделал большую часть работы, выполнил много работы по поддержке, пытался создать бизнес, и все, что я получаю за сотни, если не тысячи часов неоплачиваемой работы, это это.

если бы это не было моим чувством ответственности, я бы закрыл сайт и все остальное 2 года назад.

у меня едва хватает денег в эти времена, чтобы прожить месяц, имея несколько болезней, которые я вряд ли вылечу в ближайшее время, и я все еще стараюсь как-то поддерживать этот проект, хотя у меня вряд ли это получается.

Кроме того, я трачу большую часть своего ежедневного времени на написание этого программного обеспечения. пожалуйста, поймите, черт побери, что если мне придется удалить код, чтобы сделать более новую версию, то, черт возьми, пусть будет так. вы могли бы создать другой PR, чтобы сделать его совместимым с новой версией

да, я чертовски зол прямо сейчас. Я потратил столько лет на написание кода бесплатно, сделал большую часть работы, выполнил много работы по поддержке, пытался создать бизнес, и все, что я получаю за сотни, если не тысячи часов неоплачиваемой работы, это это.

если бы это не было моим чувством ответственности, я бы закрыл сайт и все остальное 2 года назад.

у меня едва хватает денег в эти времена, чтобы прожить месяц, имея несколько болезней, которые я вряд ли вылечу в ближайшее время, и я все еще стараюсь как-то поддерживать этот проект, хотя у меня вряд ли это получается.

Я знаю, что вы находитесь в серьезной ситуации, и этот проект, включая сообщество, внес свой вклад в вашу ситуацию. Я также уважаю вашу работу, и я также считаю, что этот проект (особенно по сравнению с другими) имеет хорошо сделанную структуру, иначе я бы не стал думать, что я могу сделать, чтобы оживить этот проект и как подготовить команду разработчиков к выполнению необходимая работа.
Не хочу сейчас подогревать прошлое, Это не поможет нам дальше идти с Partkeepr.

Из моей повседневной работы я знаю, что иногда трудно иметь дело с кодом от других людей, особенно если человек недоступен (в будущем и, если это необходимо, каждый может связаться со мной по адресу электронной почты из коммитов git или используя домен и свяжитесь со мной, используя мою домашнюю страницу). У каждого свой почерк при написании кода. На мой взгляд, это своего рода мастерство в написании кода. У меня также есть большой опыт со сложностью и тем, как тяжело это пройти, если вы будете делать апгрейд библиотеки или кучу зависимостей. Я делал это с командой в течение нескольких месяцев на моей оплачиваемой работе.
Итак, теперь у нас снова есть эта проблема, и мы должны подумать о том, как сделать это с сообществом. Это гораздо сложнее, как в платной среде, где говорят: мы сделаем это.

Я взглянул на код, и с тех пор, как я что-то сделал в прошлый раз, он ОЧЕНЬ сильно изменился (кто-то вкладывает здесь много работы!!:). Поэтому мне пришлось снова копаться в коде и начинать работать. Но для этого нам нужна тесная коммуникация и дорожная карта, что делать дальше. Я думаю, что возвращение функции печати имеет очень низкий приоритет по сравнению с другими вещами, и я или кто-то другой может сделать это позже. Для меня более достойно не потерять свои данные при следующем обновлении ОС в будущем, потому что это также будет означать МНОГО работы по переходу на что-то другое (я не знаю, что это может быть), это длительная работа. в свободное время для заполнения базы данных.

Спасибо @Boldie

@christianlupus @dromer Я думаю, мы можем закрыть это, раз уж дела снова пошли в гору ...!

Еще один момент для обсуждения: в связи с изменениями в #1091 все новые выпуски будут иметь определенные теги. Хотим ли мы иметь индикатор того, что здесь не проводилось никакой проверки людьми?

Кроме того, я согласен с закрытием этого вопроса сейчас.

чем то, что мы сделали, отличается от человеческого обзора? :)

@baradhili это именно то, что мы недавно сделали. Я имею в виду следующее: поскольку названный PR был принят, любые новые проблемы будут иметь предустановку «Ошибка», «Запрос функции» или «Требуется помощь» в качестве метки в зависимости от выбранного типа проблемы.
Это означает, что новые проблемы (которые не прошли ручную сортировку, которую мы недавно проходили) не будут отображаться как не имеющие прикрепленных ярлыков. Таким образом, в GitHub нет простого фильтра для выбора тех проблем, которые еще не рассмотрены человеком.

Короче говоря: мы хотим, чтобы need-triage или что-то подобное указывали.

можем ли мы автоматически добавить метку needs-triage в систему шаблонов github?

Да, это вопрос добавления метки и изменения одной строки в файле шаблона. Этого должно быть достаточно.

Я только что открыл # 1097 по поводу системы шаблонов задач. Если метка needs-triage не нужна, я предлагаю удалить единственную фиксацию.

закрыть это сейчас

Была ли эта страница полезной?
0 / 5 - 0 рейтинги