Zusammenfassung

  • Der W3C Process verlangt bei bereits eingetretenen Folgen einer aufgehobenen Entscheidung eine angemessene, rechtzeitige Abhilfe. Die stattgegebenen Teile des Einspruchs gelten bis dahin nicht als vollständig bearbeitet. Ein öffentlicher Nachweis dieses Zustandswechsels ist nicht festgelegt.
  • Im Fall der Vibration API gab es erkennbare Nacharbeit; der Implementierungsbericht wurde später abgeschlossen. Dennoch muss die Wirkung über Council-Bericht, technische Issues, Charterakten und Pull Requests rekonstruiert werden.
  • Eine versionierte Abhilfe-Verwahrungsakte sollte die unverbindliche Empfehlung des Council von der Entscheidung des zuständigen Organs trennen und jeden stattgegebenen Punkt mit Verantwortlichem, Befugnis, Termin, Evidenz und datierter Abschlussfeststellung verbinden.

Der Beschluss endet, seine Folgen nicht

Der W3C Council entscheidet über Formal Objections, die sich nicht auf dem üblichen Konsensweg erledigen ließen. Er bestätigt oder hebt die angegriffene Entscheidung auf. Die Einwände, welche die Aufhebung tragen, sind die stattgegebenen Teile.

Damit ist die institutionelle Arbeit nicht zwingend beendet. Eine Entscheidung kann bereits Text in ein veröffentlichtes Dokument gebracht, den Status einer Spezifikation verändert oder Charterarbeit ausgelöst haben. Eine Aufhebung nimmt der Entscheidung ihre Autorität; sie löscht die Folgen nicht aus der Welt.

Deshalb enthält der Process eine zweite Stufe. Der Council soll mögliche Abhilfen vorschlagen. Das Team ist dafür verantwortlich, dass zuständige Stellen angemessene Maßnahmen rechtzeitig umsetzen. Bis dahin gelten die stattgegebenen Aspekte nicht als vollständig bearbeitet.

Der Text schafft einen offenen Zustand nach dem Urteil, aber keine öffentliche Akte, die ihn bis zum Abschluss trägt.

Zugleich begrenzt die Anmerkung die Macht. Die konkrete Empfehlung des Council ist kein technischer Befehl. Das Team erhält keine neue Befugnis, etwa ein Dokument rückwirkend unveröffentlicht zu machen. Arbeitsgruppe, Vorsitz, Team oder anderer ursprünglicher Entscheidungsträger handeln mit ihren bestehenden Kompetenzen.

Das ist eine sinnvolle Gewaltenteilung. Der Council benennt den Fehler, eine andere Stelle wählt die sachliche Abhilfe, das Team verhindert das Vergessen. Genau zwischen diesen Funktionen kann jedoch Verantwortlichkeit verloren gehen.

Angemessen, rechtzeitig, vollständig: drei prüfbare Aussagen

„Angemessen“ verlangt eine Zuordnung. Eine Maßnahme kann hilfreich sein, ohne jeden stattgegebenen Punkt zu beantworten. Erforderlich ist eine Verbindung zwischen Einwand, fortwirkender Folge, Maßnahme und Wirksamkeitsnachweis.

„Rechtzeitig“ muss keine einheitliche Frist bedeuten. Eine redaktionelle Korrektur, die Rückstufung eines Dokuments und eine technische Neuorientierung haben unterschiedliche Zeithorizonte. Fallbezogenes Zieldatum, nächster Prüfpunkt und Verzögerungsgrund sind dennoch möglich.

„Vollständig bearbeitet“ ist ein Endzustand. Der zitierte Abschnitt benennt weder die feststellende Stelle noch den Veröffentlichungsort, die Benachrichtigung des Einsprechenden oder ein Korrekturverfahren. Der Endzustand hat einen Namen, aber keine vorgeschriebene Beweisform.

Vibration API zeigt die Arbeit und die Lücke zugleich

Ende 2024 prüfte das Advisory Committee, die Vibration API (Second Edition) als veraltete Recommendation zu kennzeichnen. Zwei Formal Objections wurden erhoben. Die Devices and Sensors Working Group beschloss auf der TPAC 2024, das Dokument zurückzustufen und mit einem neuen Candidate Recommendation Snapshot weiterzuarbeiten. Ein Einspruch wurde erledigt; der andere gelangte an einen Council.

Am 10. August 2025 gab der Council dem verbliebenen Einspruch statt. Sein Bericht beschrieb eine bereits veränderte Lage. Das Dokument war inzwischen Candidate Recommendation Draft und konnte nach der angeführten Regel nicht als obsolete gekennzeichnet werden. Die Arbeitsgruppe hatte es schon zurückgestuft, um weiterzuarbeiten und die Bedenken zu behandeln.

Der Council schrieb keine technische Endlösung vor. Er empfahl, den Publikationsprozess fortzuführen, die Implementierungserfahrung in Issue 33 zu dokumentieren und bei der nächsten Chartererneuerung einen konkreten Plan samt überzeugender Begründung vorzulegen. Ob dieser Plan mehrere große Browser-Engines einschließen würde, ließ er offen.

Nacharbeit ist sichtbar. Issue 33 wurde nach Arbeit am Implementierungsbericht am 1. Mai 2026 als abgeschlossen geschlossen. Das Charterverfahren 2026 verwies auf die Empfehlung des Council. Issue 781 verfolgte Plan und Implementierungsnachweis. Pull Request 809 schlug später ausdrückliche Pfade für Spezifikationen mit nur einer Engine vor, darunter einen Statuswechsel für Vibration, falls keine zweite Implementierung entstünde. Er wurde ohne Merge geschlossen. Das breitere Charterverfahren lief mit weiteren Änderungen und AC-Prüfung weiter.

Die Geschichte ist also keine Geschichte der Untätigkeit. Sie ist eine Geschichte verteilter Beweisstücke.

War die frühere Rückstufung bereits Abhilfe oder nur vorläufige Eindämmung? Schloss Issue 33 einen stattgegebenen Punkt oder lieferte er Material für eine spätere Entscheidung? Wurde der empfohlene Charterplan in anderer Form erfüllt, durch eine andere Konsenslösung ersetzt oder nie förmlich abgeschlossen?

Der Council-Bericht belegt Urteil und Empfehlungen. Der Teambericht belegt den Verfahrensgang. Das technische Issue belegt eine Aufgabe, das Charter-Issue eine Forderung, Pull Requests Vorschläge und das Strategy-Issue die weitere Charterentwicklung. Keines ist als maßgebliche Akte für „vollständig bearbeitet“ ausgewiesen.

Ein offenes Issue beweist keinen Process-Verstoß. Ein geschlossenes Issue beweist keinen institutionellen Abschluss. Auch ein gemergter Text würde Änderung, nicht automatisch Angemessenheit belegen. Es fehlt die autorisierte Verknüpfung.

Issue 751 zieht die richtige Grenze

Im Process Issue 751 wird seit 2023 öffentlich darüber gestritten, ob Empfehlungen des Council bindend seien, andere Konsense stören könnten oder dem Team zu viel Macht gäben.

Die Antworten markieren zwei Grenzen. Erstens sind die konkreten Vorschläge des Council unverbindlich. Das zuständige Organ darf eine andere Konsenslösung wählen. Zweitens bedeutet diese Unverbindlichkeit nicht, dass Folgen einer aufgehobenen Entscheidung liegen bleiben dürfen. Sie müssen rückgängig gemacht, neutralisiert oder gemindert werden; das Team soll dafür sorgen, dass dies nicht vergessen wird.

Das Team verfolgt, es verfasst nicht. Genannte bestehende Hebel waren die Erinnerung eines Vorsitzes, vorhandene Ernennungsbefugnisse, das Stoppen einer Publikation bei fehlenden Übergangsvoraussetzungen sowie geregelte Rückstufungs- und Abbruchwege. Eine neue Macht zum Schreiben oder Löschen entsteht nicht.

Mehrere Beteiligte sahen trotzdem ein Darstellungsproblem. Die Rolle des ursprünglichen Entscheidungsträgers solle deutlicher werden; sonst wirke es, als gehe die Sache zum Team und danach geschehe „Magie“. Die Gegenposition lautete, die Substanz sei richtig und müsse wegen verschiedener Entscheidungstypen allgemein bleiben. Das Issue wurde als redaktionell vertagt.

Entscheidend ist ein weiterer Gedanke: Der Einsprechende soll die Erledigung nicht Monate oder Jahre selbst überwachen müssen. Dazu braucht er kein Veto. Die Institution muss den Status tragen.

Die stärkste Verteidigung lautet Flexibilität

Nicht jede Formal Objection betrifft eine Working Group. Ursprüngliche Entscheider können Gruppe, Vorsitz, Team, TAG, AB oder Charterinstanz sein. Eine einheitliche Rückgabe an die Arbeitsgruppe wäre oft falsch.

Ebenso wenig darf der Council zum technischen Oberausschuss werden. Das zuständige Organ kann aufgrund von Implementierung, Patentfragen und Konsens eine bessere Alternative entwickeln. W3C veröffentlicht außerdem bereits viele Unterlagen; vertrauliche Council-Beratungen, Mitgliederinformationen, Einzelstimmen, Personalmaßnahmen und Rechtsrat können legitimerweise geschützt bleiben.

Diese Argumente sprechen für eine schlanke, anpassbare Akte und klar bezeichnete Geheimhaltungsgrenzen. Sie sprechen nicht für einen nur erratbaren Abschluss.

Inhalt einer Abhilfe-Verwahrungsakte

Jeder Council-Bericht, der eine bereits folgenreiche Entscheidung aufhebt, sollte eine versionierte Akte eröffnen. Das Team pflegt den Status; die zuständige Stelle liefert ihre Entscheidung und Belege.

Erforderlich sind:

  • Council-Bericht, Entscheidungsdatum und Process-Version;
  • aufgehobene Entscheidung und sämtliche stattgegebenen Aspekte;
  • eingetretene Folgen und betroffene Artefakte;
  • institutionell verantwortliche Rolle je Maßnahme;
  • vorhandene Befugnis dieser Stelle;
  • unverbindlich gekennzeichneter Council-Vorschlag;
  • angenommene, veränderte oder alternative Lösung;
  • Abhängigkeiten, Zieldatum oder nächster Prüfpunkt, Status und Verzögerungsgrund;
  • gegebenenfalls ausgesetzte Publikation, Fortschreibung oder Charterhandlung;
  • Abnahmekriterium und Evidenz je stattgegebenem Punkt;
  • Benachrichtigungs- oder Konsultationsstand von Einsprechendem und ursprünglichem Entscheider;
  • Stelle mit Befugnis zur Angemessenheitsfeststellung;
  • datierte Abschlussfeststellung oder ausdrücklicher Hinweis, dass sie noch fehlt;
  • Korrekturen, spätere Entscheidungen, Appeals und neue Formal Objections;
  • Abgrenzung öffentlicher und geschützter Informationen.

Die Akte macht keinen Vorschlag bindend. Sie kann dokumentieren, dass eine Arbeitsgruppe eine andere Lösung gewählt hat und warum deren Evidenz denselben Punkt beantwortet. Sie schafft kein neues Rechtsmittel. Eine neue Sachentscheidung bleibt dem normalen Einspruchsweg unterworfen. Sie erweitert auch die Team-Macht nicht, denn jede Handlung muss eine bestehende Befugnis nennen.

Vor allem trennt sie Tätigkeit vom Abschluss. Meeting, Issue und Patch sind Arbeitsnachweise. Erst der Abgleich mit einem Abnahmekriterium ist ein Nachweis der Abhilfe.

Grenzen der Feststellung

Die öffentlichen Quellen belegen weder eine interne Fristverletzung noch eine weiterhin unangemessene Vibration-Abhilfe oder bösgläubiges Verhalten Beteiligter. Der Abschluss von Issue 33 und der offene Status von Issue 781 sind reale, aber unterschiedliche Tatsachen. Keine entscheidet allein über den Process-Endzustand.

Der ungemergte Abschluss von Pull Request 809 beweist weder eine inhaltliche Ablehnung noch das Fehlen eines gleichwertigen Plans. Spätere Streitpunkte der Charter 2026 gingen über Vibration hinaus und dürfen nicht rückwirkend als Beleg gegen die Council-Nacharbeit benutzt werden.

Der Befund ist strukturell: W3C benennt einen Zustand nach dem Council-Urteil, verpflichtet aber keine öffentliche Akte, ihn bis zum Ende zu führen.

Quellen

  1. W3C Process vom 18. August 2025 — Abhilfe
  2. Aktueller Editor’s Draft des Process — Abhilfe
  3. Process Issue 751 — Nebenfolgen von Council-Entscheidungen
  4. W3C Guide — Formal Objections und Council
  5. Council-Bericht zur Vibration API, Runde 2
  6. Teambericht zum Vibration-API-Einspruch
  7. Vibration Issue 33 — Implementierungsbericht aktualisieren
  8. Charter Issue 781 — vom Council empfohlener Plan
  9. Strategy Issue 530 — Devices and Sensors WG Charter 2026
  10. Pull Request 809 — Pläne je Spezifikation
  11. Guide Issue 173 — Wer sind die Entscheider?
  12. Process Issue 1029 — Zeitpunkt der Veröffentlichung eines Council-Berichts
  13. Heng Lu — The Multi-Stakeholder Mirage
  14. Heng Lu — On the Agency Problem at the Core of Internet Governance