Meet the 2024 TAG Candidates: Lola

Questions

What is the most important problem the Web Platform faces that the TAG could reasonably address, and how will you start to address it if you're elected?
The TAG has a lot of things it can do or is asked to do, what should the TAG prioritize in the coming year?
What kinds of reviews should go to the TAG, how should the TAG triage reviews, and how can you help the group be more comfortable rejecting reviews it doesn't have time for?
Do you want the Team to release the anonymized ballots from this election? Why or why not?
The TAG has a problem with members failing to show up and do the needed work. How much time do you have to commit to TAG work? Do you have travel or scheduling constraints?
What skills, expertise, and perspectives do you have that the continuing TAG members and other TAG candidates lack?
If you disagree with a feature's design, how will you decide between just saying that it's bad, vs trying to improve its design as much as possible?
Can you show us an example of a time you found a way forward between people who initially disagreed strongly?
What mistakes has the TAG made recently?

Answers

What is the most important problem the Web Platform faces that the TAG could reasonably address, and how will you start to address it if you're elected?

Interoperability as it relates to the specs currently aiming to replace the functionality of third-party cookies. Each browser vendor and advertising agency has their proposed solutions, which are happening across a variety of working and community groups, it’s confusing to follow and difficult to truly assess specs coming in for review. While the design review includes a space for spec authors to share multi-stakeholder comments, and the TAG can glean a lot from those comments, there should also be a space for TAG members to be able to see all specs relating to a problem space, and the various groups the specs are being edited in. This space will allow not only TAG members but also spec editors to see potential duplications, and reviewing this list should be included as part of the design process.

The TAG has a lot of things it can do or is asked to do, what should the TAG prioritize in the coming year?

Promoting and encouraging the use of The Societal Impact Questionnaire and The Ethical Web Principles. Spec editors and working groups should have the users of the web at the forefront of the spec development process. While the TAG’s scope is limited to technical issues, technical issues do not exist in a vacuum and have real-world implications for web users. The W3C has an over-representation of big tech companies that have historically prioritised investor interest over user experience, accessibility and safety.

What kinds of reviews should go to the TAG, how should the TAG triage reviews, and how can you help the group be more comfortable rejecting reviews it doesn't have time for?

Design reviews make up a large portion of the work TAG partake in, and I think it should continue that way. The TAG should have a multi-stage triage process that involves individual research and group discussion. The design reviews should be split up amongst TAG members to research, compose questions and concerns, etc and then brought to the TAG meetings to be discussed as a group. Communication is important in helping spec editors manage their expectations on when a review will be complete. Letting all submitters know what the process for the design review is, what stage their review is at and also when they can expect each stage to be complete (this will be different for each review), will be helpful. Rejecting reviews due to time constraints seems harsh to me, but reprioritising reviews and communicating the reprioritisation will help with expectations.

Do you want the Team to release the anonymized ballots from this election? Why or why not?

I’m indifferent to the release of anonymized ballots. Releasing the ballots can help with transparency and data processing, it’d be a good way to see where the sentiments of voters change over time (e.g. voting for more or less people from certain professional backgrounds). However, releasing anonymized ballots alone does little to tell us about the context of the voting which is important.

The TAG has a problem with members failing to show up and do the needed work. How much time do you have to commit to TAG work? Do you have travel or scheduling constraints?

I don’t have travel or scheduling constraints and I’m committed to attending F2Fs and telecalls. For the last few years, I’ve worked in jobs that participate in the W3C in some capacity and I hope to continue that. However, as a (currently self-funded) invited expert and independent contractor, I take a variety of contracts, which means my time commitment may vary over my term.

What skills, expertise, and perspectives do you have that the continuing TAG members and other TAG candidates lack?

My technical experience is varied and includes software engineering, technical support, and web standards development. However, my first degree was in Creative Writing and English Literature which has helped me tremendously in writing and communicating difficult and heavily technical concepts to audiences and groups of people with various technical abilities. This has helped me when advising browser engineers of standards they may not engage with day-to-day, or helping students and laymen understand how the web works.

Developer Advocacy specifically within/about the W3C: I was formerly the co-chair of the W3C Developer Council which had the aim of increasing diverse developer contributions and engagement with the W3C. While we collectively decided to put a hold on this work, I have continued to give talks, workshops and write about the work that’s happening within the W3C, all of which have been positively reviewed.

My social background has informed my technical work for a long time. I’m in the class of people who are especially harmed by abused privacy technology and inaccessible websites and have many family members who are cut off from websites that lack the performance considerations required for low-bandwidth web access. So I am particularly interested in increasing access to and accessibility on the web, as well as giving input to privacy-related specs.

If you disagree with a feature's design, how will you decide between just saying that it's bad, vs trying to improve its design as much as possible?

Feedback is constructive when you can give actionable steps to improve a piece of work. Simply saying a design is bad doesn’t give the spec editor anything to work with, so I’d give specific reasons for my disagreement with a design feature. However, I’m also not the spec editor, nor will I be the sole decision-maker on the TAG. So if there’s consensus amongst the TAG and multiple stakeholders and the design feature doesn’t cause or perpetuate harm to web users (as described in the Privacy Principles, Ethical Web, Social Impact Questionnaire, etc), I’m inclined to agree to support its progression.

Can you show us an example of a time you found a way forward between people who initially disagreed strongly?

In my role as Web Platform Program Lead at Bocoup, a client wanted us to contribute to a controversial WebAPI. Some of our engineers were understandably uncomfortable working on this API, while others were unsure what to think. I took the time to do some in-depth research using the TAG design review, other browser vendor positions and comments and the spec itself to form a document highlighting the pros, cons and state of things at the time. With this document, we were able to identify who would most likely be harmed by the API and pitched to the client ways we could reduce the harm as well as conducting user research and collaborative design practices with members of the potentially affected community. Both the client and concerned engineers liked our proposal.

What mistakes has the TAG made recently?

The TAG could do more to highlight the work they have done and continue to do, data about how many design reviews are closed, common reasons design reviews are rejected and accepted, etc can help spec editors, web and browser developers, and other interested parties understand more about the TAG’s work. Additionally, collaborating with the WebDX Community Group and other web developer communities to better understand developer and web user needs could help with the prioritisation of design reviews.