- From: Glenn Adams <glenn@skynav.com>
- Date: Thu, 13 Apr 2017 17:56:18 -0600
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: Timed Text Working Group <public-tt@w3.org>
- Message-ID: <CACQ=j+eW=EgF6Mz2DBcxF_-fpdtysF+B--SHtfY7VvnebHEb+A@mail.gmail.com>
Regarding the process discussion today about TTML2 editing process, I want to remind members of the following: - An "Editor's Draft" is owned by the Editor, and is not required to represent the consensus of the group. Rather it is an interim document representing a possibly unstable point in the editing process. - We already have an agreed process for editing TTML2 [1], which is based on a commit then review procedure, and not review then commit. In particular, this process does not require the determination of consensus of the group prior to performing merges into the master (gh-pages) branch. - It is entirely the prerogative of the editor to determine when and how to merge a PR, including replacing a proposed PR with an entirely new PR or entirely new content. - The above process is not unique to TTML2 within the W3C and is widely followed by other groups, such as CSS and others. In fact, suggesting that consensus is required before merging PRs or before publishing new EDs goes counter to widespread W3C and TTWG practice. - The time for determining consensus on a particular ED is during the process of publishing a new WD. In the W3C, many groups have effectively eliminated this step by delegating the task of publishing a new WD to the editor, and, have, in fact, set up an automatic publishing process so that whenever the editor updates an ED, a new WD is automatically published. In such cases, it is generally not the case that the editor is required to obtain a consensus from the group prior to updating an ED that will automatically be published as a WD. - In contrast with this automatic WD publishing process, the TTWG has adopted a manual WD publishing process triggered by WG approval (and not the editor's arbitrary choice). - In TTML2 (and TTML1), a branch is created by the editor in which a new WD is prepared and then published. Later, after publishing has occurred, such a branch is merged back to the master (gh-pages) branch and then deleted. If desired, such branches could be used during the consensus determination process in case additional changes are required to obtain consensus, and could be retained after being published in order to track history of changes during such a process. In short, the TTML2 Editor is following documented process. Any suggestion to restrict the Editor from updating TTML2 EDs or a consideration to replace the Editor is entirely without merit and quite absurd on its face. If the group wants to move forward on TTML2, then stop arguing about the established guidelines and the Editor's processing. On the other hand, if the group prefers to spend its time talking about process and not moving forward, then feel free to do so. However, I am not interested in re-hashing the process. Finally, the established guidelines already defines a process for "Post Pull-Request Merge Issues" [2]. I urge the group to cease attempts to establish an a prior consensus on each PR, and instead, focus on documenting any pull-request merge issues using this agreed process. Every time a merge occurs on the master (gh-pages) branch, TTML2 moves forward, at least incrementally so. In general, resolving post PR merge issues is a subset of the original issue, and therefore, easier to resolve. In contrast, attempts to perfect a PR prior to merging often produces delays and hinders forward progress. [1] https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#ttml2-editing-guidelines [2] https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#post-pull-request-merge-issues On Thu, Apr 13, 2017 at 10:23 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > Thanks all for attending today's TTWG meeting. Minutes can be found in > HTML format at http://www.w3.org/2017/04/13-tt-minutes.html > > In text format: > > [1]W3C > > [1] http://www.w3.org/ > > Timed Text Working Group Teleconference > > 13 Apr 2017 > > See also: [2]IRC log > > [2] http://www.w3.org/2017/04/13-tt-irc > > Attendees > > Present > Pierre, Philippe, Nigel, Andreas, Mike > > Regrets > Glenn > > Chair > Nigel > > Scribe > nigel > > Contents > > * [3]Topics > 1. [4]This meeting > 2. [5]TPAC 2017 Advanced planning > 3. [6]IMSC > 4. [7]TTML > * [8]Summary of Action Items > * [9]Summary of Resolutions > __________________________________________________________ > > <scribe> scribe: nigel > > This meeting > > Nigel: I added to the agenda the TPAC 2017 advanced planning, > and we have TTML and > ... IMSC topics. Any other things to cover? > > Pierre: I'd like to discuss moving forward with the test > vectors for IMSC 1. > > Nigel: Great let's do that. > > TPAC 2017 Advanced planning > > Nigel: I believe we already agreed to meet at TPAC for at least > 2 (and possibly 4) days. > ... I will need to complete a survey saying how many days we > want to meet for and if > ... we wish to meet any other groups. > ... TPAC this year is in Burlingame, 6-10 November. > > [10]https://www.w3.org/2017/11/TPAC/Overview.html > > [10] https://www.w3.org/2017/11/TPAC/Overview.html > > Nigel: I will also need to state the days preferences, our > flexibility, and any overlaps with other groups to avoid. > ... There is another big event in San Francisco at the same > time so flights and > ... accommodation will be limited - advice is to book early. > ... Does anyone already know of any date preferences for our > meetings? > > Andreas: I will need to check - if we meet for 4 days then I > will probably not join TTWG on all those days. > > Nigel: OK I will come back to this next week - I have until > mid-May to complete the > ... questionnaire on behalf of the Group. > > IMSC > > Nigel: Two things here: firstly liaisons, secondly test suite. > ... For practical reasons I was unable to send the final > liaison until yesterday but have > ... now done so, with apologies to the last group to receive > the message, which gives them > ... a bit less time to deal with it. > ... The next thing is the test suite. > > Pierre: There's been a source of recurring complaint that there > is no complete test suite > ... for IMSC so what I've done over the past couple of weeks is > to combine tests from the TTML > ... test suite and the IRT test suite, and licences on both > allow that. I have modified those > ... files to be conformant IMSC 1 and to make them more > appropriate for generating test > ... vectors. Then I ran IMSC.js on them and generated a > sequence of PNGs, one for each ISD > ... based on them. I would like to submit those back to W3C and > make them the official > ... IMSC test vectors. One obvious objective is to help folk > develop and test software, another > ... is if results differ then we can review that in an issue, > in case it is an issue with the test, > ... IMSC.js or the spec. In practice I would create a pull > request against the IMSC repo > ... replacing the test subfolder with the test vectors. > > Nigel: One question is whether we base the IMSC 1.0.1 CR exit > criteria on these tests or > ... part of them or if it is completely separate? > > Pierre: This submission is not intended for the exit criteria > of IMSC 1.0.1 - it could be but that is not my primary goal. > > Nigel: Does it include tests for the new features? > > Pierre: Not yet, but I would hope to add them in time. > > Mike: One of the new features has no presentation output, so > the test would be that it does > ... not break. > > Nigel: Quite right, though a console output might log > recognition of the activeArea. > ... So the request is for W3C to host a test suite for > implementors beyond CR. Philippe, is that commonly done? > > Philippe: Yes, we could do that, but I would say that you > should not put W3C staff in the > ... critical path. > ... I would recommend setting up a github repository for it and > serving it, then we can > ... create a link to serve it from W3C with a redirect. > > Nigel: So that repo could be the imsc repository, right? > > Philippe: It could be but I would not recommend it. The test > suite licence would be different > ... so we do not need to track the IPR in the same way. > ... I can create another repo in W3C - it is not complicated. > If you really want one repository, > ... then be aware that any contributions from outside the group > will be tracked for IPR and > ... you will not be able to accept them. > ... We have licences for tests, so having two licences for one > repository would be a bit more > > <plh> > [11]https://github.com/w3c/web-platform-tests/blob/master/LICEN > SE.md > > [11] https://github.com/w3c/web-platform-tests/blob/master/LICENSE.md > > <plh> > [12]https://github.com/w3c/web-platform-tests/blob/master/CONTR > IBUTING.md > > [12] https://github.com/w3c/web-platform-tests/blob/master/CONTRIBUTING.md > > Philippe: complicated. For example the web platform tests have > a separate repository. > ... The examples above don't look at all like what is in the > IMSC repository. > ... The more I think about it they should be in a separate repo > with a clearly different licence > ... and contribution guideline from the spec. > > Pierre: Then I would propose to remove the tests from the spec > repository. > > Nigel: Will it be okay to set CR exit criteria based on tests > outside the spec repo? > > Philippe: Of course, the tests are not part of the spec. > ... I recommend that we create a separate repo for this, and > then tell me where to link from > ... in the W3C website and I will do it. > > Pierre: I will take an action item to point you exactly to > where they are. > > Philippe: Thank you, I am happy to fork an existing repo. > > Pierre: I will try to make it simple for you. > > Philippe: It would be easier for me to create the repo, and set > the access rights the same as > ... the group's spec repos. > > Pierre: OK. > > <plh> [13]https://github.com/w3c/imsc-tests > > [13] https://github.com/w3c/imsc-tests > > Philippe: That is a link to the repository. > > Pierre: I will push the tests there. > > Nigel: Great. Thank you! > ... The existing CR implementation report is based on the tests > in the spec repo, so it > ... wouldn't be great to remove them. > > Pierre: Actually the IMSC 1 implementation report links to the > Mercurial repo so nothing we > ... do here will affect the formal IMSC 1 implementation > report. > > Nigel: Ok then I guess you're free to clean up the IMSC repo as > you like! > > Pierre: Thanks, I'll suggest something. > > Nigel: Now we need to begin thinking about the Exit Criteria > for IMSC 1.0.1 CR. > ... My starting point would be for two independent > implementations passing each of some > ... new tests for the new features, which would be: > > <plh> w3c/imsc-tests should be all set > > Nigel: 1. Not failing when processing a document with > ittp:activeArea present > ... 2. (perhaps) indicating on some console output the found > value of ittp:activeArea. > ... 3. Successful presentation of the lineGap style as per the > example in the spec, in other > ... words turning that example into a test vector. > ... I think we should set the shortest period that we are able > to according to the Process, > ... which I think is a month? > > Philippe: For CR it is 4 weeks. > > Nigel: Thanks. > ... That would be my proposal. Does anyone think we need > anything more? > > group: Nothing more needed. > > Pierre: If you file an issue to remind me then I will add > those. > > [14]https://github.com/w3c/imsc/issues/226 > > [14] https://github.com/w3c/imsc/issues/226 > > Nigel: Done, in above issue #226. > > TTML > > Nigel: Even in Glenn's absence I would like to discuss our > working process. He has sent me > ... some written notes since he is unable to be present. > ... Glenn's view as he's expressed it to me is that the ED is > the Editor's prerogative to > ... work with, and that it does not necessarily represent the > Group's consensus. > ... I would rather not work against each other here but work in > harmony. However we do > > <plh> [15]https://www.w3.org/AudioVideo/TT/IMSC/tests/ > > [15] https://www.w3.org/AudioVideo/TT/IMSC/tests/ > > Nigel: seem to want a group consensus so one option is to > create a new branch to serve > ... as the group's consensus and publish WDs based on that. > > Pierre: This is also an issue because the ED is linked from the > version on /TR. > ... Another issue is that if someone creates a PR based on an > issue, especially if they have > ... been asked to, then the discussion on the PR should happen > on that PR, so that everyone > ... can track what is changing. It is unreasonable to create a > separate pull request and have > ... the discussion somewhere else, or no discussion in the case > of an early merge, because > ... it makes it hard to compare with the original submission. > > Andreas: Also, to reflect the earlier discussions, this relates > to the position of the Editor in > ... the TTML1 and TTML2 activity, where the Editor has an > extremely strong role. In my > ... experience this is even a bit stronger than usual, and > maybe is not helpful for the group > ... dynamic, so we need to agree how the different roles work > some time. > > Nigel: In my role as Chair, I think I need to identify when > there is or is not consensus. Right > ... now it is clear that there are changes being merged into > the ED for which there is not > ... consensus in the Group. > ... Glenn's view on how to proceed is to raise issues on the > merged spec. I think we > ... should recognise that from a perspective of the end result > document that could result > ... in an okay end result, even if it is not a happy process. > > Mike: Looking at this from afar, it seems like we are not all > agreed on the process we follow. > > Nigel: Exactly, I would like to come up with some kind of > action plan to resolve this. > ... Philippe, have you seen any other examples from other > groups that we could take > ... inspiration from? > > Philippe: If this doesn't work for you guys in the Group then > it needs to change, that's the > ... bottom line. If the group wants to review stuff done in the > Editor's own branch then that's > ... okay. > > Nigel: Before I make any proposal are there any other thoughts > for how to resolve this? > > Mike: Step one is to talk to the Editor, and if that does not > work then step two is for the > ... Chair to take control of merges to the draft. > > Philippe: Yes. > ... There is an easy way - we can change permission settings to > restrict who can merge > ... into the repository. > > Nigel: Okay, that's fine. And regarding the point about the > ownership of the ED, is there > ... anything in W3C or the Process about that? > > Philippe: To be clear in lots of other groups the ED does not > represent the consensus of > ... the group, even if the ED is linked from the /TR page. > ... Formal consensus is only represented in the WD. > > Pierre: So do the CSS editors try to capture group consensus in > the ED? > > Philippe: No they don't. > > Pierre: And are the changes to the ED made with pull requests > or done unilaterally by the Editor. > > Philippe: I would have to check. It used to be that they would > be done unilaterally by the Editor. > ... In some cases the Group would ask for changes on moving to > WD. > > Pierre: The great thing about pull requests is you don't have > to do that. > > Philippe: I agree, but if you do not have that working method > then it does not apply. > > Mike: The goal is for the ED to reflect the current consensus. > Forcing the members to try to > ... correct something that was not originally proposed is a lot > of work that perhaps is not > ... necessary. It is odd at best to have the editor to do > something different to what is in WD. > ... I believe it would be a better process to use pull requests > and merge on consensus > ... into the ED. > > Philippe: Nigel, you're right, the Process does not make any > requirements on the ED. > ... If the editor cannot produce a draft that the group is > willing to agree on then you may > ... need a different Editor. > > Nigel: Okay we've discussed this enough today. In Glenn's > absence I will not impose the > ... option to stop early merge as indicated in the agenda, > however I will take an action to > ... talk to Glenn about this situation. Something will change > one way or the other. > ... In Glenn's absence are there any TTML issues that anyone > wants to raise? > > Andreas: I have to drop off the call now. > > Nigel: The only one from my list on the agenda that I think we > can easily cover is: > > [16]There's no apparent use case for the "any" term in > ttp:contentProfiles > > [16] https://github.com/w3c/ttml2/issues/139 > > Nigel: I agree with Pierre (who raised the issue) that there's > no meaning for "any" here and > ... we should simply remove it. > > Pierre: That was like 2 years ago. > > Nigel: I've added a comment on the issue. > ... I've also labelled it as "Discussed and agreed". > > Pierre: I'd like to look at 244 > > -> [17]https://github.com/w3c/ttml2/issues/244 Signaling HDR > pixels in PNG for use with <image> > > [17] https://github.com/w3c/ttml2/issues/244 > > Pierre: I'm sympathetic to the point that TTML2 does not define > any image formats. > ... However the proposal raised here is something the industry > will do regardless, i.e. to put > ... PQ pixels in PNGs. Noting this in TTML2 seems reasonable > because it is most likely to > ... happen in subtitles, and because W3C is the home of PNG. I > had suggested adding it > ... as an informative annex in TTML2. An alternative perhaps is > to create a WG Note, but I > ... think it is important to write it down somewhere otherwise > people will do crazy stuff > ... all differently. The advantage of a WG Note is that if > someone outside this Group wants > ... to make it more formal then it is easier to pull out. The > drawback is it is further away > ... from TTML2 though there could be an informative pointer to > the WG Note. > ... I think it is important to point to something but I'm not > all set on it being in the TTML2 > ... spec. > > Nigel: From my perspective, it is easier to get consensus on a > WG note and it does not need > ... to hold up TTML2, so I think if you want to draft something > then go ahead. > ... Is a problem here that it is a misuse of PNG in some way? > > Pierre: That's a really big question, on review I think not. > PNG allows for arbitrary > ... gamma exponents but it only supports power law EOTFs and > also arbitrary ICC color profiles, > ... so it is not clearly an abuse of PNG, just not using one of > the built in EOTF gamma curves > ... defined today, instead using an ICC which is permitted. I > think this is classed as a > ... permitted extension. It may be better if PNG were to > support EOTFs other than just gamma, > ... but that's something that others in W3C may want to work > on. > > Mike: Would changes to PNG be made in ISO or W3C? > > Philippe: It would be W3C. It certainly has been developed > jointly in the past with ISO. I can > ... even give you the right contact in W3C. > > Pierre: Maybe the sequence of events is to draft the WG Note > and then see if there is further > ... interest. > > Philippe: Chris Lilley created the Color CG with Mark Watson - > Chris is the guy to talk to > > <plh> [18]https://github.com/w3c/strategy/issues/58 > > [18] https://github.com/w3c/strategy/issues/58 > > Philippe: in any case and he is also the one tracking our PNG > stuff such as the above issue. > > Nigel: WG Notes can be turned into Recs later, right? > > Philippe: Yes they can or they can be parked. > > Pierre: My position is we should publish the WG Note and then > make it available to the Color CG, > ... and even bring Chris Lilley into that work. That makes it > really concrete. > > Nigel: I'm happy with that. > > Mike: I don't have a particular plan in mind I just wanted to > raise the question and see if > ... there is another group we should collaborate on it. This > plan to publish a WG Note and > ... then work with others is a good plan. > > Pierre: Ideally PNG would be updated to take into account these > new use cases, but that > ... would take some work to get sufficient critical mass. > > Nigel: I've added a comment to the issue on this. > > Pierre: Could we create a repo for this? > > Philippe: Sure, what name do you want? > > Group: [some discussion] png-hdr-pq > > Nigel: That allows for other HDR extensions to PNG, if needed, > to be placed in other WG Notes > ... whose repositories would be called e.g. png-hdr-??? where > ??? would be replaced. > > Philippe: I'll get onto that. > > Nigel: Thank you! > > <plh> [19]https://github.com/w3c/png-hdr-pq > > [19] https://github.com/w3c/png-hdr-pq > > Nigel: I've added a link to that and closed the issue - any > request to create a reference to > ... the WG Note should be done in a separate new issue. > > Pierre: I'll use Respec for this. > > Philippe: I'll set it up for the WG Note. > ... I will also set up the master branch to be the one that > github.io serves. > > Pierre: That's great. > > Philippe: I did the same thing for the imsc-tests repo as well. > ... And it is replicated on the W3C website. > > <scribe> ACTION: tmichel Update the TTWG homepage and > publications pages for the new repos [recorded in > [20]http://www.w3.org/2017/04/13-tt-minutes.html#action01] > > [20] http://www.w3.org/2017/04/13-tt-minutes.html#action01 > > <trackbot> Created ACTION-495 - Update the ttwg homepage and > publications pages for the new repos [on Thierry Michel - due > 2017-04-20]. > > Nigel: I think we've run out of steam for today. Thanks all. We > have 2 hours again next week. [adjourns meeting] > > Summary of Action Items > > [NEW] ACTION: tmichel Update the TTWG homepage and publications > pages for the new repos [recorded in > [21]http://www.w3.org/2017/04/13-tt-minutes.html#action01] > > [21] http://www.w3.org/2017/04/13-tt-minutes.html#action01 > > Summary of Resolutions > > [End of minutes] > __________________________________________________________ > > > Minutes formatted by David Booth's [22]scribe.perl version > 1.152 ([23]CVS log) > $Date: 2017/04/13 16:20:49 $ > > [22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [23] http://dev.w3.org/cvsweb/2002/scribe/ > > > > > ---------------------------- > > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and may contain personal > views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in > reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > --------------------- >
Received on Thursday, 13 April 2017 23:57:16 UTC