Autofixture: AutoFixture의 다음 단계는 무엇입니까?

@Kralizek , 질문해주셔서 감사합니다.

나는 나 자신에 대해서만 말할 수 있습니다. 실제로 https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457에 쓴 대로입니다.

PR을 검토하는 데 필요한 지식이 있는 경우 괜찮습니다. 일반적으로 이전에 작업, 생성 또는 기여한 코드 기반 부분을 (기쁘게) 검토합니다.

내가 명시적으로 언급된 pull 요청이나 문제를 놓친 경우 알려주십시오. 누군가 나를 리뷰어로 추가했거나 문제에 대해 명시적으로 언급한 지 오래되었습니다...

@moodmosaic , #703을 다시 지적해 주셔서 감사합니다. 내 위치는 여전히 그때와 같습니다. AutoFixture 프로젝트에서 벗어났지만 명시적으로 호출되면 조언을 돕게 되어 기쁩니다.

아무 일도 일어나지 않는 것 같으면 이 문제를 여는 것이 합리적이라고 생각합니다. 현재 유지 보수도 이동했을 수 있습니다. 그들 중 하나로부터 응답을 받는지 봅시다. 그렇지 않은 경우 다시 ping을 보내주십시오. 일주일 정도라고 해야 할까요?

내가 경험한 분야에서 가끔 PR을 검토하는 데 여전히 도움이 될 수 있지만 요즘에는 그런 분야가 거의 없을 것이라고 생각합니다.

상황이 움직이지 않는다면 그 이유를 알아내고 필요한 경우 더 많은 사람들을 찾도록 도울 수 있는지 봅시다.

나는 프로젝트에 대한 통제권을 되찾을 생각은 없지만 내가 말할 수 있는 한 나는 여전히 저장소에 대한 쓰기 권한이 있습니다. 다른 누군가가 자원하여 프로젝트를 이끌면 기꺼이 도와드리겠습니다.

안녕 얘들아!

여기에도 제 피드백이 없습니다. 공식적으로는 아니지만 현재로서는 내가 프로젝트에서 가장 활동적인/리드 메인테이너였을 것이라는 기대가 있을 것입니다.

처음에는 유지 관리에 매우 열정적이었고 더 개선할 수 있는 아이디어가 거의 없었습니다. 오늘날에도 최소한 유지 관리 관점에서(예: .NET Standard 1.x 지원 중단) 해야 할 일을 봅니다.

최근에 나는 프로젝트 지원에서 물러났고 이에 대한 몇 가지 이유를 스스로 확인했습니다.

면책 조항 : 목적은 누구를 비난하는 것이 아니므로 개인적으로 이해하지 마십시오. 오히려 제 경험을 공유하여 이에 대해 우리가 할 수 있는 일이 있는지, 그리고 그만한 가치가 있는지 확인하고 싶습니다.

프로젝트를 변경하는 것은 어렵습니다.

이 프로젝트를 변경하는 것은 매우 어렵습니다. 모두가 Mark가 남긴 유산을 보존하려고 한다는 강한 느낌이 있기 때문입니다. Mark가 하려는 것 외에는 다른 것을 시도할 자유가 없습니다. Mark는 직접 참여하지 않은 거의 모든 PR에서 인용되었습니다. :)

어느 시점에서 나는 여기에서 무엇이든 수정하는 것이 너무 어려워졌다는 것을 느끼기 시작했습니다. 그리고 그것은 내가 프로젝트에 대한 열정을 죽였습니다.

Mark는 떠났지만 여전히 개인적으로 프로젝트의 소유권은 여전히 ​​그에게 있다고 생각합니다. Mark가 멋지게 만든 무언가를 폭력적이고 야만적으로 깨뜨릴 기회가 있기 때문에 결정을 내릴 때 많은 내부/외부 압력을 느낍니다. 이 인식 중 일부는 내가 단독으로 만든 것이지만 다른 유지 관리자가 그러한 인상을 주는 데 기여한 부분이 있습니다.

아마도 내 기대와 현실의 차이 일뿐입니다. 나는 이 프로젝트를 통해 내 아이디어를 표현하고 시도할 수 있고, 민첩하고 신선하며 새로운 기능으로 가득 차게 될 것이라고 생각합니다. 그러나 실제로는 모든 것이 잘 작동하기 때문에 많은 변경이 허용되지 않는 레거시 프로젝트처럼 느껴졌습니다.

나는 내 제안 중 일부가 이상적이지 않을 수 있음을 인정하며, 물론 나는 존경할 만한 Mark만큼 경험이 많지 않습니다. 그러나 우리는 결정을 내릴 때 더 자유로울 수 있었기 때문에 프로젝트가 더 생생했습니다.

좀 외롭다

프로젝트에 합류했을 때 무엇보다도 민첩한 토론에 참여하고 팀의 일원이 되고 다른 사람들과 어울리기를 기대했습니다. 불행히도, 시간의 운 및/또는 기타 요인으로 인해 다른 유지 관리자가 토론에 너무 많이 참여하지 않았고 결국 나는 여기에서 혼자라는 느낌이 들기 시작했습니다. 다른 관리자들이 현재 이 프로젝트에 대해 너무 많은 시간/열정이 없다고 생각하여 마침내 같은 것을 공유하기 시작했습니다.

나는 지금 AutoFixture로 활발하게 일하고 있지 않습니다.

지금은 백엔드 코드를 많이 작성하지 않으므로 AutoFixture를 너무 많이 사용하지 마십시오. 나는 여전히 이 프로젝트에 큰 재미를 느끼고 있으며 이 라이브러리가 꼭 있어야 한다고 믿습니다. 하지만 테스트를 너무 많이 작성하지 않기 때문에 개인적으로 변경을 요구하지 않습니다.

더 나아가 나는 프로젝트 생활에 참여하고 적용 가능한 경우 내 지식을 공유하는 것을 꺼려하지 않습니다. 필요한 경우 코드/유지 관리도 도와드릴 수 있습니다. 그러나 불행히도 현재로서는 수석 유지 관리자가 될 만큼의 열정과 에너지가 없습니다. 우리가 신뢰하고 열정이 넘치는 후보가 있다면 반드시 초대하여 유지 관리인으로 삼아야 합니다.

먼저 #703 토론에서 연락을 드리지 못한 @AutoFixture/core 팀에 사과하고 싶습니다. 네, 바쁜 시간이었지만(지금도 그렇습니다) 제가 너무 바빠서 답장을 못 드린 것은 아닙니다. 내 언급에 대한 알림을 받지 못했고 토론을 다시 확인할 생각도 하지 않았습니다. 나는 #703을 다시 방문하면서 문자 그대로 방금 그것에 대해 알게 되었습니다. 다시 한 번 죄송합니다. 😞

AutoFixture의 미래에 대한 나의 입장 은 2016년에 내가 표현한 것과 동일합니다. 저는 AutoFixture가 꽤 안정적이며 몇 년 동안 사용되어 왔다고 생각합니다. 누군가 다른 방향으로 가고 싶다면 깨끗한 상태에서 시작하는 것이 더 나을 것이라고 생각합니다. 자동 생성 테스트 데이터의 개념은 매우 좋은 것이며 AutoFixture는 확실히 .NET 플랫폼에서 수행할 수 있는 _유일한_ 방법이 아닙니다.

AutoFixture에 버그가 없다는 것은 아닙니다. 내가 말하는 것은 유지 관리의 양과 범위가 @AutoFixture/core 팀의 책임으로 남을 수 있을 만큼 충분히 작다는 것입니다.

수석 개발자가 필요합니까? 오픈 소스의 역사 는 개별 리드가 없는 프로젝트는 결국 포기할 것임을 시사하는 것 같습니다. 그러나 리드 그룹은 어떻습니까?

나는 우리가 임명된 리드를 뺀 현재 모델로 나아가고 그것이 어떻게 진행되는지 보려고 노력한다고 말합니다.

AutoFixture는 정말 좋은 프로젝트입니다. 서서히 사라지는 모습을 보면 매우 슬플 것입니다.

@zvirja 는 프로젝트의 가장 활동적인/리드 유지 관리자이기 때문입니다. 나는 그가 이 프로젝트가 어떻게 발전할지 이끌어가는 것이 합리적이라고 생각합니다. 오픈 소스 프로젝트를 유지 관리하려면 많은 노력과 시간이 필요합니다. 개인적으로 나는 이 프로젝트를 진행하기 위해 기부하는 것을 꺼리지 않습니다. 그리고 감사합니다 @zvirja

누군가가 방에 있는 코끼리를 지적해야 하므로 나도 마찬가지일 것입니다.

이 스레드는 장례식(또는 회고전)과 많이 비슷해 보입니다.

나는 우리(커뮤니티)가 사과를 던지는 것보다 우리가 처한 상황에서 탈출구를 찾는 데 더 집중해야 한다고 생각합니다.
지금까지 이 스레드는 문제를 지적하는 데 매우 훌륭했습니다.

1. 현재 관리자는 시간이 없습니다/프로젝트에 관심이 없습니다
2. 프로젝트는 유지하기 어렵다
3. 코드 검토가 너무 제한적입니다.

이제 우리가 취할 수 있는 조치 목록을 만들어 볼까요?

누군가 관심을 갖고 있다면 여기에 내 의견이 있습니다.

1. 새로운 회원을 커뮤니티에 받아들입니다. @Kralizek 은 잠시 동안 주변에 있었고 그는 좋은 후보자일 수 있습니다. @AutoFixture/core와 함께 다른 팀이 있습니까?
2. 문제 백로그 생성, 우선 순위 지정, 커뮤니티에 도움 요청
3. 코드 검토를 느슨하게 합니다. 이전 소유자에게 지속적으로 손을 때리면 프로젝트의 소유권을 가질 수 없습니다.
   실험을 위해 추가 패키지 AutoFixture.Experimental 를 만들 수 있습니다. 이 패키지는 아직 라이브러리의 핵심 버전에 도달하는 것으로 확인되지 않았습니다(Boost는 표준 C++ 라이브러리용).

나는 @zvirja 에 동의합니다. 이 프로젝트는 매우 위협적입니다. 저는 약 2년 전에 AutoFixture를 발견했고 최근에야 PR을 제출할 용기를 얻었습니다.
저와 같은 감정을 느끼시는 분들도 계실 거라 생각합니다. 도구를 사용하고 있고 그것이 번창하는 것을 보고 싶어하는 사람들.

방에 있는 코끼리를 가리키는 @aivascu 에게 감사드립니다.

나는 당신의 분석에 동의하지만 네 번째 옵션이 있습니다.

또한 내 이름을 목록에 올려주셔서 감사합니다. 하지만 불행히도 저는 라이브러리 내부에 대한 경험이 많지 않아 이리저리 움직일 수 없습니다.

사용자 경험에 관해서라면 기꺼이 개입할 수 있습니다...

프로젝트 유지에 대한 열정을 불러일으키는 후원/후원 프로그램은 어떻습니까?
결국 인기있는 repo입니다.

지난 3년 동안 AutoFixture를 사용한 내 2센트:

AutoFixture의 브랜드 이름이 훌륭하다고 생각합니다. 멋진 이름입니다.

스택 오버플로에서 인기가 있습니다. [autofixture] 에는 506개의 질문이 있는 반면 [xunit.net] 에는 801개의 질문이 있습니다. .NET Core의 준공식 테스트 프레임워크만큼 인기를 얻으려면 다소 놀랍고 부분적으로 Mark의 끊임없는 헌신 덕분입니다. 가르치는 것(그리고 훌륭한 교사가 되는 것). 그리고 Mark의 블로그 는 무료 테스트 지식의 샘과 같습니다.

AutoFixture의 API는 배우기 다소 어렵다고 생각합니다.

내가 좋아하는 AutoFixture 부분:

• Auto-Mocking Container 디자인 패턴을 사용하는 능력(아마도 내가 엔지니어로서 소개받은 가장 강력한 테스트 개념일 것입니다).
• Fixture.Freeze 굉장해
• 모의가 필요한 것들에 대한 설비를 빠르게 생성할 수 있는 AutoMoq 확장
• 엔터티 개체 그래프를 자동으로 생성하고 일반 리포지토리 패턴을 테스트하고 Entity Framework 리포지토리에 대한 종단 간 통합 테스트 코드 적용을 보장하는 기능.

직접 사용하지 않는 AutoFixture 부분:

• Fixture.Inject

AutoFixture의 개선/확장을 원하는 부분

• 어제 생성된 내 문제 보기: #1179
• Guids의 기본 동작을 Waffle Text Generator와 같은 더 멋진 것으로 교체하는 기능. 오늘 할 수 있다는 것을 알고 있지만 #1179가 작업된 경우 사용자 지정 데이터 공급자와 함께 임의 요소 선택기를 연결할 수 있습니다.
• AutoFixture는 느리고 Maksim Volkau의 DryIoC 프로젝트가 Maksim의 FastExpressionCompiler https://github.com/dadhi/FastExpressionCompiler 로 수행하는 것처럼 표현 컴파일 속도를 높이는 현대적인 트릭을 사용하지 않습니다.

내가 좋아하지 않는 AutoFixture 부분(대부분 사소한):

• Fixture.CustomizeVisual Studio Intellisense에서는 항상 잘못 작동합니다.
• 사용자 정의 작성 및 Customize 메소드를 사용하여 사용자 정의를 삽입할 수 없는 이유. 그런 종류의 것들은 바로크적이고 성가시며 거대한 학습 곡선을 만듭니다.
• 커스터마이징과 speciman 빌더 및 물건이 도처에 있습니다. 무질서합니다.
• 몇 가지에 대한 이상한 어휘
• 전체 Do..Without 디자인 패턴은 익숙해지기가 다소 어렵습니다. 작동하지만 장황하고 재귀 엔티티에 도움이되지 않습니다. 이를 위해서는 AutoFixture가 이미 생성된 객체의 해시 테이블을 생성하도록 지시하는 특별한 동작이 필요합니다.
• 일반 작업에 대한 단순화된 구문 없음
• 문제를 해결하기 위해 내부에 대한 깊은 이해가 필요한 모놀리식 설계. 당신은 단지 조각을 사용할 수 없습니다. AutoFixture가 뛰어난 이유를 이해하려면 초기 학습 곡선을 통과하기 위해 Mark의 PluralSight 과정을 많이 시청하거나 AutoFixture의 전문가인 개발자와 협력해야 합니다.
• AutoFixture는 "익명 값"만 생성해야 한다는 Mark의 입장입니다. 작업을 완료하기 위해 많은 타사 코드 작성이 생성됩니다. 예에는 다음 StackOverflow 게시물이 포함됩니다.
  
  
  
  • Autofixture, 사전 목록 생성대체 키
  
  
  • 목록에 있는 항목의 하위 범위에만 속성을 할당하려면 어떻게 해야 합니까?
  
  
  • AutoFixture에 항상 미리 정의된 값이 설정되어 있는 클래스 목록을 어떻게 생성합니까?
  
  

혁신 가능성이 있는 부품:

• C#이 점점 더 기능적으로 발전함에 따라(패턴 일치, 레코드 유형 등) AutoFixture는 F#의 FsCheck 및 Hedgehog처럼 점점 더 이상적으로 작동합니다.
• AutoFixture가 Arb 기능과 같은 FsCheck의 일부 concolic 테스트 개념을 구체화할 수 있다면 좋을 것입니다.
• 엔지니어가 매우 강력하고 다양한 테스트 입력을 생성할 수 있도록 RLCheck에서 논의된 것과 같은 혁신을 사용합니다(Guid as string is a hack!) https://www.carolemieux.com/rlcheck_preprint.pdf

여기에서 설명하는 문제 중 일부는 Microsoft가 .NET Core에 대한 테스트에서 AutoFixture를 사용하지 않는 이유라고 생각합니다.

실험적인 포크가 갈 수 있는 방법처럼 들립니다. AutoFixture는 개발자가 일상적으로 광범위하게 사용하고 추가 기능과 향상된 사용 편의성의 이점을 확실히 누릴 수 있으며 그 뒤에 고품질 코드베이스가 있는 몇 안 되는 오픈 소스 프로젝트 중 하나입니다. 기여 및 방향 변경에 대한 우려가 완화된다면 관심이 낮을 것이라고 상상할 수 없습니다. 이것이 액티브 포크가 하는 일입니다.

실험적인 포크가 갈 수 있는 방법처럼 들립니다.

왜 그렇게 하시겠습니까? 당신은 그 포크를 유지해야합니다. 그렇게 할 의향이 있다면 대신 이 리포지토리의 유지 관리자로 나서지 않겠습니까?

실험적인 포크보다는 위에서 논의한 QoL 개선 사항을 소개하기 위해 새 리포지토리를 생성(또는 이 리포지토리에서 계속 구축)하는 것을 고려할 것입니다.

AutoFixture에는 많은 것을 성취할 수 있지만 많은 사람들을 놀라게 할 수 있는 강력한 API가 있습니다. 대부분의 것들은 단순한 구문 설탕으로 소개될 수 있습니다.

QoL 개선 사항을 소개하기 위해

Renato( @Kralizek ), QoL은 무엇을 의미합니까? 삶의 질?

네.

그렇게 할 의향이 있다면 대신 이 리포지토리의 유지 관리자로 나서지 않겠습니까?

@ploeh 어떻게 리포지토리의 유지 관리자로 한 단계 향상됩니까? 요구 사항이 있습니까?
현재 유지 관리 목록을 보면 솔직히 채워야 할 몇 가지 큰 신발이 있습니다.
AutoFixture에 기여하고 싶습니다. 아마도 유지 관리인으로서(언젠가) 다른 사람들도 있을 것입니다. 하지만 이렇게 인기 있는 저장소를 유지 관리하는 데 동의할 사람은 아무도 없을 거라고 생각합니다.

왜 그렇게 하시겠습니까? 당신은 그 포크를 유지해야합니다.

나는 그 인용문에 동의한다. 처음에 실험 패키지를 제안했을 때 이 스레드에서 저장소를 유지하면서 @zvirja 가 가진 문제를 완화하는 방법을 생각했습니다. 패키지에는 변경된 포크가 아닌 AutoFixture 코어 위에 구축된 기능이 포함되었을 것입니다. @Kralizek이 설명한 것과 같은 것입니다.
물론 이상적으로는 이와 같은 패키지가 필요하지 않습니다. 우리가 해결해야 할 것은 기술의 문제가 아니라 사람의 문제라고 생각합니다.

우리가 해결해야 할 것은 기술의 문제가 아니라 사람의 문제라고 생각합니다.

그게 무슨 뜻인지 모르겠어요. 더 알려주세요.

우리가 해결해야 할 것은 기술의 문제가 아니라 사람의 문제라고 생각합니다.

그게 무슨 뜻인지 모르겠어요. 더 알려주세요.

그가 의미하는 바는 @zvirja가 그의 코멘트 에서 말한 것처럼 AutoFixture 가 아름다운 예술 작품을 파괴하는 것을 두려워하지 않고 자유롭게 혁신할 수 있는 헌신적인 관리자가 필요하다는 것입니다.

이전의 결정과 리더십에 의해 드리워진 그림자에 손이 묶인 것처럼 느껴지는 일에 전념한다는 느낌을 받기 어렵습니다.

몇 가지 흥미로운 아이디어가 "구식"과 상충되기 때문에 거부되었습니다. 이것은 누군가의 동기를 죽일 것입니다. 그런 점에서 포크는 이 짐을 많이 풀어줄 것입니다.

알겠습니다. 저는 단순한 사람입니다. https://github.com/AutoFixture/AutoFixture/pull/928 과 같은 것을 병합하고 싶습니다. 위에서 언급했듯이 AutoFixture는 고유한 값 생성을 지원하는 좋은 방법이 없습니다. 승법 선형 합동 생성기는 그러한 기능에 대한 좋은 기초처럼 보입니다. 우리는 최근에 우리 자신의 것을 썼고 이 트릭에 대해 아는 사람만큼 똑똑하지 않았고 나중에서야 PR을 찾았습니다.

"그래, 이 멋진 일을 더 많이 해보자."

리포지토리의 유지 관리자로서 한 단계 더 나아가는 방법은 무엇입니까?

당신은 기본적으로 당신이 그 책임을 맡을 의향이 있다고 말합니다. 내가 말할 수 있는 한, 나는 여전히 리포지토리에 대한 관리자 권한을 가지고 있으며, 현재 유지 관리자 중 누구도 이를 명시적으로 언급하지 않았지만, 아무도 이를 계속 진행하지 않을 것이라는 인상을 받았습니다.

요구 사항이 있습니까? 현재 유지 관리 목록을 보면 솔직히 채워야 할 몇 가지 큰 신발이 있습니다.

과거에 대해 걱정하지 마십시오. 지금 상황을 올바르게 읽으면 AutoFixture가 물에 잠겨 있습니다. 누군가가 그 일을 계속 진행하지 않는 한, 아무것도 바뀌지 않을 것입니다.

따라서 세상의 모든 실수를 저지를 수 있으며 상황을 악화시키는 일은 거의 없을 것입니다.

@ploeh 이렇게 올려주시면 저는 기꺼이 유지보수를 하고 다른 분들도 한 발 더 나아가길 바랍니다.

@aivascu 감사합니다.

나는 현재 관리자와 주변 사람들에게 @zvirja , @moodmosaic , @adamchester , @ecampidoglio 에 대해 약 24시간 동안 이에 대해 논평할 수 있는 시간을 줄 것이며, 항의가 없으면 관리자 권한을 부여하겠습니다.

@ploeh 내 쪽에서 이의가 없습니다.
@aivascu 탑승 을 환영합니다. 이 프로젝트가 당신이 찾고 있는 재미를 가져다 주기를 바랍니다 😊

@aivascu 저는 관리자는 아니지만 이 라이브러리를 좋아합니다. 생각을 되살릴 사람이 필요하면 저에게 핑을 보내주세요.

@ploeh , @aivascu , 괜찮습니다 :+1: :rocket:

내가 작업, 생성 또는 기여한 코드 기반 부분에 대해 토론하게 되어 기쁩니다. 내가 언급된 풀 리퀘스트(또는 문제)를 놓친 경우 알려주십시오.

@aivascu 행운 을 빕니다. 내 유일한 조언은 특히 한 곳에 명확한 "아키텍처 결정 기록"이 없는 경우 코드베이스의 코드 20,000줄마다 약 6개월이 걸릴 수 있다는 것입니다. 이러한 이유로 내가 유지 관리하는 프로젝트에서 사람들이 코드의 "스타일"을 이해할 수 있도록 작성하기 시작했습니다. Mark는 이것들을 작성했지만 대부분 그의 블로그 및/또는 StackOverflow에 있습니다. @moodmosaic 도 마찬가지였습니다. 저는 앞으로 모든 디자인 근거를 문서화하는 adr 폴더를 repo 루트에 생성한다고 말하고 싶습니다. 이를 위해 .md 파일을 사용할 수 있습니다. 복잡한 테이블의 경우 마크다운 테이블 대신 html 테이블을 사용합니다.

따뜻하게 맞아주신 모든 분들께 감사드립니다.
처음에는 @jzabroski 의 조언을 받아 새 유지 관리자와 기여자가 더 쉽게 온보딩할 수 있도록 문서 의 공백을 채우기 시작할 것이라고 생각합니다.
동시에 기존 백로그를 통해 레코딩을 시작할 수 있습니다.
바라건대 더 많은 커뮤니티 회원이 이 놀라운 도구를 발전시키기 위해 나서게 될 것입니다.

@aivascu님 축하합니다.

나는 당신이 지금 수석 개발자라고 생각합니다. 내가 이 말을 하는 것은 당신이 멈추는 즉시 모든 것이 지금의 '죽은' 상태로 돌아갈 것이라고 느끼기 때문입니다. 그래서 나는 지금 당신을 보고 있습니다 :)

Autofixture 팀이 이전에 언급한 외로운 여정 문제의 위험을 완화하기 위해 새 팀원을 '사냥'하기를 바랍니다. 누군가 이 https://github.com/AutoFixture/AutoFixture/pull/1164를 볼 수 있는 경우에만 기여하게 되어 기쁩니다.

@aivascu 핵심 AutoFixture 팀에 합류하라는 초대장을 보냈지만 초대장은 아직 보류 중입니다.

@ploeh 방금 초대를 수락했습니다. 감사합니다!

@aivascu 👍 팀에 오신 것을 환영합니다.

더 많은 도움을 드릴 수 있다면 기꺼이 도와드리겠습니다. 그러나 나는 몇 년 동안 이 프로젝트에서 비활동적이어서 실용적인 것들이 어떻게 작동하는지 더 이상 모릅니다. @zvirja 가 이러한 세부 사항을 채워줄 수 있기를 바랍니다.

감사합니다!

환영합니다 @aivascu

@aivascu 프로젝트에 참여하게 되어 기쁩니다. 실례가 되지 않는다면 음성 대화를 통해 모든 것을 보여주고 질문에 답해 드리겠습니다. 그럴 의향이 있다면 세부 사항에 동의할 수 있도록 메일을 보내주세요(커밋에서 주소를 찾을 수 있음).

그리고 다시 환영합니다.

@zvirja 정말 좋을 것입니다. 나는 당신에게 이메일을 드롭합니다.

환영합니다 @aivascu :+1:

탑승을 환영합니다, @aivascu! 🙂

@aivascu 이 문제를 해결하기 위해 열정과 에너지로 가득 찬 새로운 관리자로 올라섰다면 이 문제를 닫고 고정 해제해야 합니까? 현재로서는 우리의 미래가 정해져 있다는 말입니까? 😄

@zvirja 나는 다른 누군가가 관리자의 순위를 채우도록 요청할 수 있기를 바랐습니다. 😄

누구든지 이 저장소의 관리자가 되는 것을 즐긴다고 생각되면 문제를 열거나 메시지를 보내주십시오.
이제 문제를 종료하겠습니다.