Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Models are browsed by source, not one list with Source and Capability filters

Aperta
#1,983 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
react, typescript

Direzione di ricerca

Read docs/proposals/model-catalog.md first, especially the Screen section and step 6; then inspect the named Add model and per-source group components under surfsense_local/frontend/src/features/models/. Start by writing a failing filter-behavior test, using the listed settings and download-model tests as guides. Done means the scoped part of the proposed unified list and filters is covered, with relevant docs updated; run pnpm test and python scripts/check_docs.py.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

desktop frontend help wanted UX

The gap

docs/architecture/local-models/catalog.md lists this under Known gaps:

Browsing is still split by source, a catalog on the Add model page and one group per server, not the one list with Source and Capability filters the proposal describes.

Why it matters

You have to know where a model came from before you can look for one. Answering "what can I use for image editing?" means reading This computer, then each connected server's group, then opening Add model and reading the catalog there, then the search box — four places, and again for each of the five slots. The one question a person actually has, "what can do this job", is the one the layout cannot answer.

It is also the last piece holding several docs in a transitional state. This page opens by saying the one screen with Source and Capability filters is still to come and that the page moves to model-catalog/local.md when it does; connections.md says the same from its side. Until this ships, three architecture docs describe an interim shape.

Where

What done looks like

  • One list of models with a Source filter (All, Local, Remote) and a Capability filter offering each type that has rows, plus Unknown when any row is unknown — as the proposal specifies.
  • Hugging Face search stays its own box. That is deliberate and the proposal repeats it: what the user types goes to a third party, and it carries the egress question.
  • This is large enough to split, and splitting it is welcome. Say in the PR which part of step 6 it is and what is still to come.
  • The docs move with the work, and that is a real part of it: this page becomes model-catalog/local.md, connections.md keeps storage, keys, the probe and the runtime, and the proposal is deleted when the last piece lands. Do only the part your change earns.

What not to change

Do not change what the API returns to make the screen easier. The rows are the finished part of this design — the backend decides and the screen renders, computing no fit, no default, no recommendation and no selectability. A filter that recomputes any of those in the renderer is the failure mode this whole design exists to avoid.

How to verify

The per-slot settings pages are covered by chat-models-settings.test.tsx, image-models-settings.test.tsx, audio-models-settings.test.tsx and their siblings, and the catalog itself by download-chat-models.test.tsx. The repo is TDD: write the failing test for each filter behaviour first.

cd surfsense_local/frontend
pnpm test
cd ../..                      # this touches docs/, so check them from the repo root
python scripts/check_docs.py

Before you start

Read CONTRIBUTING.md, the model catalog proposal, this page's local model catalog doc, the connections doc and ADR 0014. React work follows the frontend-workflow skill, shadcn components the shadcn skill after it, and interface strings the translate skill, all in AGENTS.md. This is a large change: comment here with what you plan to take on before you start, so it can be split rather than collided with. Open your PR against dev, not main.

Lingua principale
Python
Stelle
16.3k
Fork
1.6k
Merge medio
9h 22m
PR unite (30g)
253

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MODSetter/SurfSense

Tutte le issue di MODSetter/SurfSense

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.