Contributing 디렉토리와 Developing 디렉토리 구분 필요성 about community HOT 8 CLOSED

Devloping 폴더의 경우, 실질적으로 코드 개발과 관련된 사항에 대해 안내하고 있는데, 제안하신 Contributing 쪽에 그 부분을 포함하지는 않는 것 같습니다.
제안하신 방안은 Contributing의 개선안이라 생각되며, 그 자체로는 문제 없어보입니다.
다만 Developing은 합치지 말고 코드 개발과 관련하여 따로 작성,발전해 가는 것이 낫지않을까 하네요

from community.

네, 좋습니다!

from community.

GitHub workflow 페이지의 경우, 코드기여 쪽에 들어가야 할 듯 한데, Issue에 들어가는 이유는 무엇 인가요?
Issue로 선정되면, 그 부분에 대한 Branch Fork를 보면 userid가 Directory에 들어가던데, 이때 주인은 누가 되는 건가요?

개발과 기여를 합치는 건 좋은 듯 합니다. 다만 원작자에게 이유를 한번 여쭈어 보는 것 좋을 듯 합니다.

from community.

GitHub workflow 페이지의 경우, 코드기여 쪽에 들어가야 할 듯 한데, Issue에 들어가는 이유는 무엇 인가요?

네, 코드기여쪽으로 들어가는게 맞을 듯 합니다. 그렇게 이슈 본문 수정해두었습니다.

from community.

Issue로 선정되면, 그 부분에 대한 Branch Fork를 보면 userid가 Directory에 들어가던데, 이때 주인은 누가 되는 건가요?

이게 실제로 Issue에서 이걸 기반으로 "개발 혹은 코드기여가 가능" 라고 판단해서 결정되는 프로세스가 뭔지는 정의해야 할 것 같아요.
글구, 일단 branch fork한건.. fork를 한 사람이 owner가 되는거구, 거기에 뭔가를 해서 이걸 PR을 올리고 나면 그 때부터는 정해진 거버넌스 프로세스에 맞추어 "사전에 정해진 리뷰어, Approver"들이 실질적인 심사 및 Merge 권한을 가지게 되는거 아닐까요?

from community.

"이게 실제로 Issue에서 이걸 기반으로 "개발 혹은 코드기여가 가능" 라고 판단해서 결정되는 프로세스가 뭔지는 정의해야 할 것 같아요."

Issue는 누구나 Announce할수 있고, 이 Issue를 승인하는 절차를 만든 후, Issue를 해결할 사람을 모집한 후, 그 중 하나가 Issue owner가 되서 Fork를 진행하면 될 듯 합니다. 좀 열린 자동화된 운영을 위해 Issue를 2가지로 나눠서, 버그Fix의 경우 예를 들어 좋아요 갯수 넘어가면 바로 승인된 후 Owner즉(Fork) 딸 사람이 자발적으로 나타나는 형태로 가는 것도 방법일 듯 합니다. 그외 신규기능은 정례회의에서 결정하구요

from community.

Devloping 폴더의 경우, 실질적으로 코드 개발과 관련된 사항에 대해 안내하고 있는데, 제안하신 Contributing 쪽에 그 부분을 포함하지는 않는 것 같습니다.
제안하신 방안은 Contributing의 개선안이라 생각되며, 그 자체로는 문제 없어보입니다.
다만 Developing은 합치지 말고 코드 개발과 관련하여 따로 작성,발전해 가는 것이 낫지않을까 하네요

그럼, 현재 developing 중에서 아래 정도를 남겨서 초안 문서를 만들면 좋을까요?

• How to Build
• Testing Guide
• Coding Convention

아니면, 초기 developing에 들어갈 토픽이 뭐가 좋을지 의견도 주시면 감사하겠습니다.

개발환경 구축에 대해서는 프로젝트별로 (tacoctl, decapod등) 조금씩 다를 것 같은데, 이건 프로젝트별 문서에 정의하고 링크만 걸어도 될 듯 하네요.

from community.

우선은 developing 은 남겨두고, 그 안에 들어갈 내용에 대해서는 별도 논의채널을 열도록 하겠습니다.
제안된 내용들은 contribution 구조로 가져 가는 것으로 하구요.

from community.