Compatibility/Meetings/2017-06-15

From MozillaWiki
Jump to: navigation, search

Minutes

Scope webcompat,.com - SF work week (ola)

I'd like to talk about the upcoming work week and the scope for it.

  • Ola: we'll have maybe 3.5 days to hack on stuff at the All Hands, so let's discuss what needs to be prepared. I would like to work on the Living Style Guide (LSG), and if we have time, Visual Regression Testing for the guide (also possibly testing, and a roadmap for Q3).
  • Ola: the LSG is based on CSS grids with a fallback, making it easy to develop modules as a team. [shows a quick layout for a responsive 3, 2 or 1 column page where each grid box is a space for a module]

decide on audience for LSG (ola)

'

  • Ola: I'd like to build the LSG first so we are all on the same page and can work independently. Those wishing to contribute can let me know what they feel they will have time to help out with during the work-week. Typography, colors for labels.. everything should have a small description (in the guide). How descriptive should the guide be?
  • Adam: depends on who is reading it. First-time contributors need more description, more experienced contributors would benefit more from a short description instead.
  • Tom: as in have two parts, one for each type of audience (a TL;DR for some, more info for newcomers?)
  • Adam: might that increase the workload too much?
  • Ola: that may be doable, but we need to decide on the audiences. Who could help us learn who the audiences and their experience-levels are?
  • Adam: Guillaume, maybe Karl.
  • Tom: we should keep an eye out in case existing contributors are at the work-week, and bring them into the conversation if possible.

Structure for LSG (What should be in there? How much description do we need for usage?) (Ola)

'

  • Ola: I'll document these things on the wiki as well. Karl helped clean up the semantics of what's already documented, and Guillaume as well. I will push things into the repository over the next week, please consider what might need to be done ahead of the work-week if possible.
  • Ola: I would also like to add a slide on accessibility (a11y). There is a CSS script that highlights warnings/errors, and lets you know if there is an a11y issue like elements with missing titles/etc.

Tests (How much do we need to change due to CSS / semantics refactor) (Ola)

'

  • Ola: I believe we will have to rewrite quite a few tests.. it's lots of work!
  • Guillaume: Yes, it is a lot of work (but very interesting). We need to start the webcompat refactor with tests, before doing anything else, or we'll never get around to writing the tests at all.
  • Ola: do you feel it will be a good idea to refactor not just the test-suite, but also change our testing methodology? As in, not just function-based tests, but separate UI tests as well?
  • Guillaume: Yes. We need to test everything, and keep the tests separate and specific to their purpose. It can be hard to make sure our tests have good coverage as well.
  • Ola: but there are a lot of tools that we can leverage if we do this properly, like dependency-checkers.
  • Ola: I want to tackle the documentation part of the LSG, because I like writing documentation.

Ownership of LSG (ola)

'

  • Ola: I'd like us to think about ownership of the LSG as well. That is, an owner for each module to ensure quality of incoming commits and such (possibly similar to Bugzilla's model).

Roadmap for refactor (ola)

'

  • Ola: as for the roadmap for the site, I've been planning a lot and will share that information during the work-week. But for now, I feel we should refactor things into modules, in a step-by-step fashion that makes us able to deploy faster (more like a rolling release). Is that ok with everyone, or should we have something more like monolithic releases?
  • Guillaume: if we use a library like Backbone, then the JS-end of things can probably be managed in that way, but it's difficult to tell which approach is better until we sort out all of the information.
  • Ola: what do you think, Adam?
  • Adam: I'm afraid I don't play enough of a role to have any insight.
  • [Intermission: surprise family-member cameo]
  • Tom: in my experience with such sites, it's best to consider smaller releases, so it's easier to back out problems. Milestones are fine, if kept reasonably small and contained.
  • Ola: that's why I want to break up into modules and have an LSG, so it's more manageable and we can more easily have smaller, self-contained changes to push to a release. I'm intentionally waiting on the JS refactor so we know how everything will change in the future, and how well-encapsulated each thing will be. That way we can do bug fix releases more smoothly.
  • Guillaume: sounds perfect.
  • Ola: also still a few things to consider, like font handling, naming conventions, etc. They're easy to change. Guillaume, we should also talk about the WebPack rebuild, and plan ahead and find out what work is necessary (so we can divide up the labor more efficiently).
  • Ola: any questions regarding the scope of the refactor? Tom, Adam: nope.
  • Guillaume: nope, just what you last mentioned about Webpack and naming conventions, etc.
  • Ola: the new linter is a huge improvement, by the way.
  • Ola: does anyone have any more topics for today's meeting? [nope]

Broken Voices of the Web

Web Compatibility Progress

FIXED (no DUPLICATE)

NEW

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2017-06-15&oldid=1174114"