<Chuck> meeting: AGWG-2021-10-26

<laura> https://www.w3.org/WAI/GL/wiki/Scribe_List

<laura> Scribing Commands and Related Info https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<GreggVan> +present

<Lauriat> Scribe: Lauriat

<AWK> +AWK

WCAG 3 Process discussion https://www.w3.org/2002/09/wbs/35422/approach_oct_21/

Chuck: [reads question to introduce topic]
... We'll summarize the comments and then go through topics and themes.
... Rachael's comment first
... Rachael's mute not working, reads Lauriat's comment (not substantial)
... sarahhorton had changes proposed

sarahhorton: For placeholder content, thinking important to be able to do, testing out new content and concepts.
... Concerned about having that kind of space in the Editor's draft. Suggested changing it so that placeholder content in the Editor's draft would require WG agreement.
... Other comment, more related to the schedule document. Not sure if this question relates to the schedule?

Chuck: Not sure yet, we can work through more and return.

JakeAbma next

JakeAbma: Core question also about placeholders. It should not be a way to publish whatever we want and just put "placeholder" in front of it.
... The placeholder guidelines already look pretty prescriptive, and feel more like methods or outcomes.
... When is something a placeholder and how detailed can it be before steering people in a direction or confusing people?

Next up: laura

laura: Would like agreement more clearly defined. The proposal lacks details about how to add editor's notes.
... Editor's draft could be renamed "WCAG 3.0 sandbox" and explain the status of the document.

Chuck: Mostly around the placeholders [summarizes points]

<laura> Fire alarm have to go.

AWK: Not adding themes. I agree with comments and concerns about putting content that hasn't gone through the WG into the Working drafts and Editor's drafts.
... People outside the group will see the Editor's draft and I worry about the impact of that when things haven't gone through more thorough review by the WG.
... In favor of the categorization, but things should be mature and stable to go into those drafts.

david-macdonald: Same concern about content going into Editor's drafts.

<Zakim> alastairc, you wanted to talk to place-holders, notes, separate doc

<AWK> AWK also likes the idea of sandbox for placeholder, exploratory, and maturing

<GreggVan> +1 for sandbox ibid on the comments of AWK and David

alastairc: On the placeholder comments, that's difficult to deal with as we need placeholders to indicate the direction of the content. They won't take on those exact names and we expect changes.
... All based on WCAG 2.x material, so that didn't bother me.
... On Notes, we proposed that any content in there would have a note saying the status and the issues in discussion on it.
... On the separate doc, it sounds like "Sandbox" is really what we meant by Editor's draft. Not really sure what would go into a Sandbox vs. Editor's draft.
... Name only or do we need another level?

GreggVan: Editor's drafts generally meant to be representative of what the group things and just needs cleaning up before it goes into a Working draft.
... Same with placehholder content.
... I think the sandbox idea is a great idea, and in there we can put whatever ideas and issues and such.
... We can still refer to it. Once it gets to an Editor's draft, it implies a level of maturity.

<Jennie_> +1 to GreggVan's points, and adding that history of use of "draft" by W3C groups won't have some understand the less mature stage.

<kirkwood> +1 to Gregg

PeterKorn: How publicly visible do folks think we can make the sandbox?

Additional Sandbox Document vs. 2 labeled documents

PeterKorn: Two main values of this kind of draft. We can see how it comes together an we can reach out to others outside the group for specific feedback.

<AWK> A link to the sandbox from the editor's draft, or even working draft, would be fine as long as it is characterized as exploratory or placeholder.

<Zakim> Rachael, you wanted to speak to intent as compromise

<GreggVan> By having a link from editors draft -- it would clearly have to be public

Rachael: As a reminder of how we got here, we have two perspectives on drafts and how we use them. One holds that Working drafts should have fairly final content.
... The Editors' drafts made a compromise between putting things in Working drafts and holding off on putting content in.
... This would make three documents to maintain.

MichaelC: W3C process doesn't require content in Editors' drafts to represent more mature and WG-agreed-on content.

sarahhorton: Going back to the "sandbox" term, the placeholder content going into the Editors' draft. If a subgroup had a proposal, it could go directly into the Editors' draft. I proposed that the WG agrees that it can go in.

<Rachael> Possible Themes for discussion: 2 or 3 documents, Whether to require working group agreement to add placeholder content, format for placeholder content

sarahhorton: The Editors' draft is a publication of the WG, so a subgroup publishing directly doesn't seem desirable.

<Zakim> jeanne, you wanted to say that there is an essential conflict between wanting experts to comment and not putting anything in the Editor's Draft that isn't mature. It makes our

jeanne: I think there's a conflict between the desire to not make work public until we have that agreement and the desire to get feedback on things. Having it in the Editors' draft makes it possible for people to track what we're working on.
... If we make a new third document, people won't know where to find it and will think we're making our work more secret and less open and we should avoid that.

<Zakim> Chuck, you wanted to say I think these will all be public, and it's setting expectations at levels

jeanne: We can put issues that we haven't finalized in to get input from others outside the group.

<AWK> Would be easy to add references to any of a series of external proposal documents into the editor's draft, not necessary to add the unapproved content into the draft directly.

Chuck: I think all of our work will be publicly viewable, regardless of location or name. If we set expectation, that can solve that challenge.

GreggVan: The sandbox was always meant to be public and linked directly from the Editor's draft.
... The Editor's draft will get messy to have the item, the notes, any alternate views.
... If we have a low threshold for getting things in, we'd have a large number of items going in.

<Zakim> alastairc, you wanted to talk about the alternatives where people reference wikis / documents

alastairc: Noting Jeanne's comment, we should probably show Wilco's work. Seems like expectations attached to "draft".
... If we add a sandbox, earlier document, rather than having lots of external proposals in different places, it'd help to have them all together in a single place.
... If we have a sandbox, our Editor's draft would become a placeholder on the way to a Working draft, so it seems like it comes down to labelling rather than a difference in practice.

shadi: I think it helps to have drafted content at different levels of maturity in the same place to get input. I don't think subgroups alone should make decisions, so those should go through the WG.

<jon_avila> I agree with Alastair and Shadi - I think it's about how we label and describe it that makes the difference - but I also agree that content needs to be reviewed for labeling by wider group and not just from sub group.

shadi: I would expect and Editor's draft with clear labels on the content of the different labels of maturity, "very rough", etc.

<alastairc> jon_avila - ever level above placeholder does need agreement from the group

<Rachael> One question we need to discuss based on the survey is whether the placeholder should also have agreement from the group

shadi: Instead of having links out to the different places, have them in the Editor's draft with clear labeling and context.
... The lower-level maturity items wouldn't make it up to the Working draft without making it up to higher levels of maturity.

JF: I agree about labeling.
... Building on the same mechanism as Editor's notes can make the labels clear.

Wilco: Full support for what Shadi & alastairc mentioned. The sandbox would just become the Editor's draft, so I'd prefer we stick to a two-document solution.

<Chuck> +1 to 2 document solution

+1 to Wilco

<Chuck> +1 Wilco

<Zakim> sarahhorton, you wanted to talk about second part of my survey response related to prototyping

Wilco: We should just try it instead of wondering how it would work.

<shadi> [[more work on the Editors, Chairs *AND* the readers]]

sarahhorton: My other part of my response had to do with when we had more of a design focus. We have this document and structure, and we need a way to share that.
... We had included prototyping in our design plan, which we need to do to figure things out and get feedback on those pieces and how they fit together.

<kirkwood> +1 to sandbox. Simpy put it should be a live s.a. a Google doc. We essetially already do it in COGA. Allows for potentially more active participation. Would allow for more inclusive feedback too (subject matter experts s.a. as non w3c process wonks).

sarahhorton: If we do put placeholder content into the Editor's draft, we need clear process for how that goes in. If we have things subgroups want to work out, those can go into prototypes.

<Zakim> Chuck, you wanted to say this compromise has 8 agreements (4 agree and 4 agree with changes)

<alastairc> (9 now, 4 agree 5 agree with changes)

Chuck: This survey is the compromise in the group, and we have no disagreements.

<Zakim> Azlan, you wanted to ask re sarahhorton 's comment about a subgroup publishing direct to the editors draft implies that each subgroup would need their own sandbox and how those

Azlan: On subgroups publishing directly to Editor's draft as undesirable, it implies that each subgroup would need their own sandbox, which would need managing.

<Zakim> Rachael, you wanted to state that the "sandbox" exists in the current proposal but it is under control of each subgroup.

Rachael: I agree that we need prototyping. In the two-document solution, the iterative prototyping would happen in whatever documentation and such the subgroup manages.

<Rachael> Themes: 2 or 3 documents, What does a sandbox/prototype look like?, Whether to require working group agreement to add placeholder content, format for placeholder content, adding prototyping to schedule

Rachael: We should stick with one theme and work through that and ensure everyone's voice is heard.

<alastairc> qv?

GreggVan: We have a false dichotomy. Putting things into the Editor's draft vs. sandbox document to work through things before having to get consensus. Could get consensus to go into the sandbox much easier.

<Rachael> Showing Wilco's work would be helpful in clarifying this

<Zakim> alastairc, you wanted to talk about removal of content

alastairc: On subgroups publishing straight to the draft, we didn't propose subgroups would. We would put things in as exploratory, noting the disagreements on it.
... On removing things, anything that doesn't progress to stable would be removed if we don'

t get full consensus.

2 or 3 documents

<GreggVan> current proposal says that Placeholders go in with just Subgroup recommendation

<Rachael> The last statement in the proposal states "content included in the final Candidate Recommendation must be at the Stable level. By default, anything else that has not reached Stable will be removed."

Wilco: Getting a sense that it might be okay not to have a sandbox. Because of the stages of maturity, I think it'd make it easier to get consensus on things.

<Rachael> Gregg, that is one of the questions that we need to discuss but have not. It is a suggestion that it require working group agreement.

<alastairc> Placeholder is a name and a note, no real text.

Wilco: We should do more of this asynchronously instead of discussing everything on a call.
... As you have things going into higher levels of maturity, we'll have more in depth review.

Whether to require working group agreement to add placeholder content

<Zakim> Chuck, you wanted to say I'm a fan of 2 documents

shadi: The correct labeling would allow for sandboxing or prototyping there, with a different level of approval or support to go in. The Working draft would be very different.

<GreggVan> Placeholder with a descriptive title will look like a coming recommendation. ( e.g. "Content is in plain language" )

Chuck: Let's focus on this topic and work through.

<alastairc> Could that be approving the schedule?

<Rachael> Gregg- that is another question we have to discuss per Jake's comments in the survey

<shadi> +1 to Wilco

Wilco: I very much think the group should be notified, but I don't think we should have large discussions and should emphasize asynchronous work.

<JF> contrary to

GreggVan: Placeholder sounds innocent, but in other standards it means that we've reserved the space for it.

<Wilco> @Gregg, do you have an alternative name/label instead of placeholder?

GreggVan: It sounds like we've already decided that we need to include it.

<JakeAbma> +1 to Gregg, that's my point too

GreggVan: If we went with the sandbox approach, we'd pull in all of sandbox documents in one place, which I think would help and avoid making the Editor's draft huge.

<Chuck> yes, will tackle scribe change after Rachael

Rachael: Regardless what we call it, the idea is to hold the place. We have a lot of things to address. We need it, because otherwise we circle around having not talked about different topics.
... We'll need to make it clear the level of maturity. I also agree with Wilco about working asynchronously so that we don't take large amounts of time to add placeholder content.

<PeterKorn_> Regrets; I need to leave for another meeting

<ChrisLoiselle> Scribe: ChrisLoiselle

<Jennie_> * Rachael: for those that may need a style of reviewing the placeholder content through discussion (that would be handled through email) could this be something done by chairs offline? COGA members state this is sometimes helpful.

Shadi: On topic of placeholder , could have a different name. Support for it , we need to have input on language and terminology.
... there is idea , but it may not be possible and reasons why. It may be wise to put these ideas out

<Zakim> alastairc, you wanted to say we need to say "This thing can be removed", and sub-group sandbox vs group sandbox

AlastairC: We should clear that things can be removed, prior to mature level. So, at placeholder we want to be clear things can be removed on topic of labeling.

<Jennie_> * Rachael - thanks. I think this topic of handling conversations outside of meetings, only through email, should be a part of the discussion.

<Zakim> Chuck, you wanted to offer an async approach

AlastairC: on Gregg's point on getting too big, there are branches and sub groups. There will be notes on what needs solving prior to being resolved. +1 to all things being in one place once working group agreement is there.

Chuck: What if we decide to talk through this asynchronously and where there is disagreement, we talk to that issue in call?

<Wilco> +1

<alastairc> As Rachael mentioned, should be part of scheduling discussion, so an occasional thing where we add a set of placeholders.

<Zakim> Rachael, you wanted to request Wilco's work

Rachael: We are talking to theoretical , does Wilco have an example?

<Zakim> GreggVan, you wanted to say that we had said earlier that a provision would need other notes on pro and con and what it needs to move up. Those provisions will be - almost by

<Wilco> https://raw.githack.com/w3c/silver/status-proposal/guidelines/index.html#normative-requirements

<alastairc> Example current note: https://raw.githack.com/w3c/silver/status-proposal/guidelines/index.html#issue-container-generatedID-3

Gregg: To Rachael, you can see that this will be at least 4 times as single provision. Second question is how many within subgroups want to do this? May be beneficial to hold vote and ask how many provisions want to be placed in. Mock up to see what it will look like.
... after that, we can talk to whether it will inflate or not.

Rachael: Adding editor's note will add space. We need to talk whether or not we can roll it up .
... Best of both worlds for having text provided and one not.

<JF> +1 to Rachael's thinking about styling

<jeanne> +1 to Jennie

Jennie: On caution for this and topic of asynchronously following conversations and voting on topics . Talks to accommodations needed for COGA on voting and contributing to topics asynchronously

<Chuck> Proposed RESOLUTION: placeholder content will require WG approval, to be sought asynchronously and with appropriate accommodations, and any content that does not get asynch approval will be discussed in call.

<Zakim> Chuck, you wanted to propose RESOLUTION: placeholder content will require WG approval, to be sought asynchronously, and any content that does not get asynch approval will be

JF: Are you talking to WBS survey for asynchronously ?

Chuck: Not prescriptive at moment.

<Rachael> Can we take an action to bring back asynchronous options with feedback from COGA for agreement here?

JF: I agree with Jennie's concerns. We need to be able to keep up with what is going on with all the various topics. Asynchronously being wide open is concerning as to where and how we do that prescriptively

<kirkwood> I share John’s concern

<david-macdonald> How about Asynchonously, in a mode approved by the grou[

JF: Rachael was talking to styling and a weekly survey, they could see in context , i.e. see here, see here for x, y, z. If topics arise out of survey, we talk to those in call .
... Surveys are asynchronous , and we wouldn't be looking at a variety of different things

<Rachael> draft RESOLUTION: placeholder content will require WG approval, to be sought asynchronously, and any content that does not get asynch approval will be. Chairs will bring back asynchronous options with feedback from COGA for agreement by working group.

<Jennie_> +1 to discuss with COGA

Rachael: We'd need feedback from COGA on what that would be , chairs will take back asynchronously topic with COGA and determine what that will be.

<jeanne> +1 to discuss with COGA

?

<Chuck> +1

BruceB: So the resolution is that the working group recognizing drafts prior to being integrated to an editors draft?

<Rachael> draft RESOLUTION: placeholder content will require WG approval, to be sought asynchronously, and any content that does not get asynch approval will be discussed. Chairs take an option to bring back asynchronous options with feedback from COGA so the working group can select an option for asynchronous decision making

<Rachael> draft RESOLUTION: placeholder content will require WG approval, to be sought asynchronously, and any content that does not get asynch approval will be discussed. Chairs take an action to bring back asynchronous options with feedback from COGA so the working group can select an option for asynchronous decision making

<Chuck> +1

<bruce_bailey> +1

<Wilco> +1

<Nicaise> +1

<ShawnT> +1

<Rachael> +1

<ToddLibby> +1

Chuck: please vote on this resolution

<shadi> +1

<Azlan> +1

<MelanieP> 0

<jeanne> +1

<GreggVan> 0

<alastairc> +1

<david-macdonald> +1/0

<Jennie_> +1 was COGA members have a way they feel comfortable participaing.

<Detlev> +0 really don't know

<JakeAbma> 0

<laura> 0

Gregg: what does asynchronously approval mean in context?

AlastairC: No objections.

<JF> 0 (I still have reservations on how many asynch options there may be - I'd be happier if it were gated to no more than 2

<Rachael> Remaining Themes: 2 or 3 documents, What does a sandbox/prototype look like, Whether to require working group agreement to add placeholder content

<Jennie_> Sorry, +1 as long as COGA members have a way they feel comfortable participating.

<kirkwood> 0

<sarahhorton> +1 but we need a place to prototype if WG approval (no objections) is required to include content in editor’s draft

<JF> 12 X +1, 7 X 0, 1 X +1/0

RESOLUTION: placeholder content will require WG approval, to be sought asynchronously, and any content that does not get asynch approval will be discussed. Chairs take an action to bring back asynchronous options with feedback from COGA so the working group can select an option for asynchronous decision making

2 or 3 documents

Chuck: On inclusion of content in documents , 3 documents may get cumbersome on managing

<Zakim> alastairc, you wanted to say it will end up being 2, it's just naming.

AlastairC: Use example of a funnel , branches, documents, then a sand box document , then editor's draft and working draft. We end up working in sandbox in most recent work.
... the difference of editors vs. sandbox disappears , so question is around status of document.

<Rachael> +1 to labelling the editor's draft so it is clearly our aggregate sandbox.

<Zakim> bruce_bailey, you wanted to ask about clarify need -- i think it is for multiple (possibly conflicting) place holders ?

Gregg: we publish the working draft, correct ? So it is published. So most people think that editor's draft is the one to be published. Editor's draft when a button is pressed, is published. So all work in editor's draft, you'd need to push publication on another item

<alastairc> levels: sub-groups work, editors-draft, working-draft.

<alastairc> OR: sub-groups work, sandbox, editors-draft, working-draft.

Bruce: I'm still looking to understand where we are talking to multiple placeholder sections .

Gregg: One is public. One is for other groups to work on . If working draft is frozen, then editor's draft is the to be published. Then the sandbox, can be used to have subgroups placing content.

<Chuck> ack

Rachael: We had resolution on placeholder content. Now, we are talking to different documents and where this is placed. I.e. this gets put in as a pull request ... talks to marking items as exploratory with a label. Do we measure in two documents or three , i.e. 2 or 3 levels?

<Zakim> Rachael, you wanted to provide an editor's perspective.

Rachael: It is not a button from editor's to published working draft. There is a huge amount of management that goes into this, so managing a third document would be huge.

<Chuck> +1 to Rachael, the work is huge

<alastairc> I'd prefer to remove the editors draft, and go from sandbox to working draft.

<GreggVan> +1 to editors have a huge amount of work

<Rachael> I agree with alastair of 2 documents "sandbox" to "working draft"

<GreggVan> +q to ask question. I thought the sandbox was more of a wiki like document and did not include pull requests and would not require editors to manage - that the subgroups really want to manage that.

Sarah: I can see a value in publishing innovation work. We should be including that are brand new. We don't have a place to do that . We need AG approval for editor's draft, but need to take it out of abstract. Prototyping space is needed.

<Zakim> GreggVan, you wanted to ask question. I thought the sandbox was more of a wiki like document and did not include pull requests and would not require editors to manage - that the

Sarah: We can't prototype for scoring for all of guidelines. Subgroups need to implement the prototype and score it. Working group and public would benefit from group's thinking.

Gregg: I thought more sandbox was more of a wiki, rather than a push or pull request type of area. If a wiki, pull requests would not be needed. Am I misunderstanding the pull request aspect?

<Zakim> bruce_bailey, you wanted to say that +1 to explore modified workflow where not *everything* in ED automatically moves to WD

<Zakim> alastairc, you wanted to answer gregg's question

<Rachael> Bruce -I believe that is already the case

AlastairC: New branches on github and preview content would be beneficial and the subgroups can do that ahead of process we are talking to today. Then we'd have a area where all groups are exploratory material nature can be seen in context

<Zakim> bruce_bailey, you wanted to say +1 to explore modified workflow where not *everything* in ED automatically moves to WD

The question is around sandbox to working draft and not using the edtiors draft, i.e. what do we can group sandbox

<JF> +1 to Bruce

<GreggVan> and would that group sandbox be GitHub pull request based ?

BruceB: I think Rachael's proposal on resolution is a bit premature. It is not in the placeholder content . I do love the idea on expanding capabilities of editor draft.

Chuck: Bruce, do you think we need to make a pre decision to be made ?

<Zakim> Rachael, you wanted to try to answer this

Rachael: The reason we were looking at placeholder solution was to look at two conflicting processes , public perceives working draft as referenced document.
... from AG perspective, we want to make sure that it is as formal and final as possible. W3C uses the working draft as a sandbox.

<alastairc> Poll idea: Having a group-approved "Sandbox" prior to Working Draft (1) OR Having an Editors draft that is essentially a sandbox.

<Zakim> GreggVan, you wanted to ask -- would a pull request need to be made for each pro and con or requirement for each provision in the "sandbox" part of the Working doc?

BruceB: I'm fully supportive of the work everyone is doing, thank you.

<Zakim> Chuck, you wanted to say I echo Alastair's comments, that if we had Placeholder->editor's draft->working draft, we will effectively skip editor's draft

<JF> +1 to Gregg

Gregg: On topic of cons within working draft, does that initiate a pull request? Same for the pro , the pull request then would get approval, that would be a slower process.

<Zakim> Rachael, you wanted to answer Gregg's question

<Chuck> Poll: Having a group-approved "Sandbox" prior to Working Draft (1) OR Having an Editors draft that is essentially a sandbox.

Rachael: I had a different perception of that. The editor's note would address pro or con at that time.

<Rachael> The subgroups maintain their own content and comments

Gregg: Worry is on subgroup and adding comments pro or con and where and how to do it.

<shadi> +1 to Rachael and Michael

MichaelC: We can tag issues to proposals and it can be dynamic

<Chuck> Poll: Having a group-approved "Sandbox" prior to Working Draft (1) OR Having an Editors draft that is essentially a sandbox.

<Zakim> Chuck, you wanted to execute the poll

<Chuck> Poll: Having a group-approved "Sandbox" prior to Working Draft (1) OR Having an Editors draft that is essentially a sandbox.

<Rachael> I am not sure the difference between those two

<ShawnT> Could we use different repositories on Github and use a continuous integration (CI) to create a pull request? Might be too technical to discuss now.

<Chuck> Poll: Having a group-approved "Sandbox" prior to Working Draft (1) OR Having an Editors draft that is essentially a sandbox (2)

Jake: On maturity and publishing , WCAG 2.1 , 2.2. editor's draft differences, the difference between drafts could be over 60 percent different. The gap between editors and working draft may be huge.

<sarahhorton> On the poll, do they both require WG approval?

<alastairc> Process would be the same

<alastairc> https://www.w3.org/WAI/GL/wiki/AG_process

<jeanne> (2) Editor draft

Jake: If two of 23 make editor's draft criteria make it from editor's to working, how do we treat that?

<Chuck> 2

<alastairc> 2 - editors draft

<Wilco> 2

<Rachael> 2

What is the poll question?

<ToddLibby> 2

Poll: Having a group-approved "Sandbox" prior to Working Draft (1) OR Having an Editors draft that is essentially a sandbox (2)

<GreggVan> 1 - because I think the sandbox should NOT require approval and the subgroups want a place that doesn not require group approval

<Detlev> Sorry, you have lost me - this entire huge meta-dicussion has lost me, I'm afraid. I want to work on content.

<jeanne> JF, Github is set up for that.

JF: Concern on small subgroups and adding content, how is that treated ? Before any content is added, there needs to be consensus of larger group. It would be troublesome, i.e. wikipedia example of introducing churn.

<jeanne> +1 to Detlev

<alastairc> That's in the process doc we started with, anything past "placeholdder " needs Working group agreement (meeting/survey).

Melanie: I'm confused with the poll , are we talking to just two or three options

Chuck: Three levels vs. two levels of collection.

<JF> @alastair - then the concern is over adding "Placeholder" content with no group review

@AlstairC, could you add in what you just said? I couldn't catch all of that.

<sarahhorton> Can you add a third option to the poll?

@Alastair

<GreggVan> a sandbox is has much less structure and format

<alastairc> scribe: AlastairC

AlastairC: We presented 2 options, neither had 3 documents.
... that was the point, the editors draft wouldn't be part of the process

<JakeAbma> 1

<Wilco> 3

Chuck: Adding an option to the poll, option 3 is the 3-doc version

<Chuck> 2

<sarahhorton> 1

<kirkwood> 1

<Zakim> GreggVan, you wanted to say/ask I thought the purpose of a sandbox before the Editors draft was that you did NOT need group approval to go into sandbox and to say that is not what

<laura> 1

<MelanieP> 1

Gregg: We're talking about the sandbox being managed the same way as an editors draft.

<bruce_bailey> i don't think we have discussed (2) sandbox to working draft

Gregg: since we have the ability to filter an editor's draft, it seems like we could get what is needed by sandbox to WD.
... But, what I thought was that the sub-groups wanted somewhere to push things to the group. More like an open discussion, wouldn't it be more wiki like?
... Then, when something is more mature, it would go into the group process.
... that would give them the ability to push stuff this way without all the approval.
... if the sandbox is managed with github etc, we could call the editors draft sandbox and then it wouldn't have the same expectations.

<bruce_bailey> i am for option (3) editors draft acts as sandbox -- because MC is confident suggested edits can be submitted via issues (and PR not required)

JF: Not concerned about the 2/3 docs, my concern is how it gets added initially.
... if we just let sub-groups plug things in, it will get confusing quickly.

<Zakim> Rachael, you wanted to point out that subgroups present their content however they want currently

<Rachael> https://www.w3.org/WAI/GL/wiki/AG_process

Rachael: Each checkpoint has a decision point. We've got 4 topics, including approval to put a placeholder in.
... for Gregg, sub-groups don't have a single location for their work, they pick a platform.
... things don't got into the pull requests until they are ready.

<jeanne> GV, the subgroups already have access to wiki, Google docs, or Github branch for working. When a subgroup brings the document to AG to move forward, we typically bring it in a wiki or Google doc. The sandbox that Sarah has been requesting is the ability to see their work in the document. That needs to be Github, otherwise it adds a lot of work.

Wilco: I would say poll to accept the proposal.

<bruce_bailey> okay , i think this proposed AG process was the (written) piece i felt like i was missing

<Rachael> @JF - Yes, and we need to vote on that

JF: According to the doc, for placeholder it was described differently in the call.
... concerned about authority for putting things in.

<Zakim> GreggVan, you wanted to make Proposal we have 2 actual documents but 3 virtual documents. Doc 1 is Sandbox (and it is old editors draft plus new sandbox items) Doc 2

david-macdonald: What we're doing is really hard, we need to be patient. It's a pivotal thing, just want to encourage everyone to be confortable in airing decisions.

<bruce_bailey> with one minute left to go , i will mention our next survey only has seven replies so far

<bruce_bailey> • WCAG 2.2 Focus appearance (1 new question added) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

GreggVan: If we have WD, sandbox, and then a 3rd doc which is pulling the approved items from the sandbox and show them to you.

That would give you one doc to manage it.

scribe: some people are worried about things getting in, but need a place to show things.

<mbgower> present_

<mbgower> BTW, I never saw last week's minutes posted to the group?

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)

Succeeded: s/Rachael not here/Rachael's mute not working/
Succeeded: s/characterized as exploratory/characterized as exploratory or placeholder/
Default Present: ShawnT, Chuck, garrison, Laura_Carlson, Lauriat, JakeAbma, Jennie_, bruce_bailey, Nicaise, present, alastairc, Rachael, GreggVan, Azlan, sarahhorton, sajkaj, AWK, PeterKorn, kirkwood, JenG, MelanieP, JF, DavidASx, MarcJohlic, mbgower, david-macdonald, ToddLibby, Detlev, jeanne, Wilco, jenniferS, jon_avila, Francis_Storr, shadi
Present: ShawnT, Chuck, garrison, Laura_Carlson, Lauriat, JakeAbma, Jennie_, bruce_bailey, Nicaise, present, alastairc, Rachael, GreggVan, Azlan, sarahhorton, sajkaj, AWK, PeterKorn, kirkwood, JenG, MelanieP, JF, DavidASx, MarcJohlic, mbgower, david-macdonald, ToddLibby, Detlev, jeanne, Wilco, jenniferS, jon_avila, Francis_Storr, shadi, ChrisLoiselle
Regrets: BenT
Found Scribe: Lauriat
Inferring ScribeNick: Lauriat
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: AlastairC
Inferring ScribeNick: alastairc
Scribes: Lauriat, ChrisLoiselle, AlastairC
ScribeNicks: Lauriat, ChrisLoiselle, alastairc

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