Partkeepr: 메타: 너무 많은 미해결 문제

그래서 기본적으로 우리는 사실상의 "백로그"를 생성합니다...
@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 : 코드 자체가 아닌 repo, wiki, 프로그래밍 표준 등과 관련된 문제에 사용
• 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시 정도에 1시간을 투자할 수 있다고 생각합니다...저는 같은 사이트의 영어 버전을 사용합니다. 's in Perth - 우리는 다른 사람이 보고 의견을 줄 수 있도록 일종의 태그로 복잡한 문제에 플래그를 지정하고 싶을 것입니다.

@dromer 새 태그 목록을 제공하면 추가할 수 있습니까?

아, 이게 내가 해야 할 일인가?

알려주시면 더 추가하도록 하겠습니다.

@christianlupus 현재 bug 태그로 오래된 문제를 해결하고 있습니다. 제 시간에는 오전 8시 또는 9시 정도에 1시간을 투자할 수 있다고 생각합니다...저는 같은 사이트의 영어 버전을 사용합니다. 퍼스에 있어요 -

좋아, 이것은 전적으로 당신에게 달려 있습니다. 도와주셔서 감사합니다. 지금은 레이블이 지정되지 않은 문제에 대해 작업 중이므로 충돌하지 않습니다.

우리는 다른 사람이 보고 의견을 줄 수 있도록 일종의 태그로 복잡한 문제에 플래그를 지정하고 싶을 것입니다.

예, 좋은 생각입니다. complex-triage 어떻습니까?

아, 이게 내가 해야 할 일인가?

알려주시면 더 추가하도록 하겠습니다.

문제에는 레이블과 이정표만 첨부할 수 있습니다. 그러나 유효한 레이블 목록에 새 레이블을 추가할 수 없습니다. 예, 관련 레이블을 추가하도록 요청합니다.

@baradhili 따라서 새로운 레이블 목록이 없습니다(수정해 주세요).

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

시의적절한 레이블( backlog , roadmap , next-release )에 대해 이것은 이정표에 따라 잡는 것이 더 낫다고 생각하지 않습니까? 또한 이것은 repo에 코드를 제공하는 사람과 조정해야 합니다.

새 레이블에 대한 요구 사항이 표시되는 즉시 이 의견을 업데이트하겠습니다. 알았어? 그렇다면 dromer에게 자유롭게 문의하십시오.

@드로머
다음 라벨을 설정할 수 있습니까?

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

감사 해요

@baradhili MD 파일에 레이블을 조금 정리하려고 했습니다. 파일을 편집할 수 있도록 협력자로 추가했습니다.

내가 쓴 정의는 괜찮습니까?

문제 없다!선적 서류 비치!

2020년 1월 14일 화요일 19:36에 Christian [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=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVEXG43VMVBW63
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

--
브렛 왓슨
감독
IT 중간 관리 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 도메인으로 이메일을 보냈습니다. 계정을 확인해 주시겠습니까?

우리는 어떤 개발자가 있습니까?
어 ... 그렇게 했다면 이 백로그가 없었을 것입니다 :)

저는 여러분이 현재 '허용'하는 프로젝트보다 조금 더 빠르게 움직이고 있다고 생각합니다. 이는 백로그를 구성하는 것이 일을 방해하기 때문에 좋은 일이므로 우선순위 지정이 기여하고자 하는 사람들에게 초점을 맞추는 데 도움이 되기를 바랍니다. (그들을 찾거나 우리를 찾도록 하는 것은 물론 다른 도전입니다)

좋아.. 이제 모든 문제가 이정표에 할당되고 상당히 많이 닫힌 문제 목록이 있습니다.
저는 지금 우리의 초점이 누군가를 개발하게 하는 것이라고 생각합니다 :) 슬프게도 저는 ExtJS와 Symfony에 대한 NFI가 있어서 도울 수 없습니다...

옵션

1. 우리는 스폰서를 얻고 guru.com 또는 stackexchange에서 프리랜서를 사용합니다.
2. 우리는 스스로를 찾으려고 노력합니다.
3. ?

또한, 접촉하지 않고 열심히 작업을 제거하여 누군가의 치아를 발로 차지 않도록 해야 합니다. 이것은 내 인쇄 기능에 발생했으며 그 이후로 나는 여기서 무슨 일이 일어나고 있는지 옆에서 지켜보고 있었습니다. 나는 또한 그러한 기능이 다시 추가되지 않았기 때문에 최신 버전에서 쓸모없는 소프트웨어를 고수했습니다.

그러한 일을 처리하는 방법과 아키텍처 결정 또는 어떤 일을 하는 좋은 방법이 무엇인지에 대한 명확한 구조가 있어야 합니다. 프로젝트 자체는 구조가 명확하며 PHP 전문가가 아닌 사람(다른 언어의 프로그래밍 전문가)도 사용되는 프레임워크 및 구조의 도움으로 쉽게 구현할 수 있습니다.

@Boldie Hi Sven, 귀하의 작업이 예고 없이 삭제된 경우 사과드립니다. 최근에 프로젝트에서 많은 것이 변경되었으며 우리는 커뮤니티 - 특히 개발자 _의 신뢰를 구축하는 데 매우 열심입니다.

BTW - 귀하의 인쇄 기능이 대량 인쇄를 수행한다고 가정하고 있습니까? 다시 작동하려면 무엇이 필요할까요?

그러한 일을 처리하는 방법과 아키텍처 결정 또는 어떤 일을 하는 좋은 방법이 무엇인지에 대한 명확한 구조가 있어야 합니다.

대부분 맞는 말이지만 프로젝트가 대부분 1인 프로젝트로 관리되었기 때문입니다. 커뮤니티 와 상호 작용하기 위해 규칙을 정의할 필요가 없었습니다. 프로젝트의 무게를 여러 사람에게 공유하기 시작하면서 진행 방법에 대한 규칙을 정의하는 것이 도움이 될 수 있습니다.

프로젝트 자체는 구조가 명확하며 PHP 전문가가 아닌 사람(다른 언어의 프로그래밍 전문가)도 사용되는 프레임워크 및 구조의 도움으로 쉽게 구현할 수 있습니다.

나는 당신이 프로그래머 자신이 권위를 가지고 그러한 진술을 할 수 있다고 가정합니다. 누군가의 기분을 상하게 하려는 것은 아니지만 그 동안에는 코드 개발에 발을 담그는 것이 더 어렵다고 생각합니다.

해봤는데 어렵네요. 라이브러리는 지옥처럼 구식이며 그 동안 이러한 오래된 코드에 대한 문서는 드뭅니다. 또한 프로젝트 문서(예: #635)가 완전하지 않습니다.
여기에서 왕따를 하는 것이 아니라 현재 소프트웨어의 몇 가지 중요한 문제를 지적하고 싶습니다. 원래 개발자는 그 당시에는 대부분 연락할 수 없었기 때문에 코드의 최소한 일부를 알고 있는 사람이 작업을 다시 정상 궤도에 올려야 합니다. "오래된 기여자"가 여기에서 도움을 줄 수 있기를 바랍니다. 제거해야 할 몇 가지 버그가 있지만 주요 문제는 소프트웨어가 종속성과 관련하여 더 이상 유지 관리 및 유지 관리할 수 없다는 것입니다. 주요 문제를 해결해야 합니다. 그렇지 않으면 프로젝트가 실패합니다.

그래서 나는 당신에게 묻습니다. 당신은 코드 작업을 했고 관련 의존성에 대한 경험이 있습니까?

BTW - 귀하의 인쇄 기능이 대량 인쇄를 수행한다고 가정하고 있습니까? 다시 작동하려면 무엇이 필요할까요?

@Boldie , 누락된 기능을 추적하기 위해 새 문제를 여는 것이 좋습니다. 어느 시점에서 이 문제는 여기에 보관될 것입니다. 결과적으로 인쇄 기능을 다시 작동시키려는 귀하의 요청은 대부분의 사람들에게 잊혀질 것입니다.

BTW - 귀하의 인쇄 기능이 대량 인쇄를 수행한다고 가정하고 있습니까? 다시 작동하려면 무엇이 필요할까요?
2개 부분으로 구성되어 있습니다.

• StorageLocations / 부품을 pdf로 대량 인쇄
• 단일 부품 인쇄(라벨용)

첫 번째는 고도로 통합되었지만 일부 문제가 있는 종속성을 추가합니다. 두 번째 것은 오늘 REST API를 사용하여 더 잘 구현될 수 있습니다. 이 200개의 공개 문제 중 하나에서 여전히 추적되고 있습니다. :)

방금 코드를 살펴보았습니다. 이 항목이 실제로 어떻게 작동하는지에 대한 몇 가지 문제가 있습니다. 프레임워크는 따르기 힘든 일종의 느슨한 결합을 사용하는 것 같습니다. 아마도 이 프레임워크를 사용하는 전문가는 다른 말을 할 것입니다. (저는 대부분 C++를 사용하고 때로는 django를 사용하는 python을 사용합니다). 나는 이것이 내가 첫 번째 구현을 할 때 몇 가지 항목을 추가하는 방법을 알아내는 것도 어려웠다는 것을 기억했습니다. 내가 보기에 문제는 이 프로젝트를 어느 정도 원맨쇼에서 커뮤니티 주도 프로젝트로 이끄는 것입니다. 불행히도 나는 의존성 문제를 도와줄 사람이 잘못되었지만 기술 부서를 줄이려면 이것이 가장 먼저 해결해야 한다는 데 동의합니다.

개발을 쉽게 하기 위해 두 번 작업하지 않고도 쉽게 개발을 시작할 수 있는 환경을 설정하는 것이 좋습니다. 우리 회사에서는 개발을 쉽게 시작할 수 있도록 테스트를 실행하고 데모 데이터를 추가하는 스크립트와 함께 도커 컨테이너를 설정했습니다.

커뮤니티에 연락할 수 있는 방법이 있습니까? 나는 대부분의 사용자가 여기에 도움이 필요하다는 사실을 모르고 있다고 생각합니다. 그렇지 않으면 프로젝트가 점점 더 오래되고 언젠가는 더 이상 사용할 수 없게 될 것입니다. 홈페이지에 성명을 올릴 수 있습니까? 대부분의 다운로드가 있기 때문에 적절한 지식을 가진 사람들은 상황과이 저장소를 여기에서 알지 못합니다.

@Boldie 좋은 생각! @dromer @Drachenkaetzchen 누군가가 기본 웹 페이지에 액세스할 수 있습니까?

@christianlupus 다음에 수행해야 하는 작업 목록이 여기 또는 이정표 보기에 있습니까? 첫 번째 작업 중 하나는 Symhony4 #1083으로 업그레이드하는 것입니다.

@Boldie 예, 우선 순위 문제에 대한 작업이 완료되었습니다. 이 목록을 참조하십시오:

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

symfony 및 기타 종속성을 업그레이드하는 것은 현재로서는 가장 크고 중요한 것입니다.
('좋은 첫 번째 이슈' 태그는 '먼저 완료해야 할 사항' 지정이 아니라 신규 이민자를 위한 것이라고 생각합니다.)

커뮤니티에 연락할 수 있는 방법이 있습니까?
우리는 irc.freenode.net의 #partkeepr irc 채널에 많은 사용자와 함께 있습니다.
Google 그룹(공개 및 비공개)도 있지만 현재로서는 문제 추적기 + IRC가 (활동 측면에서) PartKeepr에 대해 사람들과 이야기하는 가장 좋은 방법이라고 생각합니다.

또한, 접촉하지 않고 열심히 작업을 제거하여 누군가의 치아를 발로 차지 않도록 해야 합니다. 이것은 내 인쇄 기능에 발생했으며 그 이후로 나는 여기서 무슨 일이 일어나고 있는지 옆에서 지켜보고 있었습니다. 나는 또한 그러한 기능이 다시 추가되지 않았기 때문에 최신 버전에서 쓸모없는 소프트웨어를 고수했습니다.

기능을 제거해야 하는 이유는 여기에 문서화되어 있습니다. https://github.com/partkeepr/PartKeepr/issues/622

이빨로 발로 찬 느낌이 든다면 죄송합니다. 하지만 당시에는 그랬습니다.

또한, 나는 매일 이 소프트웨어를 작성하는 데 대부분의 시간을 보냅니다. 새 버전을 만들기 위해 코드를 제거해야 한다면 빌어먹을 정도로 이해해주세요. 새 버전과 호환되도록 다른 PR을 만들 수도 있습니다.

네, 지금 화가 났어요. 나는 무료로 코드를 작성하는 데 수년을 보냈고, 대부분의 작업을 수행했으며, 많은 지원 작업을 수행했으며, 사업을 하려고 노력했으며, 수천 시간은 아니더라도 수백 시간의 무급 작업에 대해 얻을 수 있는 것은 그것뿐입니다.

내 책임감이 아니었다면 나는 2년 전에 웹사이트와 다른 모든 것을 폐쇄했을 것입니다.

나는 이 시간에 한 달을 버틸 수 있을 만큼 충분한 돈이 없고, 곧 회복될 것 같지 않은 몇 가지 질병을 앓고 있으며, 나는 거의 그렇게 할 수 없음에도 불구하고 여전히 어떻게든 이 프로젝트를 유지하려고 노력합니다.

또한, 나는 매일 이 소프트웨어를 작성하는 데 대부분의 시간을 보냅니다. 새 버전을 만들기 위해 코드를 제거해야 한다면 빌어먹을 정도로 이해해주세요. 새 버전과 호환되도록 다른 PR을 만들 수도 있습니다.

네, 지금 화가 났어요. 나는 무료로 코드를 작성하는 데 수년을 보냈고, 대부분의 작업을 수행했으며, 많은 지원 작업을 수행했으며, 사업을 하려고 노력했으며, 수천 시간은 아니더라도 수백 시간의 무급 작업에 대해 얻을 수 있는 것은 그것뿐입니다.

내 책임감이 아니었다면 나는 2년 전에 웹사이트와 다른 모든 것을 폐쇄했을 것입니다.

나는 이 시간에 한 달을 버틸 수 있을 만큼 충분한 돈이 없고, 곧 회복될 것 같지 않은 몇 가지 질병을 앓고 있으며, 나는 거의 그렇게 할 수 없음에도 불구하고 여전히 어떻게든 이 프로젝트를 유지하려고 노력합니다.

귀하가 심각한 상황에 처해 있다는 것을 알고 있으며 커뮤니티를 포함한 이 프로젝트가 귀하의 상황에 기여하고 있습니다. 나는 또한 당신의 작업을 존중하며 이 프로젝트(특히 다른 프로젝트와 비교하여)가 잘 수행된 구조를 가지고 있다고 생각합니다. 필요한 작업.
나는 지금 과거를 따뜻하게 하고 싶지 않습니다. 그것은 우리가 Partkeepr로 더 나아가는 데 도움이 되지 않을 것입니다.

내 일상 업무에서 특히 그 사람과 연결할 수 없는 경우 다른 사람의 코드를 처리하는 것이 때때로 어렵다는 것을 알고 있습니다(나중에 필요한 경우 모든 사람이 git 커밋의 이메일 주소로 저에게 연락하거나 도메인을 사용하여 연락할 수 있습니다. 내 홈페이지를 사용하여 저에게 연락하십시오). 코딩을 할 때 모든 사람은 자신의 손글씨를 가지고 있습니다. 제 생각에는 코드를 작성하는 일종의 장인 정신입니다. 나는 또한 복잡성에 대한 많은 경험이 있으며 라이브러리나 여러 종속성을 업그레이드할 경우 이를 통과하는 것이 얼마나 어려운지 알고 있습니다. 나는 내 유급 일에서 몇 달 동안 팀과 함께 이것을했습니다.
그래서 이제 우리는 다시 이 도전에 직면했고 우리는 커뮤니티와 함께 ​​이것을 할 수 있는 방법을 생각해야 합니다. 다음과 같이 말하는 유료 환경에서와 같이 훨씬 더 어렵습니다. 우리는 할 것입니다.

나는 코드를 살펴보았고 지난번에 무언가를 했기 때문에 많이 바뀌었습니다(누군가 여기에 많은 작업을 투자했습니다!!:). 그래서 코드를 다시 파헤쳐서 작업을 시작해야 했습니다. 그러나 이를 위해서는 긴밀한 커뮤니케이션과 다음에 해야 할 일에 대한 로드맵이 필요합니다. 인쇄 기능을 다시 가져오는 것은 다른 작업에 비해 우선 순위가 매우 낮고 나 또는 다른 누군가가 나중에 할 수 있다고 생각합니다. 나에게는 미래에 다음 OS 업그레이드로 내 데이터를 잃지 않는 것이 더 가치가 있습니다. 이것은 다른 것으로 마이그레이션하는 데 많은 작업을 의미하기 때문입니다(이것이 무엇인지 모릅니다), 오랜 작업이 필요했습니다 내 여가 시간에 데이터베이스를 채우십시오.

@Boldie 감사

@christianlupus @dromer 상황이 다시 움직이기 때문에 이제 닫을 수

한 가지 더 논의할 사항: #1091의 변경으로 인해 모든 새로운 문제에는 일부 태그가 첨부됩니다. 여기에서 인적 검토가 이루어지지 않았다는 지표를 원하십니까?

이것과 별개로 저는 지금 이 문제를 닫아도 괜찮습니다.

우리가 한 일은 사람의 검토와 어떻게 다릅니까? :)

@baradhili 이것이 바로 우리가 최근에 한 일입니다. 내 말은 다음과 같습니다. 명명된 PR이 수락되었으므로 모든 새 문제에는 선택한 문제 유형에 따라 버그, 기능 요청 또는 도움이 필요한 사전 설정이 레이블로 지정됩니다.
즉, 최근에 수행한 수동 분류를 통과하지 않은 새 문제는 레이블이 부착되지 않은 것으로 표시되지 않습니다. 따라서 GitHub에는 아직 사람이 분류하지 않은 문제를 선택하는 간단한 필터가 없습니다.

간단히 말해서 need-triage 또는 이와 유사한 것을 나타내기를 원하십니까?

github의 템플릿 시스템 아래에 needs-triage 레이블을 자동으로 추가할 수 있나요?

네, 라벨을 추가하고 템플릿 파일에서 한 줄만 변경하면 됩니다. 그것으로 충분합니다.

문제 템플릿 시스템과 관련하여 방금 #1097을 열었습니다. needs-triage 레이블이 필요하지 않은 경우 단일 커밋을 제거하는 것이 좋습니다.

지금 닫는다