– DRAFT –
ARIA and Assistive Technologies Community Group

<Rich_Noah> SCRIBE Rich_Noah

<Rich_Noah> s3ththompson: 1st update not app specific. Howard has rerun merge conflict resolution workflow.

<Rich_Noah> s3ththompson: the workflow has been documented. merge was clean apart from manual work of merging keys. can talk about how coordination to other PRs.

<Rich_Noah> s3ththompson: much easier than in the past but still requires GH work.

<Rich_Noah> s3ththompson: The whole CG should have ownership. First few can be done together.

<Rich_Noah> Matt: are there extra steps apart from regular GH merge?

<Rich_Noah> s3ththompson: good question

<Rich_Noah> Howard: if merge PR1 then have to pull masters chsnges into PR2

<Rich_Noah> Matt: normally that is done when PR1 and PR2 touch the same files. If PR1 and PR2 are for separate tests do you still have to do that?

<Rich_Noah> Howard: Yes

<Rich_Noah> Matt: can we just do a normal rebase?

<Rich_Noah> Howard: Yes, everything was treated as a binary.

<Rich_Noah> Howard: documentation was provided to treat PRs from the past.

<Rich_Noah> s3ththompson: it is a matter of overwriting the two merge files, have to pick the newest version of the artifact.

<Rich_Noah> Matt: so there is a human step?

<Rich_Noah> s3ththompson: this might only apply to previous PRs

<Rich_Noah> Matt: so we have to cleanup old branches?

<Rich_Noah> s3ththompson: yes, this is the new issue I created.

<Rich_Noah> Matt: I would prefer not cleaning up old branches

<Rich_Noah> s3

<Rich_Noah> s3ththompson: after review it appears these steps are only for the currently open PRs.

<Rich_Noah> s3ththompson: some of these require cleaning up keys.mjs. Howard are you comfortable with that?

<Rich_Noah> James: what is the PR?

<Rich_Noah> James: How do we get from a state where a PR is not using an old build directory?

<Rich_Noah> s3ththompson: those of us at Bocoup can sign up for that.

<Rich_Noah> Matt: I almost don't carry about having reviews done on PRs, merge them and then review then fix anything we don't like. James are you good with that?

<Rich_Noah> James: yes, we keep the draft flag for anything that is not ready.

<Rich_Noah> James: if it appears to be cleaner I can close the existing PRs that are in draft and then reopen them.

<Rich_Noah> Matt: yes, that would be the cleanest.

<Rich_Noah> Matt: I assume this is a relatively speedy process, we are not signing you up for 2 days of work?

<Rich_Noah> s3ththompson: first one took 15mins

<Rich_Noah> Matt: want to make sure we are not allocating resources.

<Rich_Noah> s3ththompson: PR 347 is ready to merge

<Rich_Noah> Matt: yes, pull the trigger

<Rich_Noah> s3ththompson: you don't have any issues with Bocoup merging non-draft PRs without explicit declarations.

<Rich_Noah> Matt: If there are outstanding comments then change it to a draft PR and James can review it.

<Rich_Noah> James: Yes, let us use the capabilities of GH and convert it to Draft.

<Rich_Noah> s3ththompson: I will volunteer to work on this with you Howard.

<Rich_Noah> s3ththompson: We have successfully the latest test-queue. We are at the point of testing it internally and then will share the link. had a few days delay due to a new environment.

<Rich_Noah> s3ththompson: Matt we will give you a quick pass and then share the link broader.

<Rich_Noah> Matt: when I was looking at the test queue on Tuesday it looked really different.

<Rich_Noah> Matt: things look different on production

<Rich_Noah> James: would it be more expedient to share it publicly?

<Rich_Noah> Matt: the list for the group is small

<Rich_Noah> Matt: where would you put it so it is not public?

<Rich_Noah> s3ththompson: we would update it to the sandbox

<Rich_Noah> Matt: would you send me a link to sandbox and then push it to production?

<Rich_Noah> s3ththompson: not exactly. Staging and Production have the same version, an old version, of the app.

<Rich_Noah> James: I don't understand. Staging is used to review in a environment that is not always stable.

<Rich_Noah> s3ththompson: we cannot deploy over the current app because we cannot update the version on staging to deliver the expected feature set.

<Rich_Noah> James: can we get the development environment with more availability?

<Rich_Noah> s3ththompson: the environment won't necessarily be going down

<Rich_Noah> Matt: this is a sanity check and not a fine tuning.

<Rich_Noah> s3ththompson: this is the first deployment in a long time and we wanted to get it to the Primary stakeholder. We will not be following this practice in the long run.

<Rich_Noah> James: when will the development environment be moved to staging?

<Rich_Noah> s3ththompson: moving to staging is effected by hooking up on test-run and test-reporting.

<Rich_Noah> Matt: when you are talking about taking reports off line what does that look like?

<Rich_Noah> s3ththompson: in the neighborhood of 2 to 3 weeks. We still have work on the test-run to do.

<Rich_Noah> Matt: i was inclined to get the new test-queue as soon as possible.

<Rich_Noah> James: but where will they be doing that?

<Rich_Noah> s3ththompson: we will endeavor to get the test-queue in to staging is a reasonable time.

<Rich_Noah> James: could this be solved by creating a fourth environment? There is a gulf.

<Rich_Noah> s3ththompson: We have to figure out where the data will be saved.

<Rich_Noah> James: I believe the data migration should be seamless, if that is appropriate.

<Rich_Noah> s3ththompson: a fourth environment would increase complexity

<Rich_Noah> Matt: I want to make sure are using resources effectively. We have a small group to provide feedback. Disruptive changes are to be expected.

<Rich_Noah> Matt: I am not sure what we decided how to handle screen reader/browser combinations. How do we want to add new browsers/ATs.

<Rich_Noah> James: is the new allow list used on production or sandbox?

<Rich_Noah> s3ththompson: so far all changes have been made to the sandbox environment.

onboarding new community group members

mk: I think we need to optimize onboarding for testers right now

mk: when you join a CG, you join the w3 world with everything associated with that, such as IRC, etc. I think we should minimize the w3c overhead.

seth: I think there are some things that we control that could make it easier for new CG members. Such as space in the meetings that are reserved for questions from the group.

mk: I like what you said, the objective is to create a welcoming environment for new testers.

mk: that does create a fairly large scope, but we might want to discuss onboarding materials, process (buddy system)

hadi: for people coming to help with testing, do we need to expose them to github, irc, etc? We are not paying them and they have limited time. We want them to use their time for testing.

Jon: If new people come, they want to contribute and do something, has any of the new people been asked to do anything?

alyssa: as a new member, I feel that narrowly focused on just testing would exclude me from the whole picture. I want the opportunity to see the entire picture.

hadi: is IRC optional?

mk: I think IRC is optional, and we can communicate it as such

mk: to jon's point - do you mean that people would be discouraged if they join but don't have anything to do right away?

jon: (yes)

mk: I wonder if we should have all new testers run through a prescribed set of tests, that have already been finished, just for the purpose of them learning our testing methodology and to verify the accuracy of their results?

mk: some work has already been done in this space. What has been done so far?

seth: alyssa and I walked through onboarding from zero. From signing up for w3c, and github. Where should these instructions live? The wiki, the home page of the app? Can there be just one getting started page, or is it specific to your role?

james: it's tempting to say it should be a wiki page. I don't think we will get away from needing a github account. given that some people are not comfortable with GitHub, hosting it on the app might be more friendly.

james: in terms of audiance, regardless of your role, some things are still required. Github account. mailing list. the allowed list. But if you are a tester, you need to know how to use the test queue, etc.

mk: I agree that the github wiki might be somewhat daunting for some people. I'm a little concerned about trying to put too much in the app. I want to be careful about adding to the app roadmap the need for another feature.

mk: we can solve it near term in the wiki and then move it to the app in the future if needed

(concern about finding the right wiki page)

mk: we can make the home page itself point to relevant wiki pages

mk: I think dealing with github for a novice user of an AT would be difficult.

(sorry, that was hadi)

mk: we are not targeting novice users, because our tests need to be advanced users

hadi: how do you measure that?

mk: we haven't determined that yet

mk: what I've said before is 'if you feel like you are an advanced screen reader user'

seth: there is a gate in that someone needs to add the user to the allowed list

seth: going forward, how do we make it easier to get people involved, and remove subjectivity on our end

mk: the more you put things in the way of me contributing, the more I get frustrated

james: that goes for anything that requires human intervention, such as the allow list

(discussion of setting up an automated welcome email)

hadi: for those of us that are screen reader users, we miss some important information. So we might get stuck. So there might be a lot of questions as we get on board. Do we have any one person to help with this?

mk: no we don't

hadi: for a limited time, I could have one of my students do that

hadi: but I need a time range so that I can plan accordingly

mk: in our time lift, we should assign some actions

mk: maybe the first step is to make an action plan and sequence our ideas. We do have an issue for this, right seth?

seth: issue 420

https://github.com/w3c/aria-at/issues/420

(idea of a contributors page, and a page of whos-who)