Follow-up on this, since we now have two days remaining to respond to these proposed charters.
If you still have strong opinions about the proposed Web Platform and Timed Media Working Groups charters, please reply within 24 hours so we have the opportunity to integrate your opinions into Mozilla's response to these charters. Details below: On Wed, Aug 19, 2015 at 3:16 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > On Sun, Aug 9, 2015 at 9:59 PM, L. David Baron <dba...@dbaron.org> wrote: > > The W3C is proposing revised charters for: > > > > Web Platform Working Group: > > http://www.w3.org/2015/07/web-platform-wg.html > > https://lists.w3.org/Archives/Public/public-new-work/2015Jul/0020.html tl;dr I think we should vote to approve these charters with changes requested (but not required), based on the input in this thread to date. One point that I feel has been missed. Both these new charters make use of the new W3C Software & Document license *for all specifications* they produce, which is a more liberal license than the previous/current Web Apps and HTML WGs. This is a good thing and a pretty big step towards our goal of getting more CC0 / liberal licensing in W3C work that is produced, so work can be independently iterated on, and merged back in etc. Henri wrote: This charter doesn't mention the WHATWG by name There is one reference with perhaps a typo: " DOM Parsing and Serialization A specification describing how to parse markup into a DOM, and serialize for export, an HTML or XML fragment or document. This was initially developed in the WHAT-WG. " > and merely says "The > Working Group will consider proposals for future specifications from > Community Groups, encourage open participation from Community Group > members, and keep coordination with relevant Community Groups, all > within the bounds of the W3C patent policy and available resources." > I'd like to know (preferably in the form of charter text) what the > planned relationship with the WHATWG is supposed to be. Specifically, > I don't expect this W3C group to be able to do a good job maintaining > the features that are covered by actively maintained WHATWG specs > except by having a fast, low-bureaucracy way to import spec text from > the WHATWG. I too would like to see more explicit mention of WHATWG in this charter. Henri, could you propose suggested text for the charter that we can contribute that mentions WHATWG explicitly? It sounds like you have specific thoughts in mind for this and I'd like to capture that in the charter. Having the W3C modularize (what year is this? 1999 all > over again?) a WHATWG-originating spec with editorship "Up for taking" > looks like the opposite of what's needed to have a fast, > low-bureaucracy way to import spec text from the WHATWG. In general, modularizing the HTML spec for the sake of modularization > seems useless busy-work. I think we should object to modularization > for the sake of modularization. Given Robin's departure I don't expect the modularization to move forward until/unless another W3C editor shows up to attempt it - which I frankly don't see happening anytime soon. I think your suggestion is reasonable. Henri, could you propose specific text to change/drop regarding the existing mentions of "modularization" in the charter? > If there a bits that have an editor > lined up and the browser vendors want to do non-maintenance > development in the relevant area, then it might make sense to split > out something on a case-by-case basis. > I think this is a good way to focus such work and we should put that in our suggested changes to the charter. Furthermore, merging HTML into WebApps seems low-risk only if there > isn't much work to do around HTML. From everything I've seen, I don't expect much work around HTML beyond taking/merging bugfixes. I'm hoping with the new license that if W3C makes its own bugfixes that we find a way of propagating those bugfixes to WHATWG HTML as well. > Activity around HTML seems to > attract disruptions that would be unfortunate compared to WebApps > going on operating without those disruptions. Therefore, it seems > unwise to generate activity (such as pushing text around in order to > modularize) around HTML needlessly if WebApps is to take over HTML. > In general agreed. I also think there is important context to consider here which is the set of chairs of the new WG. IMO one of the problems with the disruptions that the HTMLWG attracted was that the chairs did not deal with those disruptions swiftly. Based on the proposed chairs for the new WG, I expect much more swift handling of any disruptors. In addition, the problem of disruptors is much better known, both in the HTML / Web Apps areas, and all the way up to the AB, and you can bet that many eyes will be watching for such behavior. Note also that since the past HTMLWGs disruptions, the W3C has adopted more anti-trolling type policies like their PWE (Positive Work Environment) policy. In short, chairs have more tools today to kick out disruptors quickly than they have in the past. If an answer to the above is not already documented in public in a way > that allows the W3C to be held to their word, I think we should ask > about the above in our charter review comments. > > This charter includes the maintenance responsibility for a number of > specs related to Widgets. Is this just a formality that pre-existing > specs have to belong to *some* WG or is the group actually expected to > spend time on maintaining Widgets? Does any vendor that can reasonably > be expected to contribute staff time to the WG actually ship W3C > Widgets or want to shift from whatever packaged Web app solution they > do ship to W3C Widgets? It seems like a bad idea to put the group's > time into Widgets if isn't the future we intend to pursue and, AFAICT, > it isn't. > That's a good observation. Shall we object to Widgets as a deliverable and ask for it to be dropped? > On Mon, Aug 10, 2015 at 1:28 PM, Gervase Markham <g...@mozilla.org> wrote: > > On 09/08/15 19:59, L. David Baron wrote: > >> The Timed Media WG splits some of the media work that was happening > >> in HTML (MSE, EME) into a separate group. > > > > Do we see a risk here that this group will become captured by the > > promoters of DRM, more than was possible when it was done in the HTML WG? > > I think moving EME into a group of its own would carry a major risk of > the group finding other DRM things to work on in order to perpetuate > its own existence. That's why I've cautioned against kicking EME out > of the HTML WG. > > Since the proposed WG is not a DRM WG but the media WG with > substantial non-DRM work to do, I'm somewhat less worried about this > proposed WG than I would be about an EME-only WG. > Agreed. As noted above, the media TF has already been operating relatively > separately. In that sense, this split doesn't involve much of a change > in terms of who subscribes to which mailing list and who follows which > meeting minutes. However, I don't see any benefit from having a Timed > Media Working Group compared to having a Timed Media Task Force of the > Web Platform Working Group and I can see potential for the separate > working group to have a downside. > > The proposed Web Platform Working Group covers so many things that > it's obvious that no single participant is going to participate in the > development of all the deliverables. In that context, I think it's > weird to split MSE, EME and the <video>/<audio> parts of HTML5 > maintenance into a separate WG. > My understanding is that there is an intent to continuing splitting off more such work, it's just that this was the first chunk that made sense to split off. I think it would be reasonable for us to record a comment along the > lines of the above paragraph and have Media as a TF of Platform. > Other opinions on this? I don't have a strong opinion about splitting media off as a separate WG or keeping it as a TF of Web Platform. Henri, if you want to write up a summary comment about Media TF vs WG to submit as part of the charter review, we can include that in our charter response as well. Thanks, Tantek Çelik _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
