Publishing Working Group Telco — Minutes

Date: 2017-12-18

See also the Agenda and the IRC Log

Attendees

Present: Nick Ruffilo, Ric Wright, Dave Cramer, Ivan Herman, George Kerscher, Jun Gamou, Wolfgang Schindler, Deborah Kaplan, Tzviya Siegman, Matt Garrish, Wendy Reid, Peter Krautzberger, Avneesh Singh, Tim Cole, Romain Deltour, Charles LaPierre, Jasmine Mulliken, Garth Conboy, Joshua Pyle, Mateus Teixeira, Toshiaki Koike, Heather Flanagan, Bill Kasdorf, Marisa DeMeglio, Hadrien Gardeur, Ben Schroeter

Regrets: Luc Audrain, Baldur Bjarnason, Evan Owens, Hadrien Gardeur, Lillian Sullam

Guests:

Chair: Tzviya Siegman

Scribe(s): Nick Ruffilo

Content:

Nick Ruffilo: scribenick:

Tzviya Siegman: Lets begin with approval of last week’s minutes.

1. minute approval

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2017/2017-12-11-minutes.html

Resolution #1: last week’s minutes approved

2. minor change to the locator document

Tzviya Siegman: https://github.com/w3c/publ-loc/pull/42

Tzviya Siegman: Minor change to locators document. Ivan would you mind going over?

Tim Cole: https://w3c.github.io/wpub-ann/

Ivan Herman: It’s minor, I’ve sent an email around earlier today. Based on the vote we had - the name has changed. So did the short-name and repository name. If you have your local copy - be careful, but github should redirect. What Tim did before making the change is taking the issues around fragment ID: we had this discussion that fragment ID would only make sense with a package, but we don’t have a package yet. What Tim did was add an editorial note to make it clear that if we don’t have our own package and don’t have a media type, this section is moot and will be removed. With that, I have finalized all three documents - they are ready to go for a first public working draft. Unless there is an objection on this call, I’ll put in the request for publication.

Tim Cole: Ivan got it right. One more thing: there were a couple of issues raised last week. One had to do with the defintion of selectors not being a normative definition of the term which CSS established. Not sure if it has any implications,, but we had a link to that issue in the draft with and editors note saying that things may change if that issues is addressed. The main thing is about changing the name and cleaning up the loose ends.

Tzviya Siegman: Comments?
… OK - we assume people are ready to publish as is and we’ll be looking for feedback.

3. Approval for self-publishing process

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Misc/publishing

Tzviya Siegman: Admin note: we hope to move forward with a self-publishing process after we get through this first round of publishing. We just need approval from the group. If you haven’t read this, please do.

Ivan Herman: The consequences for the group - as you’ve seen, we’ve had to go through lots of effort to do the first publication. But, once we are beyond that hurdle, and we set up the necessary background for publishing, what happens is that we can publish as often and easily as we want. We can publish a new version every week. I think it’s good to be able to publish when it gets to a new equilibrium point. This means that the public will always see the latest release. The technology also to say that we prepare the document and merge it to a specific branch on Github, and from there on, it automatically takes that and publishes. For that to happen, we have to go through this ‘publish often’ approach, so there is need for an approval. The high-level goal is good.

Tzviya Siegman: with that, we just need approval from the group. +1, -1 or 0

Dave Cramer: +1

Tzviya Siegman: +1

Tim Cole: +1

Jasmine Mulliken: +1

Mateus Teixeira: +1

Jeff Buehler: +1

Matt Garrish: +1

Jun Gamou: -+1

Heather Flanagan: +1

Wolfgang Schindler: +1

Garth Conboy: +1

Joshua Pyle: +1

Deborah Kaplan: +1

Ivan Herman: +1

Peter Krautzberger: +1

Jun Gamou: +1

Bill Kasdorf: +1

Ric Wright: +1

Romain Deltour: +1

Marisa DeMeglio: +1

Charles LaPierre: +1

George Kerscher: +1

Nick Ruffilo: Why not?

Ivan Herman: some groups want tighter control over things.

Nick Ruffilo: +1

Avneesh Singh: +1

Resolution #2: the group agrees to go for the self-publishing process, a.k.a. ECHIDNA (see details)

4. ARIA Overview

Tzviya Siegman: https://www.w3.org/TR/dpub-aria-1.0/

Tzviya Siegman: next item: you might have seen the announcement of several ARIA specs. Link above.

Dave Cramer: https://developer.paciellogroup.com/blog/2015/01/the-browser-accessibility-tree/

Tzviya Siegman: Here’s a quick overview: ARIA (accessibly rich internet applications) was written not very long ago to bring information to any language for accessibility - assistive technology. it can provide information to the accessibility tree (which some of us don’t know exists). You have the HTML object model, then in parallel is an accessibility tree that is provided to accessibility applications. There are even accessibility APIs that feed into applications that need. The most important thing to be aware of is that if you don’t use ARIA, HTML has native semantics. For example, all HTML elements have native semantics…

Tzviya Siegman: https://www.w3.org/TR/using-aria/

Tzviya Siegman: https://www.w3.org/TR/html-aria/

Tzviya Siegman: https://www.w3.org/TR/dpub-aria-1.0/

Tzviya Siegman: There are a few documents put together by ARIA working group (see above) - step by step instructions on how to use ARIA. The second one will show you the native semantics for an aside - so if you go to the table, you’ll see an aside has native ARIA attributes. That is the first and most important thing to know about ARIA, is that there is much that is implicit. What we did for DPUB Aria, we added some richer semantics to add some semantics but it was never really picked up by accessibility technologies. We then reduced that terminology down to what was more useful. Then we added prefixed-terms to ARIA - so that it would be distinct from the core ARIA tech. There were 20 terms that were added. Many asked how to use - and we provide code examples through the document.

Dave Cramer: http://kb.daisy.org/publishing/

Romain Deltour: http://kb.daisy.org/publishing/

Tzviya Siegman: Then there is a box below every code sample that shows all the ARIA role states and properties associated. I could go into more, and I did a sample webinar to talk about selecting the right items for each element. You should check out the super-class role. That will tell you more information. I could go on for alot longer, and this would be very beneficial for people in the broader publishing role - and provide more of a broader definition. I believe Matt has put these in the DAISY knowledge base. And that’s a basic 101 - we’ve extended the ARIA vocabular with terms useful for publishers and assistive technology

Bill Kasdorf: Do you want to comment on ARIA labels?

Tzviya Siegman: ARIA label is part of the core…

Bill Kasdorf: it provides a label that is not a heading that appears in the text?

Tzviya Siegman: it can do many things… that’s just one it can do…

Bill Kasdorf: the abstract says it does that…

Matt Garrish: It’s probably because it doesn’t have an explicit heading. The ARIA label is meant to have a name for that section.

Bill Kasdorf: that is what I was thinking, just wanted to make sure I picked it up

Tzviya Siegman: That could be seen as a bit misleading - as it seems required…
… Questions?
… Would you appreciate a deeper dive?

Romain Deltour: +1

Tim Cole: +1

Wolfgang Schindler: +1

Bill Kasdorf: +1

Avneesh Singh: +1

Nick Ruffilo: Would love something recordable

George Kerscher: our reading-system testers (as we try to crowd source) it would be great for them - so they can understand the relationship between the content, the ARIA markup, and the reading experience that you end up getting so we can provide feedback to AT developers and reading system people.

5. Reflections on group, next steps

Tzviya Siegman: Congrats to everyone - there was alot of work that went into things. But lets ask - what did we do well, what can we do better - and where are we going?
… I would love to hear what we could do better. There are a few active & vocal people - and there are quite but have important things to say. IRC is a little scary - even our guide to newbies is a little scary. Possibly the best thing we could do for new members - “here’s how to do IRC…” If I understand feedback - if you want to respond, here’s your opportunity.

Heather Flanagan: IRC isn’t scary, but it’s wildly different from the way any other organization actually takes notes and interacts. Folks who didn’t use this in college have a learning curve just to start this.

Tzviya Siegman: It’s good for us to be more welcoming to new and different voices. If you have an idea on github, please express it, but you need not repeat it. Clarification is good, but try not to say things over and over. We do not have lots of examples - there was lots of good that comes from the diagram that was provides. People love to see samples and examples.

Wendy Reid: As a new member - who is trying to keep on top of things - the github is very large and hard to keep on top of. Something that might help less-technical people is to have some summaries - ‘what is web publications’ ‘what are we working on right now’, so when someone like me goes to the github or goes to the draft, we have more context

Bill Kasdorf: +1 to Wendy’s suggestion for brief summaries of the IRC discussion

Tzviya Siegman: every week Ivan sends a summary of the meetings - do you find that helpful?

Wendy Reid: yes

Jeff Buehler: From my standpoint as a new member, I don’t have difficulties with the tech, but there’s a huge amount of information. So much of information pre-exists my joining - so 85-90% I know nothing about, so it feels appropriate to sit back and learn and get context. My co-workers would be surprised to hear that I have nothing to say. Just wanted to add that. But that’s not unusual.

Deborah Kaplan: wolfgang +1

Wolfgang Schindler: If you follow github conversations - so much are quoted - and you cannot read all the specifications, because it would take days. So to say ‘i would use this term’ you should give a short quote or description to get some context - otherwise it’s difficult to join in the discussion because readers might lack the context. You shouldn’t have to read large amounts of spec to understand one or two terms - as not all specs have a definitions section with short explanations. For example - cross references.

Jasmine Mulliken: I’m one of the new people. I really think things are well organized, and I’ve gone throught he documents. I haven’t gone through github because I don’t know where to start and I’m not experienced with it. It might also be helpful in terms of context - it might be useful as to what still needs to be done, and what tasks we might consider contributing to. I’ve brought up on the email some conversations I’ve had, or conversations some of us can have - things like DOIs and being able to assign a DOI for a single page… I am all over the place but I’m trying to go through all the points in the email thread. Just having some sort of context as to where people need to contribute to… Maybe that would be a good place for new people…

Tzviya Siegman: Makes alot of sense - somebody else suggested having a newbies checkin every once in a while. But I do think that would be a good way to do it - and if you’re not familiar with github. In github there are issues. If an issue is still open, that means it hasn’t been addressed yet.

Nick Ruffilo: Maybe have a list of open tasks that people can take - are issues the right place?

Deborah Kaplan: I think I’ve heard this reflected - it took me a while once I heard lots of wise experts with expertise - everything we do and everything we talk about touches these disparate fields. Everyone has expertise. Some have written specs, but we’re all here because we have expertise. I’ve been on both sides - guilty of being wise or feeling guilty. From this corner of field knowledge - knowing something detailed (in my case, accessibility) but I may not know much about locators… We have all different kinds of expertise and it’s important to remember that just because we know one thing well, doesn’t mean we understand the important aspects of everything. And anyone with confidence questions, you’re here because you’re good at this. It’s OK to not know something, and to ask for clarification.

Jasmine Mulliken: <3

Deborah Kaplan: Even if there are experts hashing things out, if you have a different viewpoint, it’s good to bring it up

Jasmine Mulliken: Thanks, Deborah!

Wendy Reid: Thanks, Deborah, I feel the same

Tzviya Siegman: As for DOIs and google scholar, bill - feel free to start that discussion, even if it doesn’t end up as something this group can do.

Peter Krautzberger: sorry, I have to drop off early. happy new year!

Ivan Herman: I have questions that are maybe a little less on the tech side - are there problems that people experience with the way we interact on various aspects? I think on this meeting, Wolfgang and I were the only two people who were not-native English speakers. Is this a problem? Can we do something about it? There might be other communication issues that are not on the technology side.

Tzviya Siegman: It’s an important question - we have some late-callers from Asia. How does gotomeeting work? Accessibility?

Avneesh Singh: I use Skype out to call in go to meeting

Jun Gamou: trouble with gotomeeting

Jun Gamou: I just wanted to say the IRC is very very helpful

Jun Gamou: thank you so much!

Tzviya Siegman: I appreciate the feedback and welcome more feedback over email or carrier pigeon. I think we’ve done sufficiently in this meeting. But lets talk about next steps. We’ve talked about the problems
… I’ve seen other groups with projects in github to see what people are worked on. I’m intriqued about having a new-member meeting. And see if some of the new member documentation can be reworked…

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/WorkMode/#information-for-newbies–new-group-members

Nick Ruffilo: A guide for new members

Tzviya Siegman: We have that - link above

Ivan Herman: We can more systematically - in github - assign issues to specific person or several persons. We haven’t really used that, but maybe we should to make it clear what issues are being worked on and what are not. That is halfway down what was asked - but it would help. The other thing - to which I didn’t really get an answer, from my non-english point of view. Even I - who have worked for a long time - have difficulty when a native English speaker is set to a really high gear. It can be hard for me to follow. That is something I could ask all our colleagues to be watchful of that.

Tzviya Siegman: Saying slow down is sufficient.
… There is a working group effectiveness taskforce - there was a list of items, and speaking slowly is one of them.

Wendy Reid: What Ivan just said - and Nick with the issues - some way of assigning the issues, or bringing up a list of issues that are assigned/unassigned, being able to quickly see that there are items I can jump on will help me.

Tzviya Siegman: Once we get this published, everything is available again.

Jasmine Mulliken: Second “help wanted”

Wolfgang Schindler: Github has a diff-view, so there’s lots of difficult-to-read. So if it was just vanilla HTML, it would be much easier to read. But in the usual github view, you see the red and green parts, but it’s difficult to follow that up as sometimes the content requires scrolling, making it hard to read.

Wolfgang Schindler: if it was just ordinary HTML, it would be easier to read.

Tzviya Siegman: You have the option of viewing it that way. As Dave is commenting, it’s built-in to github

Deborah Kaplan: if people ask github or git questions on the mailing list there’s a fair number of us who spend all day in github and can probably answer them there. :)

Ivan Herman: What we do have is a tool that a former colleague did - is that when we do a pull request, after a certain while, the first comment will show you a link to a diff and a link to a preview. The new version will be displayed, and the diff will give you one file that is annotated on what has changed. I found that stuff extremely useful (usually)

Deborah Kaplan: you can use many git apps to display diffs in your ui of choice. You need to find the right ones for your platform.

Ivan Herman: It puts lots of effort on editors to create their own custom diff, but we have programs that work reasonably well enough.

Deborah Kaplan: github is just built on git, so everyone can probably find a git tool for your computer that makes them happiest! :D

Ivan Herman: lets see what we can do to improve it, but we don’t control everything

Tvziva: Any other comments to make us a happier group?

Tzviya Siegman: http://irisamelia.com/impostor/GGD_Impostor-Talk.pdf

Jasmine Mulliken: Omg this is awesome!

Jasmine Mulliken: Thanks, Tzviya, for sharing that :)

Jasmine Mulliken: Happy Holidays!

Heather Flanagan: Happy holidays!

6. Resolutions