Meeting minutes
spectranaut_: Want to lock down process for merging
spectranaut_: Suggested not merging unless implemented
spectranaut_: This is what JS does
spectranaut_: HTML requires implementation commitment not implementation
spectranaut_: jcraig prefers that we merge when we have consensus but with a note that it hasn't been implemented yet
spectranaut_: can't test all of aria so can't rely on just linking to tests
spectranaut_: goal is to ease implementors but allow folks reading the spec to know what is implemented
spectranaut_: under discussion particularly if we move to evergreen
<jcraig> issue that spawned the deep dive w3c/
jcraig: some more background could be useful
jcraig: issue that spawned is #2055
<Jem> w3c/
jcraig: wanted the spec to be more permissive - but group went a different way adding name from heading. PR went through review many years ago then counterpart issues filed - bugs filed against user agents etc. Trying to follow process
jcraig: PR still not merged, bugs not fixed. Reason brought this up - ideally would have wpt tests merged ahead of implemetation
jcraig: seemed unintentionally circular. not sure how to move forward
jcraig: spectranaut_ proposed a few different options
jcraig: have a couple of different proposals
<jcraig> w3c/
jcraig: effectively what I would like is write spec prose - get signoff. Including notes with links to details including wpt tests etc. Point is it would unblock downstream changes.
<Jem> only difference from Val's two suggestion seems to be only note section. is that right?
spectranaut_: process I suggested is that have a slight preference for a spec which only has implemented stuff in it
<Jem> It would be also great we have one place - index page - to go which one is implemneted or not.
spectranaut_: 2nd proposal is to write spec prose and get signoff from the wg. Then write and land wpt tests. Has precedent in wpt itself - each spec follows their own way of landing changes. Then implementors have something to go off
spectranaut_: at that time you open bugs on browsers
<Jem> who would write and land wpt test? valerie or james?
spectranaut_: then when have at least 1 implementation AND commitments can then land it
<Zakim> jamesn, you wanted to ask how this can work for features which impact large parts of the spec
Matt: 3 questions
Matt: When there are changes from 2 different PRs which affects multiple parts of the spec someone would have to distinguish between them
Matt: would need to be some way of indicating which changes to word in the spec are related to each feature change when there are multiple that are not yet implemented
Matt: don't have that problem in spectranaut_ proposal
Matt: so it is easy to read and understand
Matt: when we go evergreen is the editors draft the evergreen spec
jamesn: normally yes but doesn't have to be
Matt: is the fundamental problem that it is hard to make inter-spec dependencies
<Zakim> jcraig, you wanted to ask how it the PR proposal could work for large changes... concerns are: multiple PRs, implementers time constraints (we're potentially adding confusion for the front line engineers) and to mention conflicts with multi-year PRs
jcraig: opposite is that I can't see how proposal 1 works for anything with large changes
jcraig: concern is that have features which hang around for a long time
jcraig: potentially discourages additional contributors to WG
jcraig: ideally the spec PR could reference accname
jcraig: and vice versa
jcraig: merge conflicts is one of the big issues
<Zakim> Jem, you wanted to ask about the ownership of each process such as wpt and how and when would you be ableto confirm "commitment"
jcraig: core differnce between proposals the implemeting engineers would not have the cross referencing issue
jcraig: we have something in the spec that is known not to be implmented
Matt: linking is a technical issue so want a technical solution
Matt: merge conflicts is a non technical issue
Matt: you shouldn't feel like once it is merged it is done - you can't move on until it is implemented
Matt: it is important that someone leading a change moves it from start to end
Matt: if implmentations are really slow on small changes then that might create a problem
<Jem> one way to think about this topic may be categorizing complex issues vs simple issue and each have the different process.
Matt: idea... for the specs with most inderdepencies
Matt: what if they were all in the same repo - then you could have a PR with links from each
<Jem> I like the one repo idea! interconnectivity of the ARIA work.
<Jem> united world
Matt: could solve the technical challenge of linking across documents
spectranaut_: responding to 3 points
spectranaut_: new contributors would hopefully not run across large issues like these
spectranaut_: clear issues on browsers - Need to add the links to all the specs in browser PRs
spectranaut_: it is true the links between specs wouldn't work but language in issues is
spectranaut_: merge conflicts would help
<Jem> /me I think we are talking about the base problem, ownership, commitment, "sheperding" which block us to move on.
Matt: if small changes haven't been implemented soon then it is maybe a problem
Matt: would rather a PR with merge conficts that is 2 years old
<Zakim> jcraig, you wanted to add-on… We could keep the issue tracker repos separately, but have all the PRs in the main ARIA repo...
<spectranaut_> Jem: I want to hear your thoughts about those thing
jcraig: I think your proposal could solve the largest issues
jcraig: issue trackers can be separate like WPT
jcraig: could move the source files to aria
jcraig: could work
jcraig: pointing to one PR could maybe work.
<Jem> I like warning idea a lot.
<spectranaut_> +1 to link to tests, good idea about link to issues
<Jem> warning idea is also similar to "current status"
jcraig: for things that aren't testable could have links still
<jcraig> add an "implementation notes" section to each relevant feature?
aaron: imagining the different things - some things change an already implemented feature. Like the idea of flagging - don't like fixing merge conflicts. Wonder how flags will work with the messy reality
<Jem> flagging = warning = current status?
aaron: each change is interesting in its own right
<Jem> flagging = warning = current status = implementation note?
<Jem> +1 to explore the idea of one repo
<Jem> how about warning?