Write about assumptions of the committee #109
Description
It was discussed in the ARRM meeting today that we document some of our assumptions.
For instance, accessibility and QA roles are assumed. They are generally not decision makers in the RACI framework we have adopted. They need to coach other roles or evaluate the implementations. The quality of implementing the task is up to the primary, secondary and contributor roles.
Likewise, nothing is going to actually be built on the web without front-end developers. So, assuming the other roles did their jobs correctly, it should be a matter of how to actually create the HTML/CSS/JS to make it a reality.
For these reasons, we are not including accessibility, QA and front-end developers on every task, unless they have a decision-making role which isn't superseeded by another role.
We are also writing this for general use-cases. We do not want to have something that was too-specific.
It might make sense to add a paragraph or two to highlight that here:
https://www.w3.org/WAI/planning/arrm/tasks/
Maybe something like this:
Assumptions about Roles
In developing these task role assignments, we are making some broad assumptions that help keep the framework practical and not overly prescriptive. Accessibility specialists and quality assurance (QA) staff are assumed to be present, but their roles are typically advisory or evaluative rather than decision-making within the RACI model. Their responsibility is to coach other roles, review outcomes, and flag issues, while the quality of the actual implementation rests with the primary, secondary, and contributing roles assigned to the task.
Similarly, we recognize that nothing is ultimately delivered on the web without front-end developers. Provided that other roles have fulfilled their responsibilities, the role of front-end development is to implement the agreed design and technical decisions in HTML, CSS, and JavaScript. For this reason, we do not list accessibility, QA, or front-end developers on every task by default unless they carry a specific decision-making responsibility that is not already assigned elsewhere.
Finally, this framework is written for general use cases. It is not intended to dictate project-specific details but to provide a consistent structure that teams can adapt to their own context.