- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Tue, 27 May 2014 13:06:20 -0600
- To: List WebPlatform public <public-webplatform@w3.org>
- Message-ID: <CAFDDJ7x=hLwnUOGYS6rdMjh+vz2Bvd7ykMPnYro_KEQ1a8SpNA@mail.gmail.com>
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
Received on Tuesday, 27 May 2014 19:06:49 UTC