11. Offene SkoHub-Entwicklungstreffen

Alle SkoHub-Nutzer:innen und potentielle Beiträger:innen sind herzlich eingeladen! Wir werden anhand des SkoHub-Kanban-Boards gemeinsam den aktuellen Stand und nächste Schritte besprechen.

Notizen zum Treffen

:information_source: Dieser Beitrag ist ein Wiki und kann somit von den Teilnehmenden ergänzt angepasst werden.

Anwesende

@acka47
@phu
@steffen_roertgen

Entwicklungsplanung

Wir haben zunächst das Kanban Board](SkoHub · GitHub) aktualisiert. Oberste Priorität hat das Code-Review der SkoHub- Reconcile-PRs (skohub-reconcile#38, skohub-reconcile-publish#24). Sobald das erledigt ist, kann @phu auch diesen Dienst auf die neue VM umziehen.

LLM Policy

@acka47 hat das Thema Nutzung von Large Language Models (LLMs) in der SkoHub-Entwicklung aufgebracht: In der Vergangenheit wurde bereits Code, Commit-Nachrichten und PR-Texte von LLMs verfasst, wir haben aber nie darüber gesprochen, wie wir damit im Projekt umgehen wollen und welche Grenzen des LLM-Einsatzes es gibt. In diesem Treffen stiegen wir in ein Gespräch darüber ein, ohne direkt Entscheidungen treffen zu wollen. ir waren uns einig, dass wir mittelfristig die CONTRIBUTING.md um einen entsprechenden Abschnitt zur NUtzung von LLMs ergänzen sollten.

Zunächst haben wir uns darüber ausgetauscht, wie es bisher genutzt wird, bzw. inwiefern das Thema die an der SkoHub-Entwicklung Beteiligten beschäftigt.

  • @steffen_roertgen nutzt bisher Claude, möchte aber perspektivisch mehr Open-Weight-Modelle nutzen und die Abhängigkeit von kommerziellen Modellen abbauen.
  • Bei Kimi steht er auf der Warteliste und hat neuerdings auch Zugriff auf die Modelle der GWDG. Er füttert dem LLM das Issue und tauscht sich danach zur Implementierung aus.
  • Jeder Pull Request wird vorher auf Code-Ebene angeschaut. PR und Commit Messages werden von Claude entworfen und dann von Steffen überarbeitet und gekürzt.

  • @acka47 hat sich als Gruppenleitung gegen die Nutzung kommerzieller Modelle in der Software-Entwicklung ausgesprochen.
  • Stattdessen hat er die Beschaffung eines KI-Servers angeleiert zum Betrieb von Open-Weight-Modellen (bisher qwen) für das LLM-gestützte Programmieren.
  • Er hat im Kontext der SWIB-Konferenz mit der Entwicklung einer KI-Policy zu tun (siehe Working towards an AI policy for SWIB: an appeal to the SWIB community - General - SWIB Forum, der Entwurf einer SWIB-KI-Policy wird bald veröffentlicht), wo es auch Talk-Einreichungen gab, die mit LLM entwickelte Software-Tools behandeln.
  • Als Richtlinie für die LLM-gestützte Entwicklung empfiehlt er die Recommendations When Using LLM-backed Generative AI Systems for FOSS Contributions.
  • Er hatte bisher eine Aversion gegen die Nutzung von LLM-generierten Texten in Mensch-zu-Mensch-Kommunikation und kann gut den entsprchenden Passus im Forgejo AI Agreement nachvollziehen:

    All communication, that includes: commit messages, pull request messages, documentation, code comments and issues (and comments on issues/pull requests), that is intended to be read by people to understand your thoughts and work must not have been generated with AI. We exclude machine translation and tooling that helps with grammar and spelling check.

  • Zunehmend fragt er sich, ob diese Aversion für PRs und Commit Messages genauso berechtigt ist wie für z.B. E-Mails. Für Dokumentation und das spätere Nachvollziehen von PRs, ihrem Kontext etc. können die ausführlichen LLM-generierten Kommentare ja durchaus nützlich sein.

  • @phu hat auch bereits LLMs für Skripte, aber auch für die Unterstützung bei SkoHub-PRs genutzt. Er bestätigt, dass die durch ein LLM ergänzten Kommentare – auch in Skripts – häufig sehr gut sind und das Ergebnis besser, als wenn man sie wegließe.

Markierung von LLM-unterstützten Commits

Bisher wurden SkoHub-Commits, die mit LLM-Unterstützung entstanden sind, selten bis nie entsprechend markiert. Auch gab es keine gesonderten Konten für KI-Coding-Assistenten. Von gesonderten Konten sehen wir weiterhin ab. Wir haben uns aber darauf geeinigt, in Zukunft entsprechende Commits zu markieren. Dabei orientieren wir uns an den Vorgaben für den Linux Kernel, die so aussehen:

When AI tools contribute to kernel development, proper attribution helps track the evolving role of AI in the development process. Contributions should include an Assisted-by tag in the following format:

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Where:

  • AGENT_NAME is the name of the AI tool or framework
  • MODEL_VERSION is the specific model version used
  • [TOOL1] [TOOL2] are optional specialized analysis tools used (e.g., coccinelle, sparse, smatch, clang-tidy)

Basic development tools (git, gcc, make, editors) should not be listed.

Example:

Assisted-by: Claude:claude-3-opus coccinelle sparse

Claude gibt ohnehin schon etwas sehr Ähnliche raus, z.B.: Co-authored by: Claude Fable 5

Lizenz

Die Recommendations When Using LLM-backed Generative AI Systems for FOSS Contributions empfehlen unter Punkt 10.) aus rechtlichen Gründen „‚Copyleft Everything‘ remains the best viable and safest approach“. Es gab einen ersten Austausch über einen mögliche Umstieg der SkoHub-Lizenz von Apache auf AGPL. Wir werden das Thema in künftigen Treffen wieder aufnehmen.

Nächster Termin

Das nächste Treffen findet am 23.9. um 9 Uhr statt: 12. Offenes SkoHub-Entwicklungstreffen