Team charters will have a section on "Responsibilities and Commitments" that lay out the team responsibilities according to the DARCI framework. The items in this framework are arranged roughly by decreasing levels of responsibility.
These is the set of topics for which the team is the final decision maker on. For some groups, it may be useful to select a subset of consensus builders or deciders, but for most teams it is expected that this will simply be the team as a whole. This can also be on a per-topic basis; for example, a team can record that bikeshed questions are for the team leads to ultimately decide. It is also possible that some questions are escalated to some other team. For example, project groups would often record the parent team as the decision makers, but the project group is still accountable for completing the work to prepare for that decision, and has some amount of "small" decision making.
This is the set of topics that the team is accountable for work being completed in. The team is thus responsible for ensuring work is happening, but is not necessarily responsible for doing the work themselves. The most common case of being "accountable for results" but not "responsible for work" is when a subgroup has been delegated the responsibility for executing an area of work.
The goal for this section is that this is the group that will be asked and consulted with if the task(s) are not being done in a timely manner. They should also be actively tracking work in any area they are accountable for, so that they can communicate to groups which need to be informed if the task is not done; ideally in time for more resources to be invested or for others to know that the dependency they may need won't be ready.
This is the set of topics on which the group are the ones engaged in the active work. This is how, for example, people can discover where to go if they're interested in actively working on some feature or area.
This is the set of topics on which this group should be consulted. In particular, consultation means that the group may have feedback, but they are not going to make any final decisions.
This is the set of topics on which this group should be informed. This means that the group will not necessarily have to provide feedback on the topic.
The goal for this section is that some teams would benefit from knowing of particular decisions or events, but don't need to engage on the process itself. One example is changes made in rust-lang/rust with sufficient weight that we want to mention them in release notes - the relnotes label is a way to passively inform the release team of this.