Update Eliana Rosselli's talk description to use consistent terminology

Author: Eliana Rosselli

_schedule/talks/2023-10-17-17-15-t0-an-approach-to-lightweight-tenancy-management-using-django-rest-framework.md

@@ -27,10 +27,10 @@ title: An approach to lightweight tenancy management using Django Rest Framework
 track: t0
 ---
 
-Over the last few years, I have run into the same multitenancy use case across different projects. This scenario is a “lightweight” multitenancy use case, where we have a tenant model and tenants are instances of this model; all tenants share the same database, schema, and application instance. Resources belong to a single tenant, but users can belong to multiple tenants. Almost all api routes need to be nested under the tenant id, with urls of the form `api/tenants/tenant-id/some-resource`. The challenges we faced were how to effectively nest our API urls and how to consistently restrict access to resources, so that users could only access those resources that belong to tenants that the user has permission to access. 
+Over the last few years, I have run into the same multitenancy use case across different projects. This scenario is a “lightweight” multitenancy use case, where we have a tenant model and tenants are instances of this model; all tenants share the same database, schema, and application instance. Resources belong to a single tenant, but users can belong to multiple tenants. Almost all API routes need to be nested under the tenant id, with urls of the form `api/tenants/tenant-id/some-resource`. The challenges we faced were how to effectively nest our API urls and how to consistently restrict access to resources, so that users could only access those resources that belong to tenants that the user has permission to access. 
 
 We’ll cover:
-- A brief description of the use case and multi-tenancy
+- A brief description of the use case and multitenancy
 - How we implemented nested routes in our API using [drf-nested-routers](https://github.com/alanjds/drf-nested-routers)
 - How we wrote a custom viewset to centralize all logic related to checking that the user has permission to access resources under a specific tenant
 - Custom model manager to avoid accidentally leaking information from other tenants