Wiki Glossary (on going)

[krystalphn]

Dependency

• [ ] Waiting for new glossary terms to be added.

Overview

We need to create a process for adding new glossary terms as they are discovered or become necessary so that our 311 Data glossary is up to date.

Action Items

• [ ] Add a glossary term in a new comment
• [ ] Move issue to Prioritized Backlog
• [ ] Change Role to match the practice area of the glossary term (e.g. technical terms get Role: Fronted, UX Content terms get Role: Content, etc)
• [ ] When a volunteer picks up the ticket, move ticket to In-Progress while they add the new definition to the glossary
• [ ] If there are more glossary terms to define in the comments of this ticket, assignee should attempt to define them. Otherwise, the ticket should move back to prioritized backlog.
• [ ] When all the terms on the comment are defined, hide the comment as Resolved
• [ ] when there are no more terms to define, move this ticket back into the icebox and add the Dependency label, remove the role label and add "Role: Missing"

Resources/Instructions

• previous ticket: https://github.com/hackforla/311-data/issues/1982
• Reference Material: 📝 Google Doc: How To: Create A Project Glossary
• 📂 Google Drive Path: 311-data.org > 3 - Project Management > Glossary
  • Deliverable: 📊 Google Sheet: 311 Data: Wiki Glossary Draft
• List of all NC councils: https://neighborhoodempowerment.lacity.gov/councils/
• Alternative Boundary Sources
  • Bonnie requested Federally defined boundaries be backed up by local government sources. Local governments do not (seem to!) use the same boundary definitions, but SCAG (Southern California Association of Governments) has some good alternatives:
    • Urbanized Areas (definition, map, dataset)
    • Counties (definition, map, dataset)
    • Federal vs. Local Term Comparison Worksheet

[rayneng]

HTTP Status Code

• 200
• 500
• 503
• 408

Resources

• copy info from "More Details" and "Resources" in https://github.com/hackforla/311-data/issues/2024

[ykimdeveloper]

HTTP Status Codes - RESOLVED

1. In Context of Hugging Face API + DuckDB Frontend

200 — OK

A response indicating that the request succeeded and the server returned valid data.

Project Context:
A 200 means the Hugging Face API responded normally, DuckDB successfully processed the data in memory, and the frontend can safely render the results.

---

500 — Internal Server Error

A server-side error indicating that the server encountered an unexpected condition and could not complete the request.

Project Context:
A 500 usually means the Hugging Face API failed internally or returned malformed data that DuckDB could not process. The frontend should show a fallback state instead of attempting to render.

---

503 — Service Unavailable

A response indicating that the server is temporarily unable to handle the request, often due to overload or maintenance.

Project Context:
A 503 from Hugging Face means the model endpoint is down or rate-limited. DuckDB never receives data, and the frontend should retry or show a temporary “service unavailable” message.

---

408 — Request Timeout

A response indicating that the client took too long to send a request, causing the server to time out.

Project Context:
A 408 typically occurs when the Hugging Face API takes too long to respond (model cold start, heavy load). DuckDB receives no data, and the frontend should handle the timeout gracefully.

---

source

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status