Seite 5: Lebenszyklus eines Standardisierungsvorschlags

Inhaltsverzeichnis

Um ein neues Feature in den Standard aufzunehmen, muss jemand einen Vorschlag dafür einreichen, und bis zur endgültigen Standardisierung durchläuft dessen Bearbeitung mehrere Phasen. Mit der zuvor beschriebenen feingranularen Strukturierung des Komitees spielen die Arbeits- und Studiengruppen verschiedene Rollen und werden in unterschiedlichen Phasen des Standardisierungsprozesses aktiv. Diese Rollen sind:

• Akzeptanz: Die beiden Incubator Study Groups entscheiden, ob es sich lohnt, eine neue Idee weiterzuverfolgen.
• Domänenexpertise: Die anderen Study Groups diskutieren, inwieweit der Vorschlag dem Wissensstand des jeweiligen Fachgebiets gerecht wird.
• Design: Die beiden Arbeitsgruppen Evolution und Library Evolution verfeinern die Umsetzung der Idee. Das umfasst technische Details – etwa welche Funktionsargumente konstant sein sollten oder ob etwas zur Compilezeit berechenbar sein soll und ob die Schnittstelle einen Konflikt mit anderen Features birgt.
• Formulierung: Die beiden anderen Arbeitsgruppen Core und Library – im Weiteren Wortgruppen genannt – diskutieren die genaue Formulierung, die es in den Standard aufzunehmen gilt.

Durch diese Aufgabenteilung durchläuft ein Vorschlag für ein neues Sprachfeature typischerweise die folgenden Phasen:

1. Coole Idee, die in einem Blog, einer Mailingliste, Reddit et cetera veröffentlicht wird. (Die meisten Vorschläge schaffen es nie über dieses Stadium hinaus.)
2. Die Antragsteller reichen ein erstes Designkonzept ein und stellen es meist als Erstes der Incubator-Gruppe vor. Der Entwurf sollte eine Begründung, in Betracht gezogene Alternativen, konkrete Beispiele und einen konkreten Vorschlag enthalten, der detailliert genug ist, um ihn zu bewerten.
3. Die Incubator-Gruppe bekundet Interesse und veranlasst, dass die Diskussion dieses allgemeinen Features in die nächste Runde geht. Daraufhin leitet sie den Vorschlag an die Designgruppe und (soweit vorhanden) parallel an eine Gruppe von Domainexperten weiter.
4. Die Design- und Expertengruppen bitten nach ausführlichen Diskussionen um Nachbesserungen. Das wiederholt sich in der Regel über mehrere Sitzungen. Liegen konkurrierende Vorschläge vor, dauert die Iteration und Konvergenz etwas länger. Wenn viele Iterationen erforderlich sind und zwischen den Sitzungen zusätzliche persönliche oder telefonischen Sitzungen infrage kommen, kann der Vorsitzende der Designgruppe empfehlen, eine Studiengruppe für das Thema zu gründen. Überarbeitete Vorschläge wandern dann wieder in die Entwurfsgruppe zurück.
5. Die Designgruppe stimmt zu, eine bestimmte ausgereifte Designrichtung zu verfolgen, und bittet um eine erste Ausformulierung für den Standardtext.
6. Die Designgruppe stimmt zu, eine bestimmte ausgereifte Designrichtung zu verfolgen, und bittet um eine erste Ausformulierung für den Standardtext.
7. Die Wortgruppe überprüft und verfeinert die Formulierung, bevor sie letztlich zustimmt, die Featurespezifikation in den aktuellen Entwurf des Sprachstandards aufzunehmen. Daraufhin erhält das gesamte Komitee den Vorschlag zur Abstimmung.
8. Das gesamte Komitee stimmt zu, den Wortlaut in den aktuellen C++-Entwurf zu übernehmen, und erstellt eine Issue-Liste zum Nachverfolgen von Problemfragen.
9. Design- und Wortgruppen verfeinern die Spezifikation und leiten jede Änderung zur Genehmigung an das komplette Komitee weiter. Der Wortlaut muss das verabschiedete Design korrekt beschreiben; alle Fragen dazu, was bestimmte Codebeispiele bedeuten sollen, müssen im Design gelöst werden und sich in der Formulierung widerspiegeln; der Wortlaut muss so klar sein, dass die Compilerentwickler exakt wissen, was sie zu implementieren haben. Das Ziel ist, dass alle Programmierer portablen Code schreiben können, der bei verschiedenen Compilerimplementierungen auf die gleiche Weise funktioniert.
10. Das vollständige Komitee sendet den Arbeitsentwurf (CD oder DIS) zur Abstimmung über ISO an die nationalen Standardinstitutionen, und einige Monate später senden diese die Kommentare zur Abstimmung an das Komitee zurück.
11. Design- und Wortgruppen entscheiden über Kommentare zur Abstimmung und leiten jede Änderung zur Genehmigung an das gesamte Komitee weiter.
12. Das vollständige Komitee sendet den Arbeitsentwurf (FDIS) zur endgültigen Abstimmung und/oder Veröffentlichung.
13. Wurde der Vorschlag zunächst in einem TS veröffentlicht, kann das Komitee nach Erhalt von Beta-Feedback (normalerweise einschließlich der Erfahrung eines Compileranbieters, der das Feature implementiert und dies von Nutzern hat testen lassen) den Editor beauftragen, den TS in den Arbeitsentwurf von C++ zu integrieren.

Ein kleiner und wenig kontroverser Vorschlag kann mehrere Phasen während eines Meetings durchlaufen, während andere Vorschläge mehrere Meetings für eine einzelne Phase benötigen.