COGA Resolution Processes

COGA Decision Policy (passed/agreed on - do not edit)

Decisions

The Cognitive and Learning Disabilities Accessibility Task Force (COGA) strives to reach consensus via unanimous agreement.

Small items

Such as: wording changes or normal issue responses that will be part of a final CFC later has the following process:

• Agreement on the email list OR
• Agreement on the call

Medium items

Such as important issue responses (such as an issue from the tag, or other working group)

• Agreement on the email list AND
• Agreement on the call
• All decisions are recorded on a wiki page with date and link (for now COGA Resolutions)

Large items

Such as asking the parent group to open a cfc publication

• Agreement on the call AND
• Agreement on the email list with at least 2 working days AND
• Clear wording on the email to the list with attention grabbing subject line and clear instructions and deadlines such as calling it a CFC and using that template
• All decisions are recorded on a wiki page with date and link

Discussion

• Facilitators encourage discussion to continue until all points of view have been expressed and the group has considered the variety of information presented.
• Facilitators encourage all participants to express their views.
• Discussion may include outreach outside the call (emails, surveys,etc)
• COGA strives to use technology that people who want to participate can use. This is especially important for decisions.
• COGA strives to have a review by a representative of each disability group or minority affected by important decisions.
• During discussion, participants can raise objections freely.

Agreement

• COGA strives to get a quorum for responses. Quorum depends on the context.
  • Typically, at least in a call there should be at least 4 non-leadership members present who agree.
  • If Facilitators say that a lack of response will be considered agreement, less people have to agree to reach quorum. (But they should have had the opportunity to respond)
• If objections to a proposed agreement are raised, the facilitators should try and find an alternative that everyone can live with
• COGA strives to provide enough time for participants to consider before making a decision.
  • When finalizing a decision facilitators can give a time limit and time table for objections.
• When discussion is done and the group is making a decision, participants should only raise objections that they “can’t live with.”
• Compromise on points people can "live with" is an essential part of decisions.
• The facilitators can allow a decision to go through with some objections if a significant majority approves the decision.
• Decisions should ideally be based on research-supported recommendations  

Parent Groups

The Accessibility Guidelines (AG) and Accessible Platform Architectures (APA) Working Groups use their own decision policies:

• [AGWG Decision Policy]
• [APA Decision Policy]

Consensus from the Working Groups is required to publish content.

Examples

Glossary

Stage 1. For each item

• Agreement on the list OR Agreement on the call
• Stage 2. At the end for all of approved terms in "CFC type" email
• Try to get review by one or more reps of each disability group / minority involved

Issues

Our process for issues, which has gone though TF consensus is:

• Take an issue (assign it to you)
• Make a proposal. (currently we have a google doc for proposals - see our action/todo list)
• Inform the list
• Once we have four +1 and no objections you can answer the issue and close it

Note:

• comments on opened issues should be from the task force. Please do not respond without going through the process
• On 4 feb 2020 we decided that for issues can go to the list nd if we get 3 +1s then we can close them. See for https://www.w3.org/2021/02/04-coga-minutes.html. Also for issues that are editorial items - 2 editors on a call they can close it. Subject line should include review in x number of days. Content of email: old language, new language. Info on who already approved.

Task/ Subgroup Leaders

A subgroub/task leader:

• coordinates meeting
• manages the deadlines
• manages the subgroup pages (such as the wiki, issues opened etc)
• reports back to coga
• manages the communications between the group and the other working groups involved,
• updates the task in the planning pages, and actions table,
  • includes adding new tasks as needed (often from responses from the other WG, such as requests for more info )
• chairs subgroup calls
• reports and problems and issues to tf facilitators

When to cc the task force is up to you but as a rough guide: when we have something to report or when additional and/or feedback is useful

Liaisons

A liaisons job is to communicate with the TF and another group. This includes

• Notice if there is a topic that could do with input from coga, or a coga topic that could benefit from input from the other group
• If there is an issue on the group that COGA should know about - make sure coga knows! (And for the other group)
• Ask the TF facilitator for time on the next agenda. Remind them until you get it!
• If there is a task, such as a potential review -updates the task in the actions table

Liaisons can also be a task leader when there is a task for COGA from the other group (but not always)