W3C home > Mailing lists > Public > public-tt@w3.org > February 2016

Re: {minutes} TTWG Meeting 2016-01-28

From: Glenn Adams <glenn@skynav.com>
Date: Tue, 2 Feb 2016 12:43:25 -0700
Message-ID: <CACQ=j+dJ7stMSgtQTg+yFMG56-FnrHvFXhxozrOr9K8hKogExA@mail.gmail.com>
To: Pierre-Anthony Lemieux <pal@sandflow.com>
Cc: Dae Kim <dakim@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>
It was just a minor term, and certainly not required to interpret or
implement @condition.

On Tue, Feb 2, 2016 at 12:31 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Thanks for adding a definition for "conditionalized element" in the latest
> ED!
>
> Best,
>
> -- Pierre
>
> On Fri, Jan 29, 2016 at 9:30 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > On Fri, Jan 29, 2016 at 10:24 AM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> > btw, what does "conditionalized element" have to do with the initial
> >> > element?
> >>
> >> "conditionalized element" is referenced in the definition of
> >> <condition>, which is referenced by the definition of <initial>.
> >
> >
> > most every element type in TTML2 now specifies optional use of the
> > @condition attribute; so that isn't related to the initial element as
> such
> >
> >>
> >>
> >> More importantly, TTML2 is unfinished, so I am interested in
> >> understanding how users plan to use it, so that their feedback can
> >> guide decisions by the group, including features at risk.
> >
> >
> > there are no features at risk at this juncture, since we have not
> surveyed
> > any implementations to determine coverage; i am aware of at least two
> > implementations that support the condition element
> >
> >>
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Fri, Jan 29, 2016 at 9:16 AM, Glenn Adams <glenn@skynav.com> wrote:
> >> >
> >> >
> >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux
> >> > <pal@sandflow.com>
> >> > wrote:
> >> >>
> >> >> Hi Dae,
> >> >>
> >> >> > initial
> >> >>
> >> >> How does Netflix plan to use <initial>?
> >> >>
> >> >> The current ED states "conditionalized element" is "To Be Defined".
> >> >
> >> >
> >> > btw, what does "conditionalized element" have to do with the initial
> >> > element?
> >> >
> >> >>
> >> >>
> >> >> Best,
> >> >>
> >> >> -- Pierre
> >> >>
> >> >> On Thu, Jan 28, 2016 at 9:35 AM, Dae Kim <dakim@netflix.com> wrote:
> >> >> > Hello all,
> >> >> >
> >> >> > We're starting to engage with subtitle program vendors for TTML2
> >> >> > support
> >> >> > and
> >> >> > I'm hoping the following features will be preserved as-is to Rec:
> >> >> >
> >> >> > initial
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#styling-vocabulary-initial
> >> >> >
> >> >> > tts:position
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-position
> >> >> >
> >> >> > tts:textEmphasis
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-textEmphasis
> >> >> >
> >> >> > tts:ruby
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-ruby
> >> >> >
> >> >> > tts:rubyAlign
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyAlign
> >> >> >
> >> >> > tts:rubyPosition
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyPosition
> >> >> >
> >> >> > tts:rubyReserve (specifically, "outside")
> >> >> >
> >> >> >
> >> >> >
> https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyReserve
> >> >> >
> >> >> > If everyone can kindly review, I'd like to collect everyone's
> >> >> > opinions
> >> >> > on
> >> >> > these.
> >> >> >
> >> >> >
> >> >> > Cheers, Dae
> >> >> >
> >> >> >
> >> >> >
> >> >> > Dae Kim | Video Engineer | Encoding Technology
> >> >> > 9420 94f4 a834 b038 2920 34b3 38ad b632 3738 942c 942f
> >> >> >
> >> >> > On Thu, Jan 28, 2016 at 8:34 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 https://www.w3.org/2016/01/28-tt-minutes.html
> >> >> >>
> >> >> >> In text format:
> >> >> >>
> >> >> >>    [1]W3C
> >> >> >>
> >> >> >>       [1] http://www.w3.org/
> >> >> >>
> >> >> >>                 Timed Text Working Group Teleconference
> >> >> >>
> >> >> >> 28 Jan 2016
> >> >> >>
> >> >> >>    See also: [2]IRC log
> >> >> >>
> >> >> >>       [2] http://www.w3.org/2016/01/28-tt-irc
> >> >> >>
> >> >> >> Attendees
> >> >> >>
> >> >> >>    Present
> >> >> >>           nigel, andreas, pierre, shinjan, glenn, tmichel, dae
> >> >> >>
> >> >> >>    Regrets
> >> >> >>           frans
> >> >> >>
> >> >> >>    Chair
> >> >> >>           nigel
> >> >> >>
> >> >> >>    Scribe
> >> >> >>           nigel
> >> >> >>
> >> >> >> Contents
> >> >> >>
> >> >> >>      * [3]Topics
> >> >> >>          1. [4]This Meeting
> >> >> >>          2. [5]Action Items
> >> >> >>          3. [6]IMSC issues
> >> >> >>          4. [7]Commit policy on github
> >> >> >>      * [8]Summary of Action Items
> >> >> >>      * [9]Summary of Resolutions
> >> >> >>      __________________________________________________________
> >> >> >>
> >> >> >>    <tmichel> I will be a few minutres late ...
> >> >> >>
> >> >> >>    <scribe> scribe: nigel
> >> >> >>
> >> >> >> This Meeting
> >> >> >>
> >> >> >>    nigel: [Goes through likely topics for meeting]: Actions, IMSC
> >> >> >>    1 issues, TTML2, possibly profiles
> >> >> >>    ... Any specific topics to cover, or AOB?
> >> >> >>
> >> >> >>    pal: IMSC 1 issues please
> >> >> >>
> >> >> >>    nigel: Yes
> >> >> >>
> >> >> >>    glenn: I'd like to discuss commit policy on github
> >> >> >>
> >> >> >>    nigel: Okay
> >> >> >>
> >> >> >> Action Items
> >> >> >>
> >> >> >>    action-453?
> >> >> >>
> >> >> >>    <trackbot> action-453 -- Thierry Michel to Schedule between
> >> >> >>    tmichel and philippe the transition to cr3 with any director
> >> >> >>    call as needed. -- due 2016-01-21 -- PENDINGREVIEW
> >> >> >>
> >> >> >>    <trackbot>
> >> >> >>    [10]http://www.w3.org/AudioVideo/TT/tracker/actions/453
> >> >> >>
> >> >> >>      [10] http://www.w3.org/AudioVideo/TT/tracker/actions/453
> >> >> >>
> >> >> >>    tmichel: IMSC 1 CR3 is published and has been announced to AC
> >> >> >>    and Chairs, and triggered a 2 month patent exclusion
> >> >> >>
> >> >> >>    close action-453
> >> >> >>
> >> >> >>    <trackbot> Closed action-453.
> >> >> >>
> >> >> >>    tmichel: I had to extend the CR exit point to Feb 28 because we
> >> >> >>    moved the publication back by 2 days.
> >> >> >>
> >> >> >>    nigel: Thanks
> >> >> >>
> >> >> >>    pal: I'll modify that on github too - Feb 28?
> >> >> >>
> >> >> >>    tmichel: Feb 28 yes
> >> >> >>
> >> >> >>    nigel: Thanks everyone whose helped with publication of that
> >> >> >>    CR.
> >> >> >>
> >> >> >>    action-454?
> >> >> >>
> >> >> >>    <trackbot> action-454 -- Philippe Le Hégaret to Create stub
> >> >> >>    files to redirect from hg to github for ttml1 and ttml2 -- due
> >> >> >>    2016-01-28 -- PENDINGREVIEW
> >> >> >>
> >> >> >>    <trackbot>
> >> >> >>    [11]http://www.w3.org/AudioVideo/TT/tracker/actions/454
> >> >> >>
> >> >> >>      [11] http://www.w3.org/AudioVideo/TT/tracker/actions/454
> >> >> >>
> >> >> >>    glenn: I noticed on the CR3 that a message was issued, a call
> >> >> >>    for exclusions message. Is a call for exclusions a
> >> >> >>    ... multiple event or a single event? Normally in the past
> >> >> >>    process a call for exclusions only occurred on the first CR
> >> >> >>    ... but not subsequent CRs. Has that changed?
> >> >> >>
> >> >> >>    tmichel: It's actually the com team who does that. I don't
> >> >> >>    remember - I need to check if we sent an exclusion for the
> >> >> >>    ... 2nd CR and will look into it and let you know. My
> >> >> >>    interpretation is every CR publication triggers an exclusion
> >> >> >>    ... period of 2 months, but I will investigate.
> >> >> >>    ... It makes sense because if you add functionality into the CR
> >> >> >>    version then it may result in a patent exclusion.
> >> >> >>
> >> >> >>    glenn: I agree.
> >> >> >>
> >> >> >>    action-454?
> >> >> >>
> >> >> >>    nigel: Okay I guess we'll close this one.
> >> >> >>
> >> >> >>    close action-454
> >> >> >>
> >> >> >>    <trackbot> Closed action-454.
> >> >> >>
> >> >> >>    action-455?
> >> >> >>
> >> >> >>    <trackbot> action-455 -- Glenn Adams to Update ttml2
> >> >> >>    spec/readme to include config for keyword replacement. -- due
> >> >> >>    2016-01-28 -- OPEN
> >> >> >>
> >> >> >>    <trackbot>
> >> >> >>    [12]http://www.w3.org/AudioVideo/TT/tracker/actions/455
> >> >> >>
> >> >> >>      [12] http://www.w3.org/AudioVideo/TT/tracker/actions/455
> >> >> >>
> >> >> >>    action-445?
> >> >> >>
> >> >> >>    <trackbot> action-445 -- Andreas Tai to Propose to mdolan this
> >> >> >>    addition to the profile registry document. -- due 2015-11-06 --
> >> >> >>    OPEN
> >> >> >>
> >> >> >>    <trackbot>
> >> >> >>    [13]http://www.w3.org/AudioVideo/TT/tracker/actions/445
> >> >> >>
> >> >> >>      [13] http://www.w3.org/AudioVideo/TT/tracker/actions/445
> >> >> >>
> >> >> >>    atai: I checked with Mike and will make a proposal for a new
> >> >> >>    column for the profile registry table that shows where
> >> >> >>    ... the profile information can be found inside the TTML
> >> >> >>    document instance for the corresponding TTML profile
> >> >> >>    specification.
> >> >> >>    ... Some are for ttp:profile attribute, or element, or
> >> >> >>    ebuttm:documentConformsToStandard element.
> >> >> >>
> >> >> >>    mike: Andreas and I exchanged a couple of emails and it makes
> >> >> >>    sense to me.
> >> >> >>    ... I'm hopelessly behind on the profile document!
> >> >> >>
> >> >> >>    nigel: What can I do to help?
> >> >> >>
> >> >> >>    mike: The wiki is what I think we want to produce, in the text.
> >> >> >>    It's more about putting it into a document template
> >> >> >>    ... and using the tools to publish it in W3C.
> >> >> >>
> >> >> >>    nigel: Thierry, would you be able to assist?
> >> >> >>
> >> >> >>    tmichel: Yes, I'd be happy to help turn the wiki text into a
> >> >> >>    first version on github
> >> >> >>
> >> >> >>    action-429?
> >> >> >>
> >> >> >>    <trackbot> action-429 -- Mike Dolan to Draft a wg note for the
> >> >> >>    profile short name registry and ttml media type registration --
> >> >> >>    due 2015-10-08 -- OPEN
> >> >> >>
> >> >> >>    <trackbot>
> >> >> >>    [14]http://www.w3.org/AudioVideo/TT/tracker/actions/429
> >> >> >>
> >> >> >>      [14] http://www.w3.org/AudioVideo/TT/tracker/actions/429
> >> >> >>
> >> >> >>    action-429: [TTWG meeting 2016-01-28] tmichel to help this
> >> >> >>    along with a first draft on github
> >> >> >>
> >> >> >>    <trackbot> Notes added to action-429 Draft a wg note for the
> >> >> >>    profile short name registry and ttml media type registration.
> >> >> >>
> >> >> >>    close action-445
> >> >> >>
> >> >> >>    <trackbot> Closed action-445.
> >> >> >>
> >> >> >> IMSC issues
> >> >> >>
> >> >> >>    pal: I'd like to start with issue #127
> >> >> >>
> >> >> >>    [15]https://github.com/w3c/imsc/issues/127
> >> >> >>
> >> >> >>      [15] https://github.com/w3c/imsc/issues/127
> >> >> >>
> >> >> >>    nigel: Extensibility goals not documented
> >> >> >>
> >> >> >>    pal: The discussion is whether or how IMSC 1 can have an
> >> >> >>    opinion on IMSC 2 and how an IMSC 1 document will be
> >> >> >>    ... processed by an IMSC 2 processor and vice versa. Before we
> >> >> >>    have started on IMSC 2 it is very difficult to have a
> >> >> >>    ... good opinion. I think we should have that discussion when
> >> >> >>    we start on IMSC 2.
> >> >> >>
> >> >> >>    glenn: The issue here is whether we address this in IMSC 1 or
> >> >> >>    wait. I'm insisting on addressing it in IMSC 1 and not
> >> >> >>    ... waiting. I agree that it needs a bit of thinking. We don't
> >> >> >>    have to refer to IMSC 2, we can simply refer to future
> >> >> >>    ... versions. At least TTML2 talks about future and past
> >> >> >>    versions.
> >> >> >>    ... In retrospect we should have given more thought to
> >> >> >>    extensibility and at least documented our goals. I'm asking
> >> >> >>    ... for informative material that describes our goals. It would
> >> >> >>    be a sad state of affairs if we cannot document our goals now.
> >> >> >>
> >> >> >>    pal: I don't think this is as dire as you just painted it. IMSC
> >> >> >>    1 already allows foreign vocabulary, which allows for
> >> >> >>    ... straightforward extensibility.
> >> >> >>
> >> >> >>    glenn: It may be sufficient to describe those goals, for
> >> >> >>    example the goal of supporting vocabulary not in IMSC 1.
> >> >> >>
> >> >> >>    pal: That's §6.2
> >> >> >>
> >> >> >>    glenn: I'm asking for a specifically labelled section on goals,
> >> >> >>    in an annex, the introduction or somewhere else.
> >> >> >>
> >> >> >>    pal: Okay. I don't really know how to write that section. I'd
> >> >> >>    like to consider a concrete proposal.
> >> >> >>
> >> >> >>    glenn: I hope people already have goals in mind and could
> >> >> >>    articulate them.
> >> >> >>    ... Foreign vocabulary is one goal. The same comments are going
> >> >> >>    to apply with #126 on interoperability.
> >> >> >>
> >> >> >>    nigel: [opens up to group to offer options for extensibility]
> >> >> >>
> >> >> >>    glenn: Both forward and backward compatibility come into this
> >> >> >>    category. I would hope that a goal is to be as
> >> >> >>    ... forward and backward compatible as possible, as a generic
> >> >> >>    goal that applies to most of W3C development.
> >> >> >>    ... That doesn't mean it's not possible to create a breaking
> >> >> >>    change in the future. If we think that such a breaking change
> >> >> >>    ... could occur then we could document it as a discussion
> >> >> >>    point.
> >> >> >>
> >> >> >>    nigel: One of the points I think is probably implied is that
> >> >> >>    the purpose of the profile exercise is that extensions from
> >> >> >>    within TTML are excluded unless listed.
> >> >> >>
> >> >> >>    glenn: Since we don't list all the features there's an
> >> >> >>    implication that unlisted features from TTML 1 are permissible
> >> >> >>    in IMSC 1, yes?
> >> >> >>
> >> >> >>    pal: We put a significant effort in to list all TTML 1 profile
> >> >> >>    features.
> >> >> >>
> >> >> >>    glenn: Okay, so all features from TTML Annex D are listed as
> >> >> >>    prohibited or permitted, yes?
> >> >> >>
> >> >> >>    pal: Yes, that was the goal, and I think we achieved it.
> >> >> >>
> >> >> >>    glenn: We could argue about if that's extensibility or
> >> >> >>    interoperability, but it is possibly both, so we could discuss
> >> >> >>    that under extensibility goals.
> >> >> >>    ... I suggest we open this up for comments over the next couple
> >> >> >>    of weeks and that I will draft a proposal based on that.
> >> >> >>
> >> >> >>    nigel: Those comments should be on the github issue
> >> >> >>
> >> >> >>    pal: What are we asking people to do?
> >> >> >>
> >> >> >>    glenn: Give us opinions on what are and are not extensibility
> >> >> >>    goals.
> >> >> >>    ... I haven't written down my own thoughts on this yet. I'm
> >> >> >>    more struck by the absence of this topic than anything else.
> >> >> >>    That was my point in filing the issue.
> >> >> >>    ... I'm prepared to draft something but can't articulate my own
> >> >> >>    thinking on this right now.
> >> >> >>
> >> >> >>    nigel: I think we should be careful to understand if we need
> >> >> >>    this or if we can build on something already in TTML1
> >> >> >>    ... by inheritance?
> >> >> >>
> >> >> >>    glenn: I don't think we have extensibility goals described in
> >> >> >>    TTML1
> >> >> >>    ... which in retrospect we should have put in.
> >> >> >>    ... In TTML1 we used a QA guideline checklist. One of the
> >> >> >>    points there was a set of good practices. Number 18
> >> >> >>    ... states that if extensibility is allowed define an extension
> >> >> >>    mechanism.
> >> >> >>    ... I suggest we review what's in IMSC 1 and TTML 1 and go from
> >> >> >>    there.
> >> >> >>
> >> >> >>    nigel: Okay so action on everyone to complete this research and
> >> >> >>    record their goals in the issue.
> >> >> >>
> >> >> >>    glenn: Very much the same comments apply to the
> >> >> >>    interoperability issue.
> >> >> >>
> >> >> >>    pal: What's the time box that we have on this?
> >> >> >>
> >> >> >>    glenn: I can respond by mid-Feb with some material.
> >> >> >>
> >> >> >>    nigel: Okay, that sounds like 2 weeks to note extensibility and
> >> >> >>    interoperability goals in the github issues.
> >> >> >>
> >> >> >>    pal: How are we doing on #111 and #114?
> >> >> >>
> >> >> >>    glenn: I've got to draft some material based on a conversation
> >> >> >>    I had with Nigel, where we think we may be able to resolve both
> >> >> >>    of those.
> >> >> >>    ... Mid-Feb is reasonable for those too.
> >> >> >>
> >> >> >>    pal: #125 [16]https://github.com/w3c/imsc/issues/125 Unable to
> >> >> >>    normatively determine non-conformance when testing content
> >> >> >>    constraints.
> >> >> >>
> >> >> >>      [16] https://github.com/w3c/imsc/issues/125
> >> >> >>
> >> >> >>    glenn: At present IMSC 1 specifies that if a document is not
> >> >> >>    conformant then behaviour is undefined. Correct?
> >> >> >>
> >> >> >>    pal: Correct. The document does not specify a normative
> >> >> >>    behaviour in the presence of a non-conformant document.
> >> >> >>
> >> >> >>    glenn: A couple of points: 1. Since all behaviour re
> >> >> >>    non-conformance is unspecified then it is impossible to
> >> >> >>    normatively
> >> >> >>    ... test non-conformance because any outcome is possible, from
> >> >> >>    aborting to ignoring and anything in between.
> >> >> >>    ... I'm not happy with that state of affairs. Part 2, which I
> >> >> >>    did make a proposal for, is to introduce the concept of a
> >> >> >>    ... validating processor and to allow for some normative
> >> >> >>    behaviour in the face of non-conformance if and when the
> >> >> >>    ... IMSC processor is also a validating processor. So an IMSC
> >> >> >>    transformation or validation processor that also supports
> >> >> >>    ... validation and it is enabled then it is possible to define
> >> >> >>    some constraints on non-conformance.
> >> >> >>
> >> >> >>    atai: I thought the conclusion here from previous meetings when
> >> >> >>    we discussed this is that handling of non-conformant
> >> >> >>    ... files is out of spec and I agree with that. What Glenn
> >> >> >>    wants to define is behaviour on encountering non-conformant
> >> >> >>    documents.
> >> >> >>    ... I think that's out of scope of the spec. The topic came up
> >> >> >>    before and from what I read of the minutes the conclusion
> >> >> >>    ... was out of scope.
> >> >> >>
> >> >> >>    pal: That's my recollection, but it sounds like Glenn is
> >> >> >>    proposing something a little narrower, only for validating
> >> >> >>    processors.
> >> >> >>    ... So for those who choose to describe processors as
> >> >> >>    validating then this is the behaviour.
> >> >> >>
> >> >> >>    glenn: That's right. I don't disagree with Andreas but I think
> >> >> >>    we can do better than that at little or no cost to the
> >> >> >>    specification.
> >> >> >>    ... For example the TTT toolset has a presentation engine in
> >> >> >>    it. It performs validation processing as a precursor to
> >> >> >>    ... presentation. It's an existing implementation (also of a
> >> >> >>    transformation processor) that does implement the optional
> >> >> >>    ... features of validation. So we can go further than saying
> >> >> >>    it's completely out of scope and having normative
> >> >> >>    ... language that allows us to introduce defined behaviour.
> >> >> >>
> >> >> >>    pal: The particular thing here is that it's a class of
> >> >> >>    processors described as validating processors.
> >> >> >>
> >> >> >>    glenn: Yes, TTML2 introduces these all formally along with some
> >> >> >>    specific vocabulary for controlling it. I didn't want
> >> >> >>    ... to inject that into this proposal because that would be
> >> >> >>    going too far, but I took the semantics of what we're
> >> >> >>    ... proposing and put them into a form that we could adopt in
> >> >> >>    IMSC 1.
> >> >> >>
> >> >> >>    atai: Thank you for the clarification. It is of course a
> >> >> >>    different use case. I would like to see the concrete proposal.
> >> >> >>    ... There are of course existing possibilities to check
> >> >> >>    conformance, for example using an XML schema. This already
> >> >> >>    ... has a defined behaviour for how to identify
> >> >> >>    non-conformance. I'm not sure if we should also define
> >> >> >>    behaviour for
> >> >> >>    ... QC processes of TTML.
> >> >> >>
> >> >> >>    glenn: Take a look at #125 because there is a proposed set of
> >> >> >>    language there.
> >> >> >>
> >> >> >> Commit policy on github
> >> >> >>
> >> >> >>    glenn: There are two kinds of policies that are commonly used
> >> >> >>    in development - Review Then Commit, when a
> >> >> >>    ... consensus approval is obtained prior to a commit. Then
> >> >> >>    there's Commit Then Review, which allows a
> >> >> >>    ... retroactive veto. In the history of this group all of the
> >> >> >>    work on TTML1 and TTML2 in Mercurial and CVS was done
> >> >> >>    ... on a Commit Then Review (CTR) lazy consensus process. It
> >> >> >>    was based on the editor to decide when to commit
> >> >> >>    ... and then notify the group and make sure that they had log
> >> >> >>    info to give them a chance to review post facto and
> >> >> >>    ... object if necessary. Most teams follow a CTR process
> >> >> >>    because it provides the least barriers to making changes.
> >> >> >>    ... It can result in more bugs potentially. My experience is
> >> >> >>    I've worked with both kinds of processes. With github
> >> >> >>    ... which has a Pull Request mechanism it is possible to
> >> >> >>    snapshot the changes and call them out for review. We
> >> >> >>    ... discussed and agreed the move to github in Sapporo and
> >> >> >>    talked about the review process but I don't recall doing
> >> >> >>    ... so in depth. At the time I remember thinking it should be
> >> >> >>    up to the Editor to decide how to use that facility. I never
> >> >> >>    ... anticipated changing from CTR to RTC. Recently both Nigel
> >> >> >>    and Pierre have in the context of IMSC 1 been following
> >> >> >>    ... a RTC process in their thinking. I would object to that for
> >> >> >>    TTML2. I might be willing to agree to it for other work.
> >> >> >>    ... I find it a strong barrier to process. For example right
> >> >> >>    now I have 4 different issues that Pierre has delegated to me
> >> >> >>    ... to create PRs. All of those fixes are going to change the
> >> >> >>    same lines of code.
> >> >> >>
> >> >> >>    pal: I think there's a misunderstanding - you can create a PR
> >> >> >>    that covers multiple issues, and we've done that in the
> >> >> >>    ... past.
> >> >> >>
> >> >> >>    glenn: I agree that's possible.
> >> >> >>
> >> >> >>    nigel: github also provides a tool for merging work in other
> >> >> >>    branches to resolve the clashes.
> >> >> >>
> >> >> >>    glenn: I agree there are tools there but it's much more awkward
> >> >> >>    and difficult to do that. My basic point is that
> >> >> >>    ... we don't have a firm consensus on CTR or RTC as a policy.
> >> >> >>    Secondly even if we are using RTC on e.g. IMSC 1 I don't
> >> >> >>    ... think it should be a blanket policy but up to the Editor to
> >> >> >>    decide what policy to use. For trivial changes there's
> >> >> >>    ... no reason to follow the more time consuming process.
> >> >> >>
> >> >> >>    atai: I think we should check again what we discussed at TPAC.
> >> >> >>    I think we explicitly had some discussion about the
> >> >> >>    ... new policy with github and I thought we agreed but I'm not
> >> >> >>    sure.
> >> >> >>
> >> >> >>    nigel: We did discuss this in Sapporo and I'm pretty sure we
> >> >> >>    did agree that. For WDs we always followed a RTC process
> >> >> >>    ... and said that to reduce the time between ED updates and WD
> >> >> >>    publications and to use the automated WD publication
> >> >> >>    ... tool we would use PRs.
> >> >> >>
> >> >> >>    glenn: I do recall saying that I wouldn't be happy to adopt
> >> >> >>    this for TTML2.
> >> >> >>
> >> >> >>    nigel: I'm happy to review the notes on this and return to it
> >> >> >>    as a topic. In the meantime I would also like plh's views
> >> >> >>    ... and I would myself strongly recommend that we use pull
> >> >> >>    requests for everything including TTML2.
> >> >> >>
> >> >> >>    glenn: I don't mind using pull requests but I object to a 2
> >> >> >>    week period before a merge is permitted.
> >> >> >>    ... I think it should be up to the Editor or possibly the Chair
> >> >> >>    to decide to merge if a change is non controversial and
> >> >> >>    ... not to impose a 2 week delay on all PRs.
> >> >> >>
> >> >> >>    nigel: That's coincident with what we said in Sapporo. There
> >> >> >>    may be a middle ground there that is actually acceptable.
> >> >> >>
> >> >> >>    glenn and pal: [discussion without conclusion on who should be
> >> >> >>    allowed to merge pull requests]
> >> >> >>
> >> >> >>    nigel: We're out of time now so I'll adjourn. An hour again,
> >> >> >>    same time next week. Thanks everyone [adjourns meeting]
> >> >> >>
> >> >> >> Summary of Action Items
> >> >> >>
> >> >> >> Summary of Resolutions
> >> >> >>
> >> >> >>    [End of minutes]
> >> >> >>      __________________________________________________________
> >> >> >>
> >> >> >>
> >> >> >>     Minutes formatted by David Booth's [17]scribe.perl version
> >> >> >>     1.144 ([18]CVS log)
> >> >> >>     $Date: 2016/01/28 16:33:11 $
> >> >> >>
> >> >> >>      [17]
> >> >> >> http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
> >> >> >>      [18] 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 Tuesday, 2 February 2016 19:44:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:27 UTC