Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

First contribution: verify a real screen-sharing walkthrough

オープン 初心者向け
  • 何か問題がありますか？
#29 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
半日
初心者へのやさしさ
74/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
macos, swift
領域
documentation

調査の方向性

README.mdの2つのショートカットのセクションと、docs/unification.mdの未検証のリモート参加者に関する注記から始めます。会議アプリと2人目の参加者またはデバイスを使って1回手順を実施し、さらに2人目の参加者またはデバイスを使ってもう1回実施します。その後、各ツールについて、アプリとmacOSのバージョン、共有モード、受信者に見える内容を記録します。検証済みの手順と注意点を既存のREADMEまたはQAドキュメントに追加し、テストしていないハードウェア経路は未検証のままにしておきます。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Swift
スター
0
フォーク
1
平均マージ
8時間 16分
マージ済み PR（30日）
210

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Ship-Work/workbench のほかの issue

Ship-Work/workbench の issue をすべて見る

似ている issue

Swift の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。