14 Mar 2016

See also: IRC log


Janina, Katie, Haritos-Shea, Debbie_Dahl


<Lisa_Seeman> agenda: this

<Lisa_Seeman> michae;, canyou unmute

<Lisa_Seeman> michael

<scribe> scribe: janina

<Lisa_Seeman> scribe Janina

<Lisa_Seeman> next item

ls: Timelines are we wish we were already publishing
... Suggests we may be OK to ask our parent WGs for publishing permission

Michael - what help he needs for the issue papers

ls: Main question is how to clean up the docs ...

<MichaelC> http://www.w3.org/2001/06/manual/

mc: Main thing to know is to follow W3C manual of style

<MichaelC> https://www.w3.org/respec/

mc: Much literal styling is done by a respec script
... hrefs need to be styled appropriately per above URI

mc i.e. [wcag20] which is then referenced in its own section at bottom of doc

mc: Just putting in links is inappropriate

<MichaelC> [[WCAG20]]

mc script would pick up the above and appropriately convert the shorname

john: I'm unclear ...

mc: I'm mixing up two pieces ...

<MichaelC> https://www.w3.org/2001/06/manual/#References

mc: This says how output doc looks
... However, we also use respec, and therefore

<MichaelC> https://www.w3.org/respec/guide.html#references

mc: respec is a script already attached to our documents; offers a shorthand using double brackets

<MichaelC> [[wcag20-ext-reqs]]

mc: e.g.

john: Is there a list of the shortnames?

mc: no

<MichaelC> https://www.w3.org/TR/2016/WD-wcag2-ext-req-20160105/

<MichaelC> Latest published version:

<MichaelC> http://www.w3.org/TR/wcag2-ext-req/

mc: Look at "latest published version" in the document

<EA> Is there a template we can all use for our issue papers to get this all correct.

mc: for any W3C publication, it's after the tr/ and up to the next slash /
... There are some not in the db, however
... So we've created our own db listings

<MichaelC> https://raw.githubusercontent.com/w3c/coga/master/common/biblio.js

mc: Unfortunately not the easiest to look at

<MichaelC> "ADI-1":

mc: references al start in quotes followed by colon

<MichaelC> "title": "World Alzheimer Report 2010",

<MichaelC> "ADI-1":

<MichaelC> {

<MichaelC> "title": "World Alzheimer Report 2010",

<MichaelC> "publishDate": "2010",

<MichaelC> "authors": ["Alzheimer's disease International"],

<MichaelC> "etAl": false

<MichaelC> },

mc: look up before the brace (curly bracket)

ls: If not referencing standard W3C doc, one looks into this resource

<Lisa_Seeman> [[ADI-1]]

ls: If anyone uncomfortable about getting this right, contact me with complete reference -- and include a shortname, please

mc: Suggest Lisa or el choose the shortname
... I'm not suggesting everyone learn how to update the bib file

<MichaelC> @@reference to docname

mc: the @@ is a W3C convention marking something that needs cleanup

ls: But check if it's already there! That will save time.
... If it was in the research docs, it's probably already there.
... Does this help? Are there questions?

ea: Still a bit concerned that we have too few of us on the call, and yet so many docs to cover
... Wonder about how to be efficient

<Lisa_Seeman> [[ea1]]

ea: Hoping we can develop a template by end of this call, something plain

<JohnRochford> +1 to EA's template idea

mc: Agree we should shift gears, there are other issues perhaps more tractable
... So, to recap, there's a W3C style sheet and scripts attached to our docs that help
... So, more detail on the email I sent ...
... First structure ...
... We need nested structure

<MichaelC> <section><h1>Heading</h1><p>Content</p><section><h2>Sub-section</h2></section></section>

mc: Every section needs a heading, the script will take care of the actual level number
... The script will generate a TOC using the nested structure
... So, look at the generated ToC to see whether nesting was done correctly
... Next item, we need well formed code. If some tag is opened, we need to be certain it's also closed at some point.
... Beyond that, spelling and grammar is also very important.
... Also, we need to check URI ..

<MichaelC> As the WCAG extension requirements at https://www.w3.org/TR/2016/WD-wcag2-ext-req-20160105/ say

mc should be

<MichaelC> As the <a href=¨https://www.w3.org/TR/2016/WD-wcag2-ext-req-20160105¨/> WCAG Extension Requirements</a> [[wcag2-ext-reqs]]

mc: Above is an example of cleaning up a naked URI
... We need also to check understanability of the document.
... Key to that is a very good intro section.
... There should be a direct flow, with concepts properly flowing one to the next

ls: Do we need to orient the reader on an issue paper by issue paper level, or does the global grouping cover the orientation

mc: We may need to work on this
... Probably needs something up top that explains how this issue paper is different from others

ls: Perhaps a boilerplate for our use?

mc: Sometimes these weren't filled out!
... If we do use, they need to be completed -- or an editorial note that it's yet to be done.

<EA> Happy to follow a standardised boiler plate for issue papers as they are not too long.

<Lisa_Seeman> i sent it a private chat katie

mc: TF should come up with the approach, but then follow through to be consistent and complete

ls: Questions?

ea: Happy to follow a structured template ... This is very helpful

ls: Would an example page be helpful?

ea: Yes!

<JohnRochford> +1 to example boilerplate

<Lisa_Seeman> action lisa to write sample page

<trackbot> Created ACTION-157 - Write sample page [on Lisa Seeman - due 2016-03-21].

ea: It's a challenge to do this correctly when other work has its own requirements. Good templates and specifics really help.


ea: Also a finished issue paper would be helpful!

ls: Good. I'll do one -- but may not succeed at grammar!

ea: Happy to correct spelling and grammar! That works for me!

<JohnRochford> Janina, what does the following mean? %s/john:/jr:/

ls: OK. I'll do an example paper, and also create a checklist of what needs doing
... We should now decide what sentences we want at the top of each paper.
... Also, do we need github help?

khs: Need github help

mc: Let me talk github basics ...
... It's well documented
... First step is get an account on github.com

<MichaelC> https://github.com/

curt: Easy to find the docs when first you setup, but then becomes hard to find

mc: Most likely then you will want to download a github client
... Then you clone the repository

<MichaelC> https://github.com/w3c/coga

<MichaelC> https://github.com/w3c/coga.git

mc: This creates a local copy where you can edit and save
... Now the client will notify that there are changes you may want to do something about
... Next, you might commit the changes
... Will ask for a summary, so you say what you did so people can tell what your changes were
... Now only half way done!
... Above commits to a local db. Next need to be uploaded
... It's called either push or sync
... Which uploads my changes and grabs any others have made
... It's possible to run into conflicts if two people were making changes in the same part of a doc
... Strongly suggest editing in small chunks. Push early and often to avoid clashes!

Janina notes github also well supported at the command line

ea: Asking about a good Win client

mc: Suggest the official github client
... Noting that any git client can work with github, but may be more challenging to setup

<Lisa_Seeman> This is an issue paper looking into how cognitive disabilities are affected by ….

<Lisa_Seeman> It is part of a series of issue papers is part of the gap analiais of the

<Lisa_Seeman> ...

<Lisa_Seeman> what the xxxxx

ls: Asking for opinions on the above suggestion ...

mc: Notes that the issue papers inform the gap analysis, but are separate publications

ls: But would the above be sufficient

mc: Perhaps, if the cover page has more

ls: Something more?

mc: I haven't figured out how to put the issue papers into the overall mix
... One doc? Separate docs?
... If seperate, need a main file with overall TOC

ls: Expect we'll be adding issue papers as new issues arise. So perhaps we're publishing separately and adding to a main TOC?

mc: Either XX separate pubs, or one called "Issue Papers" were the entire doc is republished for each new added issue paper.
... Notes that all of HTML is republished daily now, for better or worse!

ls: Worried about versioning

mc: There's normally dated and undated. Recommendation is to href undated which gets the latest
... Suggest relying on the "latest" approach as a hard rule.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/03/14 17:05:15 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: janina
Inferring ScribeNick: janina
Default Present: Janina, Katie, Haritos-Shea, Debbie_Dahl
Present: Janina Katie Haritos-Shea Debbie_Dahl
Regrets: JMary_Jo_Mueller

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 14 Mar 2016
Guessing minutes URL: http://www.w3.org/2016/03/14-coga-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]