MDN/Development/CompatibilityTables/Status 03-07-2014
From MozillaWiki
< MDN | Development | CompatibilityTables
Checking meeting :: 03/07/2014
Progress
- Luke: Welcome John Whitlock, the new contractor who will work on the technical side of the project.
- Jeremie: Reminder of the current status of the project.
- Holly: Presentation of the macro data workflow
Planning
- John & Luke
- Start working on the Data Schema
- Jeremie
- Help Holly connect with the right people for each todo and question in Holly's doc
- Identify canonical spec for data, and include sample data to help Holly move forward and link to this doc from the wiki overview.
- Create a RASCI matrix for the project
- Holly
- Finish clearing up the global data workflow
Issues & Questions
- Jeremie:
- Should I open more bugs (Design of the read/write API, kuma binding, etc.)?
- Luke, Maris, and John will meet and file bugs for:
- Create the django app with all models to cover requirements
- Create the resource API on top of those models
- Luke, Maris, and John will meet and file bugs for:
- Should I open more bugs (Design of the read/write API, kuma binding, etc.)?
- Ali:
- we should discuss product versions and if it makes sense to add the requirements for that into the backend project - I think it is similar enough on the data side that it at least needs to be considered.
- Yes, the only current issue we have with that is Product subproduct (i.e. WebWorkers in Browsers). This is discuss on bug http://bugzil.la/1006539
- we should discuss product versions and if it makes sense to add the requirements for that into the backend project - I think it is similar enough on the data side that it at least needs to be considered.
- Sheppy:
- I agree with Ali that it sounds like product versioning would dovetail with this very well if we design the schema properly. Being able to flag info as being relevant only to a given version or range of versions of a specific browser would make this entire thing remarkably awesome instead of just awesome.
- We don't necessarily need to implement the product versioning feature as part of the compatibility data project -- the idea here is to keep it in mind while designing the schemas, to avoid duplicate effort later
- I agree with Ali that it sounds like product versioning would dovetail with this very well if we design the schema properly. Being able to flag info as being relevant only to a given version or range of versions of a specific browser would make this entire thing remarkably awesome instead of just awesome.
- Andrew Overholt:
- I want to see how things are going to get an idea of when I can tell people to stop looking at the horrible wiki page I have and to look at MDN instead :)
- The only deadline we have is John end of contract (December) and we plan to emphasis quality over speed, but the idea is to have a first private alpha by end of Q3 and a first public beta by end of Q4.
- I want to see how things are going to get an idea of when I can tell people to stop looking at the horrible wiki page I have and to look at MDN instead :)
- Justin Crawford:
- Where is the canonical reference for the schema?
- https://etherpad.mozilla.org/MDN-compat-schema
- https://etherpad.mozilla.org/b4YZ3PbNTK
- IRC consensus says it is this: https://docs.google.com/a/mozilla.com/document/d/1YF7GJ6kgV5_hx6SJjyrgunqznQU1mKxp5FaLAEzMDl4/edit
- Those are draft. The final work still need to be done, see planning.
- Would sample data be helpful for UX design? Where is it?
- Yes, some hard data set has been identified:
- Where is the canonical reference for the schema?
- Mars:
- Is there a RASCI matrix recording the Who's Who for this project?
- Will be done until next meeting, see planning
- Is there a RASCI matrix recording the Who's Who for this project?
- Chris:
- We are going to be able to have simple tables showing support for a specific feature, granted, but are we going to be able to also show support for a bunch of different features alongside one another, to compare and contrast? I am thinking of things like the big support table we will want on the APIs landing page
- There is no reason to be unable to do so technically speaking, but this could require some UX work. See MDN/Development/CompatibilityTables/Data_Requirements#4._Tables_with_filtering
- So far we've sketched out existing MDN layout, caniuse layout, and mobileHTML5 layouts: MDN/Development/CompatibilityTables/Data_Requirements#Compatibility_Tables. Will we be able to filter content, e.g. by gecko version, by product version, by IE version, only show privileged APIs?
- Yes, discussing in http://bugzil.la/1006539
- Will we be able to attach metadata to each entry, such as further links to useful workarounds, notes, etc?
- Yes, "implementation notes" in the requirements: MDN/Development/CompatibilityTables/Data_Requirements#Implementation_notes
- We are going to be able to have simple tables showing support for a specific feature, granted, but are we going to be able to also show support for a bunch of different features alongside one another, to compare and contrast? I am thinking of things like the big support table we will want on the APIs landing page