Good first issues for new contributors, ordered by difficulty.
🟢 Easy (< 1 hour) | 🟡 Medium (1-2 hours) | 🔴 Hard (2+ hours)
Difficulty: easy | Time: 45–60m
Follow how a chat message is sent from the web app to the Python API by tracing calls starting in code/frontend/src/api/ through the backend entrypoints in code/app.py and code/create_app.py. Write a short markdown note (in docs/) describing the request/response flow and where auth/config is
Code navigation in a monorepo; understanding API boundaries between TypeScript frontend and Python backend
- Identifies the exact frontend function(s) that issue the chat request
- Identifies the backend route/handler that receives it
- Includes a sequence diagram or bullet-step flow with file/line references
- Search for the chat endpoint path in
code/frontend/src/api/* - Use “Find in files” for
FastAPI/route decorators or app wiring incode/create_app.py
code/frontend/src/api/*code/create_app.py
Difficulty: easy | Time: 45–60m
Inspect the ingestion/batch workload entrypoint in code/backend/batch/function_app.py and map out what triggers exist and what each trigger does at a high level. Add a short section to an existing or new doc under docs/ explaining how ingestion is invoked locally vs in Azure.
Understanding Azure Functions structure in Python; separating batch workflows from request/response APIs
- Lists each function trigger found in
function_app.py - Explains inputs/outputs at a conceptual level (queue/blob/timer/etc.)
- Notes how configuration is provided (env vars/settings) with file references
- Look for decorators/registration patterns in
function_app.py - Search for local run instructions in
README.mdand relate them to the function entrypoint
code/backend/batch/function_app.pyREADME.md
Difficulty: easy | Time: 30–60m
Create a Python unit test that imports the backend app factory and verifies the application can be created without raising exceptions (and optionally that a health or root route exists if present). Place the test alongside existing Python tests under code/ (use the repo’s existing test framework/c
Running and extending the Python test suite; validating app wiring/DI doesn’t regress
- Test runs via the repo’s standard test command
- Test fails if app creation raises
- Test is placed in the appropriate test folder and follows existing naming conventions
- Inspect
pyproject.tomlfor pytest configuration - Search existing tests under
code/for patterns/fixtures
pyproject.tomlcode/**/tests/*.py
Difficulty: medium | Time: 1.5–3h
Pick one API wrapper in code/frontend/src/api/ (e.g., chat/history) and add unit tests that validate it calls fetch with the correct method, URL, headers, and body. Use the frontend’s existing test tooling from package.json (e.g., Vitest/Jest) and mock fetch.
Writing TypeScript unit tests; testing API client contracts without hitting the backend
- Tests cover success and error cases (non-2xx)
- Tests assert request shape (URL/method/body)
- Tests run in CI/local via the standard frontend test command
- Check
package.jsonfor the configured test runner and scripts - Use a
fetchmock/spies and assert on calls rather than responses only
package.jsoncode/frontend/src/api/*
Difficulty: medium | Time: 3–5h
Add a backend endpoint that returns build/version information (e.g., git SHA or package version) and expose it in the frontend (e.g., footer or about panel). Backend: implement route in the app created by code/create_app.py (or wherever routes are registered) and ensure it’s reachable from `code/a
Full-stack feature addition; API design; writing tests across Python and TypeScript
-
/versionreturns JSON with stable keys (e.g.,version,commit) - Frontend displays the value and handles failure gracefully
- Both Python and frontend tests added and passing
- Use environment variables for commit/version to avoid runtime git calls
- Follow existing route patterns in
code/create_app.pyand existing API wrapper patterns incode/frontend/src/api/
code/create_app.pycode/frontend/src/api/*
Difficulty: medium | Time: 1-2 hours
Follow a chat request from code/frontend/src/api/* through the backend entrypoints in code/app.py and code/create_app.py; write a short developer note in docs/ describing the call flow, key functions, and where auth/config is applied.
Code navigation across a monorepo; understanding request lifecycles and module boundaries
- Document includes the exact frontend function(s) that initiate the request
- Document names the backend route/handler and the app factory wiring
- Document explains where configuration/environment is loaded
- Start at
code/frontend/src/api/and search for the chat/history call sites - Use ripgrep for route names in
code/app.py
code/frontend/src/apicode/app.py
Difficulty: medium | Time: 2-4 hours
Identify one backend API behavior implemented via code/app.py/code/create_app.py (e.g., request validation, error mapping, or a small helper used by routes) and add/extend unit tests under code/tests/ to cover success + failure cases.
Writing focused Python tests; using fixtures/mocking to isolate external services
- Tests include at least one success and one failure case
- Tests run locally via the repo’s Python test command (per
pyproject.toml) - New tests fail before the fix/change and pass after
- Look for existing patterns in
code/tests/for client/fixture setup - Prefer testing pure functions/helpers or dependency-injected components over live Azure calls
code/testspyproject.toml
Difficulty: hard | Time: 4-6 hours
Add a new lightweight backend endpoint (e.g., /healthz/details or /api/config) in code/app.py (wired via code/create_app.py) that returns structured JSON; then add a matching client function in code/frontend/src/api/* and a minimal usage point (or export) so it’s callable from the frontend
Designing API contracts; end-to-end wiring across backend and frontend; maintaining backward compatibility
- Backend endpoint returns JSON with at least 3 fields and appropriate HTTP status codes
- Frontend API wrapper calls the endpoint and parses the response type-safely
- Tests added/updated to validate the endpoint response shape
- Mirror existing endpoint patterns in
code/app.py - In the frontend, follow existing fetch wrapper conventions in
code/frontend/src/api
code/app.pycode/frontend/src/api
Difficulty: hard | Time: 6-8 hours
Refactor code/create_app.py to make dependency construction (clients/services/config) explicit and testable (e.g., extract a build_services(config) function or similar); update code/app.py accordingly; adjust/add tests to validate the new wiring without changing runtime behavior.
Refactoring for testability; dependency injection patterns; minimizing behavioral diffs
- No functional behavior changes (existing tests still pass)
- New unit tests cover service construction with different config inputs
- Refactor reduces direct global/env access in request handlers
- Identify where config is read and where clients are instantiated
- Keep the public app factory signature stable if possible
code/create_app.pycode/app.py
Difficulty: hard | Time: 6-10 hours
Update or add a GitHub Actions workflow under .github/workflows/ to run targeted tests when files under code/ change (Python tests) and when files under code/frontend/ change (frontend lint/test/build); ensure it integrates cleanly with existing workflows and repo scripts.
CI pipeline design in monorepos; path filters; balancing coverage vs runtime
- Workflow uses path-based triggers or conditional steps for
code/vscode/frontend/ - Workflow runs successfully on a PR that changes only backend or only frontend
- Documentation added to
README.mddescribing how CI decides what to run
- Review existing workflows in
.github/workflows/for conventions - Use
paths/paths-ignoreorif:conditions withgithub.event.pull_request.changed_filespatterns
.github/workflowsREADME.md