Re: Process for updating specs

I do care about the process, because things are becoming messy. I also agree with your observation regarding governance. I will talk to Philippe about best practices in W3C.  As a first step we stop simply committing PRs to the spec. We have regular sync meetings and this is where PRs should be discussed. We merge if there are no serious concerns by group participants. If you are the owner of a PR that you want to get merged you are responsible for ensuring a proper discussion. The alternative is, that only I as the chair can merge against the spec. I want to, however, avoid dictatorship.

// Alois

From: Yuri Shkuro <shkuro@gmail.com>
Date: Monday, 17. December 2018 at 15:05
To: Alois Reitbauer <alois.reitbauer@dynatrace.com>
Cc: "public-trace-context@w3.org" <public-trace-context@w3.org>
Subject: Re: Process for updating specs

Personally, I care less about the mechanics of the branches than about the governance, which is currently undefined. I opened a ticket about it a few months back. In the absence of established governance model the branches are still one vote away from becoming a part of the spec.

On Dec 17, 2018, at 8:39 AM, Reitbauer, Alois <alois.reitbauer@dynatrace.com<mailto:alois.reitbauer@dynatrace.com>> wrote:

Working group members,

Due to the recent changes – some done by me 😊 – I realized we need a better defined process for changing specs. Up to now we were mostly committing against the master spec. This has led to an ad-hoc update behavior against the spec.  As we will now have more people reading the spec and we need to have a more defined process on how to update them. Plus, we need to ensure to separate issues from our “golden master”  spec vs. the next iteration of the spec.

Therefore I propose a new approach to update specs that I will also add to our contributing.md once I have collected your feedback. The new process will work as follows:


  *   Master spec is not updated directly all update work is done in a separate branch – I just created the CR-editing-version for the CR.
  *   We will have an active working branch at least for every milestone. We might decide to also have one for larger changes e.g. more protocols to be supported.
  *   All changes are done against this branch and not the master branch also PRs are files against the branch and not master directly.
  *   Once we have an agreed-upon set of changes they are committed as a whole against the master branch with a full change log.

What are the advantages of this approach:


  *   Have a more release oriented contribution approach will make it easier for people to follow.
  *   Clear separation of issues against the last spec and current working document
  *   Better visibility of what changed since the last version of the spec.
  *   Reduce the number of individual branches against master which is hard to follow
  *   Easier collaborative editing than with branches on individual forked repos other editors have no access to.

I hope, this makes sense for everyone.

// Alois
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistädterstraße 313
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistädterstraße 313