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

First contribution: verify a real screen-sharing walkthrough

Aperta Adatta ai principianti
  • Qualcosa non va?
#29 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
Mezza giornata
Idoneità per principianti
74/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
macos, swift
Ambito
documentation

Direzione di ricerca

Inizia dalla sezione sulle due scorciatoie in README.md e dalla nota sui partecipanti remoti non verificati in docs/unification.md. Esegui una procedura con un’app per riunioni e un secondo partecipante o dispositivo, quindi una seconda procedura con un secondo partecipante o dispositivo. Registra poi, per ciascuno strumento, le versioni dell’app e di macOS, la modalità di condivisione e ciò che vede il destinatario. Aggiungi i passaggi verificati e le possibili insidie alla README esistente o alla documentazione QA, mantenendo contrassegnati come non verificati i percorsi hardware non testati.

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

Descrizione

documentation good first issue help wanted

Transferred from the archived StageMark project. New work belongs in EthDawg/workbench on a branch from main.

Why this helps

The README explains that the audience must see the entire display, but the existing QA notes explicitly lack verification by a remote participant. A real teaching/demo walkthrough would help new users immediately.

Scope

Use one available meeting app (Zoom, Teams, or Meet) and a second participant/device. On a blank synthetic demo, verify pen/arrow, cursor highlight, whiteboard, and timer while sharing the full display. Also check what the recipient sees when sharing only an application window. One meeting app is enough for the first PR; do not claim all three were tested.

Start here

README.md → Start with two shortcuts; docs/unification.md → Not verified with physical hardware or remote participants.

Done when

  • Record app/macOS versions, share mode, and what the recipient actually saw for each tool.
  • Add a short verified walkthrough and any gotchas to the existing README/QA docs.
  • Use only synthetic content and get consent before including another person's screen or recording.
  • Leave unrelated hardware gaps marked unverified.

Skills: no coding required. Equipment: one Mac plus a willing participant or second device. Size: one short demo session and a docs edit. Comment if you would like to try it; partial evidence is welcome.

Ecosystem follow-up · 20 September 2026

Keep the original one-meeting-app acceptance scope. If choosing Teams, include a switch between prepared Chrome profiles: Workbench changes browser focus, not Teams' selected sharing source. A tab/window share can keep showing the previous content. Observe the receiver rather than treating Switch to success as presentation success.

Optional later rows compare Teams desktop display/scene-window sharing with Teams web tab sharing, including one sound sample and stop/restart recovery. Record OS/client/browser, share mode, audience-visible controls and actual audio. Separate presenter microphone, application playback and phone conversation. Android through a permitted scrcpy setup is another optional hardware row; Workbench does not currently embed that window. Do not make all routes prerequisites for closing this small first-contribution issue.

Researched routes and limitations in PR #66.

The Android-on-Mac comparison now details USB/wireless scrcpy, native screenshot transfer and emulator alternatives. It separates device picture/control, phone audio and meeting delivery, and includes an optional three-screen handoff trial. Workbench can capture the visible display; it does not embed scrcpy, and chosen-image import remains #60. These routes are documented feasibility, not hardware acceptance or extra conditions for closing this issue.

Lingua principale
Swift
Stelle
0
Fork
1
Merge medio
12h 29m
PR unite (30g)
201

Preparare l'ambiente

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 Ship-Work/workbench

Tutte le issue di Ship-Work/workbench

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.