Skip to content

TSC

What: AI Guideline for ALASCA/Governance Organizer: Josephine Seifert, Christian Berendt

Attendees:

  • Josephine Seifert
  • Martin Mai
  • Robert Holling

AI Policy Discussion

Ziel: Wir wollen unsere Projekte (gegen Lizenz-Streitigkeiten aufgrund von KI-Nutzung) und unsere Maintainer/Developer (gegen Überlastung) schützen!

vlt. größer denken: Contributing Guideline

  • Reports, MR, PR nur von Menschen ?
    • was machen wir mit Projekt-Bots?

TSC + Projects Discussion: PRs / Merge Requests von Bots / AI

Bestandsaufnahme: Gab solche Anfragen schon in euren Projekten? Wie seid ihr damit umgegangen?

  • alle Projekte hatten sowas nocht nicht -> noch keine vollständig automatisierten PRs/MRs von Bots

  • Wir brauchen AI-Policy (beschreibt Idealzustand) <- wichtig für Reviewer/Maintainer:

    • Jonas Vorschlag: https://gitlab.redox-os.org/redox-os/redox/-/blob/master/CONTRIBUTING.md#ai-policy -> sehr streng; alles rejecten
    • OpenInfra: https://openinfra.org/legal/ai-policy
    • vlt Differenzierung nach unterschiedlichen Klassen: simpler Bug-fix --- Feature --- Architektur-Umstrukturieren
    • Beinhaltet auch Issues/Bug Reports -> wollen wir damit anders umgehen?
    • reale Menschen müssen Issues/Bug-Reports und MRs/PRs öffnen und validieren (wichtig!)
      • KI-generierte Inhalte von PRs/MRs?
      • Teilerstellung /Hilfe durch KI?:

        - Ivan: Source of Code weniger wichtig als Funktion / Sinn des Codes

    • DDoS durch automatische PRs/MRs möglich -> was machen wir dagegen? -> automatisches Blocken solcher Accounts? oder Whitelisting?

  • moralische Dimension: Ki lernte durch "geklauten" Code

  • rechtliche Bedenken: Wie sieht das mit der IP aus? Wie sieht das mit den Lizenzen aus?
  • Maintainer-Zeit: ist wertvoll, wir wollen sie nicht auf "irgendetwas" verschwenden
  • Pre-Screening? -> techninsche Llösung wäre unzuverlässig -> daher ungünstig
  • TODO: Diskussion / Bestandsaufnahme mit den Projekten

from OpenStack PTG:

  • PRs/MRs (not easy to review for big patches)
  • automated reviews

  • AI-Bug-Reports (absolut number of bug goes up, may they be valid or not -> currently still a lot of AI-Slop)

    • bug triage still done through people -> much increased overhead

  • number goes up -> heavy load on maintainers; vulnerability management

  • upgrades because of Dependencies also getting that much of security bugs, etc...

  • creating features is easier, but working on infrastructure, security bug triage, etc. has become much much harder

  • crawler ddos might be incoming also for yaook

  • people don't want ppl to burn out... but what about machines?... they will not care.

-> open source not only code but also infrastructure (hosting, pipelines, etc..)

  • rechtliche komponente: sind die codelizenzen damit kompatibel, was die LLM AGBs sagen?

  • Man wird Leute verlieren, wenn man solche agents.md in die Repos passt

    • aber KIs können davon stark profitieren und weniger Slob produzieren

AI Policy / Contribution Policy

Präambel

Warum wir KI-Nutzung regulieren wollen:

  • Wir wollen die Arbeitslast für Reviewer und Maintainer in einem angemessenen Rahmen halten.
  • Wir wollen, dass Contributor ein Verständnis für die Projekte und den Code aufbauen und sich ihrer Verantwortung in ihren Beiträgen bewusst sind.

  • Dadurch erwarten wir eine Sicherung der Code Qualität und der Wartbarkeit des Codes.

  • Wir wollen sicherstellen, dass Urheberrechts- und Lizenz-Problematiken bei KI-Nutzung vermieden werden.

  • Der Energieverbrauch von KI sowohl durch dass Lernen, wie auch durch das Generieren ist nicht zu vernachlässigen.

Policy

Diese Policy gilt für alle ALASCA Projekte, sofern sie nicht durch eine Projekt-eigene KI-Richtlinie ersetzt oder ergänzt wird.

Sämtliche Interaktionen (Reports, MRs, PRs) müssen, mit Ausnahme von Projekt-internen Bots, durch Menschen getätigt werden.

Diese Contributor müssen ihre Beiträge verstehen und getestet (Code) beziehungsweise für Reviewer nachvollziehbar geprüft (Bug Reports) haben. Sie versichern außerdem, dass keine Lizenzen durch ihre Beiträge verletzt werden.

KI-generierte Beiträge genügen nicht diesen Anforderungen und werden daher abgelehnt.

KI-assistierte Inhalte müssen als solche gekennzeichnet werden. (AI generated content must be marked as such)

Accounts, die der Policy zuwider handeln, werden geblockt.

Infrastruktur von ALASCA gegen KI absichern?

Anfang des Jahres DDoS auf OpenStack Docs -> könnte auch unsere Projekte treffen.

Governance von ALASCA Projekten

Link: https://gitlab.com/alasca.cloud/governance/governance/-/blob/main/docs/alasca/tsc-guidelines.md?ref_type=heads

Projekt Governance

Was bedeuten Rollen:

Projektvertreter:

  • verantwortlich für das Projekt:
    • Ansprechpartner für TSC, Vorstand, etc.
    • Information von extern in Team und umgedreht streuen
    • Organisation von Meetings; Anbieten von Office Hours -> Kommunikation hier: https://docs.alasca.cloud/
    • Rollenvergabe an Contributor (Wer ist Maintainer, wer Developer?)
    • Aufnahme und Löschung von Accounts (Contributor) -> Account- und Rechteverwaltung von Nutzern innerhalb des Projekts
    • Festlegung, wie ein Contributor eine Rolle bekommt
    • NICHT verantwortlich für kompletten Überblick über den Code
    • Security Issues: Bestimmung eines verantwortlichen Maintainers oder Contributors

Contributing guideline

  • Jedes Projekt sollte eine haben oder unsere zu definierende verlinken
  • darin muss stehen, ob die KI-Richtlinie übernommen wird
  • Welche rollen es gibt (Developer Maintainer, owner, blablabla)
  • Für owner (evtl. auch maintainer) MUSS 2FA eingerichtet werden
    • da maintainer nicht löschen dürfen, wäre
  • Wo sollen Security Issues reported werden? -> Need to know Prinzip !!!!!!!!!! (GITLAB MACHT ES UNS UNNÖTIG SCHWER!!!!)
  • code of conduct verlinken
  • projekt-spezifische Dokumentation verlinken
    • setup test-environment
    • developer documentation