Update Guidance for Logging Function on Accessibility Example

[alexfinnarn]

In https://github.com/CivicActions/cypress-tests/blob/main/examples/AccessibilityTesting.md there is code I also found online that helps log accessibility violations in the terminal. However, the name terminalLog was suggested to be more specific during a code review, since the logging function can only format an array with objects of a specific shape.

So should the function name be updated? How should that change (and the general advice on Cypress a11y testing) be disseminated if so?

There are some QA and testing meetings on the calendar, but not everyone writing Cypress tests goes to those meetings. Being new, I'm not sure how discussions like these happen.

[dmundra]

Hey @alexfinnarn, that is a good point. Do you want to make changes? It can either be directly done or you can do a pull request.

In terms of discussions, I welcome them as issues so we can do as much as possible in the open. Slack conversations are also fine for the back and forth. What do you think and prefer?

[alexfinnarn]

Hey @alexfinnarn, that is a good point. Do you want to make changes? It can either be directly done or you can do a pull request.

I can make a PR for this change, but I'd rather put the change in the actual code that the example documentation explains. In my last job, I created https://github.com/CUCentralAdvancement/testing-methods as a way for people to learn about testing complete with code they could copy straight from the cypress directory.

Another advantage is using Dependabot to keep the testing dependencies updated with potential sample tests. For instance, I was updating only the Cypress dependency for a JIRA ticket but other Cypress-related dependencies needed updating too. Having this repo update all the core Cypress and contributed Cypress dependencies together would be helpful, I think, and could be utilized across projects using Cypress. Otherwise, the docs could become out-of-date with a Cypress update and we wouldn't know it since they aren't tied to actual tests.

Thoughts on installing and running Cypress tests in this repo?

In terms of discussions, I welcome them as issues so we can do as much as possible in the open. Slack conversations are also fine for the back and forth. What do you think and prefer?

I'd like to see every team using Cypress have someone who keeps up with these testing changes as a representative. That way it is easier to ping people and work with them on how to incorporate changes into their team and make compromises. Within the WECMS project, the Operations & Maintenance team can help standardize things, but I'm not sure about other projects.

In past jobs, we've used the RACI matrix for delegating responsibilities https://www.toolshero.com/project-management/raci-matrix/ across areas, but I'm not sure what CivicActions does. Then, you can ping the appropriate part of the RACI when asking questions about that area. If delegates have opinions, they chime in when asked. If not, you have a time period for additional comments and then merge in the changes...so kind of relates to a contributor agreement, but I got used to the RACI terminology at my last job.

[dmundra]

Thoughts on installing and running Cypress tests in this repo?

Great idea! I never thought it and it makes sense. Please go ahead and start the changes and I help convert other examples as needed.

I'd like to see every team using Cypress have someone who keeps up with these testing changes as a representative. That way it is easier to ping people and work with them on how to incorporate changes into their team and make compromises. Within the WECMS project, the Operations & Maintenance team can help standardize things, but I'm not sure about other projects.

Most projects use RACI and it is generally defined in team working agreements or similar documentation, I believe. We have used RACI for global items like the tech lead role description. Outside of that it is pretty much flat, that is anyone can take responsibility and run with things. @bobschmitt-civicactions and I helped start this repo but I am happy to have you contribute to it and make wholesale changes. I will chime as needed.

In the practice areas, Associate Directors now have some responsibility but again we are not gatekeepers for others to take responsibility on something. Now the question is the vagueness a detriment to contribution and should we have RACIs for the practice areas? What would you prefer?

CC: @eknapier

[alexfinnarn]

Okay @dmundra , I made #3 to start discussing converting this repo into a living example of Cypress best practices and techniques. Feel free to modify that list of items, and I will only work on adding Cypress, the other dependencies, and Dependabot first.

For converting things to tests, the accessibility example makes the most sense to me since I came to the same solution but independently. Another good one is how to handle iframes as that comes up with CKEditor testing amongst other things that use iframes.

Now the question is the vagueness a detriment to contribution and should we have RACIs for the practice areas? What would you prefer?

It's good to see that RACIs are used in places across the organization. In my work, I have not seen them used so far...but I don't want to go down any heavy-handed suggestion route to jump into trying to use those across practice areas vs. a more organic evolution of process change.

One of the issues I see with "anyone can take responsibility and run with things" is that the collective team loses efficiency when two or more people work on the same problem without knowing about the others' work. By dividing up the issues or pairing on them, then those two people can learn from each other without suddenly discovering they've come to the same conclusion as someone else but taken days to get there...days they could have been solving a different problem.

How does that relate to anyone being able to take responsibility, you might ask? Well if no one is "in charge of this" then I don't know who to ask to find out if I'm working on the same problem as someone else at CivicActions. By providing people with the opportunity and responsibility of being the go-to person, then they want to keep on top of things. I think of accessibility at CivicActions and knowing I can ask Mike Gifford about anything related to that area, and I bet he feels like he should keep apprised of what's going on with accessibility across the org along with the accessibility people he works with.

But from a more personal/psychological angle, it can be defeating to think "aha! I have come to a solution that I want to share and others will benefit from...hey everyone, look what I did...oops, I didn't know someone already provided a solution to that problem...and darn it covers more things than I did...maybe I shouldn't be as enthusiastic to share next time since I now feel defeated".

Of course, that is a hypothetical scenario I'm just making up, but I think it's far more empowering to be deputized into taking on responsibility for practice-area-like concerns than having a more loose attitude to company guidance on an issue. Plus, if someone takes off and you know their RACI obligations, its easier to tell new people "well, we have these slots open that you can look at and see if you want to pursue being responsible for an area" vs. having to ask around and wonder where you can best fit in.

Well, I'll leave it there after more words than I planned to write...but I'm interested in any thoughts on what I wrote. There's both a cold, organizational perspective and a warmer, feeling perspective involved. However, I think I've strayed off-topic to the purpose of this issue so the discussion could go some other place.

[dmundra]

I think an "antidote" to some of the concerns is approaching it as collaborative-first and open all the time. That is posting in slack in specific channels (#engineering, #accessibility) or even all the way in #general. Sharing what you are interested in doing, asking whether others are interested or have already made progress, sharing you own progress, and asking for approval. Also it is also okay to ask for approval/forgiveness after the fact but that easier said than done.

Also I would say we have a culture of support and collaboration so ideally no one should feel defeated or lose enthusiasm when they hear that someone solved the problem already. I hope I didn't do that to you when I shared this repo for example. I would hope that discovery turns into discussion that leads into future collaboration opportunities and combined solution building. This issue and #3 is an example of the ideal outcome. Maybe we lost some efficiency I think it has been worthwhile.

In terms of next steps, I would like to bring the RACI conversation to the Drupal practice area call and see if we can implement it there. I will close this issue since we have the new issue to progress the work in this repo.

[alexfinnarn]

I think I get what you're saying and no worries about anything I'm mentioning, it's just for discussion purposes.

I try to use hypotheticals when exploring topics and push them to extremes to get the best sense of differences. I think CivicActions has a great culture of sharing and collaborating, and for those people who naturally engage when coming onto a new team, it's a great experience. However, not everyone feels naturally empowered to ask questions and post in Slack and so forth...imposter syndrome and such...and so for those people, I think more structure helps them grow into their role.

I could also sum up my thoughts psychologically as: the emotional variance to stimuli can be greater when the stimuli don't fit into already known patterns or schemas. And emotions usually spring up first before thought, so we're left to rationalize why we feel certain ways.

Or in big O notation: I want to have constant time when investigating how I can fit into CivicActions vs. "n" time and having to ask everyone so I know where they stand.

But more concretely, I think the accessibility and security areas are good places to look at how the onboarding was approached and led me to understand more about people in those areas than the other practice areas at CivicActions. They both had training and an onboarding meeting. Maybe I am forgetting other meetings, but those are the two practice areas I remember most from onboarding.

So, I think comparing what those practice areas have done with onboarding is a good thing to talk about within the Drupal practice area. For this repo, though, I'd think it's in the QA/Automated testing practice area and I try to go to those monthly meetings where topics like these can be broached.

But now I will look at #3 and the start towards turning this repo into a living example and maybe later a training resource.

[dmundra]

Well said @alexfinnarn. My one additional comment in favor of a structure is that it will ensure the practice area lasts even if folks leave as the structure can speak to "transition" plans or something like that.

[mgifford]

First, wanted to note that there are quite a few Responsibility assignment matrix to consider. RACI is just one.

This came up recently with the W3C's ARRM Project - Accessibility Roles and Responsibilities Mapping.

People with way more experience in this than I did provided some interesting discussions about pros/cons of different frameworks.

I think Adobe is using this.

But ultimately, it is about prioritizing who is on first, so that barriers don't slip through the cracks. This is potentially of value if we want to align with anything else.