-
Notifications
You must be signed in to change notification settings - Fork 24
Minutes Tuesday, 6 February 2018
Marcos: Ethan, will you lead the discussion
Ethan: sure, I'll try to set the stage a little bit. The main tasks we have in front of us are: 1. decide on roles, such as chair, editors, etc. and 2. sync on what we need to get done.
Marcos: We should do a round of introductions.
In attendance:
- Ethan (independent dev),
- Marcos (Mozilla, WICG Chair),
- Viktor (dev with strong interest in components),
- Tommy (Indie web dev),
- Tantek (Mozilla, web standards),
- Keith (web dev - works on large sites, working on a book),
- Jason (web dev in Boston, speaker/writer interest in fonts and responsive design),
- James (web dev),
- Dan (front-end lead, works from UK at Auto Trader, previously at the BBC),
- Eric (web dev)
Ethan: this group would make a great cast for a heist movie on containers queries!
Ethan: Eric and I were tagged as potential chairs (by Marcos) - we were not sure how that would work, so we reached out to Marcos to see how this would work.
Ethan: basically we see this as a partnership with the CSS folks and implementers. We are doing the first leg of the work.
Ethan: As developers, we understand the problem deeply from a developer perspective. So, the first phase of our work would be to focus on use cases and requirements as we understand them.
Ethan: looking at the Responsive Images use cases document from the RICG was very helpful - because it outlines the problems, how the community tried to address those problems (via JS or whatever), and why those solutions were insufficient.
Ethan: so, doing something similar for our group, it would be good to articulate from first principles: we don't need to propose a CSS solution, just describe how things are being done and what problem we are trying to solve.
Eric: just echoing what Ethan said - we need to define the problem, and then see if we can convince the CSSWG and implementers to help us solve it with an actual spec.
Marcos: I agree with everything that Ethan and Eric said.
Jason: it's good to have a feedback loop with implementers, as they understand the nuances.
Ethan: so, if we quickly draft a use cases document, it would be good to present it to the CSS Working Group. We want to have a conversation with all parties.
Keith: The concept of container queries has been happening for a long time. How can new people catch up? How do we know which things have been discussed?
Eric: We’re a small enough group right now that the best way to catch up is probably just to ask questions.
Eric: But we want to lower the bar for new people to come in, come up to speed quickly, and contribute – we should add documentation/links to the wiki on GitHub.
Jason: I've been using the Wiki, the few links there already are great.
Ethan: we could spend the next 1-2 months developing the use cases documents.
Ethan: explaining the problem - and then having our first checkin meeting with the CSS working group
Eric: Marcos had proposed a pretty quick timeline. Maybe 1-2 months. Would that work?
Dan: how big should the document be? how much detail?
Eric: the Responsive Images use cases document is pretty long, but ours can be much shorter, as we aren’t up against as much resistance. There’s a lot of general agreement and understanding about the container query problem.
Marcos: we should keep it about 3 pages - around 1500 words.
Dan: how does the pull request process work?
Marcos: People submit pull requests, we review them as group. The Editors help get it into shape, ask hard questions, and help the contributor with answering those questions. Once there is consensus, and the contribution is in good shape, then it gets merged into the document.
Ethan: it's good that we have people with experience in this area to call upon.
Marcos: we need to work as a group - always aim to help each other out.
Marcos explains process - audiences (community, browser vendors, and us - for our own sanity). The Chairs need to triage issues, and make sure those issues get closed - they close them, or they help find solutions to closing them. They keep things moving forward, manage the project, and moderate the discussion threads. Editors "edit". That is, they write text, the review text from contributors, they ask questions, and they help those questions get answered.
Marcos: try to gather what's already out there with regards to content (particularly blog posts). People have thought long and hard about this stuff already, so we should leverage as much of that as possible.
Eric: to go back to the roles, as I understand it, the Editors serve as point people, responsible for the text. The Chairs deal with human issues.
Jason: what should we do with the current doc?
Marcos: we should review it as a group, keep whatever is good - eject whatever is not. Please everyone read it.
Jason: it's good to establish criteria to evaluate what is in the document - how are users affected?, how are developers?, etc.
Keith: are there other use cases that used to be in the document?
Eric: don't think so.
Ethan: Keith, if there anything you want to jump onto there, that would be great.
Ethan: Eric and I volunteer to Chair. Tommy and Dan volunteer to edit.
Marcos: I'd like for Ethan to also contribute text and do some editing.
Ethan: Thanks everyone for joining!
THE END
ok