7 tekniske porteføljeidéer til IT-studerende

7 tekniske porteføljeidéer til IT-studerende

Posted on By

Suveræne karakterer er gode – men en skudsikker, teknisk portefølje er ofte det, der får rekrutterings-chefen til at sige “wow”. Som IT-studerende konkurrerer du ikke kun med dine medstuderende, men med kandidater fra hele verden, der alle kan fremvise GitHub-repos og sideprojekter. Så hvordan skiller du dig ud?

Svaret ligger i at vælge projekter, der både demonstrerer dyb teknisk kunnen og løser virkelige problemer. Derfor har vi samlet 7 konkrete porteføljeidéer, som spænder fra fuld-stack økonomiapplikationer til cloud-native microservices og ansvarlig AI. Hver idé er designet til at:

  • lære dig “rigtige” værktøjer fra industrien (tænk Kubernetes, Airflow, MLflow, OpenTelemetry),
  • vise, at du kan tage et projekt fra idé til deployment – med alt hvad det indebærer af CI/CD, security og monitoring,
  • fortælle en historie om impact, fx bedre studenterøkonomi eller sikrere software.

Uanset om du drømmer om en karriere som full-stack developer, data engineer, ML-specialist eller DevOps-guru, finder du her en idé, der kan formes til det projekt, der gør din LinkedIn-profil uimodståelig. Klik dig videre og se, hvordan du kan forvandle semesterets fritid til den portefølje, rekrutterere taler om ved kaffemaskinen.

Er du klar til at kode dig til drømmejobbet? Lad os dykke ned i de syv idéer – og gøre teorien til håndfast, hire-værdigt proof-of-work.

Full‑stack budget‑app til studenterøkonomi

En personlig budget-app viser ikke bare, at du kan bygge en fuld end-to-end løsning; den demonstrerer også forståelse for det problemrum, de fleste studerende lever i: begrænset økonomi, mange mikroudgifter og behov for overblik. Projektet giver dig mulighed for at kombinere softwarearkitektur, brugercentreret design og compliance på én gang – guld værd i et CV eller til jobsamtalen.

Teknisk overblik

Lag Teknologiforslag Nøgletakeaways
API / Backend Node.js + TypeScript
NestJS / Express
PostgreSQL + Prisma		 REST eller GraphQL, rolle-baseret auth (JWT), rate limiting og OpenAPI-spec.
Frontend React + Vite
Material UI
Service Worker (PWA)		 Offline-cache, responsive design, dark-mode & intuitiv onboarding.
CI/CD & Deploy GitHub Actions → Docker → Fly.io/Render Automatiseret test, linters, container-scan og “one-click” staging-miljø.
Observability Prometheus + Grafana
Sentry		 Metrics (p95 latency, error-rate) og front-/backend tracing via OpenTelemetry.

Backend: Fra datamodel til psd2

  1. Datamodel
    • Tabeller: users, transactions, categories, goals, budgets.
    • Brug decimal(12,2) til beløb – aldrig floats.
    • Soft-delete og CDC for historik.
  2. Autentificering & autorisation
    • Sign-in with edu-mail via OAuth (Google/Microsoft), fallback til password+TOTP.
    • RBAC: student, admin.
    • Refresh-tokens, rotation & revocation end-points.
  3. PSD2 / Open Banking-sandbox (bonus)
    • Tilknyt sandbox-bank eller Salt Edge for automatisk transaktions-import.
    • Webhook-listener til transaction.created → kategorisering via ML eller regex rules.

Frontend: Ux der rent faktisk bliver brugt

  1. PWA-krav: Installérbar (manifest), offline fallback, push-notifikationer for “budget brudt”.
  2. Design-system: Brug et eksisterende komponentbibliotek men tilføj eget ThemeProvider for konsistens og WCAG 2.1 AA.
  3. Micro-interactions: Lottie-animation når et sparemål nås – giver positiv feedback.

Test & kvalitet

  • Unit-tests (Jest) for service-lag + React hooks.
  • Contract-tests (Pact) mellem frontend og API.
  • End-to-end (Cypress/Playwright) i headless browser m. mock bank-API.
  • Performance-budget i Lighthouse CI – mål Time to Interactive < 3 s på 3G.

Deployment-pipeline

name: CIon: [push]jobs: build-test: runs-on: ubuntu-latest steps: - checkout - setup-node 18 - run: npm ci && npm test - run: docker build -t budget-app:$GITHUB_SHA . - run: trivy image budget-app:$GITHUB_SHA deploy-prod: needs: build-test if: github.ref == 'refs/heads/main' steps: - uses: superfly/flyctl-action@v1 with: args: "deploy --image budget-app:$GITHUB_SHA"

Gdpr & privacy by design

  1. Data­minimering: Gem kun kontoalias, aldrig fulde kontonumre.
  2. Encryption: pgcrypto + AES-256 for følsomme felter.
  3. Retention-policy: Automatisk sletning efter 36 måneder eller ved brugerens anmodning.
  4. Databehandleraftale: Skabelon som bilag i repo’et → viser professionel modenhed.

Sådan pitcher du projektet

Nævn konkrete business metrics du har forbedret (“gennemsnitlig loading-tid skåret med 42 % gennem lazy-loading”) og vis en demo-video på max 90 sek. Læg link til GitHub-repo, live-url samt generer automatisk badges for build-status og test-coverage.

Med et så gennemarbejdet projekt demonstrerer du ikke kun teknisk kunnen – du viser, at du forstår hele produktlivscyklussen fra idé til drift og compliance. Det er præcis det, der får rekrutterere til at stoppe op og invitere dig til samtale.

Data pipeline og dashboard på danske åbne data

Forestil dig, at du vil demonstrere, hvordan man kan forvandle en offentlig dansk datasæt-guldgrube til konkrete, handlings­orienterede indsigter. Et gennemført end-to-end data pipeline-projekt viser, at du mestrer både data engineering og data-analyse – og det tager sig fremragende ud i porteføljen.

1. Vælg et relevant dansk datasæt

Definér en use case: f.eks. “Hvordan har elprisernes udsving påvirket elbil-opladning i Region Hovedstaden det sidste år?”

2. Arkitektur og værktøjer

Lag Teknologi Formål
Orkestrering Apache Airflow Planlæg, overvåg og log alle jobs (ETL/ELT-DAGs).
Rå/Stages Cloud Storage
(GCS/S3/MinIO)		 Gem ubehandlede JSON/CSV-filer; gør pipeline reproducible.
Transform dbt SQL-modeller, tests og documentation site med lineage-graf.
Datalager Postgres (lokalt)
eller BigQuery (GCP)		 “Single source of truth” til exploration og BI.
Visualization Metabase / Grafana Dashboards, ad-hoc-spørgsmål og alarmer.

3. Implementér etl/elt-flowet

  1. Extract: Skriv en Airflow-PythonOperator, der henter API-data hver nat og lægger råfiler i en “bronze” bucket.
  2. Load: Brug Airflow-PostgresOperator eller Cloud Composer til at lægge data ind i råtabeller.
  3. Transform: dbt-modeller:
    • stg_* – renser datatyper, flatten JSON, tilføjer _loaded_at.
    • int_* – joiner relaterede tabeller (fx elpris + opladningspunkter).
    • fct_*/dim_* – færdige fakta- og dimensionstabeller til BI.

4. Data­kvalitet & lineage

  • dbt tests: not null, unique, accepted values (fx gyldige postnumre).
  • Great Expectations (valgfrit) til profiler og daglige valideringer.
  • Lineage-graf: dbt’s auto-genererede dokumentation viser, hvordan kilden løber hele vejen til dashboardet.
  • Observability: Airflow logs + Grafana alarmer ved data freshness < 24 timer.

5. Dashboard & indsigter

I Metabase kan du lave:

  1. Heatmap over elpriser pr. time versus antal aktiverede ladestandere.
  2. Trendlinje for pendlerstrømme på regionale tog samt vejrdata som eksternt .csv.
  3. Automatiske puls-alarmer til Slack, når CO₂-udledning pr. kWh overstiger X g.

6. Dokumentér & del

Et stærkt portefølje­proof består af:

  • README.md med arkitekturdiagram, tekniske valg og opsætnings­guide (docker-compose til lokalt dev-miljø).
  • Skærmbilleder/GIFs af Airflow DAG, dbt lineage-graf og dashboardet.
  • En kort video (2-3 min.) hvor du præsenterer forretningsspørgsmålet, løsningen og resultaterne.
  • Link til GitHub-repo + public Metabase-share link (husk anonymisering hvis nødvendigt).

Bonus: Tilføj CI/CD (GitHub Actions) der kører dbt build + tests ved pull request og deployer til en preview-environment.

Med dette projekt viser du, at du kan håndtere hele dataværdikæden – fra rå API-kald til datadrevne beslutninger – og ikke mindst, at du tager data governance og kvalitet alvorligt.

AI/ML‑projekt med MLOps og ansvarlighed

Et gennemarbejdet AI/ML-projekt er guld værd i porteføljen, fordi det viser, at du kan mere end blot at træne en model – du kan håndtere hele livscyklussen og reflektere over ansvarlig brug af data. Her er et forslag til, hvordan du kan strukturere projektet, så rekrutterings­panelet både ser teknisk dybde og etisk modenhed.

1. Problem & data

  1. Use case: Byg en tekstklassifikator, der spotter positive/negative Trustpilot-anmeldelser for danske webshops eller en anbefalings­model til studiebøger baseret på Bogpris.dk-ratings.
  2. Datakilder: Hent data via deres API’er eller web-scraping (robot.txt-venligt). Gem rå data i et data/raw/-repo og versionér med DVC.
  3. Feature-engineering: Brug SpaCy til sprog­forbehandling, TF-IDF eller transformer-embeddings. Dokumentér hvert skridt i Jupyter-notebooks, der trackes som artefakter i MLflow.

2. Reproducerbar træning

Komponent Værktøj Best practice
Data versionering DVC dvc repro-pipeline med stages for ingest, clean, split, train
Eksperiment-tracking MLflow Log hyperparametre, metrics, modeller og artifacts
Miljø Conda + requirements.txt Fastfrys dependencies for deterministiske builds

3. Ansvarlighed: Bias-tests & forklarbarhed

  • Bias-analyse: Del test­sættet i køn, alder eller region (hvis lovligt) og mål performance pr. gruppe (demographic parity).
  • SHAP: Generér globale og lokale forklaringer; læg interaktive plots på en Streamlit-demo.
  • Fairness-rapport: Beskriv fund og evt. afbødning (re-sampling, bias-vægtning).

4. Modelserving & driftsovervågning

  1. Pakkér modellen i en pydantic-valideret FastAPI-service og containerisér med Docker.
  2. Sæt autoskalerbar hosting op (Railway, Render eller en gratis K8s-sandbox).
  3. Log inferens-latency, input-drift og out-of-spec data til Prometheus + Grafana dashboards.
  4. Implementér shadow deployment: Nye modeller kører sideløbende og sammenlignes i real-tid.

5. Modelkort & gdpr-checkliste

Etabler en simpel markdown-skabelon i repoet:

  • Intended use / users: Fx kundeservice-teams hos e-handels­firmaer.
  • Datasæt & licens: Oprindelse, lovlighed, behandlings­grundlag (artikel 6).
  • Eval-metrics: Accuracy, F1, fairness-score pr. demografi.
  • Etiske risici: Fejlklassificering → potentielt diskriminerende kundeservice.
  • Afhjælpninger: Human-in-the-loop, manuel review ved usikkerhed > x %.
  • Sletningsstrategi: DVC-pruner, data-anonymisering, ret-til-at-blive-glemt.

6. Vis det frem

  • GitHub-repo: Readme med arkitekturdiagram, Makefile til one-click opsætning og badges for build & coverage.
  • Interaktiv demo: URL til FastAPI-endpoints + Swagger UI – eller embed en Streamlit-front.
  • Blogpost / video: Gå igennem pipeline, bias-tests og live-dashboards på <5 min.

Med dette setup viser du, at du ikke blot kan træne en model, men at du også forstår MLOps, ansvarlig AI og dansk/europæisk lovgivning – præcis den helheds­forståelse virksomhederne efterspørger.

Cloud‑native microservice med observability

En lille, fokusret API-service er en perfekt rampe til at vise, at du behersker moderne DevOps-praksis. Du får både kodet, automatiseret drift og demonstreret, at du kan holde øje med applikationen i produktion – alt sammen kompetencer, der efterspørges i SRE- og platform-roller.

Projekt­oversigt

Komponent Teknologi Hvad du viser
Service-kode Go / Node / Python + Dockerfile Letvægtsimage & multi-stage build
Kubernetes-miljø minikube eller kind Cluster-opsætning lokalt
Deployment Helm-chart Konfig-skabeloner & versionsstyring
CI/CD GitHub Actions / GitLab CI Push-til-prod workflow + security-scans
Observability OpenTelemetry, Prometheus, Grafana Logging, metrics, tracing & dashboards
Quality gates K6, Locust, Artillery Load-tests & SLO-validering

1. Byg og containerisér din service

  1. Skriv en simpel REST-endpoint (fx /api/v1/quote) der henter data fra en in-memory DB eller Redis.
  2. Tilføj otel-SDK i koden for automatisk trace-instrumentering.
  3. Lav en Dockerfile med:
    • Multi-stage build (compile → runtime) for små images.
    • HEALTHCHECK så K8s kan lave livenessProbe.

2. Spin et lokalt kubernetes-cluster op

  1. minikube start --profile micro-obs eller kind create cluster.
  2. Installer metrics-server for autoscaling-demo.
  3. Indsaml logs via kubectl logs og stern som quick-check før du går videre.

3. Helm-chart = genbrugelig deployment

Opret charts/micro-obs/ med værdifiler til dev og prod. Demonstrér:

  • ConfigMap til feature-toggling
  • Secret med database-password (sealed-secrets eller SOPs)
  • HorizontalPodAutoscaler baseret på CPU eller custom Prometheus-metric

4. Ci/cd-pipeline

# .github/workflows/pipeline.ymlon: [push]jobs: build-test: steps: - uses: actions/checkout@v3 - name: Build & unit-test run: | docker build -t ghcr.io/<user>/micro-obs:${{ github.sha }} . scan: needs: build-test uses: anchore/scan-action@v3 # SBOM og vuln-report deploy-dev: needs: scan runs-on: ubuntu-latest steps: - uses: azure/setup-helm@v1 - name: Helm upgrade --install run: helm upgrade micro charts/micro-obs --namespace dev --set image.tag=${{ github.sha }}

Vis i README hvordan en pull request automatisk kører preview-miljø med helmfile.

5. Observability-stack

  1. Deploy Prometheus Operator (eller kube-prom-stack) via Helm.
  2. Eksponer OpenTelemetry Collector som sidecar eller DaemonSet for at samle:
    • Logs fra stdout & stderr
    • Metrics (http.server.duration, redis.calls …)
    • Traces (W3C TraceContext)
  3. Konfigurer Grafana dashboards:
    • Golden signals: latency, traffic, errors, saturation.
    • Service map for at vise trace-relations.
  4. Skriv Alertmanager rules som afspejler dine SLO’er (næste afsnit).

6. Definér slo’er & slis

Start småt – to eller tre Service Level Indicators er nok til porteføljen:

SLI SLO Måling
Availability ≥ 99.5 % over 30 dage 1 - (5xx / total_requests)
P95 latency < 200 ms Prometheus histogram http_request_duration_seconds
Error rate ≤ 0.1 % error_requests / total_requests

Dokumentér SLO-budgettet og link til Grafana-paneler der viser overholdelse.

7. Load- og stresstests

  1. Skriv et k6-script der rammer /quote med stigende VUs (virtual users).
  2. Kør det i CI som separat job:
    • Gem summary.json
    • Upload HTML-rapport som pipeline-artifact
  3. Visualisér testkørsler i Grafana med k6-data-source eller push metrics via statsd.
  4. Afslut README med en Before/After graf – fx efter du aktiverede caching eller autoscaling.

Sådan pitcher du projektet til rekrutterere

  • Lav en 2-minutters skærmoptagelse, hvor du:
    1. Trigger en PR → se CI/CD
    2. Klikker rundt i Grafana
    3. Starter et load-test og viser autoscaling in action
  • Pakkér koden som template, så andre studerende let kan forke og prøve selv – det viser community-mindset.

Med denne microservice demonstrerer du end-to-end ejerskab: fra kode til drift, fra overvågning til løbende forbedring. Det er præcis den helhedsforståelse moderne virksomheder leder efter.

Offline‑first mobilapp til campus‑livet

En offline-first mobilapp er guld værd på en travl campus, hvor Wi-Fi og 4G kan være lige så ustabile som kantinekøen omkring frokost. Vælg enten React Native (JavaScript/TypeScript) eller Flutter (Dart) – begge giver dig én fælles kodebase til iOS og Android og demonstrerer samtidigt din evne til at arbejde cross-platform.

1. Arkitektur & kernefunktioner

  1. Offline-synk
    • Implementér local-first datalag med WatermelonDB (React Native) eller Drift/Isar (Flutter).
    • Synkronisér via Conflict-Free Replicated Data-types (CRDT) eller PouchDB + CouchDB for at håndtere konflikter uden nedetid.
  2. Krypteret lokal lagring
    • iOS: KeychainServices   |   Android: EncryptedSharedPreferences.
    • Tilbyd biometrisk oplåsning (Face ID/Touch ID) gennem react-native-keychain eller local_auth.
  3. Push-notifikationer & geo-funktioner
    • Brug Firebase Cloud Messaging eller OneSignal til beskeder om fx klasse­ændringer.
    • Geo-fencing til at minde om aflevering, når man nærmer sig biblioteket (react-native-background-geolocation / geofencing).

2. Tilgængelighed (wcag 2.1 aa)

Krav React Native Flutter
Kontrast-ratio AccessibilityInfo Semantics + ThemeData
Skærmlæser-labels accessibilityLabel Semantics(label:"")
Dynamic Type allowFontScaling MediaQuery.textScaleFactor

Lav automatiske checks med @react-native-a11y/eslint-plugin eller flutter_a11y i CI-flowet.

3. Performance-profilering

  • React Native: Brug Flipper (Hermes heap-analyse, FPS-monitor) og react-native-performance.
  • Flutter: Indbygget DevTools (timeline, memory, CPU) – sæt mål (SLO’er) på < 200 ms interaktions­latens.

4. Privacy by design

  1. Data­minimering: Gem kun studie-ID, ikke CPR.
  2. Gennemsigtige permissions: Vis rationale-dialoger før GPS eller kamera.
  3. Differential privacy i analytics (Matomo eller anonymiseret Firebase Analytics).
  4. Udarbejd en kort DPIA og link til den fra GitHub-repoet.

5. Ci/cd & beta-udgivelser

  • GitHub Actions + fastlane til automatisk bygning.
  • Udgiv TestFlight builds med fastlane pilot og Play Console via supply.
  • Automatisér release notes fra commit-historik (Conventional Commits → semantic-release).

6. Hvad viser du frem i din portefølje?

  • Skærmvideo hvor du flyver på flight-mode og appen stadig virker.
  • Lighthouse-/Perf-score, WCAG-rapport og memory-profil.
  • Link til åben PRD (Product Requirements Doc) og en GitHub Actions-badge, der viser grøn build.
  • App-store-optimeret teaser-tekst samt QR-kode til beta-download.

Med en sådan app dokumenterer du både mobilkompetencer, DevOps-disciplin og privacy-first mindset – alt sammen egenskaber, som moderne arbejdsgivere hungrer efter.

Sikkerhed i praksis: fra trusselsmodellering til SAST/DAST

En stærk portefølje viser at du tænker sikkerhed helt fra idé-fasen og til drift. I dette referenceprojekt bygger du en lille REST-API til en “studiebuddy-notes” tjeneste, men arkitekturen og processen kan genbruges i alt fra hobby-apps til enterprise-løsninger.

1. Kick-off: Owasp top 10 som kravliste

  • Lav en simpel /notes-ressource (CRUD) med bevidst implementerede sårbarheder (f.eks. SQL-injektion, usikre JWT’er).
  • Udarbejd en “Security Test Matrix”, hvor hver række er et punkt fra OWASP Top 10 (2021) og kolonnerne er risiko, testcase, fix-commit.
  • Vis før/efter-diffs i README så censor/arbejdsgiver ser din læringskurve.

2. Trusselsmodellering med stride

STRIDE-kategori Eksempel i projektet Modtræk
Spoofing Forgyldt JWT HS256 → RS256, rotating keys
Tampering Man-in-the-middle på http HSTS + TLS 1.3
Repudiation Ingen audit-logs Immutable log-stream i Loki
Information disclosure Stacktraces i prod Custom error handler
Denial of service Ubegrænset payload Rate-limit & body-size limit
Elevation of privilege Admin-flag i frontend RBAC i API-gateway

3. “secure by default” konfiguration

  1. Headers: Content-Security-Policy, X-Content-Type-Options, osv.
  2. Container hardening: Distroless base-image, ikke-root-user, read-only filesystem.
  3. IaC-sikkerhed: Brug Checkov på Terraform/Kubernetes manifests.

4. Secrets management

Demonstrér fejlscenariet (.env i git), og vis derefter en transition til:

  • GitHub Actions ${{ secrets.DB_URL }}
  • HashiCorp Vault Dev-mode til lokal test.
  • AWS Parameter Store eller GCP Secret Manager til cloud-deploy.

5. Dependency-scanning med dependabot

.github/dependabot.yml opdaterer både backend (pip) og frontend (npm). Tilføj en auto-merge strategi for patch-release < CVSS 7.0 og manuelle PR-reviews for resten.

6. Ci/cd med sast & dast

  1. SAST: GitHub CodeQL-workflow som blokkerer merge, hvis der findes “high” alerts.
  2. DAST: OWASP ZAP kører i “baseline-scan” mod den containeriserede staging-url.
  3. Rapportering: Udgiv SARIF-filer som artefakter og vis badge i README.

7. Mini-runbook til hændelser

Tilføj en docs/incident-runbook.md på max én side:

  • Detection: Alert fra CodeQL eller ZAP.
  • Containment: Rul tilbage via blue/green eller scale-to-zero.
  • Eradication: Patch, git tag -s vX.Y.Z, redeploy.
  • Recovery: Post-mortem i issues, checklist opdateret.
  • Lessons Learned: Føj “lignende mønstre” til semgrep-regler.

Bonus: Før/efter kode-eksempel

# Før: sårbar SQL-injektioncursor.execute(f"SELECT * FROM notes WHERE owner='{user}'")# Efter: parameteriseret forespørgselcursor.execute("SELECT * FROM notes WHERE owner=%s", (user,))

Ved at levere både bevidst usikre commits, systematisk test-dækning og dokumenterede fixessender du et klart signal: “Jeg kender truslerne, jeg kan finde dem, og jeg kan fjerne dem.”

Open source værktøj/bibliotek med moden projektstyring

Byg et lille, men nyttigt command-line tool (CLI) eller et biblioteks-SDK, der løser et afgrænset problem for studerende – fx et værktøj til at generere pæne APA-referencer, et mini-wrapper til Rejseplanen-API’et eller et CLI, der synkroniserer læseplaner med Google Calendar.

Foreslået teknologistak

  • Sprog: TypeScript (NPM) eller Python (PyPI) – begge har aktive økosystemer og er nemme at publicere til.
  • Pakkeværktøj: npm publish / twine upload.
  • CI/CD: GitHub Actions til test, lint, build og release.
  • Dokumentation: Typedoc / Sphinx + Read the Docs.

Projektstruktur og “enterprise-touch”

Mappe/fil Formål
src/ Al produktionskode.
tests/ Unit- og integrationstests (pytest/jest).
docs/ Markdown eller reStructuredText, auto-deployes.
.github/ISSUE_TEMPLATE Guidede felter til bug/feature-requests.
.github/PULL_REQUEST_TEMPLATE.md Tjekliste for tests, changelog-linje og licens-komplians.
CODE_OF_CONDUCT.md Contributor Covenant v2.
LICENSE MIT, Apache-2.0 eller GPL v3 – forklar valget i README.
CHANGELOG.md Følger Keep a Changelog.
ROADMAP.md Milestones & vision (0-3-6 mdr.).

Semver og release-flow

  1. Merge til main trigger automatisk bump af patch-version, hvis alle tests passer.
  2. Features på feat/*-branches – når de merges, oprettes minor-release-tag (v1.2.0).
  3. Breaking changes kræver RFC-issue og major-release (v2.0.0).
  4. GitHub Actions publicerer pakken og opdaterer CHANGELOG.md via auto-changelog.

Dokumentation & eksempler

  • Skriv en README.md der viser TL;DR-install, kort kodeeksempel og badge for build-status.
  • Host fuld API-reference på docs.studentergaver.dk/<dit-projekt> eller Read the Docs.
  • Tilføj “cookbook”-sektion med konkrete studielivs-relaterede use-cases (fx npx skema2gcal my_skema.ics --semester fall23).

Community & feedback

  • Discussions-forum: Slå GitHub Discussions til og lav kategorierne “Q&A”, “Ideer” og “Show & Tell”.
  • Labels: good first issue, help wanted, priority-high gør det nemt for nye bidragsydere.
  • Feedback-cyklus: Automatisk bot (Probot) der beder om reproducerbart eksempel eller test-case.
  • Contributor stats: Aktivér all-contributors-bot og giv credit til dokumentations-PR’s.

Governance light

Når (hvis!) projektet vokser:

  1. Etabler en “triage-team” på to medstuderende, der kan reviewe PR’s.
  2. Udskriv mindre “office hours” på Discord én gang om måneden.
  3. Udgiv kvartalsvis status-blogpost: metrics, roadmap-justeringer og call for maintainers.

Hvorfor er det en stærk portefølje-demo?

Rekrutterere elsker at se vedvarende frem for engangsprojekter. En åben-kildekode-pakke med:

  • Real-world QA-processer (pytest-cov, linters, CI).
  • Regression-tests der kører på hver PR.
  • Aktive issues og community-interaktion.

…viser, at du forstår både teknik og menneskelige processer.

Ekstra stjernestøv

  • Integrér OpenTelemetry for CLI-telemetri (opt-in!) og del anonymiserede usage-grafer.
  • Tilføj GitHub Actions-badge til “Average time to first response”.
  • Brug deployment previews (Vercel/Netlify) til auto-genererede docs-PR’s.

Med andre ord: don’t just ship code – ship et lille økosystem. Det giver dig et synligt “mini-maintainer”-track-record, som vejer tungt til både studiejob, praktik og senere fuldtidsstillinger.

Økonomi & Karriere

Related Posts

Indholdsfortegnelse

→ Indhold