Pods: Ярлыки GitHub

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

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

«Патч» - это то, что я никогда не использовал в своем рабочем процессе, так как он кажется мне избыточным. Если это пиар, то это патч. Но @ sc0ttkclark традиционно использовал этот ярлык, поэтому он может иметь для него некоторую ценность для рабочего процесса.

~ Component: Multi-site было бы хорошим дополнением, это еще одна область, такая как REST API и шаблоны, которые были бы полезны для начала тегирования для целей фильтрации. ~

Выполнено

Фокус: обратная совместимость
Фокус: совместимость / устаревание
В центре внимания: совместимость

Для этих трех, возможно, доработанных:

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

Изменить: это сделано

Помимо этой мелочи, я все готово к этому. Классификация намного лучше, и я бы хотел ее использовать, хотя 2.7.7.

Я хочу сначала получить явные одобрения от @ sc0ttkclark .

В чем разница между Discussion и Team Discussion ? Можно ли их заменить на Needs: Developer Feedback ?

Что такое Integration ?

Вот мой второй проход. Несколько новых дополнений / изменений. Те, у которых есть ведущие вопросительные знаки, могут быть отброшены, если не используются:

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

В чем разница между обсуждением и групповым обсуждением? Можно ли их заменить на "Потребности: отзывы разработчиков"?

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

Что такое интеграция?

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

Я не уверен, что раздел «Потребности:» лучше ... Мне понравилась идея их как части «Статус:», поскольку я думаю, что они часто используются именно так.

Изменить: все это было решено

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

~ Это похоже на билеты, которые не очень хорошо описаны другими. ~

Выполнено

Кроме того, для прокрутки мне интересно, следует ли нам просто обновлять список в начальном сообщении, а не публиковать новые версии по ходу?

Выполнено.

Мне нравится эта идея:

Требуется: обратная связь с разработчиками
Потребности: Исследования
Требуется: список задач
Потребности: Тест (ы)
Потребности: обратная связь с пользователями
Потребности: проверка / воспроизведение
Потребности: Голоса

Но «Обратная связь с пользователем» и «Проверка / воспроизведение» на самом деле являются «статусом / рабочим процессом», как отмечал @pglewis выше, или мы могли бы

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

support.pods.io и docs.pods.io вообще не должно быть (у нас есть репозитории для этих двух веб-сайтов), если только мы не планируем использовать GitHub для обновлений поддержки и документации. Если мы собираемся это сделать (для чего я ВСЕ), мы добавляем префикс для Docs: и Support: и создаем два проекта в GitHub в этом репозитории для поддержки и документации. Поскольку иногда проблема поддержки может превращаться в фактическое улучшение кода / функцию или исправление ошибок, для нас действительно имеет смысл использовать тот же интерфейс. Конечно, у нас будет больше, но мы также позаботимся о том, чтобы получить именно то, что нам нужно, для решения проблем поддержки и обновления документации.

Я просмотрел это и хотел бы увидеть следующие изменения:

• Тип : Добавить Support & Docs Update (удаление Support из Keyword )
• Компонент : нам не нужны support.pods.i o или doc.pods.io в Component . У этих двух репо есть свои проекты. Компонент должен быть полностью посвящен основной области стручков.
• Приоритет : переместить Focus из ключевого слова в Priority . Blocker в порядке, если мы знаем причину, которая должна исходить от потребностей .

Итак, если я правильно это сделаю, все должно иметь:
Тип : определяет тип билета.
Статус : определяет, где он находится в рабочем процессе. Небольшое обсуждение того, какой статус должен быть «Заблокирован», «Сделать» или «Удерживать», если нам нужна обратная связь с пользователем или проверка / воспроизведение. Не уверен, каков будет статус для запроса функции / улучшения, где потребности - это голоса. Возможно, они следуют тому же формату, что и типичная доска Kanban, и их статус - BackLog, пока он не будет активно работать. Блокировщик указывает, что с ним нельзя работать, пока не будут удовлетворены потребности.
Компонент : определяет область ядра модуля для функции / улучшения / ошибки.
Ключевое слово и Фокус предназначены только для дополнительного пояснения?

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

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

Вот случай, когда мы не используем ярлык с теми же намерениями. Я всегда использовал Blocker (и я думаю, что Скотт тоже) для проблем, которые блокируют выпуск (или, может быть, другой тикет) и должны быть выполнены; нельзя колоть.

В моем рабочем процессе нет причин отмечать что-то как удерживающее с помощью «Блокировщика» ... текущие метки состояния должны подразумевать это. Мне не нужны «Нужна обратная связь с пользователем» плюс «Блокировщик», так как первый уже говорит мне, что он блокирует и почему.

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

~ Я думаю, что "Фокус" также должен переместиться с ключевых слов на приоритет. ~ Оставить ключевые слова

Мне нравится эта идея:

Требуется: обратная связь с разработчиками
Потребности: Исследования
Требуется: список задач
Потребности: Тест (ы)
Потребности: обратная связь с пользователями
Потребности: проверка / воспроизведение
Потребности: Голоса

Для меня это в первую очередь статусы билетов, поэтому я предлагаю пока оставить их там. Если длина является проблемой, мы можем сократить некоторые («Статус: нужен Dev FB», «Статус: нужна проверка / репродукция»).

Думаю, можно пойти в "Список задач". Я не думаю, что этого достаточно, чтобы получить ярлык. Не уверен, что когда-либо использовал его, если да, то редко. Вероятно, то же самое для «Требуются тесты». Остальные все мне подходят под «Статус: *».

Кроме того, список складывается для меня хорошо, наверное, стоит обсудить цветовую схему.

Еще пара, которая, вероятно, может быть удалена из Статусов вместе с «Требуется список задач»:

• ~ "Выведено для проверки", вероятно, просто непреднамеренное дублирование "Готово для проверки" ~ Оставляем его
• "Unit Tested" - это не статус (по крайней мере, пока), скорее разное ... так что, наверное, переместили в Ключевые слова?

Таким образом, список статусов мне кажется приятным.

"Выведено для проверки", вероятно, просто непреднамеренное дублирование "Готово для проверки".

Не согласен. Если я создам PR, то, когда он будет готов, я добавлю «Готово к рассмотрению». Но, возможно, у вас не будет времени сделать этот обзор позже - но к тому времени Скотт не уверен, начали ли вы обзор или нет. Короче говоря, это две разные группы людей, добавляющих «Готово для проверки» и «Выведено для проверки».

Вероятно, то же самое для «Требуются тесты».

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

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

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

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

Я согласен с Филом здесь - я понял, что это означает, что Проблема с этой меткой блокирует _release_. Возможно, объяснение Джима лучше подходит для ярлыка Status: Is Blocked или аналогичного, хотя Needs: * будет означать то же самое.

Кстати, можно ли удалить промежуточный список здесь: # 5016 (комментарий)?

@pglewis Удалите (или спрячьте в <details>...</details> для исторической справки) все, что хотите.

support.pods.io и docs.pods.io здесь вообще не должно быть

Это я добавил их из-за неуверенности в существующем теге «Docs Improve» (по сравнению с Docs: inline) - их можно удалить, если они обрабатываются где-то еще.

Docs Improvement лучше было бы записать как «Docs: Inline» »Docs: Examples» «Docs: Tooltips» и тому подобное. Если мы не обрабатываем рабочий процесс документации (т.е. письменной документации на веб-сайте docs.pods.io) в GitHub, здесь нет причин для этого. Любые улучшения документации в нашем коде означают, что документы _в нашем коде или управляются в нашем коде, или как файл readme, который анализируется и отправляется в репозиторий плагинов WordPress.org.

Мне нравится Status: Is Blocked поскольку это очень информативно, но если вы сделаете что-то в этом роде, для этого также потребуется Needs: *

Как я уже сказал, все получает Type и Status . Пока мы не начнем полное гибкое управление проектами с помощью GitHub, приоритеты не нужно там определять, они лучше представлены в единицах работы, необходимых для выполнения «истории». Мы всегда использовали Focus, чтобы выделить элементы из сотен проблем, на которые нужно обратить внимание в следующем выпуске обслуживания.

Я думаю только о ярлыках UI / CSS, так как именно с ними я имею дело больше всего ... кажется, что, возможно, просто удалить CSS как компонент и полагаться только на UI имеет для меня наибольший смысл. Не уверен, что у вас есть какие-то мысли, но CSS - это результат, а не то, что нужно исправить ... если это имеет смысл. Пользовательский интерфейс был бы осязаемой вещью, над которой нужно работать или улучшать, css будет результатом или тем, как это исправить. В остальном мне это нравится 👍

Я думаю только о ярлыках UI / CSS, так как именно с ними я имею дело больше всего ... кажется, что, возможно, просто удалить CSS как компонент и полагаться только на UI имеет для меня наибольший смысл. Не уверен, что у вас есть какие-то мысли, но CSS - это результат, а не то, что нужно исправить ... если это имеет смысл. Пользовательский интерфейс был бы осязаемой вещью, над которой нужно работать или улучшать, css будет результатом или тем, как это исправить.

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

Я бы проголосовал за то, чтобы оставить CSS и UI в том виде, в каком они были предложены на данный момент, но мы, безусловно, можем продолжить его доработку после фазы I.

RE: Требуются тесты

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

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

«Тип: тесты» было бы хорошим дополнением, потому что сейчас добавленные тесты, вероятно, лучше всего как их собственные пары проблема / PR.

Мне нравится Status: Is Blocked, поскольку это очень информативно, но если вы сделаете что-то в этом роде, для этого также потребуется Needs: *

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

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

• Сортировка: отфильтровать недопустимые, поддержка, функции / улучшения; установить тип на ошибку
• Обычно статус сразу переходит в "требуется проверка / повторное изготовление".
• Может переключаться между «требуется обратная связь от пользователя» и «требуется обратная связь от разработчика» на протяжении всего срока службы.
• Проверено / воспроизведено
• Необходимы исследования: теперь, когда мы знаем, как это сделать, выясним и поймем, почему
• Исследовано: я, наверное, единственный, кто этим пользуется. Сигнализирует, что в какой-то момент было сделано глубокое погружение, и у меня, вероятно, есть внутренние детали, хранящиеся в моей голове
• Исправлено / Требуется тестирование

Не согласен. Если я создам PR, то, когда он будет готов, я добавлю «Готово к рассмотрению». Но, возможно, у вас не будет времени сделать этот обзор позже - но к тому времени Скотт не уверен, начали ли вы обзор или нет. Короче говоря, это две разные группы людей, добавляющих «Готово для проверки» и «Выведено для проверки».

Я думаю, что в таких случаях лейбл «Удержать» исторически был лучше, чем «Вытянут для проверки».

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

Мы можем удалить «Патч», я начал использовать его, когда в GitHub был более запутанный UX между PR и проблемами, было легче увидеть представление «Release» с исправлениями, в основном для того, чтобы вернуться к вещам для журнала изменений. Нам это не нужно.

Актуален ли список в исходном описании проблемы с учетом всех обсужденных нами изменений?

Актуален ли список в исходном описании проблемы с учетом всех обсужденных нами изменений?

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

Что бы мы ни решили здесь, нам нужно применить ко всем другим нашим репозиториям Pods, используя такой инструмент, как https://github.com/dwyl/labels, для их синхронизации.

Перемещение «регрессии» от типа к ключевым словам. Ошибка по-прежнему является типом проблем с регрессией.

Сейчас это в значительной степени реализовано. Несколько разных вещей, которые я пока что засунул в раздел «Ключевые слова».

На данном этапе главное, над чем нужно работать, - это цвета.

? Закрыто: недействительно

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

На данном этапе главное, над чем нужно работать, - это цвета.

Цвета на этом этапе второстепенны - добавьте надписи и определите цветовую схему позже.

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

Я добавлю Invalid, я просто пометил это как напоминание, потому что у нас его еще не было.

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

Цвета на этом этапе второстепенны - добавьте надписи и определите цветовую схему позже.

Ярлыки в значительной степени реализованы.

Нужен ли нам «Тип: GitHub» или что-то подобное? У этой проблемы нет типа.

Type: Project ?

Что, если вместо «Не исправить» мы использовали «Оставить как есть» или что-то в этом роде?

Что, если вместо «Не исправить» мы использовали «Оставить как есть» или что-то в этом роде?

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

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

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

What if instead of "Won't Fix" we used "Leave as is" or something like that?

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

Я согласен. Не все, что делает ядро ​​WordPress, нужно дублировать

Я согласен. Не все, что делает ядро ​​WordPress, нужно дублировать

Это также одна из меток по умолчанию при настройке нового репо на GH - см. Https://github.com/GaryJones/daterange/labels, где есть метки по умолчанию.

I agree. Not everything that WordPress core does needs to be duplicated

Это также одна из меток по умолчанию при настройке нового репо на GH - см. Https://github.com/GaryJones/daterange/labels, где есть метки по умолчанию.

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

Я буду придерживаться своей неприязни. Мой непосредственный вопрос на тему «Не исправлю»: «Почему мы отказываемся что-то исправлять?». И если кто-то даст мне хороший краткий ответ на этот вопрос в билете, я скажу, что это именно то, что должно быть написано на этикетке, а не «Не исправлю».

Я думаю, что в любом случае Out of Scope - лучший ответ. «Не исправить» просто подразумевает и не дает «ничего» человеку, открывающему проблему.

возможно, это могло бы пойти в нужном направлении - не стесняйтесь предлагать «решение», но у команды недостаточно ресурсов для этого: D может быть, у кого-то есть идея для короткого сокращения для этого ^^

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

Не стесняйтесь не указывать это.