Giithub의 Project(Beta)를 열심히 사용했습니다(+생각해 보았습니다)

먼저
특정 달력에 쓰시길 원해서 제안과 상담을 모집 중입니다.
저는 개인적으로 상당히 좋은 기술 노하우를 얻었다고 생각합니다. 만약에 기사나 실제 운용 중인 프로젝트를 보실 수 있고 좋으시다면 꼭 알려주세요.
결론

Giithub로 끝난다는 뜻이라면 매우 편리하다

기존의 관리 도구를 대체할 수 있을지 의문

비즈니스에서 사용하지 않아야 함(베타 버전이기 때문에 공식적으로 발표하지 못할 위험도 있고 이 기사를 직접 사용하지 못할 가능성도 있음)

Giithub Project(Beta)란 무엇입니까?
베타 기능은 차치하고 지허브 프로젝트를 사용하는 사람이 독자의 대상이기 때문에 지허브 프로젝트 기능을 모르는 사람이 먼저 사용해 보자.
개인 개발자용
대부분의 사람들이 아이슈 쓰기, PR 등 원래의 기트 사용법을 잘 사용하지 않는다고 생각한다.나도 그래.
하지만 최근 지이허브 계정에 구직·이직하는 사람(또는 대리)도 많기 때문에 자신의 지이허브 계정을 충실하게 채우는 게 좋다.
Qita에 어떤 기사를 쓰는지, 어느 계층부터 반응을 보이는지, 그러면 면접관으로서도 괜찮은데 거기까지 어떤 일이 있었는지, 이렇게 (내가 면접관이라면) 흥미를 끌 수 있기 때문에 Qita가 평가를 하기 전에Giithub을 사용하여 자신의 기술을 실천적으로 보여주는 것을 잊지 마세요!1
기존 Project 기능과 비교
다음은 사용하고 있는 사람을 향한 이야기다.
한마디로
기존의 프로젝트 기능은 각자의 창고에서 쉽게 사용할 수 있다는 인상은 아무리 해도 지워지지 않았지만, 이번 베타 버전의 대응으로 창고 간 프로젝트 관리가 쉬워져 좋은 인상을 남겼다.
잘 비교하다

창고가 아니라 사용자와 연관된 프로젝트이기 때문에 "그 프로젝트는 어느 창고입니까?"이런 상황에 빠지지 않겠습니다.

기존 프로젝트도 직접 사용 가능

기존 항목은 보드 형식(보드)만 표시할 수 있지만 표에서 일람하면 한꺼번에 더 많은 정보를 볼 수 있다

[동아시아]는 검색 기능과 필터 기능을 강화하였으며, 상태(열)와 자유자 외에도 Asain 정렬에 대응하였다.

열의 자동 설정은Preseet을 통해 설정할 수 있는 내용으로 제한되지만 제한 없이 자유롭게 사용할 수 있음

자유도가 매우 높은 인상을 주다.
쓰다
먼저 아래와 같이 열거한다.

구상은 다음과 같다.
열 이름
Issue의 Open/Close(PR에서는 사용하지 않음)
투입 조건
자동 또는 수동
열 볼 사람.
필요한 일
[Issue/PR] 토론/분배 중
Open
Issue/PR 시작 시2
자동
Issue: 장작 마스터 3/PR: 개표인
프로펠러 소유자는 Issue가 작업인지 오류인지 보류인지 판단하고 분배한다
[Issue] 작업: 우선 순위 중/[Issue] 버그: 우선 순위가 높음
Open
에스슈가 미션인지 버그인지 우선도 등을 고려해 분배4
수동
개발팀(개발자)
개발 및 홍보
[PR] 검토 요청
-
PR을 개발하여 발송하고'토론/분배 중'인 PR을 이동할 때2
수동2
관찰자(발견자)
코멘트
[PR] 반품
-
시청자가 Request change를 보낼 때
자동
방문자
수정 후 수동으로 검사 요청으로 돌아가기
[PR] 댓글 오케이.
-
시청자가 앱러브를 보낼 때.
자동
샌드 마스터
쉬다
[Issue] 완료
Close
Issue 종료 시5
자동
제품 소유자
스탠드에 보고 가능
[Issue] 보존: 낮은 우선 순위
Close
대응 인원 이동 시
수동
제품 소유자
필요한 경우 토론으로 돌아가기
[Issue] 지원되지 않음
Close
대응 인원 이동 시
수동
제품 소유자
왜 대응하지 않는지 묻다
[Issue] 검색용/Project
Close
(후술)
수동
누구든지
거의 안 건드려요.
※ 이곳은 간단한 설명을 위해 테스트를 고려하지 않았습니다.(후술)
검색 열(상태)
프로젝트 화면에서 보이는 검색이 아니라 창고에서 보이는 검색입니다.
원래 창고로 이슈트리를 만들려면 창고에서 프로젝트를 만들어 개별 관리해야 하는데 사용자 프로젝트와 창고 프로젝트가 완전히 독립돼 관리가 번거롭다.
이에 따라'프로젝트 화면에서 봤을 때는 아무런 의미가 없지만 필요한 이슈'를 명확히 하기 위해 검색란(무의미한 상태)을 추가했다.
그러므로
- 프로젝트 화면에서 관련 Issue를 검색하려면: 검색 열을 보거나 검색 기능을 사용합니다.
- 창고 Issue 화면에서 관련 Issue를 검색하려면: Project 화면으로 이동↑
이런 조치를 취하다.
(단, 무의미한 이슈가 하나 더 있어 어느 정도 인정이 필요하다.
→ 해결책으로 검색을 위해 만든 이슈는 금방 클로즈가 되는데, 안 보이면 귀찮아서 박는 게 좋을 것 같아요.
예: is:open 을 표시했지만 닫힌 이슈가 눈에 띄었다

테스트를 고려하는 Project를 설계할 때
나도 여러 가지 일을 해 보았는데 아마도 개발과 다른 프로젝트를 세우고 각자의 Issue/PR을 분배하는 것이 좋을 것이다.
기존 프로젝트에 테스트용 열을 추가해 활용하는 방법도 있지만, 개발 완료와 테스트 실시(테스트 NG라고 해도)는 처리 방식이 다르다.
따라서 클로즈가 진행되는 PR 리오픈을 개발함으로써 테스트 근거를 나타내는 아이슈를 링크하면 이해하기 쉽다고 본다.
이 점은 팀 내에서 실제로 운용하고 나서야 말한 것으로 생각하지만, 현재 운용하고 있는 관리 도구를 버리고 Giithub Project를 사용하는 장점이 있는지 모르겠다.
총평가

Giithub로 끝난다는 뜻이라면 매우 편리하다

기존의 관리 도구를 대체할 수 있을지 의문

비즈니스에서 사용하지 않아야 함(베타 버전이기 때문에 공식적으로 발표하지 못할 위험도 있고 이 기사를 직접 사용하지 못할 가능성도 있음)

소절
프로젝트 화면에서 창고를 검색할 수 있기 때문에 Issue의 제목[リポジトリ名][プロジェクト名]과 같은 검색 문자열을 추가할 필요가 없습니다.
하지만 창고 검색으로 전환하는 데 시간이 좀 걸리기 때문에 번거로운 방법으로 이슈 템플릿에 편입시켜 번거로움을 줄였다.
이슈의 제목을 보기 조금 어렵지만 표 뷰를 사용하면 어느 정도 효과를 볼 수 있어 개의치 않는다.
메모
이번에는 주석이 많다.
[스킬 전시 방법] 여기 면접관의 시각으로 썼어요. 저는 프리랜서예요. 면접이라기보다는'주변에 좋은 엔지니어가 없나요?'너와 상의할 때도 소개하기 쉽다.  ↩
[PR발신시 행동] 현재 상태라면 아이슈를 쓸 때(Open/Reopen)와 PR을 보낼 때(Open/Reopen)를 쓰는 시기가 같기 때문에 수동으로 대응해야 한다.이것도 헤어졌으면 좋겠어요.  ↩
[이슈를 시작할 때 대응하는 사람] 원래 이슈가 타당한지 논의할 필요가 있고 제품 소유자도 봐야 한다.  ↩
[미션 오류 대응] 판넬 등을 볼 때 이 프로젝트에 들어가자마자 바로 일을 시작하고 싶을 때가 있기 때문에 일하기 전에 누가 대응하는지 잘 소통하는 것이 좋다.활용에 익숙해지면 아이슈에게만 결단을 내릴 수 있을 것 같다.  ↩
[이슈를 폐쇄할 때의 행동] 하나의 이슈가 하나의 PR을 통해 해결된다면 이상적이지만 현실적으로 잘 풀리지 않는 경우도 있다.이 경우 대응책으로 이슈를 적고 재생하거나, 여러 PR을 하나의 이슈에 집중하는 방법이 있다.  ↩