Pods: GitHub 레이블

~"Changelog 필요" 레이블로 갈 수 있습니다. 나는 변경 로그 업데이트를 병합 프로세스의 일부로 만들고 그 단기 레이블을 사용하지 않았습니다.~
완료

나는 가는 빗으로 처리할 시간이 없었지만 첫 번째 스킴에서 즉시 눈부신 어떤 것도 보지 못했습니다. 솔리드 패스에서 몇 가지 조정, 누락, 삭제를 찾을 수 있지만 내 본능은 이것이 제안된 현재 레이블 시스템보다 크게 개선될 것이라는 것입니다.

"패치"는 제 작업 흐름에서 한 번도 사용하지 않은 것인데, 저에게 중복되는 것 같습니다. 그것이 PR이라면, 그것은 패치입니다. 그러나 @sc0ttkclark 는 전통적으로 그 레이블을 사용했기 때문에 그에게 약간의 워크플로 가치가 있을 수 있습니다.

~ Component: Multi-site 는 좋은 추가 사항이 될 것입니다. REST API 및 필터링 목적으로 태그 지정을 시작하는 데 도움이 되는 템플릿과 같은 또 다른 영역입니다.~

완료

초점: 이전 버전과의 호환성
초점: 호환성/사용 중단
초점: 호환성

이 세 가지에 대해 아마도 세련되었을 것입니다.

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

편집: 완료되었습니다

지금까지 그 작은 것들 외에, 나는 이것에 대해 모두 GO입니다. 분류가 훨씬 좋아져서 2.7.7에도 사용하고 싶습니다.

먼저 @jimtrue 및 @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

토론과 팀 토론의 차이점은 무엇입니까? Needs: Developer Feedback으로 대체할 수 있습니까?

많지는 않습니다. 토론은 전 세계에 공개되고 팀 토론은 내부에 있을 것입니다. 그렇게 세분화된 단일 일반 토론 레이블이 필요하지 않다고 생각합니다(중복은 의도하지 않은 것일 수 있음). 개발자 피드백은 일반적으로 상태로 사용되며 일반적으로 사용자 피드백을 위해 보류 중이고 피드백을 받은 티켓입니다.

통합이란 무엇입니까?

주로 다른 플러그인, 라이브러리, 테마 등과의 통합과 관련된 기능 요청입니다. 기존 통합의 버그가 이 우산에 속할 수 있다고 생각하지만 종종 통합이 이루어지면 "호환성"으로 더 적절합니다. (그래서 통합은 유형일 수 있지만 아마도 당신이 한 것처럼 Focus에서 더 의미가 있을 수 있습니다)

'Needs:' 섹션이 더 나은지 잘 모르겠습니다... "Status:" 섹션의 아이디어가 마음에 들었습니다. 왜냐하면 자주 사용되는 방식이라고 생각하기 때문입니다.

편집: 이것은 모두 해결되었습니다

~다음 키워드가 실제로 유형: 릴리스, 지원 및 도구일 수 있다고 생각합니다.~

~그건 다른 사람이 잘 설명하지 않는 유형의 티켓처럼 보입니다. ~

완료

또한 스크롤을 위해 새 버전을 게시하는 대신 초기 메시지의 목록을 최신 상태로 유지해야 하는지 궁금합니다.

완료.

나는 이것의 아이디어를 좋아한다:

필요: 개발자 피드백
필요: 연구
필요: 작업 목록
요구 사항: 테스트
요구 사항: 사용자 피드백
필요: 검증/복제
필요: 투표

그러나 '사용자 피드백'과 '검증/복제'는 위에서 @pglewis가 언급한 것처럼 실제로 '상태/작업 흐름'이거나 이를 차단기의 '이유'인 필요와 함께 상태: 차단기로 둘 수 있습니다.

상태 워크플로는 이상적으로 프로젝트의 스윔 레인으로 축소되어야 합니다. 이 레이블 목록을 보고 우리가 이렇게 많은지 몰랐지만 여러분이 몇 개 더 만들었던 것 같습니다.

지원 및 설명서 업데이트를 위해 GitHub를 사용할 계획이 아니라면 support.pods.io 및 docs.pods.io 는 여기에 전혀 포함되어서는 안 됩니다(두 웹 사이트에 대한 저장소가 있음). 그렇게 하려는 경우(저는 모두) Docs: 및 Support:에 접두사를 추가하고 이 리포지토리의 Support 및 Documentation에 대해 GitHub에 두 개의 프로젝트를 만듭니다. 때때로 지원 문제가 실제 코드 향상/기능 또는 버그 수정으로 바뀔 수 있으므로 동일한 인터페이스를 사용하는 것이 합리적입니다. 물론 더 많은 것이 있을 것이지만 지원 문제 및 문서 업데이트에 필요한 것을 정확히 얻을 수 있도록 할 것입니다.

나는 이것을 살펴보았고 다음과 같은 변화를 보고 싶다.

• 유형 : Support 및 Docs Update ( Support 에서 Keyword )
• 구성 요소 : 우리는 필요가 없습니다 support.pods.i O 또는 doc.pods.io 에서 Component . 이 두 저장소에는 자체 프로젝트가 있습니다. 구성 요소는 전적으로 Pods Core 초점 영역을 위한 것이어야 합니다.
• 우선 순위 : Focus 를 키워드에서 Priority 합니다. Blocker 는 Needs 에서 나온 이유를 알고 있는 한 괜찮습니다.

따라서 이것을 올바르게 따르면 모든 것이 다음과 같아야 합니다.
유형 : 티켓의 유형을 정의합니다.
상태 : 워크플로의 위치를 ​​정의합니다. 사용자 피드백 또는 확인/복제가 필요한 경우 상태가 '차단됨' 또는 '할 일' 또는 '보류'여야 하는지에 대한 논의가 거의 없습니다. 요구 사항이 투표인 기능/개선 요청에 대한 상태가 확실하지 않습니다. 아마도 그것들은 일반적인 Kanban 보드에 대해 동일한 형식을 따르고 활발히 작동할 때까지 상태는 BackLog입니다. 차단기는 요구 사항이 처리될 때까지 작업할 수 없음을 나타냅니다.
Component : Feature/Enhance/Bug에 대한 Pods Core의 영역을 결정합니다.
키워드 및 초점 은 추가 설명을 위한 것입니까?

이러한 상태가 더 이상 자동으로 추가되지 않도록 WaffleBot을 제거했습니다.

차단기는 요구 사항이 처리될 때까지 작업할 수 없음을 나타냅니다.

다음은 같은 의도로 레이블을 사용하지 않는 경우입니다. 저는 릴리스(또는 다른 티켓)를 차단하고 완료해야 하는 문제에 대해 항상 Blocker(그리고 Scott도 마찬가지라고 생각합니다)를 사용해 왔습니다. 펀트 할 수 없습니다.

내 워크플로에서 '차단기'를 통해 무언가를 보류 중인 것으로 표시할 이유가 없습니다... 현재 상태 레이블이 이를 의미해야 합니다. "사용자 피드백 필요"와 "차단기"가 필요하지 않습니다. 첫 번째 항목이 이미 차단 중이고 그 이유를 알려 주기 때문입니다.

내 투표는 우리가 그것을 그런 식으로 사용하고 나에게 완벽한 설명이기 때문에 "우선 순위: *" 아래에 보관한다는 것입니다.

~포커스도 키워드에서 우선순위로 옮겨야 한다고 생각합니다.~ 키워드 남기기

나는 이것의 아이디어를 좋아한다:

필요: 개발자 피드백
필요: 연구
필요: 작업 목록
요구 사항: 테스트
요구 사항: 사용자 피드백
필요: 검증/복제
필요: 투표

이것들은 주로 나에게 티켓 상태이므로 지금은 거기에 보관하는 것이 좋습니다. 길이가 문제인 경우 일부를 축약할 수 있습니다("상태: Dev FB 필요", "상태: 확인/복제 필요").

"작업 목록 필요"는 갈 수 있다고 생각합니다. 나는 그것이 레이블을 보증하기에 충분하다고 생각하지 않습니다. 사용해 본 적이 있는지 잘 모르겠습니다. 사용하는 경우는 거의 없습니다. "테스트 필요"도 마찬가지일 것입니다. 나머지는 모두 "상태: *"에서 저에게 완벽하게 맞습니다.

또한 목록이 나에게 멋지게 형성되고 있으므로 색 구성표에 대해 논의해야 할 것입니다.

"작업 목록 필요"와 함께 상태에서 다듬을 수 있는 몇 가지 더:

• ~"Pulled for Review"는 아마도 "Ready for Review"의 의도하지 않은 복제일 것입니다~ 나가기
• "Unit Tested"는 상태(적어도 아직 아님)가 아니라 더 다양한... 그래서 아마도 키워드로 옮겨졌을까요?

그것은 나에게 좋은 상태 목록을 남겨줍니다.

"Pulled for Review"는 "Ready for Review"의 의도하지 않은 중복일 수 있습니다.

동의하지 않는다. PR을 만들고 준비가 되면 검토 준비를 추가합니다. 그러나 나중에 검토할 시간이 없을 수도 있습니다. 하지만 그때까지 Scott은 검토를 시작했는지 여부를 확신하지 못합니다. 간단히 말해서 Ready for Review와 Pull for Review를 추가하는 두 그룹의 사람들입니다.

"테스트 필요"도 마찬가지일 것입니다.

더 많은 코드 적용 범위를 원하기 위해(아직 개인적으로 이 영역을 많이 조사하지는 않았지만) 이 레이블은 "수정 사항은 훌륭하지만 단위 테스트가 가장자리를 덮는 것을 보고 싶습니다. 회귀가 도입되지 않도록 특정 버그 수정".

'초점'도 키워드에서 우선순위로 옮겨야 한다고 생각합니다.

우선 순위는 일반적으로 낮음, 중간, 높음, 중요, 차단이며 초점에 대해 다른 의미를 갖습니다(적어도 내 생각에는). Keyword: Focus 레이블은 문제가 _for_에 중점을 둔 릴리스를 말하는 이정표가 없는 한 그 자체로는 관련이 없습니다. 우선 순위는 컨텍스트가 없지만 프로젝트 전체에 적용되는 만큼 다른 우선 순위를 추가하는 것이 반드시 좋은 생각은 아니지만 마찬가지로 Focus가 우선 순위라고 생각하지 않습니다. 아마도 우리가 말하려고 하는 것은 "이 티켓은 마일스톤 하이라이트입니다.

차단기는 요구 사항이 처리될 때까지 작업할 수 없음을 나타냅니다.

나는 여기서 Phil의 말에 동의합니다. 이 레이블이 있는 문제가 _release_를 차단한다는 의미로 이해했습니다. Jim의 설명은 Status: Is Blocked 레이블 또는 이와 유사한 레이블에 더 적합할 수 있지만 Needs: * 는 동일하게 표시됩니다.

BTW, 여기에서 임시 목록을 삭제해도 될까요? #5016 (comment) ?

@pglewis 계속 해서 원하는 것을 제거(또는 역사적 참조를 위해 <details>...</details> 에 숨김)하십시오.

support.pods.io 및 docs.pods.io는 여기에 있으면 안 됩니다.

기존 "문서 개선" 태그(대 문서: 인라인)에 대한 불확실성으로 인해 추가한 것입니다. 다른 곳에서 처리되는 경우 제거할 수 있습니다.

문서 개선은 '문서: 인라인' '문서: 예제' '문서: 도구 설명' 등으로 작성하는 것이 좋습니다. GitHub에서 Documentation(즉, docs.pods.io 웹사이트에 문서로 작성된 문서) 워크플로를 처리하지 않는 한 여기에는 이유가 없습니다. 코드 내부의 문서 개선은 우리 코드 내에서 관리되거나 구문 분석되어 WordPress.org 플러그인 리포지토리에 푸시되는 readme와 같은 문서를 의미합니다.

매우 유익한 Status: Is Blocked 가 마음에 들지만, 그런 성격의 일을 하려면 필요 사항도 필요합니다.*

내가 말했듯이 모든 것이 Type 및 Status 얻습니다. GitHub로 전체 Agile 프로젝트 관리를 수행할 때까지는 우선 순위를 정의할 필요가 없으며 실제로 '스토리'를 완료하는 데 필요한 작업 단위로 더 잘 표현됩니다. 우리는 항상 Focus를 사용하여 다음 유지 관리 릴리스에서 집중해야 하는 100가지 문제의 항목을 차별화했습니다.

내 유일한 생각은 UI/CSS 레이블에 관한 것인데, 가장 많이 다루는 레이블입니다. CSS를 구성 요소로 제거하고 UI에만 의존하는 것이 가장 합리적입니다. 거기에 생각이 있는지 확실하지 않지만 CSS는 수정해야 할 유형의 것이 아니라 결과입니다. UI는 작업하거나 개선해야 할 유형의 것이 될 것이고 CSS는 결과 또는 고정 방식이 될 것입니다. 그렇지 않으면 나는 그것을 좋아합니다 👍

내 유일한 생각은 UI/CSS 레이블에 관한 것인데, 가장 많이 다루는 레이블입니다. CSS를 구성 요소로 제거하고 UI에만 의존하는 것이 가장 합리적입니다. 거기에 생각이 있는지 확실하지 않지만 CSS는 수정해야 할 유형의 것이 아니라 결과입니다. UI는 작업하거나 개선해야 할 유형의 것이 될 것이고 CSS는 결과 또는 고정 방식이 될 것입니다.

예, 거기에서 해야 할 개선 사항이 있습니다. 나는 주로 CSS 레이블을 당신 및/또는 Jory가 필터링할 Bat-signal로 사용했는데, 당신이 그 방향으로 가는 사람들이었기 때문입니다.

나는 지금 제안된 대로 CSS와 UI를 남겨두는 것에 투표하고 싶지만 우리는 확실히 1단계 이후에도 계속해서 개선할 수 있습니다.

RE: 테스트 필요

더 많은 코드 적용 범위를 원하기 위해(아직 개인적으로 이 영역을 많이 조사하지는 않았지만) 이 레이블은 "수정 사항은 훌륭하지만 단위 테스트가 가장자리를 덮는 것을 보고 싶습니다. 회귀가 도입되지 않도록 특정 버그 수정".

현실은 우리가 유지 보수 수정을 계속해야 하고, 릴리스 브랜치에서 작업해야 하며, 새로운 테스트를 작성하는 장벽은 간단한 것에도 다소 높습니다. 레이블을 그대로 둘 수는 있지만 훨씬 더 많은 리팩토링이 완료되고 실제 단위 테스트를 도입하거나 더 많은 리소스를 사용할 수 있을 때까지는 많이 사용되지 않을 것입니다.

"유형: 테스트"는 현재 추가된 테스트가 자체 문제/PR 쌍으로 가장 적합하기 때문에 좋은 추가 사항이 될 것입니다.

나는 Status: Is Blocked가 매우 유익한 정보라는 점을 좋아하지만, 그러한 성격의 일을 하는 경우 Needs:*도 필요합니다.

나는 그것을 떠나는 것이 좋지만 주로 상태를 추적하는 사람이며 상태로 "차단됨"을 표시할 필요가 없었습니다. 내가 만나는 방향이 애매모호한 것은 모두 "Holding"으로 더 잘 커버됩니다.

그리고 명확하게 하는 데 도움이 되는 경우 평균 버그에 사용하는 일반적인 워크플로입니다.

• 분류: 무효, 지원, 기능/향상을 필터링합니다. 유형을 버그로 설정
• 일반적으로 상태는 즉시 "확인/재검증 필요"로 변경됩니다.
• 수명 기간 동안 "사용자 피드백 필요"와 "개발자 피드백 필요" 사이를 왔다갔다 할 수 있습니다.
• 검증/복제
• 연구 필요: 이제 우리는 그것을 실현하는 방법을 알았으므로 그 이유를 찾고 이해합니다.
• 조사 대상: 저만 이것을 사용하는 것 같습니다. 어느 시점에서 심층 다이빙이 완료되었다는 신호이며 아마도 내 머리에 내부 세부 정보가 저장되어 있을 것입니다.
• 고정/테스트 필요

동의하지 않는다. PR을 만들고 준비가 되면 검토 준비를 추가합니다. 그러나 나중에 검토할 시간이 없을 수도 있습니다. 하지만 그때까지 Scott은 검토를 시작했는지 여부를 확신하지 못합니다. 간단히 말해서 Ready for Review와 Pull for Review를 추가하는 두 그룹의 사람들입니다.

이러한 경우에는 보류 레이블이 검토를 위해 끌어오기보다 역사적으로 더 낫다고 생각합니다.

참고로 과거에는 릴리스를 차단하는 문제를 표시하기 위해 차단기를 사용했습니다.

우리는 '패치'를 제거할 수 있습니다. 저는 GitHub가 PR과 이슈 사이에 더 혼란스러운 UX를 가지고 있을 때 그것을 사용하기 시작했습니다. 주로 변경 로그 항목에 대한 내용을 되돌리기 위해 패치가 있는 '릴리스' 보기를 보는 것이 더 쉬웠습니다. 우리는 그것을 필요로하지 않습니다.

원래 문제 설명의 목록이 우리 모두가 논의한 변경 사항과 함께 최신 상태입니까?

원래 문제 설명의 목록이 우리 모두가 논의한 변경 사항과 함께 최신 상태입니까?

아마도 완전히는 아닐 수 있습니다. 원하는 경우 자유롭게 수정하십시오. 일단 엄지손가락을 치켜들고 업데이트되지 않은 것으로 결정한 모든 항목을 검토하겠습니다.

여기서 무엇을 결정하든 https://github.com/dwyl/labels 와 같은 도구를 사용하여 다른 모든 Pod 저장소에 적용하여 동기화해야 합니다.

유형에서 키워드로 "회귀" 이동. 버그는 여전히 회귀 문제의 유형입니다.

이것은 이제 거의 구현되었습니다. 지금은 "키워드"에 갇힌 몇 가지 기타 사항.

이 시점에서 가장 중요한 것은 색상입니다.

?닫힘: 무효

나는 적어도 이것을 유지하는 것이 좋습니다. 아마도 수정하지 않을 수도 있습니다. 다른 버그 추적기에서는 상당히 표준적인 해상도입니다.

이 시점에서 가장 중요한 것은 색상입니다.

이 시점에서 색상은 부차적입니다. 레이블을 구현하고 나중에 색상 구성표를 결정합니다.

나는 적어도 이것을 [무효]로 유지하는 것이 좋습니다. 아마도 수정되지 않을 것입니다. 다른 버그 추적기에서는 상당히 표준적인 해상도입니다.

Invalid를 추가하겠습니다. 아직 알림이 없기 때문에 미리 알림으로 표시했습니다.

"Won't Fix"는 내가 그냥 싫어하는 톤 중 하나입니다. 또한 내 태도는 "수정하지 않을 것"보다 수정하지 않는 더 구체적인 이유가 있는 레이블이 있어야 한다는 것입니다.

이 시점에서 색상은 부차적입니다. 레이블을 구현하고 나중에 색상 구성표를 결정합니다.

레이블은 거의 구현되어 있습니다.

"유형: 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 세계에서는 대부분의 수정되지 않는 티켓이 다른 문제로 덮여 있거나 수정을 정당화하기 위해 더 많은 정보가 필요하거나 아무도 불평하지 않기를 바라고 있습니다(종종 경우). .

나는 나의 싫은 것을 고수할 것이다. "Won't Fix"에 대한 나의 즉각적인 질문은 "왜 우리가 무언가를 고치기를 거부합니까?"입니다. 그리고 누군가 티켓에서 이에 대한 간결한 답변을 해준다면 'Won't Fix'가 아닌 레이블이 읽어야 할 _that_이라고 말하고 싶습니다.

어쨌든 Out of Scope 가 더 나은 대답이라고 생각합니다. 수정하지 않음은 문제를 여는 사람에게 '아무것도'를 암시하고 제공하지 않습니다.

방향으로 갈 수도 있습니다. "해결책"을 자유롭게 제출할 수 있지만 팀에는 이를 수행할 수 있는 충분한 리소스가 없습니다.

사용 사례는 일부 기능의 버그 또는 CS 위반일 수 있으며, 이는 어쨌든 다음 버전에서 다시 작성되고 릴리스됩니다.

그래도 자유롭게 남겨주세요.