Wie gehe ich mit einem schwierigen Programmierer um, der sich einem Open Source-Projekt anschließt?

Ich habe ein Open-Source-Skript für eine bestimmte Site (ich versuche, hier nichts beim Namen zu nennen), das ich und einige andere Entwickler kürzlich zu GitHub verschoben haben. Seit wir auf das neue System umgestiegen sind, haben wir mehrere neue Entwickler bekommen, darunter einen sehr aktiven. Dieser Aktive hat jedoch begonnen, einen Großteil des Projekts zu verändern.

Zuerst hat er unser Versionssystem gelöscht (nicht wie Git, aber so - wir haben es Versionen genannt v4.1.16) und gesagt, es wäre besser, den Code einfach auf die Site zu pushen, wenn wir glauben, dass es fertig ist. Jetzt gibt es keinen zentralen Ort, an dem Versionshinweise abgelegt werden können, was ärgerlich geworden ist.

Das Ding, das mich fast fertig gemacht hat, meine Koffer zu packen und zu gehen, war das Push-Skript. Ein anderer Entwickler des Projekts schrieb ein einfaches Python-basiertes Push-Skript. Da wir an verschiedenen Stellen mehrere Versionen des Skripts online halten, begann ich, ein größeres Java-Programm mit einer grafischen Oberfläche zu programmieren, die das Python-Skript ersetzen wird. Ich ging in das IRC, um alle darüber zu informieren, und der Programmierer antwortete sehr ärgerlich, dass das alte Skript auf Python-Basis alles kann, was ich kann und so viel leichter ist (er kommentierte auch die Tatsache, dass er dachte) Python war besser als Java und so weiter. Ich überflog den Code für das alte Push-Skript und stellte fest, dass keine der von ihm genannten Funktionen vorhanden war.

Jetzt möchte ich wissen, was ich tun soll. Ich habe viel Zeit mit diesem Projekt verbracht, also möchte ich nicht einfach aufstehen und gehen, aber es fällt mir schwer, mit diesem neuen Entwickler zusammenzuarbeiten. Auf der anderen Seite ist er jetzt der # 1 Committer im Projekt, mit noch mehr Commits als der Hauptentwickler. Ich bin mir nicht sicher, was ich dagegen tun soll. Hat jemand anderes dieses Problem erlebt? Wenn ja, was hast du gemacht?

UPDATE 1 : Ich habe den Commit-Zugriff aller Benutzer deaktiviert und fordere die Benutzer auf, Pull-Anforderungen zu bearbeiten. Ich schlug auch verschiedene Maßnahmen vor, um die anderen Probleme zu beheben. Alle anderen haben keine Unterstützung dafür gezeigt. Der lästige Entwickler hat einfach gesagt, dass Leute, die die "Commit-Aktion" nicht genau verfolgen, denken können, dass das Projekt desorganisiert ist, wenn es wirklich nicht so ist. Ich stimme dem offensichtlich nicht zu, daher denke ich ernsthaft darüber nach, von dem Projekt zurückzutreten.

UPDATE 2 : Der leitende Entwickler begann sich darüber zu ärgern, dass einer meiner Commits angeblich drei neue Zeilen im Code löschte (das Revert Commit wurde direkt nach dem Posten der Diskussion angezeigt und bezieht sich nicht einmal auf mein "Commit"), und dann Die beiden begannen zu diskutieren, ob sie meinen Commit-Zugriff widerrufen sollten. Also habe ich das Logische getan und das Projekt verlassen. Vielen Dank für Ihre Hilfe!

1. Sie können aufhören. Dies ist nicht das Konstruktivste, aber manchmal die einzige Option. Wenn Sie dies tun, sitzen Sie nicht herum und jammern Sie darüber, wie Sie es aufgeben mussten, nehmen Sie diese Energie auf und stecken Sie sie direkt in etwas anderes - mit anderen Worten, machen Sie weiter.

2. Sie können es gabeln. Es gibt keinen Grund, warum Sie mit jemandem arbeiten müssen. Fork, verbessere den Code und lass die anderen weiterhin ein kleines Ego-Fest für sich haben. Ihr neues Projekt wird einfach mit dem alten konkurrieren und es liegt an Ihnen, ob Sie es zum Erfolg führen oder ob Sie das alte Projekt in Bezug auf Benutzer und Funktionen übertrifft.

3. Sie können sich mit dem Rest des Entwicklungsteams an dem Projekt beteiligen, um Ihre Bedenken auszudrücken. Machen Sie es nicht persönlich, sondern stellen Sie fest, dass Sie mit der Abwanderung von Code oder dem Mangel an etablierten Qualitätsprozessen unzufrieden sind oder dass die neuen Entscheidungen nur ohne die Zustimmung aller getroffen werden. Entweder wird Ihnen gesagt, dass nichts falsch genug ist, um sich zu ändern, oder einige andere stimmen Ihnen zu, dass das Team die Dinge regeln muss. Das könnte dazu führen, dass der Störer seinen Commit-Zugriff verliert. Vielleicht sind Sie sich alle einig, dass einige der Änderungen keine Verbesserungen sind und das Projekt zurückgesetzt werden muss. (Diese letztere Option ist das wahrscheinlichste Ergebnis, es sei denn, sie wird zu einem massiven Argument fester Meinungen.)

Es kann schwierig sein, wenn jemand vorbeikommt und die sicheren und bequemen Routinen ändert, an die Sie sich gewöhnt haben, aber man könnte sagen, dass es an sich gut ist, jemanden zu haben, der die alten, gemütlichen Praktiken aufmischt.

Sie haben es ein wenig unklar gemacht, welche Rolle Sie hier spielen. Die Antwort hängt davon ab, wie Sie passen.

Wenn Sie das Projekt leiten und das Git-Repository kontrollieren

Übernimm die Kontrolle zurück. Wenn dieser Typ Commits macht, die Sie nicht mögen, ohne Sie zu befragen, entfernen Sie seinen direkten Commit-Zugriff. Er kann das Projekt verzweigen und Pull-Anfragen stellen, um seine Commits zusammenzuführen. So sollte Open Source funktionieren, bis ein Benutzer Vertrauen aufbaut. Sie müssen und sollten nicht sofort vollen Zugriff gewähren.

Wenn jemand anderes das Repo kontrolliert

Bringen Sie Ihre Bedenken gegenüber der Person zum Ausdruck, die dies tut, und fördern Sie einen disziplinierteren Prozess für die Planung und Genehmigung von Änderungen. Wenn die Führung für einen Prozess nicht zugänglich ist, können Sie den Status Quo akzeptieren und weiterhin Beiträge leisten, das Projekt teilen und an Ihrer eigenen Version arbeiten (und jeden mitbringen, der mit Ihnen einverstanden ist), oder Sie können wählen, zu gehen und an anderen Dingen arbeiten. In jedem Fall müssen Sie sich nicht weiter darum kümmern.

Bitte verzeihen Sie meine Stumpfheit, aber Ihr Beitrag liest sich wie ein Scherz.

Sie sagen, es ist der andere, der sinnlose Veränderungen will, aber dann widersprechen Sie sich selbst, wenn Sie über Ihr neues, glänzendes Java-Programm sprechen.

Mach eine Pause; Es ist keine Einbahnstraße, bitte versuchen Sie, Kompromisse zu finden (wenn Sie weiter an dem Projekt arbeiten möchten - Gabelung ist die einfachste Entscheidung, führt Sie jedoch nicht zu nützlichen Zielen, obwohl es Ihr Ego streicheln kann).

Denken Sie auch gründlich über die Arbeitsteilung im Projekt nach - Rasenkriege sind unvermeidlich, wenn Sie keine klaren Grenzen haben, die Ihnen sagen, wer in was kompetent ist . Ja, manchmal muss man dem Urteil anderer vertrauen.

In mehreren Antworten wurde bereits erwähnt, dass Arbeitsteilung eine Möglichkeit ist, Konflikte zu reduzieren. Hier einige konkrete Beispiele:

1. Gleichgewicht zwischen Produktivität und Stabilität. Um eine Analogie aus Strategiespielen auszuleihen, muss ein Team aus einer Mischung aus Boom, Turtle und Rush bestehen , und Teamkollegen müssen bereit sein, die Rollen als Reaktion auf die Situation zu wechseln.
   • Wenn jemand in einer Produktivitätsbegeisterung steckt, können andere daran arbeiten:
   • Andere Eigenschaften
   • Bugfixing
   • Spezifikationen (Verwaltung neuer Funktionsanforderungen und Überprüfung, ob die Software die vereinbarten Kriterien erfüllt)
   • Qualitätskontrolle
     • Manuelle (Erkundungs-) Prüfung
     • Automatisiertes Testen
   • Dokumentation
   • Refactoring und Codebereinigung
   • Führen Sie Benutzerstudien durch, um Ideen für Verbesserungen zu sammeln
   • usw.
2. Ein Projekt kann modularisiert (wie in der Softwarearchitektur) oder sogar unterteilt (wie in der Projektverwaltung) werden, sodass jedes Modul unabhängig bearbeitet werden kann.
   • Im Allgemeinen sollten die meisten Programme, die sowohl ein Front-End als auch ein Back-End enthalten, modularisiert werden, da sie unterschiedliche Entwicklungsgeschwindigkeiten aufweisen.
   • UX-reiche Software lässt sich möglicherweise nur schwer modularisieren, da sie häufig modulübergreifendes Ereignisrouting verwendet.
   • Der Projektbetreuer möchte das Projekt möglicherweise einfach halten, indem er die Modularisierung vermeidet.
3. Feature-Zweig . Jeder Entwickler kann das Projekt teilen, an seinem Lieblingsfeature für Haustiere arbeiten und die Zusammenführung anfordern, wenn die Implementierung abgeschlossen ist. Der Hauptentwickler kann das letzte Wort haben, ob er die Zusammenführung akzeptiert.

Abgesehen vom Aspekt der Konfliktvermeidung ist offensichtlich, dass das Projekt möglicherweise keine ausreichende Governance aufweist .

Warum ist Governance wichtig? Stellen Sie sich vor, eines Tages hat ein ehemaliger Teamkollege ein Stück der Software genommen und das Team wegen Verstoßes verklagt. Oder das Team, das von Patent Troll verklagt wurde. Oder ein Unbekannter hat beschlossen, DMCA-Benachrichtigungen an die Hosting-Site des Projekts zu senden und den Quellcode des Projekts zu löschen.

Zumindest:

• Die Lizenz, die von allen zur Verfügung gestellten Quellcodes verwendet werden soll
• Die Lizenz (en), unter denen der Quellcode des Projekts veröffentlicht werden kann
  • Wenn eine neue öffentliche Lizenz beantragt wird, wie Sie die Zustimmung jedes Mitwirkenden erhalten können
• Wer kann administrativen Zugriff auf das Projekt haben?
• Wer wird für die Beantwortung von rechtlichen Anfragen bestimmt (z. B. DMCA-Mitteilungen oder Patenttrolle)?
• Wer verwaltet die Finanzierung für das Projekt (Übernahme der Serverausgaben und Buchhaltung der Werbeeinnahmen oder Spenden)
• Wer hat das Stimmrecht, neue Mitglieder aufzunehmen und Mitglieder auszuschließen.
• usw.

Die meisten Open-Source-Projektwebsites bieten fertige Chartas zur Projektsteuerung.

Ich habe das Problem schon einmal gesehen. Aber nach ein paar Jahren wird man des Projekts wirklich müde, und meine Lösung bestand darin , das Projekt zu verlassen . Es funktioniert vielleicht nicht für Sie, aber das Problem ist grundsätzlich, dass verschiedene Menschen auf unterschiedliche Weise denken. Funktionen, die Sie für sehr wichtig halten, sind für andere Menschen überhaupt nicht wichtig.

Ein guter Plan wäre es, die Aufgaben verschiedener Personen zu teilen . Wenn Sie mit den Personen übereinstimmen können, welcher Teil des Projekts in der Verantwortung jeder Person liegt, trifft nur eine Person Entscheidungen über einen bestimmten Teil des Projekts. Teamwork ist aber immer schwierig. Sie werden die Entscheidungen, die andere Programmierer getroffen haben, immer noch nicht mögen. Die beste Lösung besteht darin, sich nie anzuschauen, was andere Programmierer beschlossen haben. Vertraue einfach darauf, dass sie das Richtige tun.

Gemeinsames Ziel wird Ihre Bemühungen auf das Wichtige konzentrieren. Jeder, der in die gleiche Richtung arbeitet, ist schwer zu bekommen, und Konflikte werden sowieso passieren. Um ein gemeinsames Ziel zu bestimmen, muss der aktuelle Status des Projekts bekannt sein und nach einiger Zeit entschieden werden, wo es sich befinden muss.

Hier ist ein Beispiel für Dinge, die vermieden werden sollten: Beispielsweise glauben viele C ++ - Programmierer, dass Code, der keine STL-Bibliothek verwendet, fehlerhaft ist. Andere Programmierer glauben, dass jede Abhängigkeit von externen Bibliotheken, einschließlich STL, zerstört ist. Solche Konflikte können einfach nicht richtig gelöst werden - beide Situationen können nicht gleichzeitig erfüllt werden - und die problematischsten Menschen werden ihre Meinung vertreten, egal auf welche Opposition sie stoßen.

Vier Möglichkeiten, würde ich meinen.

1. Schmeiß ihn raus. Du bist (angeblich) immer noch der Hauptdarsteller in diesem Projekt; widerrufen seine Push-Privilegien und nennen es einen Tag. Das wahrscheinlichste Ergebnis ist, dass er das Projekt forkt, seine Gemeinschaft spaltet und dann ein Krieg ausbricht, und wenn sich der Staub gelegt hat, wird eine der Gabelungen die populäre sein.
2. Gabeln Sie es und fahren Sie woanders fort. Weniger aggressiv als 1., aber die Folgen sind ansonsten gleich. Sie müssen jedoch in der Community aktiv sein, um die Leute an Ihre Seite zu ziehen.
3. Lassen Sie es sein: Lassen Sie ihn einfach tun, was er tut, beruhigen Sie sich und hoffen Sie auf das Beste.
4. Diskutieren Sie mit der Community, gehen Sie bei Bedarf Kompromisse ein und lösen Sie die Situation.

Ich persönlich bevorzuge Option 4.

Google hatte vor ein paar Jahren ein paar technische Gespräche darüber. Beobachte sie:1 ,2 . In einer Nussschale:

1. Begreifen : Verstehen Sie Ihre Gemeinde , die Motivation für Ihr Projekt vs alle anderen Opportunitätskosten zu arbeiten, und diese Gründe zu bewahren.
2. Stärken : Bauen Sie eine gesunde Gemeinschaft mit sozialen Normen wie Höflichkeit, Respekt, Vertrauen und Demut auf.
3. Identifizieren : Suchen Sie nach verräterischen Anzeichen giftiger Menschen (zu viele, um sie aufzulisten, aber wenn Sie diese Frage stellen, kennen Sie wahrscheinlich bereits viele von ihnen).
4. Desinfizieren : Seien Sie ruhig und behaupten Sie sich, reagieren Sie nicht auf Beleidigungen, Beleidigungen, Herausforderungen, Missachtung usw. und setzen Sie sich beharrlich für die Einhaltung Ihrer Gemeinschaftsnormen ein.

Eine umfassende schriftliche Übersicht ist ebenfalls verfügbar, wenn Sie lieber lesen als zuschauen möchten.

Sie können nicht einfach aufhören, ohne sich Mühe zu geben, Ihre Bedenken und Schwierigkeiten auszudrücken. Ich weiß, dass es schwierig sein kann. Wenn Sie und Ihre Teammitglieder jung genug sind, um nicht aus erster Hand viele soziale Probleme zu erleben, die in einem Entwicklungsteam auftreten, kann dies sehr schwierig sein.

Ich bin jedoch der festen Überzeugung, dass Sie Ihre Bedenken zum Ausdruck bringen sollten. Sie können sie in die E-Mail schreiben und Ihren vertrauenswürdigen Freunden zeigen, die nicht zum Team gehören und kein oder nur geringes Interesse an Ihren Aktivitäten haben. In diesem Fall erhalten Sie möglicherweise ein gutes Feedback, damit die Formulierung Ihrer E-Mail nicht zu hart ist. Halten Sie sich jedoch an die Fakten. Nicht beschuldigen oder beschuldigen. Nur Fakten, dass es schwierig ist, etwas für Sie zu tun, weil "bla" fehlt. Warum 'blah' fehlt, sollte jedem Teammitglied klar sein, dh "der neue Programmierer" hat etwas gelöscht oder nicht erreicht.

Auch hier ist das Senden dieser E-Mail schwierig, aber das allein ist eine großartige Erfahrung, die für Sie in Zukunft sehr nützlich sein kann. Tolle Lektion zum Lernen.

PS: Ich wollte nicht zu elterlich klingen. Allerdings ist es in der Tat etwas, was ich jedem sagen würde, auch meinen Kindern.