거버넌스¶
핵심 팀의 분주한 벌들은 BeeWare라는 벌집을 움직이게 하기 위해 여러 책임을 맡고 있습니다. 이 프로젝트는 지속적으로 발전 중이므로, 이 페이지는 변경될 수 있습니다.
여기에는 이슈에 대한 대응, 코드 검토 및 및 코드 병합, 새로운 기여자 멘토링, BeeWare 프로젝트 전체의 BeeWare 프로젝트 전반.
코드 결정을 내릴 때 신뢰하는 사람이 있고, 코드 및 조직 결정을 내릴 때 신뢰하는 사람이 있습니다. 코드 및 조직 결정을 내릴 수 있도록 신뢰하는 사람이 있습니다. 전체 조직의 비전을 이끌고, 커뮤니티가 합의에 도달하지 못하면 커뮤니티가 합의에 도달할 수 없는 경우 최종 결정을 내릴 수 있습니다.
팀 내 선후배 관계¶
BeeWare 프로젝트의 다양한 경력 수준은 다음과 같습니다:
벌, 또는 일벌¶
BeeWare 커뮤니티의 모든 구성원. GitHub에서 공개적으로 작업하므로 누구나 코드 변경을 제안하고 자신의 코드가 병합될 수 있습니다. 기여 능력에 대한 유일한 제한은 해당 권한을 가진 팀원이 여러분의 작업을 병합해 주는 것입니다.
양봉가¶
신뢰할 수 있는 기여자로 인정받은 꿀벌입니다. 이 꿀벌들은 일정 기간 동안 BeeWare 프로젝트의 특정 부분과 관련하여 능력을 입증했습니다. 이는 기술적 수준(자바스크립트, 파이썬, 오브젝티브-C 전문성; GTK+, macOS 지식)이거나 다른 수준(커뮤니티 관리, 코드 리뷰)일 수 있습니다. 양봉가들은 또한 자신의 전문성이 인정된 프로젝트에 대한 커밋 권한을 가질 수 있습니다.
고급 양봉 전문가¶
GitHub에서 높은 접근 권한을 가진 양봉가들로서, 프로젝트 전체를 감독하는 추가적인 책임도 부여받습니다. 이들은 아키텍처 결정을 내릴 수 있지만, 궁극적으로는 BDFN에 보고합니다.
지금은 선의의 독재자 (BDFN)¶
평생 선의의 독재자 개념에 대한 해석으로, 프로젝트의 방향성과 결정에 대한 책임은 궁극적으로 BDFN에게 있습니다. "평생" 대신 "현재로서는"이라는 표현을 사용한 것은 핵심 유지보수자의 책임을 개인의 자연수명 전체에 걸쳐 부과하지 않는다는 장고(Django)의 철학을 반영한 것입니다. 오픈소스 외부의 삶도 존재하며, 코드와 삶의 균형 및 전반적인 웰빙은 항상 염두에 두어야 할 매우 중요한 사항입니다.
BeeWare의 BDFN은 러셀 키스-매기입니다.
창립 양봉가¶
언덕 위에 서서 털깎기가 필요한 야크를 처음 발견한 사람. 이 역할은 영원히 변하지 않고 계속되지만, 조직 내에서 본질적으로 추가 권한을 부여하지는 않습니다. 현재 창립 양봉가는 BDFN(최종 결정권자)이기도 하지만, 이는 시간이 지나면서 바뀔 수 있습니다.
지침 (실제 규칙이 아님)¶
커밋 권한을 가진 사람이 한 명 이상인 프로젝트와 마찬가지로 팀이 따라야 할 몇 가지 일반적인 지침이 있습니다:
- 프로젝트를 더 넓은 커뮤니티에 잘 대변해 주십시오
- 모든 BeeWare 프로젝트에 대한 문의와 기여를 존중하는 마음으로 대하십시오.
- 모든 사람이 선의를 가지고 있다고 가정하라, 비록 그들이 말을 잘 선택하지 못했더라도
- 누군가가 무언가를 "잘못된" 방식으로 했다면, 그것은 우리가 그 과정을 제대로 전달하지 못한 탓이라고 가정하라
- 분노나 좌절감을 표현하는 모든 행동은 BeeWare 도구/라이브러리를 사용하려는 진심 어린 마음에서 비롯된 것이라고 가정하십시오.
- BeeWare 커뮤니티 내외를 막론하고, 커뮤니티의 다른 구성원들이 자신의 커뮤니케이션에서 이러한 이상을 반영하도록 권장하십시오.
- 어떤 양봉가도 자신의 코드를 커밋해서는 안 됩니다
- 예외: "무언가가 심각하게 고장 났으며 즉시 수리해야 합니다"
- 예외: BDFN (향후 변경될 수 있음)
- 핵심 팀원이 검토를 위해 제출한 모든 코드는 다른 팀원이 검토해야 합니다.
- 예외: BDFN (향후 변경될 수 있음)
- 모든 코드는 병합되기 전에 지속적 통합 테스트를 통과해야 합니다.
- 예외: 고장난 것으로 알려져 있지만 다른 이유로 커밋해야 하는 코드
- 예외: CI 테스트가 불충분한 저장소의 코드
- 예외: 완벽하지만 하지 않는 것보다 일하고 헌신하는 것이 낫다
- 수락 프로세스는 가능한 한 자동화되어야 합니다
- 이는 테스트, 린팅, 맞춤법 검사, 커버리지 등을 의미합니다.
양봉가가 되기¶
새로운 아피어리스트를 팀에 영입하는 것은 기존 코어 팀의 단독 재량으로 재량에 따라 결정됩니다. 현재 이에 대한 명확한 규칙은 없지만 에 대한 확실한 규칙은 없지만, 일반적으로 누군가가 BeeWare 프로젝트의 BeeWare 프로젝트에 기여한 공로를 입증한 경우 프로젝트에 대한 기여를 입증한 경우 초대됩니다. 또한 특정 도메인에 대한 지식이 있는 사람에게도 적용될 수 있습니다. 특정 도메인에 대한 지식(예: iOS/macOS)이 있는 사람으로 확장될 수도 있습니다. 기존 팀. 또한 커밋을 기반으로 할 필요도 없습니다. 다음과 같은 사람이라면 누구나 프로젝트 전반에 대한 기득권을 증명할 수 있는 사람은 누구나 프로젝트에 커밋할 수 있는 권한을 요청할 수 있습니다.
모든 신규 양봉가는 프로젝트의 핵심 가치와 지침에 대해 '입문 교육'(적절한 표현이 없어)을 받게 됩니다. 핵심 가치 요약은 소개 페이지에서 확인할 수 있습니다. 팀에 합류하는 모든 구성원은 해당 가치를 준수하고, 시간이 지남에 따라 가치 발전에 관한 논의에 기여할 것으로 기대됩니다.
신규 또는 기존 아피어리스트를 막론하고 어떤 아피어리스트라도 단독 관리자가 될 수는 없습니다. 많은 양봉가가 있고, 그 옆에는 도움과 조언, 멘토링을 제공할 수 있는 도움과 조언, 멘토링을 제공할 수 있습니다.
커밋 비트?¶
유닉스 시스템에서 파일의 단일 비트는 파일 실행 권한을 나타내는 데 사용됩니다. 권한을 나타내는 데 사용됩니다. 소스 제어 시스템에서도 비슷한 비트가 존재합니다. 코드 병합 기능을 나타냅니다. 누군가 "커밋 비트"를 가지고 있다고 말하는 것은 가 있다는 것은 코드 베이스에 대한 쓰기 권한이 있다는 뜻입니다. GitHub 용어로 이는 다음을 의미합니다. 풀 리퀘스트를 병합하고 프로젝트에 직접 코드를 커밋할 수 있는 프로젝트에 직접 커밋할 수 있다는 뜻입니다.