The school's people, scoped to what this staff member is answerable for.

SCOPE is the rule this endpoint enforces. Owner/admin and platform staff read the whole school. A plain teacher reads THEIR OWN sections' students plus the school's staff — the rail one inch above this list says "YOUR SECTIONS", and the product already refuses this teacher the other section's gradebook, roster and assignments (_require_group_staff). A flat school directory behind the same login would be the same leak by another door: 23 students' names to somebody responsible for 12 of them.

EMAILS go to every staff member, teachers included.

(Changed 2026-09-03, on Nancy's call. This endpoint used to drop the address for a plain teacher, and argued for it: nothing a teacher DOES on this screen consumes an email — announcements fan out to each student's own address without the teacher seeing it, a question is a DM, and adding or removing a member is _require_admin — so an address the UI never used was personal data kept on a screen for decoration. The premise was that a teacher never needs to reach a student outside the product. Schools tell us otherwise, and the teacher is the person a family actually deals with.)

What did NOT change, and should not be assumed to have:

• scope. A teacher still sees only their own sections' students. This was always the load-bearing half of the two rules, and it stands.
• /roster, the student-facing list, is still "privacy-filtered, no emails". A classmate is not staff.

A teacher in a school with NO sections at all still gets everyone — the Guanajuato rule _resolve_class_scope already follows, because a school that never adopted sections must not have its people page silently blanked. A teacher in a school that DOES use sections but staffs none of them is a teacher with no class, and correctly sees staff only.