<shari> present_

<JakeAbma> scribe: JakeAbma

Triage update

<jeanne> https://github.com/w3c/silver/labels

Jeanne: we have wiki page for github issues

<jeanne> https://github.com/w3c/silver/labels

<jeanne> https://github.com/w3c/silver/issues

Jeanne: issues are labeled with 'action', 'guideline', 'section'
... will create URL for all specific subgroups
... so you don't have to search in Github
... no need to change based on comments, but mention the reason at the Github issue

<jeanne> https://github.com/w3c/silver/issues/261

Jeanne: provide comments at the bottom of the issue

Wilco: Jeanne, you talked about closing the issues, but they are official comments, do we need official response?

<JF> +1 - sub group responses would not be consensused

Wilco: are the subgroups responsible for the responses? Not the Silver WG? They do not have official mandate

Chuck: MC probably need to answer, but we can probably give to subgroups, if agreed, but pass it to MC

<JF> +1 to review process

Jeanne: if we go along Wilco's comment, that actually the AGWG need to respond, not even SIlver only

<sajkaj> +1 to Wilco

<Lauriat> +1 to Wilco to have a clear process for this, regardless

<jennifer> +1 to Wilco

Wilco: not against delegating, but we probably need some official approach probably

<sajkaj> Let's remember it's still early days.

SL: let say for now the subgroups can respond, and formalize the approach

JF: really concerned sub-sub groups speak for all in the AGWG. We might end up with a 'no-no-no' we did not have consensus. Strongly would like to see official approach to responses.
... we need minimum review

<Fazio> I understand thee desire to move through this quickly. JF haas a point

<JF> https://www.w3.org/2020/Process-20200915/#Consensus

SL: we will ask what level is required for consensus, will ask MC, Chuck and the other chairs

<Zakim> sajkaj, you wanted to remind that github has at least 3 interfaces for issue management

JS: CR status is probably a moment where consensus is very important, yet it will probably not be that important, but agree with formal processes.

<Fazio> true proposed responses

<Zakim> Lauriat, you wanted to mention comments getting more question or starting to work through things

JenniferS: can we create an automated response for the issues? to make sure people understand our approach

<Lauriat> https://github.com/w3c/silver/issues/261

<Sheri_B-H> scribe:Sheri_B-H

Janina: We've adopted github, we get everything that comes with it. There are no side conversations, anyone can comment, everyone will see it.
... Second point W3C process requires formal comments to get comments back from the original commenter. If we ask "do you agree with this" for every comment, it will be a very heavy process, and it is too early to do that.

<Zakim> JF, you wanted to ask if the ability to Close an issue can be constrained to Chairs/Facilitators

JF: there is a concept of lazy consensus
... Is there any way in github to constrain the ability to close the issue, so only chairs/facilitators can close issues?
... we don't want a continuous ping-pong approach

<jennifer> All that open+close, etc., creates friction on the trust of the WCAG for the public, too.

JF: In 20 minutes I could close every issue
... I want to see some kind of process that in a rush to close out tickets, we don't achieve consensus

<Zakim> Lauriat, you wanted to propose a process for right now while asking about other groups' processes.

<Fazio> we use it for cog and agwg

<Fazio> coga

VMware uses it for all 3000+ of our open source tools

it==github

Wilco: anyone can open, not everyone can close or reopen

<JF> +1 to enforcing permissions

Shawn: Do we need a resolution?

<JF> @Shawn: TFM ;-) https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

Chuck: no one is going to be closing issues at this time, we don't need a resolution

Janina: we shouldn't close until we can point to the editor's change in the draft, or it is "won't fix"

What asynchronous collaboration processes & best practices do you use in your organizations? (not a tooling question)

<Lauriat> Sheri: Difficult to separate processes from tools.

Shawn: make sure stakeholders that are clearly assigned

<Lauriat> Sheri: Heavy use of RACI diagrams ("Responsible Accountable Consulted Informed")

<Lauriat> +1, it helps so much…

<Lauriat> Sheri: Things do bounce around between tools, sometimes due to access.

<Lauriat> Sheri: Think about the process, identify tooling that supports, then finalize with that.

Shawn: RACI works better for large categories

<Fazio> we assign peopl to github issues

<Lauriat> Sheri: Maybe infeasible in W3C, but we assign people to monitor certain communication channels to ensure things make it back to the rest of the group.

Shawn: there are a lot of places conversations can start/happen. Different people prefer different channels. I (Shawn) struggle with email threads, where comments in git or google docs work better for me. I've had varying degrees of success in looping back issues that need to be discussed by the group.

Sheri: We do make heavy use of tagging at VMware

Shawn: will put it out to the group in an email blast

sbyrnehaber@vmware.com

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: Francis_Storr, sajkaj, jeanne, JakeAbma, Chuck, mgarrish, joconnor, jennifer, Wilco, Sheri_B-H, sarahhorton, JF, Jemma, KimD
Present: Francis_Storr, sajkaj, jeanne, JakeAbma, Chuck, mgarrish, joconnor, jennifer, Wilco, Sheri_B-H, sarahhorton, JF, Jemma, KimD
Found Scribe: JakeAbma
Inferring ScribeNick: JakeAbma
Found Scribe: Sheri_B-H
Inferring ScribeNick: Sheri_B-H
Scribes: JakeAbma, Sheri_B-H
ScribeNicks: JakeAbma, Sheri_B-H

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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.)