Skip to content

Latest commit

 

History

History
24 lines (17 loc) · 2.36 KB

continuous_incubation.md

File metadata and controls

24 lines (17 loc) · 2.36 KB

Continuous Incubation

Here is the background. We are evolving in practice to have incubation before starting a WG. It works well. We incubate in a CG. We then bring it to a WG. We are structured to have efficient WGs.

But then, once the WG is created, people have new ideas. Whereas the ideas that birthed the WG were well incubated; not all of the new ideas are equally vetted. Yet, once the WG is created, it is hard to ignore these new ideas - even the ones that are more aspirational in nature.

Discussion

In order to address this issue, there requires discipline on the part of the Chair and the Working Group. There should be a high bar to introducing new features into a spec; especially when those features have not been incubated anywhere.

On the other hand, when there are these new features - we don't want to lose them. Even if they are not mature enough for the current specification, it is important that the ideas should not be lost.

Proposed practice

  1. Each group should document the current features that they are working on for the specifications they are taking to Recommendation.
  2. Each group should have a documented approach to dealing with incubating new features. Some groups might specifically assign new features to be worked on in a Community Group (WASM is a recent example). Other groups might want to incubate new features in their existing Working Group (CSS is an example). Whatever the approach, the group should discuss and document what approach they want to use.
  3. When a WG participant proposed a new feature the group should consider its disposition recognizing its incubation policy:
  • If the new feature has been well incubated somewhere, it is probably a candidate to be added to what the group is currently working on.
    • Even in this case, there could be considerations why it is held off for v.next (e.g. lack of implementations, schedule delay for the document in question).
  • If the new feature has not been well incubated, it should be dealt with in accordance to the group's incubation policy
    • In many cases it would be referred to a CG
    • In some cases it might be incubated within the WG - but kept apart from the REC being developed
    • In some cases, the importance of the feature might be sufficiently great that it joins the current document being developed: but this decision is made by the WG in full regard of the dangers of scope creep.