Autofixture: Was kommt als nächstes für AutoFixture?

@Kralizek , danke der Nachfrage.

Ich kann nur für mich sprechen, es ist tatsächlich (noch) so, wie ich es in https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457 geschrieben habe:

Gut für mich, wenn ich das erforderliche Wissen habe, um die PR(s) zu überprüfen. Normalerweise überprüfe ich (freudig) Teile der Codebasis, an denen ich zuvor gearbeitet, erstellt oder beigetragen habe.

Wenn ich einen Pull-Request oder ein Problem verpasst habe, in dem ich explizit erwähnt wurde, lass es mich bitte wissen. Es ist jedoch schon eine Weile her, dass mich jemand als Rezensent hinzugefügt oder mich ausdrücklich in einem/n Problem(en) erwähnt hat...

Vielen Dank, @moodmosaic , für den Hinweis auf #703. Meine Position ist immer noch die gleiche wie damals: Ich bin aus dem AutoFixture-Projekt raus, stehe aber gerne mit Rat und Tat zur Seite, wenn ich explizit dazu aufgerufen werde.

Ich denke, dass es sinnvoll ist, dieses Thema zu eröffnen, wenn nichts zu passieren scheint. Es kann sein, dass die derzeitigen Betreuer auch weitergezogen sind. Mal sehen, ob wir von denen eine Antwort bekommen. Wenn nicht, pingen Sie mich bitte noch einmal an, in einer Woche oder so?

Ich kann immer noch helfen, die gelegentliche PR in Bereichen zu überprüfen, in denen ich Erfahrung hatte, aber ich denke, diese Bereiche sind heutzutage wahrscheinlich selten und weit voneinander entfernt.

Wenn sich die Dinge nicht bewegen, lassen Sie uns sehen, ob wir herausfinden können, warum, und dann sehen, ob wir helfen können, mehr Menschen zu finden, die helfen, wenn nötig.

Ich habe nicht die Absicht, die Kontrolle über das Projekt zurückzugewinnen, aber soweit ich das beurteilen kann, habe ich immer noch Schreibzugriff auf das Repository. Wenn sich jemand anderes freiwillig bereit erklärt, das Projekt zu leiten, helfe ich gerne dabei, dies zu verwirklichen.

Hallo Leute!

Hier fehlt auch mein Feedback. Nicht offiziell, aber wahrscheinlich gibt es Erwartungen, dass ich vorerst der aktivste/leitende Betreuer des Projekts war.

Anfangs war ich sehr leidenschaftlich in der Wartung und hatte nur wenige Ideen, was noch verbessert werden könnte. Auch heute noch sehe ich Dinge, die zumindest aus Wartungssicht sinnvoll sind (zB Verzicht auf .NET Standard 1.x Support).

Kürzlich habe ich mich von der Unterstützung des Projekts zurückgezogen, und ich habe selbst einige Gründe dafür identifiziert.

HAFTUNGSAUSSCHLUSS : Es geht nicht darum, jemandem die Schuld zu geben, also nimm es nicht persönlich. Vielmehr möchte ich nur meine eigenen Erfahrungen teilen, damit wir sehen können, ob wir etwas dagegen tun können und ob es sich lohnt.

Es ist schwierig, das Projekt zu ändern.

Es ist sehr schwierig, dieses Projekt zu ändern, da ich das starke Gefühl habe, dass jeder versucht, das Vermächtnis zu bewahren, das Mark hinterlassen hat. Es gibt keine Freiheit, etwas anderes zu versuchen, außer dem, was Mark tun würde. Mark wurde in fast jeder PR zitiert, an der er nicht persönlich teilgenommen hat :)

Irgendwann hatte ich das Gefühl, dass es mir zu schwierig wurde, hier etwas zu ändern. Und es tötete die Leidenschaft, die ich für das Projekt hatte.

Obwohl Mark gegangen ist, habe ich persönlich immer noch das Gefühl, dass das Eigentum an dem Projekt immer noch bei ihm liegt. Ich spüre viel internen/externen Druck, wenn ich die Entscheidungen treffe, da die Möglichkeit besteht, etwas, das von Mark so gut gemacht wurde, gewaltsam und barbarisch zu zerstören. Ein Teil dieser Wahrnehmung wurde allein von mir geschaffen, aber es gibt Teile, an denen andere Betreuer dazu beigetragen haben, einen solchen Eindruck zu hinterlassen.

Wahrscheinlich ist es nur der Unterschied zu meinen Erwartungen und der Realität. Ich dachte, dass ich mit diesem Projekt meine Ideen ausdrücken und ausprobieren könnte, dass es agil, frisch und voller neuer Funktionen sein wird. Aber in Wirklichkeit fühlte es sich wie ein altes Projekt an, an dem man nicht viel ändern darf, da die Dinge sowieso gut funktionieren.

Ich gebe zu, dass einige meiner Vorschläge nicht ideal gewesen sein könnten, und natürlich bin ich nicht so erfahren wie der ehrenwerte Mark. Aber wir hätten freier in unseren Entscheidungen sein können, damit das Projekt lebendiger wird.

Es ist ein bisschen einsam

Als ich dem Projekt beitrat, erwartete ich unter anderem, an agilen Diskussionen teilzunehmen, ein Teil des Teams zu sein und mit anderen Kontakte zu knüpfen. Unglücklicherweise beteiligten sich andere Betreuer aus Zeitgründen und/oder anderen Faktoren nicht allzu sehr an den Diskussionen und schließlich begann ich zu fühlen, dass ich hier allein bin. Ich habe das Gefühl, dass andere Betreuer im Moment nicht allzu viel Zeit/Leidenschaft für dieses Projekt haben, also fing ich endlich an, dasselbe zu teilen.

Ich arbeite derzeit nicht aktiv mit AutoFixture

Im Moment schreibe ich nicht viel Back-End-Code, also benutze AutoFixture nicht zu oft. Ich bin immer noch ein riesiger Spaß an dem Projekt und glaube, dass diese Bibliothek ein Muss ist. Da ich aber nicht zu viele Tests schreibe, fordere ich persönlich keine Änderungen.

Darüber hinaus habe ich nichts dagegen, am Projektleben teilzunehmen und gegebenenfalls mein Wissen zu teilen. Wenn es nötig ist, könnte ich auch beim Code/der Wartung helfen. Aber im Moment habe ich leider nicht genug Leidenschaft und Energie, um ein Lead Maintainer zu sein. Wenn wir dafür einen Kandidaten haben, dem wir vertrauen und der voller Leidenschaft ist, sollten wir ihn/sie unbedingt einladen und zu einem der Betreuer machen.

Zunächst möchte ich mich beim @AutoFixture/core-Team dafür entschuldigen, dass ich mich in der #703-Diskussion nicht bei Ihnen gemeldet habe. Ja, es war eine arbeitsreiche Zeit für mich (und ist es immer noch), aber ich war nicht so beschäftigt, dass ich nicht antworten konnte. Ich habe einfach keine Benachrichtigungen für meine Erwähnungen erhalten und habe nicht daran gedacht, die Diskussion erneut zu überprüfen. Ich habe es buchstäblich gerade erst herausgefunden, als ich # 703 erneut besuchte. Nochmals, es tut mir leid. 😞

Meine Position zur Zukunft von AutoFixture ist dieselbe, die ich bereits 2016 geäußert habe . Ich glaube, AutoFixture ist ziemlich stabil und das schon seit Jahren. Wenn jemand es in eine andere Richtung lenken möchte, sollte er meiner Meinung nach besser von Null anfangen. Das Konzept der automatischen Generierung von Testdaten ist sehr gut, und AutoFixture ist sicherlich nicht die _einzige_ Möglichkeit, dies auf der .NET-Plattform zu tun.

Das soll nicht heißen, dass AutoFixture fehlerfrei ist. Was ich sagen will ist, dass das Volumen und der Umfang der Wartung klein genug ist, dass sie in der Verantwortung des @AutoFixture/Kernteams bleiben kann.

Brauchen wir einen Lead Developer? Die Geschichte von Open Source scheint darauf hinzudeuten, dass ein Projekt ohne individuelle Leitung irgendwann aufgegeben wird. Aber was ist mit einer Gruppe von Leads?

Ich sage, wir versuchen, mit dem aktuellen Modell ohne einen festgesetzten Vorsprung voranzukommen, und sehen, wie es läuft.

AutoFixture ist so ein gutes Projekt, es wird sehr traurig sein, es langsam verblassen zu sehen.

Da @zvirja der aktivste/leitendste Betreuer des Projekts ist. Ich glaube, es macht Sinn, dass er die Entwicklung dieses Projekts leitet. Die Pflege eines Open-Source-Projekts erfordert viel Mühe und Zeit. Ich persönlich habe nichts dagegen zu spenden, um dieses Projekt am Laufen zu halten. Und danke @zvirja

Jemand sollte auf den Elefanten im Raum hinweisen, also könnte ich es auch sein.

Dieser Thread sieht sehr nach einer Beerdigung (oder einer Bedauernsperspektive) aus

Ich glaube, wir (die Community) sollten uns mehr darauf konzentrieren, einen Ausweg aus der Situation zu finden, in der wir uns befanden, als Entschuldigungen herumzuwerfen.
Bisher war dieser Thread sehr gut darin, auf die Probleme hinzuweisen (können Sie gerne vervollständigen):

1. Die derzeitigen Betreuer haben keine Zeit/sind nicht an dem Projekt interessiert
2. Das Projekt ist schwer zu pflegen
3. Die Codeüberprüfung ist zu restriktiv

Können wir jetzt eine Liste mit Maßnahmen erstellen, die wir ergreifen können?

Falls es jemanden interessiert, hier meine Meinung dazu:

1. Nehmen Sie neue Mitglieder in die Community auf. @Kralizek ist schon eine Weile dabei, er könnte ein guter Kandidat sein. Vielleicht haben Sie ein anderes Team neben @AutoFixture/core?
2. Erstellen Sie einen Rückstand von Problemen, priorisieren Sie, bitten Sie die Community um Hilfe
3. Lockern Sie die Codeüberprüfung auf. Man kann kein Projekt übernehmen, wenn man ständig vom Vorbesitzer auf die Hand geschlagen wird.
   Lassen Sie Experimente zu, erstellen Sie vielleicht ein zusätzliches Paket AutoFixture.Experimental , für Dinge, die noch nicht bestätigt sind, um zur Kernversion der Bibliothek zu gelangen (wie Boost für die Standard-C++-Bibliothek).

Ich stimme @zvirja zu, das Projekt ist sehr einschüchternd. Ich habe AutoFixture vor ungefähr zwei Jahren entdeckt und erst kürzlich den Mut gefunden, eine PR einzureichen.
Ich glaube, es gibt andere, denen es genauso geht. Personen, die das Tool verwenden und es erfolgreicher sehen möchten.

Danke @aivascu für den Hinweis auf den Elefanten im Raum.

Ich stimme Ihrer Analyse zu, aber ich hätte auch eine vierte Option (obwohl ich sie hassen würde): einen neuen Fork, um seinen Betreuern die Freiheit zu geben, sich zu bewegen und herumzuspielen.

Vielen Dank auch, dass Sie meinen Namen in die Liste aufgenommen haben, aber leider bin ich mit den Interna der Bibliothek nicht so erfahren und kann mich wirklich nicht darin bewegen.

Ich kann gerne eingreifen, wenn es um die Benutzererfahrung geht ...

Wie wäre es mit einem Patenschafts-/Unterstützerprogramm, um etwas Begeisterung für die Aufrechterhaltung des Projekts zu wecken?
Es ist schließlich ein beliebtes Repo.

Meine zwei Cent mit AutoFixture in den letzten drei Jahren:

Ich finde den Markennamen für AutoFixture großartig. Es ist ein cooler Name.

Es ist beliebt bei Stack Overflow. [autofixture] hat 506 Fragen, während [xunit.net] 801 Fragen hat. Dass es fast so beliebt ist wie das quasi-offizielle Test-Framework von .NET Core, ist ziemlich bemerkenswert, und teilweise aufgrund von Marks unermüdlichem Engagement zu unterrichten (und ein großartiger Lehrer zu sein). Und Marks Blog ist wie eine Quelle für kostenloses Testwissen.

Ich denke, die API von AutoFixture ist ziemlich schwer zu erlernen.

Teile von AutoFixture, die ich liebe:

• Fähigkeit zur Verwendung des Auto-Mocking Container-Entwurfsmusters (wahrscheinlich das leistungsfähigste Testkonzept, das mir als Ingenieur vorgestellt wurde).
• Fixture.Freeze ist erstaunlich
• AutoMoq-Erweiterung zum schnellen Erstellen von Vorrichtungen für Dinge, die einen Mock erfordern
• Fähigkeit, automatisch ein Entitätsobjektdiagramm zu generieren und mein generisches Repository-Muster zu testen und eine End-to-End-Integrationstestcodeabdeckung für meine Entity Framework-Repositorys zu gewährleisten.

Teile von AutoFixture, die ich nie direkt verwende:

• Fixture.Inject

Teile von AutoFixture, die ich verbessern/erweitern möchte

• Siehe mein gestern erstelltes Problem: #1179
• Möglichkeit, das Standardverhalten von Guids für Strings durch etwas Netteres wie Waffle Text Generator auszutauschen. Mir ist klar, dass Sie dies heute tun können, aber wenn an #1179 gearbeitet würde, könnten wir Arbitrary Element Pickers mit einem benutzerdefinierten Datenanbieter einbinden.
• AutoFixture ist langsam und verwendet keine modernen Tricks, um die Kompilierung von Ausdrücken zu beschleunigen, wie es Maksim Volkaus DryIoC-Projekt mit Maksims FastExpressionCompiler https://github.com/dadhi/FastExpressionCompiler tut

Teile von AutoFixture, die ich nicht liebe (meistens unbedeutend):

• Fixture.Customizefunktioniert immer falsch mit Visual Studio Intellisense.
• Schreiben von Anpassungen und warum die Customize-Methode es Ihnen nicht ermöglicht, eine Anpassung einzufügen. Diese Art von Zeug ist barock und nervig und schafft eine riesige Lernkurve.
• Anpassungen und Musterbauer und andere Dinge sind überall zu finden. Es ist unorganisiert.
• Seltsames Vokabular für manche Dinge
• Das ganze Do..Without Designmuster ist ziemlich gewöhnungsbedürftig. Es funktioniert, aber es ist ausführlich und hilft Ihnen nicht bei rekursiven Entitäten. Dafür benötigen Sie spezielle Verhaltensweisen, um AutoFixture anzuweisen, eine Hash-Tabelle mit bereits erstellten Objekten zu erstellen.
• Keine vereinfachte Syntax für allgemeine Aufgaben
• Monolithisches Design, das ein tiefes Verständnis der Interna erfordert, nur um Probleme zu lösen. Sie können nicht nur Bits und Stücke verwenden. Sie müssen sich Marks PluralSight-Kurs ansehen, um die anfängliche Lernkurve zu überwinden, oder mit einem Entwickler zusammenarbeiten, der Experte für AutoFixture ist, um zu verstehen, warum AutoFixture so großartig ist.
• Marks Haltung, dass AutoFixture nur „anonyme Werte“ generieren sollte. Es erstellt eine Menge Code von Drittanbietern, um Dinge zu erledigen. Beispiele sind die folgenden StackOverflow-Beiträge:
  
  
  
  • Autofixture, erstellen Sie eine Wörterbuchlistemit Wechseltonart
  
  
  • Wie weise ich eine Eigenschaft nur einem Teilbereich von Elementen in einer Liste zu?
  
  
  • Wie erstelle ich eine Liste von Klassen, die immer einen vordefinierten Wert in AutoFixture haben?
  
  

Teile, die ich für Innovation sehe:

• Da C# immer funktionaler wird (Musterabgleich, Datensatztypen usw.), würde AutoFixture idealerweise immer mehr wie FsCheck und Hedgehog in F# funktionieren.
• Es wäre schön, wenn AutoFixture in der Lage wäre, einige konkolische Testkonzepte von FsCheck, wie die Arb-Funktion, zu replizieren.
• Verwenden Sie Innovationen wie die in RLCheck besprochenen, damit Ingenieure superrobuste, vielfältige Testeingaben erstellen können (Guid als String ist ein Hack!) https://www.carolemieux.com/rlcheck_preprint.pdf

Ich denke, einige der Probleme, die ich hier skizziere, sind, warum Microsoft AutoFixture in keinem seiner Tests für .NET Core verwendet.

Es klingt, als könnte eine experimentelle Gabel der richtige Weg sein. AutoFixture gehört zu den wenigen Open-Source-Projekten, die ich kenne, die sowohl von Entwicklern im Alltag weit verbreitet sind, definitiv von zusätzlichen Funktionen und einer verbesserten Benutzerfreundlichkeit profitieren können, als auch eine qualitativ hochwertige Codebasis dahinter haben. Ich kann mir nicht vorstellen, dass das Interesse gering wäre, wenn die Bedenken hinsichtlich eines Beitrags und einer Richtungsänderung gemildert würden, was ein aktiver Fork tun würde.

Es klingt, als könnte eine experimentelle Gabel der richtige Weg sein.

Warum würden Sie das tun wollen? Sie müssten diese Gabel warten. Wenn Sie dazu bereit sind, warum treten Sie nicht stattdessen als Betreuer dieses Repositorys auf?

Anstelle eines experimentellen Forks würde ich erwägen, ein neues Repo zu erstellen (oder weiter auf diesem aufzubauen), um die QoL-Verbesserungen einzuführen, die oben besprochen wurden.

AutoFixture hat eine leistungsstarke API, die viel erreichen kann, aber viele Leute abschrecken kann. Die meisten Dinge können als einfacher syntaktischer Zucker eingeführt werden.

um die QoL-Verbesserungen einzuführen

Renato ( @Kralizek ), wofür steht QoL? Lebensqualität?

Ja.

Wenn Sie dazu bereit sind, warum treten Sie nicht stattdessen als Betreuer dieses Repositorys auf?

@ploeh wie tritt man als Betreuer für das Repository auf? Gibt es Anforderungen?
Um ehrlich zu sein, wenn man sich die aktuelle Liste der Betreuer ansieht, gibt es einige große Fußstapfen zu füllen.
Ich würde gerne zu AutoFixture beitragen, vielleicht sogar als Betreuer (eines Tages) und ich bin mir sicher, dass es andere gibt, aber ich kann mir vorstellen, dass niemand akzeptiert würde, ein so beliebtes Repository zu pflegen.

Warum würden Sie das tun wollen? Sie müssten diese Gabel warten.

Ich stimme diesem Zitat zu. Als ich ursprünglich ein experimentelles Paket in diesem Thread vorschlug, dachte ich über eine Möglichkeit nach, die Probleme von @zvirja zu mindern und gleichzeitig das Repository beizubehalten. Das Paket hätte Funktionen enthalten, die auf dem AutoFixture-Kern aufbauen, nicht auf einem geänderten Fork. So etwas wie das, was @Kralizek beschrieben hat.
Im Idealfall wäre ein solches Paket natürlich nicht erforderlich. Was wir meiner Meinung nach lösen sollten, ist eher das Problem der Menschen als ein Technologieproblem.

Was wir meiner Meinung nach lösen sollten, ist eher das Problem der Menschen als ein Technologieproblem.

Ich weiß nicht, was das bedeutet. Erzählen Sie uns mehr.

Was wir meiner Meinung nach lösen sollten, ist eher das Problem der Menschen als ein Technologieproblem.

Ich weiß nicht, was das bedeutet. Erzählen Sie uns mehr.

Ich denke, was er meint, ist, dass AutoFixture engagierte Betreuer braucht, die sich frei fühlen, innovativ zu sein, ohne befürchten zu müssen, ein schönes Kunstwerk zu zerstören, wie es @zvirja in seinem Kommentar gesagt hat.

Es ist schwer, sich einer Sache verpflichtet zu fühlen, bei der man das Gefühl hat, dass einem die Hände gebunden sind durch den Schatten, der durch frühere Entscheidungen und Führung geworfen wird.

Einige interessante Ideen wurden abgelehnt, weil sie im Widerspruch zu den „alten Wegen“ standen. Das würde jedem die Motivation nehmen. Aus dieser Sicht würde eine Gabel viel von diesem Ballast freisetzen.

OK, ich bin ein einfacher Typ, ich möchte nur Dinge wie https://github.com/AutoFixture/AutoFixture/pull/928 zusammenführen. Wie ich oben erwähnt habe, hat AutoFixture keine guten Möglichkeiten, das Generieren eindeutiger Werte zu unterstützen. Der multiplikative lineare kongruente Generator scheint eine gute Basis für ein solches Feature zu sein. Wir haben kürzlich unsere eigene geschrieben und waren nicht so schlau wie jemand, der von diesem Trick wusste, und ich habe die PR erst später gefunden.

Ich sage: "Ja, lass uns mehr von diesem coolen Zeug machen."

Wie tritt man als Betreuer des Projektarchivs auf?

Sie erklären grundsätzlich, dass Sie bereit sind, diese Verantwortung zu übernehmen. Soweit ich das beurteilen kann, habe ich immer noch Administratorrechte für das Repository, und obwohl keiner der derzeitigen Betreuer dies ausdrücklich angegeben hat, habe ich den Eindruck, dass keiner von ihnen dies fortsetzen wird.

Gibt es Anforderungen? Um ehrlich zu sein, wenn man sich die aktuelle Liste der Betreuer ansieht, gibt es einige große Fußstapfen zu füllen.

Mach dir keine Sorgen um die Vergangenheit. Wenn ich die Situation richtig verstehe, ist AutoFixture im Moment tot im Wasser. Wenn niemand die Aufgabe übernimmt, sie voranzubringen, wird sich nichts ändern.

Damit kann man alle Fehler der Welt machen und wird es kaum noch schlimmer machen.

@ploeh Wenn du es so ausdrückst, würde ich mich freuen, als Betreuer aufzutreten, und ich hoffe, dass andere auch aufsteigen werden.

@aivascu Danke, das ist großartig.

Ich gebe den derzeitigen Betreuern und Hangarounds @zvirja , @moodmosaic , @adamchester , @ecampidoglio etwa 24 Stunden Zeit, um dies zu kommentieren, und wenn ich keine Proteste sehe, gebe ich Ihnen Betreuerrechte.

@ploeh Keine Einwände von meiner Seite.
@aivascu Willkommen an Bord. Ich hoffe, dieses Projekt bringt Ihnen den Spaß, den Sie suchen 😊

@aivascu Ich bin kein Betreuer, aber ich liebe diese Bibliothek. Rufen Sie mich einfach an, wenn Sie jemanden brauchen, der Ihre Gedanken widerspiegelt.

@ploeh , @aivascu , gut von mir :+1: :rocket:

Ich freue mich, über Teile der Codebasis zu diskutieren, an denen ich gearbeitet, erstellt oder beigetragen habe. Wenn ich einen Pull-Request (oder ein Problem) verpasst habe, in dem ich erwähnt wurde, lass es mich bitte wissen.

@aivascu Meine besten Wünsche an dich. Mein einziger Rat ist, dass es für jeweils 20.000 Codezeilen in einer Codebasis etwa 6 Monate dauern kann, insbesondere wenn es an einem Ort keine klaren "Architekturentscheidungsaufzeichnungen" gibt. Aus diesem Grund habe ich bei den Projekten, die ich betreue, damit begonnen, diese zu schreiben, damit die Leute den "Stil" des Codes verstehen. Mark hat diese geschrieben, aber hauptsächlich in seinem Blog und/oder StackOverflow. @moodmosaic hat dasselbe getan. Ich würde sagen, erstellen Sie in Zukunft einen adr -Ordner im Repo-Root, der alle Designgründe dokumentiert. Sie können dafür .md-Dateien verwenden. Verwenden Sie für komplexe Tabellen eher HTML-Tabellen als Markdown-Tabellen.

Vielen Dank für den herzlichen Empfang.
Ich denke, für den Anfang werde ich den Rat von @jzabroski befolgen und damit beginnen, die Lücken in der Dokumentation zu füllen, um das Onboarding neuer Betreuer und Mitwirkender zu erleichtern.
Parallel dazu kann ich vielleicht anfangen, den bestehenden Rückstand abzuarbeiten.
Hoffentlich werden sich mehr Community-Mitglieder melden, um dieses erstaunliche Tool weiterzuführen.

Herzlichen Glückwunsch @aivascu.

Ich glaube, Sie sind jetzt der leitende Entwickler. Ich sage das, weil ich das Gefühl habe, dass die Dinge in den 'toten' Zustand zurückkehren werden, den sie jetzt haben, sobald du aufhörst - also schaue ich dich jetzt an :)

Ich hoffe, dass das Autofixture-Team neue Teammitglieder „jagt“, um das Risiko des zuvor erwähnten Problems der einsamen Reise zu mindern. Ich leiste nur dann gerne einen Beitrag, wenn jemand einen Blick auf diese https://github.com/AutoFixture/AutoFixture/pull/1164 werfen könnte.

@aivascu Ich habe Ihnen eine Einladung geschickt, dem AutoFixture-Kernteam beizutreten, aber die Einladung steht noch aus.

@ploeh Ich habe gerade die Einladung angenommen. Danke schön!

@aivascu 👍 Willkommen im Team.

Wenn ich noch mehr tun kann, um Ihnen zu helfen, werde ich das gerne tun. Ich bin jedoch seit Jahren inaktiv an dem Projekt, daher weiß ich nicht mehr, wie einige der praktischen Dinge funktionieren. Ich hoffe, dass @zvirja Sie über diese Details informieren kann.

Danke schön!

Willkommen @aivascu

@aivascu Ich würde mich freuen, Sie in das Projekt aufzunehmen. Wenn es Ihnen nichts ausmacht, würde ich mich sehr über ein Gespräch mit Ihnen freuen, damit ich alles zeigen und die Fragen beantworten kann. Wenn Sie dazu bereit sind, schreiben Sie mir bitte eine Mail (Adresse finden Sie in den Commits), damit wir uns auf Details einigen können.

Und nochmals herzlich willkommen.

@zvirja das wäre wirklich schön. Ich schicke Ihnen eine E-Mail.

Willkommen @aivascu :+1:

Willkommen an Bord, @aivascu! 🙂

@aivascu Angesichts der Tatsache, dass Sie als neuer Maintainer voller Leidenschaft und Energie angetreten sind, um daran zu arbeiten, sollten wir dieses Problem einfach schließen und loslösen? Sozusagen, dass unsere Zukunft vorerst bestimmt ist? 😄

@zvirja Ich hatte irgendwie gehofft, jemand anderes würde darum bitten, die Reihen der Betreuer zu füllen. 😄

Wenn jemand das Gefühl hat, dass es ihm Spaß machen könnte, ein Betreuer für dieses Repository zu sein, öffnen Sie ein Problem oder schreiben Sie uns eine Nachricht.
Ich werde das Thema jetzt schließen.