<fantasai> RRSAgent: make logs public
<inserted> ScribeNick: fantasai
plh: Our goal is to make /TR
relevant
... Part of doing that was going under hood, make sure right
info is in right place
... part of that is fixing process
... ultimately if everything goes well, should have a new
/TR
fantasai: Clarify whether the page at /TR or stuff under it?
plh: http://www.w3.org/TR/
... There are around 1900 documents on that page
... Want to fix this but along the way want to make it more
useful for everyone
... One thing that we did was, when you take any spec in /TR
and you click on Previous Version link, an dyou load that
document
... You will get this annoying red warning that this version is
outdated
... By default this is what we do
... Have an exception mechanism for e.g. particular dated
versions that are referenced by someone else (like the legal
code)
... Ironically, sitll have 2 issues to fix on that
... We didn't get proper a11y review on that, I apologized to
my colleages about that
... Other issue is inteorp on CSS
... told Webmaster to talk to Bert and find out what's going
on
... I haven't received complaitns about it, so I assume it's a
success, although there are these two issues
... This is a way to prevent issues reported on documents that
are already old / outdated
... We communicated with editors prior to this, nothing to
change for them
plh: Right now we have
/TR/foobar-N and we have /TR/foobar
... CSP has 3 versions, one is a REC, one is a WG NOte, and one
is a WD
... correspond to different levels
... What happens at /TR/CSP?
... Was returning WD, but wantd to expose e.g. latest REC
... Want to expose this ifnormation, manage with bikeshed, make
things more predictable etc.
... So spent some time discussing how we should manage
this
... Talked to several individuals, then narrowed down different
categories of audience
... People who want to see stable version of speification
... not latest WG discussions
... This is what /TR/foobar/latest is about.
... Wanted to call it /TR/foobar/stable but stable is
overloaded, and didn't want to load a 404 if there wasn't a
stable spec yet
... /TR/foobar/upcoming is the highest level, regardless of
stability. Latest thing the WG is working on
... /TR/foobar proxies to either latest or upcoming, depending
on what the WG's preferred work mode is
... whatever the WG most wants other people to look at
... So standardized on this system, using /TR/foobar-N for
levelling, and managing this all in a database system
... So now /TR/foobar/all lists all the versions
... and /TR/foobar/ed will redirect to editor's draft
... /TR/CSP/all for example will list links to each of the 3
levels of CSP
... There are some bugs
... So if there's anything weird, let us know.
... e.g. if shorname changed, system is confused and doesn't
know the specs are related
... Sometimes specs split or merge or both, e.g. DOM1 ->
DOM2 modules -> DOM3 more modules -> DOM4 monolithic
spec
... We're trying to collect these cases and then try to figure
out how to handle this
... So if you run into something doesn't 100% make sense, let
us know, we will fix over time
<tantek> slide deck is linked from the Plenary page, plh's talk this morning
plh: So /ed redirects to Editor's
Draft
... 2 years ago or last year, we started to tell ppl that if
you put Editor's Draft into header, we'll put it in database,
now we can expose it
... These are all redirected now from /ed if the WG has a
public ED
... If you go to wiki page here, there are details for the
algorithms
... One question I got was shouldn't /TR/foobar/ed redirect to
ED of /TR/foobar/upcoming rather than ED of /TR/foobar (which
could be latest rather than upcoming)
... That seems to make sense
<hadleybeeman> +1
plh: So this is all implemented, going through to make sure it all make sense
<tantek> plh's slide deck URL: https://www.w3.org/2017/Talks/tpac-slides/plenary-project/ that he's showing
plh: We didn't say what to do
with these links now
... So we have editors who'll want to put that in the top of
their draft
... and pubrules checker doesn't know anything about these
things
... Two weeks ago I decided to make a mockup
... We have people who are interested into latest and greatest,
closes to ED if not the ED
... and we have other ppl who are more traditional, want to see
what is most stable
... each community feels strongly about it
... Living Standard ppl are like why you bother with these
thing
... WGs like Service Workers don't care about levels or
anything like that
... Now that we have the links, what do we have at the top of
the spec
... My proposal is to have some subset of the headers shown,
and others hidden dynamically
... then each community can show what they want to show, e.g.
only show link to latest and not links to levels or info about
levels or any of that
... but that info is there, can expand the <dl> to show
that extra info
... to show level info for ppl who want to see that info
... that way everyone can get what they want
... Had some discusison about, which links should we show by
default?
... probably have to pick a minimum set
... and then WG can pick which other ones they want
visible
... problem with that approach is that you, as a user, you
might not be happy with what you see
... Deploying any solution requires updating pubrules,
bikeshed, respec, etc.
... btw, i18n was asking if instead of Level 2 can we have e.g.
2017?
... For us it's a number
Tantek: Half time up?
plh: Yeah, I'm pretty much
done.
... Wrt /TR page, we're making a new one that's easily
searchable e.g. if you're intersted in JS specs, or
whatever
... [some discussion about obsolete vs superseded]
tantek: Where are you tracking issues on /TR?
plh: Go to wiki page, latest page
with algorithm
... tracking issue sthere
<plh> https://github.com/w3c/tr-pages/wiki/Latest-versions-proposal-for-leveled-specifications
plh: Have a separate one for the
styling
... but for logic of those thigns, that's here
... OK, I'm done
r12a: you said you're going to
have lots of stuff or less stuff
... You said there would be mechanism for WG to choose what
they want by default
... Talked about users, but then didn't quite finish
... What's the mechanism for the user to decide?
plh: It'll be decided at
publication time
... From editor's PoV, you don't see that
... you get option within respec or bikeshed, and they'l take
care of making pubrules happy
r12a: Let's say I'm a user and I
don't like to see different set of metadata, and I want that to
stick when I come back to that document later
... might also want to to stick for all docs I look at on
/TR
plh: Toby gave same feedback:
great, but not giving choice to the user
... ...
... Main concern is that same page looks differnet for
different people
... otherwise will introduce a lot of confusion, if at /TR/CSP
differnet ppl see different things
... So gotta think about that
... Also, haven't talked to Comm team and Director
... I want to fgure out what we want, then try to go convince
them
r12a: I would suggest that the switch be at the top, and to produce version you want by putting a parameter in the URL
gerald: You could have a #fragment and have JS figure it out
fantasai: It's a spec, your'e going to click on a ToC link
michel: I think we wnat to shrink front matter as much as possible, not increase the number of links
plh: People have been expanding the list of stuff at the top, so we need to do a real redesign
TabAtkins: CSSWG switched over to
hiding *all* of the metadata
... My ideal is to see the actual content of the spec above the
fold I'd be so happy
leaverou: Probably first time you see spec you want to see all the headers, sbusequent times hid them
fantasai: I think that's the opposite of what's true
dsinger: Yeah, I'm usually
looking for actual content of the spec the first time
... later times I might be looking for an old versin or how to
file bugs or whateer
falken: as an implementer,
there's often several specs about the same thing, and different
ersions of it
... and I'm trying to get to the version I'm looking for
hadleybeeman: I often go to /TR
to then find the ED, because that's way easier than trying to
find the ED
...
plh: We could just do what CSSWG does, and have it all collapsed
r12a: Wnat to be able to open spec metadata and have it stay open across specs
TabAtkins: There are plenty of APIs to do this
plh: fingerprinting is definitely the best method
falken: Another issue about
hiding by default, if it's shown it makes it more obvious that
this isn't what you're looking for
... e.g. for Service workers, ppl landed on Service Workers 1
and they wanted Service Workers Nightly
... we had to put a warning at the top
... If you hide all that info, ppl don't notice that there's
other version
annette_g: If you hid thing,s don't know there's stuff there. Maybe better to show it
TabAtkins: automatically applying obsoletion notice..
fantasai: happens for dated versions
plh: Yes, but doens't happy
across levels
... The way to say "Don't look at Level 3, look at Level 4" is
to obsolete or supsersede the spec
dsinger: Btw, that's a stunningly ugly presentation of the information
plh: we are not fixing the design right here
<inserted> scribenick: TabAtkins
fantasai: We all agree this
presentation of metadata is bad.
... Also agree the amoutn of crap in the status section is
unreasonable
... It would be lovely, delightful even, to see the spec above
the fold.
... Problem is none of us (except maybe Lea) have the skills to
do this well
... So we're gonna collab with people who do have these
skills.
... Not now, in 2018.
... Design school in Philly who are plannign to work on this in
the Sprint semester
... The school gets to paly with stuff and show off thier
skills, and we get results where no design agency would touch
it.
... It's gonna be way way better.
... Robin and I did a mockup some time ago.
plh: Right. But I can't wait for the design to get good, so I needed a stopgap solution that'll give the info I need.
<fantasai> http://fantasai.inkedblade.net/style/design/w3c-restyle/
<fantasai> https://www.w3.org/wiki/SpecProd/Restyle/Content
fantasai: Proof of concept about
compressing the info. Not what we're going for, jsut showing it
is possible.
... And the wiki has more accumulation of stuff, please
contribute.
ishida: Did we do an analysis of whether people liked the previous design?
plh: No, but we had a bunch of
people, including staff, say "what are you doing", then a few
months later agree it was a good change.
... Right now our point is to progress.
... The school is planning ot interview people in the community
about what they need.
leaverou: Issue is that asking people is bad - they don't know what they want, they get used to something.
ishida: Right, why I want to know what people think of the 2-years-ago changes. They've had time.
annette_g: If we're having inteaction-design students, that's really good. Rather than just asking random people, they can actually do testing.
plh: Next year in the spring, get
a list of people to be interviewed.
... If you're interested in being on that list, go ahead and
put it into IRC.
<annette_g> happy to help work with students on new interaction design
singer: A year ago we introduced a progress to declare something obsolete. Have we actually done it?
plh: We ran an aC review, and the feedback was "you have to supersede them, not obsolete them"
singer: What about P3P and PICS?
plh: Haven't done those yet.
<fantasai> ralph: Still on my desk
singer: I think cleaning up TR means removing some of those specs, because we don't recommend them.
plh: Agree.
singer: And keywording is absolutely critical, the list is so long and alphabetical doesn't help.
plh: I haven't identified a
designer yet to give us a new TR page.
... denis didn't want to do it ^_^
... So yeah, I need to go back and find one.
... We know the info we want to show, just want to figure out
someone to do it.
<fantasai> TabAtkins: There's a separate project going on in Bikeshed to inline test annotations, and to generate a test-annotated output
<fantasai> TabAtkins: So we'll have a plain version of the spec, and an test-annotated version of the spec
<fantasai> TabAtkins: So there might be additions to URL structure
<fantasai> fantasai: That would probably jsut be another file in the spec directory
plh: In the next 2 or 3 weeks
I"ll send an email to spec-prod with these details
... Just need to make sure I get a11y review before I deploy
this time ^_^
fantasai: My wish for outdated is
that it's easier to go away.
... EVery time I have to go thru an old spec, I keep having to
dismiss the warning.
TabAtkins: Same as Lea.
leaverou: Yeah, same for "not ready for implementation" specs I work on.
<fantasai> leaverou: every time I referesh the spec I'm editing, gotta dismiss the notice
<fantasai> Meeting closed.
<fantasai> RRSAgent: make minutes
<fantasai> RRSAgent: make minutes public
<fantasai> RRSAgent: make logs public
<fantasai> RRSAgent: make minutes
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/links/spec/ Succeeded: s/fine/find/ Succeeded: s/???/annette_g/ Succeeded: s/PIX/PICS/ Succeeded: i/topic: design/scribenick: TabAtkins Succeeded: i/plh: Our goal is to make/ScribeNick: fantasai Present: tantek dsinger fantasai hadleybeeman leaverou wilhelm falken Found ScribeNick: fantasai Found ScribeNick: TabAtkins Inferring Scribes: fantasai, TabAtkins Scribes: fantasai, TabAtkins ScribeNicks: fantasai, TabAtkins 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 WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]