- From: Carine Bournez <carine@w3.org>
- Date: Mon, 2 Dec 2019 07:56:34 +0000
- To: Florian Rivoal <florian@rivoal.net>
- Cc: Jeff Jaffe <jeff@w3.org>, "public-w3process@w3.org" <public-w3process@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Philippe Le Hegaret <plh@w3.org>
On Mon, Dec 02, 2019 at 04:20:38PM +0900, Florian Rivoal wrote: > 2. I still don't like "Extensible". Several alternatives were proposed. > What is our process to bikeshed the name? > > Ideally, I'd like more than 3 people involved... but switched it to Expandable > for now. It sounds a bit too close to "expendable" to me :D Maybe we could indeed ask for more suggestions. I don't think I have good ones: "elastic", "organic" Ever-something seems a better idea, but we'd need to find the something. > 3. 5.2.6. There has been discussion in the W3Process CG that it might make > more sense to allow every WG to decide what to designate as an Extensible > REC rather than having this done in the Charter. While I don't feel > strongly, I felt that this opinion was getting greater traction from > reviewers. Taking that path might simplify some of the Process document > text. > > The goal of placing a constraint on non-Expandable RECs is not to better fit > the WG's work-mode, but to make a promise to the outside world that a REC will > not gain new features. It won't be always easy to determine whether the REC will or will not be extensible at charter time. The best solution would be to have a MAY: the charter MAY indicate that the deliverable is an extensible REC, otherwise the WG will determine later. I like the subsequent proposal to merge and only have 1 kind of REC, because since the start of the development of the evercolored process I've seen a risk of getting a "low-class REC" compared to the other. [...] > 9. 6.2. I think we have a capability now for Documents to come in at CR > level (i.e. CR = FPWD for those documents). I don't know if that is clear > enough in the process doc. We are using it, for example, for DOM and HTML. > > Hmmm. Interesting problem. I don't think there's anything in the process that > allows for that. FPWD is supposed to come before CR, and the Patent Policy > seems to have this as an assumption (not sure anyone has evaluated the > consequences of breaking that assumption). It's been used a couple of times, and the PP FAQ mentions something about the exclusion opportunity length, IIRC (the FPWD opportunity covers the CR one). > 10. 6.2. CRUD. I thought we were going to work on the acronym. > > Lol. Done. > s/CR Update Draft/CR Udate/ > s/CR Review Snapshot/CR Snapshot/ I find this distinction still rather confusing (just my 2 cents). The goal of having it is unclear in the document. > 11. 6.2. Rescinded CR. I'm not clear on why we need that. We seem to have > too many states already. Can we just call it a Note? > > No, because rescinding something has implications for patent obligations. If we > adopt the updated Patent Policy which applies obligations to CRs, we will need > to be able to rescind CRs as well as RECs. Making assumptions on a future PP is a bit speculative. If you start with a simpler process and complicate it only if the PP needs it, we might end up with a simpler process as a result.
Received on Monday, 2 December 2019 07:56:42 UTC