charter

chris: need to get dbaron's response to Chris' email about Mozilla's objection
... so without that we can't get forward

heycam: I will ask him when I go back upstairs

AmeliaBR: the community group, we got a letter of concern from the Apple team who are looking at the 3 sentence topic sentence and taking that as a broad charter scope
... so I've responded to that
... hope Chris can take over some of that discussion

chris: yes I can
... the WG charter and CG charter comments should be considered together

AmeliaBR: but there is a process for a CG to get a proper charter, that's one of the first tasks
... one thing to discuss here is what is the CG's scope and charter and how should it related to the WG

chris: anything that's related to SVG should be in scope, no matter how broad or extensive
... regardles of implementor support, since the point is brainstorming and figuring things out
... only once there's a proposal that's fleshed out, with implementor interest, that we involve the WG and see if they want to take it up
... so I don't see a particular need to constrain the scope
... it's naturally self constraining, since nobody's going to put effort into things that are getting no interest

AmeliaBR: I think that's a good way. the place that needs clarification is what point should things move from CG to WG
... and how that process should work

chris: CGs can publish reports, including a Final Report (that's a winding up the group thing)
... the report can point to github issues, spec, summary to date
... links to implementor interest
... use cases
... that's a useful report to have

krit: it has to fit in the SVG WG charter in the end
... without implementor support it won't get taken up in the SVG WG

myles_: so there's an introductory document, a collection of GH issues, and implementor issues?

heycam: implementor interest

myles_: sounds fine
... I know of one topic that one topic the CG will probably discuss soon. do we know of other topics?

AmeliaBR: as a broad scope, all the things we've pulled out of the SVG 2 draft as we don't have implementor support
... can get organized in the CG into standalone specs where we can work on getting the community support, use cases, maybe polyfills
... maybe still workshopping the syntax/structure of the feature
... so things like mesh gradients / hash proposals

krit: one suggestion: we shouldn't automatically put these in the CG, but should need interested editors

AmeliaBR: good point, no point throwing them off to the CG if nobody's working on them
... I could send out an email saying these are some of the projects
... those ones and the L3 specs that we have sitting neglected (advanced path features, some of the other ones)
... that have been discussed but never made it into the current SVG spec
... list them out, see if anyone wants to take responsibility and make a standalone spec, get community support, looking at polyfills, use cases
... to then bring back to implementors

myles: are you asking that to us directly?

AmeliaBR: this is a strategy of me sending out a request to members of the CG
... so find someone who's willing to shepherd each feature through these steps

myles: sounds good

AmeliaBR: right now we have a list of 16 participants. it's a mix of WG members and couple former members
... then various community members who saw the call out
... but I would encourage people to do outreach and get people who might be interested and able to do this sort of work involved
... as we start doing things on thta mailing list, and make it clear that's something that's actually going to do work, and have active involvement, that might help people get interested and sign up
... if you know someone who's been keen on a given feature, this is where we want to get them onboard

<chris> https://www.w3.org/community/svgcg/

heycam: this whole setup sounds good to me
... sounds like a good way to try to resolve past problems of wasted effort

AmeliaBR: so this should hopefully regain community trust

myles_: out of general curiosity, where the historical problems because there was no one willing to implement? or somebody but patches rejected?

chris: I think there've been cases of both

<AmeliaBR> scribescribe: AmeliaBR

<AmeliaBR> heycam: I think there were cases where WG members were interested, but didn't have the skills to make it happen

chris: one good thing about the WG in the past is that it had lots of graphics experts
... but sometimes that led to features that were difficult to convince the implementing teams that it's valuable to implement

AmeliaBR: that suggests that for managing the CG one thing will be to give that guidance of how do you make a good proposal to convince people
... that's something I've been thinking about lately

krit: speaking of organization, how/where do we organize the work?

chris: I would suggest using GitHub, it's so much better having all the discussion in one issue
... I know that means we have more focused discussion

leaverou: you can create general issues...

myles_: I think the example of CSS to switching to GitHub has been a great success

AmeliaBR: I'm a big supporter of GitHub. we briefly commented on giant mono repo or ...
... we can set up a new org, then for each feature proposal have a very focused repo per proposal
... within that repo create use cases, explainer doc, spec proposal, demos, polyfill

TabAtkins: agree

myles_: that's how ECMA does it too

TabAtkins: our use of a monorepo is historical in CSS, not necessarily good practice

AmeliaBR: GitHub has got better at switching issues between repos now

krit: so create a new org? just svg?

myles_: should the SVG WG and CG be in the same org?

chris: right now they're in the w3c org

leaverou: is it possible to move an issue from CG to WG?
... then they should be under the same org?

AmeliaBR: there's no nested orgs
... if we want to do an org that has clear repos for each feature then it can't be within the w3c org, has to be a separate one
... does mean transferring issues from CG to WG isn't going to be as easy currently though maybe GitHub will add that feature in the future

heycam: I think we should make it easy to migrate issues from CG to WG

myles_: seems to be a good pick, no going to be likely to migrate issues to some different WG

chris: one benefit under the w3c org is that we have a tool for contribution detection, pinging for licensing commitments
... we also have two existing things under the w3c org
... so it's some work to shift to a separate org
... there's no limit on repos named like svg-cg-blah

AmeliaBR: the issue is that the licence agreements are different for CGs
... maybe just using that IPR thing might not work
... as a CG chair I can't give people permissions to create a repo within the main w3c org
... anything there would have to go through the w3c permissions

chris: if you tell me then I can get it made
... I can do that very easily. I could also get you admin rights if you need to do that
... you don't need to be w3c staff

AmeliaBR: how about you run it through the w3c staff who's responsible for CGs and check with them

chris: in this case since the new SVG WG charter explicitly links to the CG
... and this is an emerging pattern, with parallel WG and CG
... having a CG that's dedicated to being a feeder for a WG is an emerging pattern

AmeliaBR: ok
... if we can get it set up later this week that would be wonderful
... process wise, GitHub for code and issue discussion as much as possible
... mailing list and blog for the CG on the web site, so I might do a couple quick posts about what we're trying to achieve here
... and how people should get involved
... there is a template for draft CG charters

<AmeliaBR> http://w3c.github.io/cg-charter/CGCharter.html

chris: the idea with these two repos, one for WG one for CG, you copy the template to another file, rename it, then you can have issues on that repo while the charter is under development

AmeliaBR: so that happens in this cg-charter repo?

chris: yes

AmeliaBR: I agree with Chris' statement from earlier to keep the scope fairly broad with the emphasis on clarity that once things get to the point where multiple implementations, and trying to get more, we should be transferring it to the WG
... do we want to list specific deliverables?

chris: I think that's premature
... and it will evolve over time

AmeliaBR: test suites and other software, if each proposal is encouraged to come up with the test suite as the spec is developed that's great
... also polyfills

chris: each proposal that is ready to go off to the WG should have a detaile dproposal, implementor interest, tests, polyfill ideally, backgrounder doc
... this is a comment we got on the SVG WG charter, needs to have clear use cases and requirements
... and I think that's a fair point

AmeliaBR: especially for new features yes
... so working on this charter should be one of the first priorities
... so we can send out a call to the current group membership, start with copying this template with most of the notes intact and starting issues for discussion in that repo
... so I will take care of getting the ball rolling and that will start the discussion

heycam: I'm assuming the CG isn't having meetings?

AmeliaBR: I think at this point we don't want to schedule anythin
... as we get people working on specific feature proposals, that might make sense to have targetted telcons

myles_: maybe eventually, or even soon, but right now no

chris: the thing needs to make sure the charter doesn't say they can't happen
... e.g. at TPAC there's an option for CGs to have 2 hour blocks for meeting
... it probably is too early for this year
... might not be
... but I don't think we have an imminent need for it
... having single purpose telcons once we have fleshed out proposals would be ok

heycam: I assume you'll be using Bikeshed rather than my scripts for these CG specs

AmeliaBR: yes

chris: the major limitation of Bikeshed is lack of multi page specs, but these CG specs will be small single page specs

TabAtkins: I'll fix that some day, but it hasn't become important enough yet

<Rossen> I'm sure this was already asked but since I can't find an answer - Why not WICG?

<chris> rossen, the svg wg charter allows input from WICG but the proposal to the membership was a focussed CG, as for example we have a web audio wg and cg

<chris> so that is the proposal that the AC review concluded was a good one

<Rossen> chris, fair enough, thanks

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/emergent need/imminent need/
Present: AmeliaBR heycam emilio TabAtkins skk Amelia Tab Emelio Krit Leaverou ChrisL Myles
No ScribeNick specified.  Guessing ScribeNick: heycam
Inferring Scribes: heycam
Found Date: 27 Feb 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)