Charta des CHAOSS-Projekts
Die Linux-Stiftung
CHAOSS – Community Health Analytics Open-Source-Software
Projektcharta (die „Charta“)
Gültig ab: 1. September 2017
Letzte Aktualisierung: März 15, 2019
Diese Charta legt die Verantwortlichkeiten und Verfahren für den technischen Beitrag zum CHAOSS – Community Health Analytics Open Source Software Project (das „Projekt“) innerhalb der Linux Foundation und die Aufsicht darüber fest. Mitwirkende am Projekt müssen die Bedingungen der Charta sowie alle anwendbaren Richtlinien der Linux Foundation einhalten.
1. Die Projektmission
Die Mission des Projekts ist:
-
integrierte Open-Source-Software zur Analyse der Softwareentwicklung und Definition von Standards und Modellen zu erstellen, die in dieser Software in bestimmten Anwendungsfällen verwendet werden;
-
Implementierungsunabhängige Metriken zur Messung von Community-Aktivitäten, -Beiträgen und -Gesundheit etablieren; und
- optional standardisierte Austauschformate für Metriken, detaillierte Anwendungsfälle, Modelle oder Empfehlungen zur Analyse spezifischer Probleme in der Industrie/OSS-Welt erstellen.
2. Leitungsgremium
-
Das Governance Board (das „GB“) ist für die Gesamtaufsicht über das Projekt und die Koordinierung der Bemühungen aller technischen Komitees und Arbeitsgruppen verantwortlich.
-
Zu Beginn des Projekts bestehen die stimmberechtigten Mitglieder des GB aus den auf der Projektwebsite (https://chaoss.community). Nach Beginn des Projekts wird der Vorstand Verfahren und Methoden für die Auswahl der stimmberechtigten Mitglieder des Vorstandes aus der beitragenden Gemeinschaft implementieren.
-
Das Präsidium fördert die Transparenz (z. B. Veröffentlichung öffentlicher Protokolle). Die Sitzungen der Ausschüsse und Arbeitsgruppen sind öffentlich und können elektronisch, per Telefonkonferenz oder persönlich abgehalten werden.
-
Der Vorstand ist befugt, Ausschüsse zu gründen, die sich auf kodifizierte oder nicht kodifizierte Bemühungen konzentrieren können, um die Mission voranzubringen (z. B. Standards, Spezifikationen und/oder Architektur). Die Ausschüsse des Projekts sind das „Software-Komitee“, das für die technische Überwachung von Inbound- und Outbound-Codierungsprojekten zuständig ist, und das „Metrics Committee“, das für die Sammlung von technologieunabhängigen Metriken und Standards verantwortlich ist, die vom Projekt entwickelt werden sollen, und das „Metrics Committee“. Der GB sorgt für die Koordinierung der Wechselbeziehung zwischen dem Software- und dem Metrik-Ausschuss.
-
Arbeitsgruppen werden von Projektmitwirkenden eingerichtet und unterhalten, um die Projektarbeit voranzutreiben. Arbeitsgruppen konzentrieren sich auf spezifische metrische, methodische, ethische und technische Fragen im Zusammenhang mit der Gesundheit von Open-Source-Projekten.
-
Rollen: Komitees und Arbeitsgruppen beinhalten Mitwirkende und Betreuer:
-
Mitwirkende: Jeder in der Community, der Code, Dokumentation, Anwendungsfälle, standardisierte Metriken oder andere Community-Aktivitäten im Zusammenhang mit dem Projekt beisteuert;
- Betreuer: Mitwirkende, die die Möglichkeit haben, sich direkt an das Repository eines Projekts zu binden und auf Beiträge oder Änderungen von Mitwirkenden reagieren. Betreuer sind in der README-Datei jedes Repositorys aufgeführt.
-
-
Die Teilnahme am Projekt, einschließlich Beiträgen zu Komitees oder Arbeitsgruppen, steht gemäß den Bedingungen dieser Charta allen offen.
-
Der Vorstand kann (1) Arbeitsablaufverfahren für die Einreichung, Genehmigung und Schließung/Archivierung von Komitees und Komiteeprojekten festlegen, (2) Anforderungen für die Beförderung in oder die Entfernung aus Komiteerollen festlegen, soweit zutreffend, und (3) ändern , die Rollen nach eigenem Ermessen anpassen, verfeinern und/oder eliminieren.
-
Der GB wählt jährlich einen GB-Vorsitzenden und einen GB-Co-Vorsitzenden aus Vertretern, die an einem oder beiden des Software- oder des Metrik-Ausschusses beteiligt sind, so dass sowohl der Software- als auch der Metrik-Ausschuss durch die Co-Vorsitzenden vertreten werden. Der Vorsitzende und der Co-Vorsitzende legen die Tagesordnung fest und leiten die Sitzungen des Präsidiums.
-
Verantwortlichkeiten: Der Vorstand ist auch verantwortlich für:
-
Koordinierung der Leitung des Projekts;
-
Erstellung von Projektrichtlinien, einschließlich für das Hinzufügen und Entfernen von Betreuern und Dokumentieren aller Anforderungen für offizielle Projektfreigaben (Software oder Metriken);
-
Genehmigung von Projekt- oder Systemvorschlägen (einschließlich, aber nicht beschränkt auf Inkubation, Ablehnung und Änderungen an der Charta oder dem Umfang eines Projekts);
-
Richtlinien in Bezug auf geistiges Eigentum festlegen;
-
Einrichtung von Ausschüssen, um sich auf projektübergreifende Themen und Anforderungen zu konzentrieren;
-
Erleichterung der Kommunikation und Zusammenarbeit zwischen den Ausschüssen;
-
Kommunikation mit externen und Branchenorganisationen in Bezug auf Projektangelegenheiten;
-
Ernennung von Vertretern zur Zusammenarbeit mit anderen Open-Source- oder Open-Standard-Communities;
-
Erstellung von Gemeinschaftsnormen, Arbeitsabläufen oder Richtlinien, einschließlich Prozessen für Beiträge (zur Veröffentlichung auf der Projekt-Website), Herausgabe von Freigaben und Richtlinien zur Meldung von Sicherheitsproblemen;
-
Diskussion, Suche nach Konsens und gegebenenfalls Abstimmung über Angelegenheiten im Zusammenhang mit Metriken oder der Codebasis, die mehrere Projekte betreffen; und
- Koordination von Marketing, Veranstaltungen oder Kommunikation mit der Linux Foundation.
-
3. GB-Abstimmung
-
Obwohl es das Ziel des Projekts ist, als eine auf Konsens basierende Gemeinschaft zu operieren, stimmen die jeweiligen stimmberechtigten Mitglieder mit einer Stimme pro stimmberechtigtem Mitglied ab, wenn eine Entscheidung des Vorstands oder des Ausschusses eine Abstimmung erfordert, um voranzukommen.
-
Die Beschlussfähigkeit für Präsidiums- und Ausschusssitzungen erfordert zwei Drittel aller stimmberechtigten Mitglieder des Präsidiums bzw. eines Ausschusses. Das Präsidium oder jeder Ausschuss kann weiterhin zusammentreten, wenn die Beschlussfähigkeit nicht erreicht ist, ist jedoch daran gehindert, auf der Sitzung Entscheidungen zu treffen. Wenn die Beschlussfähigkeit nicht erreicht wird, kann nach zwei Wochen eine zweite Sitzung mit der gleichen Tagesordnung einberufen werden, deren Beschlussfähigkeit 1/2 aller stimmberechtigten Mitglieder beträgt.
-
Außer wie in Abschnitt 8.b(iv) und 9.a vorgesehen, bedürfen Beschlüsse durch Abstimmung bei einer Versammlung der Mehrheit der Stimmen der Anwesenden, sofern das Quorum erreicht ist. Entscheidungen, die durch elektronische Abstimmung ohne Sitzung getroffen werden, bedürfen der Mehrheit aller stimmberechtigten Mitglieder des Präsidiums oder eines Ausschusses, soweit zutreffend.
- Falls eine Abstimmung innerhalb eines Ausschusses nicht entschieden werden kann, kann der Vorstand die Angelegenheit entscheiden. Für den Fall, dass eine Abstimmung nicht vom Vorstand entschieden werden kann, ist jedes stimmberechtigte Mitglied des Vorstands berechtigt, die Angelegenheit zur Unterstützung bei der Entscheidungsfindung an die Linux Foundation zu verweisen.
4. Kartellrechtliche Richtlinien
-
Alle Teilnehmer des Projekts müssen sich an die Antitrust Policy der Linux Foundation halten, die unter verfügbar ist http://www.linuxfoundation.org/antitrust-policy.
- Alle Teilnehmer sollten eine offene Teilnahme aller Organisationen fördern, die in der Lage sind, die Teilnahmevoraussetzungen zu erfüllen, unabhängig von Wettbewerbsinteressen. Anders ausgedrückt, die Community darf nicht versuchen, einen Teilnehmer aufgrund von Kriterien, Anforderungen oder Gründen auszuschließen, die nicht angemessen sind und auf nicht diskriminierender Basis für alle Teilnehmer gelten.
5. Verhaltenskodex
-
Der GB kann mit Zustimmung der Linux Foundation einen fairen, angemessenen und nicht diskriminierenden Verhaltenskodex für das Projekt annehmen, wie unten beschrieben.
-
Das Projekt wird jederzeit transparent, offen, kooperativ und ethisch einwandfrei arbeiten.
-
Die Ergebnisse aller Projektdiskussionen, Vorschläge, Zeitpläne, Entscheidungen und Status werden offen und für alle leicht sichtbar gemacht.
- Den aktuellen Verhaltenskodex des Projekts finden Sie unter (https://chaoss.community/about-2/code-of-conduct/).
6. Budget und Finanzierung
-
Das GB wird jeglichen Budget- oder Finanzierungsbedarf mit der Linux Foundation koordinieren. Teilnehmende Organisationen können gebeten werden, Projektaktivitäten und Infrastrukturbedarf auf freiwilliger Basis zu sponsern.
-
Das Projekt wird keine Gelder aufbringen und wird auf freiwilliger Basis von den Projektteilnehmern unterstützt.
- Unter keinen Umständen wird von The Linux Foundation erwartet oder verlangt, dass sie im Namen des Projekts Maßnahmen ergreift, die mit dem steuerbefreiten Zweck von The Linux Foundation unvereinbar sind.
7. Allgemeine Regeln und Abläufe
Das Projekt sollte:
-
sich in professioneller Weise an der Arbeit des Projekts zu beteiligen und dabei eine kohärente Community aufrechtzuerhalten und gleichzeitig den guten Willen und die Wertschätzung der Linux Foundation in der Open-Source-Software-Community aufrechtzuerhalten;
-
die Rechte aller Markeninhaber respektieren, einschließlich aller Marken- und Nutzungsrichtlinien;
-
Beauftragung der Linux Foundation für alle Presse- und Analystenaktivitäten des Projekts;
-
auf Anfrage Informationen zur Projektteilnahme, einschließlich Informationen zur Teilnahme an vom Projekt gesponserten Veranstaltungen, an The Linux Foundation weitergeben; und
- Abstimmung mit The Linux Foundation in Bezug auf Websites, die direkt für das Projekt erstellt wurden.
8. Richtlinie zum geistigen Eigentum
-
Das Projekt versucht, andere Open-Source-Projekte innerhalb der in Abschnitt 1 oben dargelegten Mission zu integrieren und zu ihnen beizutragen. Das Projekt versucht auch sicherzustellen, dass relevante patentierbare Innovationen verfügbar gemacht werden, ohne dass Patentlizenzen erforderlich sind. Basierend auf diesem Ziel für das Projekt wird die Entwicklungsgemeinschaft:
-
alle Lizenzanforderungen der vom Projekt genutzten Open-Source-Projekte erfüllen (solche Projekte zusammen „Upstream-Projekte“); und
- Maximierung der Möglichkeiten zur Kompatibilität mit anderen Projekten, die vom Projekt genutzt werden könnten.
-
-
Außer wie in Abschnitt 8.c beschrieben, unterliegen alle Code-Beiträge zum Projekt dem Folgenden:
-
Alle neuen eingehenden Codebeiträge müssen von einem Entwickler-Ursprungszertifikat begleitet werden (http://developercertificate.org)
-
Alle Codebeiträge werden unter der GNU General Public License, Version 2 oder höher, oder Version 3 oder höher, empfangen und zur Verfügung gestellt.
-
Alle Beiträge zu implementierungsunabhängigen Metriken und Standards, einschließlich zugehöriger Skripte, SQL-Anweisungen und Dokumentation, werden entgegengenommen und unter der MIT-Lizenz (https://opensource.org/licenses/MIT).
- Der Vorstand kann ausnahmsweise die Verwendung einer alternativen Lizenz für eingehende oder ausgehende Beiträge genehmigen. Ausnahmen bedürfen einer Zweidrittel-Zustimmung des gesamten GB.
-
-
Codebeiträge des Upstream-Projekts, die nicht im Hauptcode-Repository des Projekts gespeichert sind, müssen dem Beitragsprozess und den Lizenzbedingungen für das entsprechende Upstream-Projekt entsprechen
- Das Projekt kann The Linux Foundation beauftragen, die Verfügbarkeit von Warenzeichen und Dienstleistungsmarken, die Eigentum der Linux Foundation sind, zu ermitteln und zu registrieren. Alle projektbezogenen Domainnamen und Warenzeichen sind Eigentum von The Linux Foundation und alle bereits bestehenden projektbezogenen Domainnamen oder Warenzeichen sind zur Verwendung durch das Projekt an The Linux Foundation zu übertragen.
9. Änderungen
- Diese Charta kann mit einer Zweidrittelmehrheit des gesamten Vorstands geändert werden, vorbehaltlich der Genehmigung durch die Linux Foundation, um sicherzustellen, dass die Änderung mit den Anforderungen der Gemeinnützigkeit und den Prinzipien von Open Source in Einklang steht.