Weekly Meeting Notes, 27 May 2014

Weekly Webplatform.org Meeting, 27 May 2014


Chair: Doug Schepers (shepazu)

Scribe: Amelia Bellamy-Royds (AmeliaBR)


Attending:

(On the teleconference): Doug Schepers (shepazu), Jen Simmons (jensimmons),
Julee Burdekin (julee)

(On IRC only): Renoir Boulanger (renoirb), Eliezer Bernart (eliezerb)



TOPIC: The SSO (single sign-on) project

shepazu: renoirb will be sending out an email, should create a single sign
on system to combine annotation system with main wiki sign-on

..."we seem like we're in a pretty good shape on annotations" renoirb was
working all weekend

<@renoirb> Note: Any wiki that is configured as a client to our OAuth
Resource server (test wiki will be able to use it too)

julee: to confirm, we'll need to update accounts?

shepazu: just passwords will be updated, all account data will be
transferred

...once this gets rolled out, there is a second system called Firefox
Profiles; this is all piggy-backing on work being done within Mozilla,
they're pretty far along but still working

...the profiles are what we wanted when we installed the social profile
extension to Mediawiki, but never worked well; we're going to migrate that
to the accounts.webplatform.org

...we're rushing this because w3c is having an advisory committee meeting
in a few weeks, and we want annotations working by then since the system
will also be used for annotating/feedback on w3 specs

* renoirb about accounts and SSO: There’s a misconception I want to fix
with the profile server. Its not a pretty frontend like what we see at
accounts.webplatform.org. The profile server is an API on which we can make
calls.  Our other applications (e.g. MediaWiki, WordPress) will read from
it.  Later down the road, we’ll make our own frontend with css/js to show
what we want.


NEW TOPIC: Compatibility tables

shepazu: worked with frozenice Thurs and Fri, also Pat Tressel; there was
much mutual confusion...

...we weren't sure of the next step (for getting data from MDN); frozenice
clarified that we just needed a list of MDN pages that we wanted to scrape;
we didn't actually need a crawler for every single page on MDN (just the
ones that matched webplatform.org pages)

... generated list with ~1900 urls by going through the cover pages; 1400
after duplicates and redirects

with list, frozenice queried MDN to find compatibility tables; only about
half had tables, there were some inconsistencies in what had tables and
what not

...older, widely supported elements often didn't have tables, but we want
to have tables for everything for consistency

...Plan (1): Walk through all the MDN pages to find "false negatives"
(compatibility information that wasn't discovered by the automated script)

... Plan (2): identify any of the MDN links as to whether they have
links/redirects/compatibility; if no compatibility, is this widely
supported element (in which case we can add a basic "Is widely supported"
compatibility section

... questions?

jensimmons: agree that we should make sure data is complete, even for old
elements.  But it's the new stuff that people care about the most, and we
need to keep up-to-date.  Will we be periodically syncing with MDN?

shepazu: The MDN script is a one-time thing.  Once we have data, we'll
expose it as an API, and expose it back for MDN to keep up-to-date with us.

...their information is not test-driven, it's only people's opinions.

... we also want to get information from caniuse, which is at least
test-driven, even if it tends to be broader topics instead of individual
pages

...we'll have to map the caniuse compatibility information to our tables

...nobody has exactly the information we're looking for

...w3c comes closest, with the enormous amount of tests for minutia of
specifications; there is too much detail, many different tests need to be
compiled, determine which aspects are "core tests", which are about
combinations of features or sub-features

...for sub-features, we need to break that out to create "drill-down"
tables for those results

...for "edge cases" (versus core features) we would have caveats or
callouts, but wouldn't confuse that with a lack of support for the main
feature

...we would want to bundle-up all the tests to give a "confidence score"

...lots still to decide, but if we get this done, it has potential to be
much more useful than caniuse, which is more a quick-and-dirty overview

...we want people to be able to know all the "gotchas" and how to work
around it, by knowing exactly what isn't working

julee: this would be great to right as requirements

shepazu: oh, it's all written down already

julee: what are we going to do about Javascript pages, many have manual
information already, the script should not wipe this out if MDN doesn't
have data

shepazu: we're not going to remove the data from the manual tables; even if
we remove the templates, we won't lose the information

julee: but it won't be on the page?

shepazu: Yes, but then we could scrape our own site and try to compare it
with MDN

julee: Agreed, we're not comparing data right now, but we should be able to
write the script/template so that if we have data and MDN doesn't we don't
delete it

shepazu: What we're going to do is put this data in a mediawiki extension,
and then pull that into a table with templates

...all the pages will be changed because the template will be changed; data
will still be there but not displayed

julee: if there are technical problems, we should at least create a list of
pages where MDN data is blank, so that we can go back over and fill in
manually

shepazu: scraping our own data should not be that hard, but I really don't
know if there are many of our pages that have unique compatibility
information (i.e., that wasn't just copied from MDN)

...I will ask frozenice if it would be feasible to modify the script to
scrape any data we currently have and compile with the MDN data

julee: can you send the link/reference for the end goal structure of how to
combine compatibility info with w3c test suite?

shepazu: will do; and will update it if necessary

shepazu: by the end of this week, we will have all the data we can get from
MDN, so we will be "at least as good" as them.

...at that point, we will have compatibility data on all our pages

...I (shepazu) will walk through the pages with no MDN data, and if I know
that things are widely supported I will mark it.

...this is important because this is one of the things preventing us from
declaring we're out of Alpha stage

...the other thing is the flag readiness markers

...However, for compatibility, even after we add template, we may have to
manually go through and add a field to the page defining the search name to
use to extract data from the database generated from MDN; the name in our
template needs to match the one used by MDN to make sure we're getting the
right data

...this could be added to the task list for the content readiness review

jensimmons: Yes, we need to have a clear list of what needs to be done, so
that we only go through all the pages once

shepazu: This should be our workplan for June.  That would finish this
phase of major verification.


NEW TOPIC: Readiness

jensimmons: I should be able to get the CSS deployed this week.

...anything else?

AmeliaBR: we need a clear to-do list, but we also need a way to divide up
tasks?

jensimmons: we can probably start one section at a time (e.g. CSS), and
then divide it up alphabetically

<@renoirb> I have one quick task for jen if that’s possible

<@renoirb> We'd need to have an enveloppe with our logo <
http://imgur.com/RlBxBte

<@renoirb>
https://github.com/webplatform/fxa-content-server/blob/webplatform-customizations/app/images/graphic_mail.png

shepazu: that simple approach should probably work, and CSS pages should be
the first priority.  This is grunt work, but should only take a few minutes
per page.  With the regulars all committing a few hours it should be done.

...We will call this the QA Checklist; we need to come up with ideas for
what to do, and then get it done.  I'm confident we can do this by
mid-to-late June.

...then we can come up with a plan to announce that CSS stuff is "done" and
everything that went in to getting it there (compatibility, readiness, etc.)

...and what this means for the infrastructure

shepazu:  we should also send out an email; we have to do it anyway as part
of the password reset

jensimmons: it would be really great if the password reset email be sent
out after the readiness states are live

shepazu: it would also be good if the contributer pages could be ready

jensimmons: yes, I will be working on that

julee: what about formatting the index tables on category pages?

AmeliaBR: Eliezerb and I had mentioned that we could look into this; I can
make this a priority if necessary

shepazu: Can you at least coordinate this (to AmeliaBR); ask for help when
necessary!

shepazu: So by mid-to-late June, we want to be able to make a big outreach
effort after these changes are made; reach out to stewards for promo,
announce new steward DreamHost and get their logo on their site

...try to have a flurry of blog posts leading up to big announcement,
detailing all the work that has been done.

shepazu: one last detail on compatibility, when he's working through the
list of MDN pages where there is no compatibility data at MDN, he will
identify MDN pages that are just stubs and "brag" a bit about the fact we
have info they don't

shepazu: Don't want to end up in an adversarial position with MDN

<+eliezerb> Hey, and about the Contributors Guide?

<AmeliaBR> What about it eliezerb?  You'll need to pass any requests to
jensimmons...

<+eliezerb> AmeliaBR: Do we have some expectation to get that done?
http://docs.webplatform.org/wiki/WPD:Contributors_Guide

<AmeliaBR> eliezerb, yes that is on the list of things to get done before
mid-to-late June outreach push

<AmeliaBR> (sorry I wasn't clear earlier)

<+eliezerb> Ohh, thanks... :)

shepazu: Summer plan:  getting new infrastructure up and running

julee: but we need to coordinate infrastructure push with content push


Agreed ACTIONS:

TODO: jensimmons: CSS for readiness markers

TODO: shepazu: manual walk-through of MDN import dataset

TODO: Everyone: talk about the QA checklist, AmeliaBR will send out an
initial email


meeting adjourned