Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Foundation F: enforce complete journeys in contribution and release

Abierto
  • ¿Algo no está bien?
#282 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, python, swift
Área
devops, release, testing

Línea de trabajo

Start with the canonical brief in docs/mac-foundation.md, the current evidence in #7, and the acceptance addendum #288; reread the current source before changing anything. Inspect scripts/release/publish_update.py, release.json, and .github/workflows/ci.yml, preserving the existing workflow and release path. Done requires independently required journey coverage and final-artifact-bound evidence, fail-closed validation for missing, stale, malformed, or failing evidence, and the specified real-world acceptance; a schema or green spec alone is not enough.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The repo already has grammar, surface checks, one CI workflow and one updater, but these do not establish that a complete signed user journey works. Deliver package F of the focused Mac foundation, using #7 as the existing integration/release owner.

Decided scope

  • Put the canonical Value before scope questions into the existing PR template: user outcome/evidence, simpler subtraction/native route, existing owner/useful fallback, total complexity cost and complete acceptance/revisit trigger. Apply them to UI, settings, permissions, updates, CI and marketing. One concise rationale and relevant evidence links suffice for ordinary changes; do not paste the whole policy into every fix or create an approval system.
  • Extend existing harness/gallery checks and source-route audit to test actual admission/callback behavior, retired routes and independently expected failures. Preserve .github/workflows/ci.yml, its classifier, merge-group event and aggregate gate. Add no second quality workflow/dashboard/service.
  • Add a versioned journey acceptance receipt beside release.json, bound to source/channel/build/bundle/final archive hash. Human observation evidence is separate from source/CI. In scripts/release/publish_update.py, reject missing/unknown/stale/failed/not-tested required evidence before external publication.
  • Required scenarios and promoted host/client/route variants come from version-controlled release policy independently of the candidate receipt; the receipt cannot choose its own smaller coverage. Test malformed/stale/missing-variant and deliberately failing cases. Keep reset-completion policy distinct from each independently releasable slice's impact policy. Start with an explicit small requirements list for actual journeys, not a generic host/OS applicability engine.
  • Record the brief's three uncoached outcome tasks and actual native/device/receiver evidence. Before substantial investment/promotion, also establish a real alternative, total correction effort and later voluntary reuse; a one-off working demo is not adoption evidence. Preserve private content; receipts contain only needed environment/results, not transcripts/media/device identifiers.
  • Keep WorkbenchUpdates/Sparkle and one promotion path. Verify old-to-new update, active-work deferral, cancel/failure/relaunch and preserved data. Reuse #271 and coordinate #277 release-lead work.
  • Reconcile exact package/site/handbook claims. Correct signing wording; qualify universal call support, automatic rich-result return, lossless absolutes and setup duration against actual evidence. Narrow unsupported claims instead of labeling failed behavior accepted.

Boundaries and acceptance

The decided coverage addendum #288 extends the merged #278 contract with I1/I2 and Q1–Q3. They are required for the whole-reset claim, with implementation in #287/#15/#165 and the relevant tool owners. A prerequisite or native check may remain pending; it cannot be omitted by reading only the earlier snapshot. #225’s retained correctness repairs belong to A. The delivery lead maintains one package completion checkpoint in #7.

No new release command/orchestrator, telemetry, scheduled cleanup, broad native framework rewrite or count-driven CI deletion. Current parallel CI phases serve distinct purposes; consolidate only proven duplication.

First use #7's existing evidence and exact identity for independently accepted B/C/E or retirement fixes. Exercise one real evidence record, then add the smallest validator and fail-closed fixture cases before claiming the whole reset complete. Do not make new release automation a dependency of the first useful fix. Overall completion requires D1/M1/M2/H1/H2/S1/ST1/P1/P2/R1/U1/U2/I1/I2/Q1/Q2/Q3/X1/X2/X3 and applicable promoted routes under final artifact identity. Read is removed and gets X3 absence/preservation acceptance; Read-only #267 is superseded, not a dependency. Consume relevant #137/#263/#264/#265 evidence without treating unresolved native acceptance as delivered. Review unchanged-path evidence by source/config/environment impact; version number alone cannot transfer acceptance.

A green spec PR, receipt schema or harness cannot close this issue. Actual work-Mac device and receiver limits remain explicit until exercised by an able owner.

Decision and evidence: spec PR #278, canonical brief, research. Baseline is main 7989426; reread current source/issues before implementation.

Implementation map: A #279; B #280; C #281; D existing #63; E existing #276; F #282; G #283; H #284; I #287; J #15 with #165. #7 remains the programme gate.

Lenguaje dominante
Swift
Estrellas
0
Forks
1
Merge medio
8 h 16 min
PR fusionados (30 d)
210

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Ship-Work/workbench

Todos los issues de Ship-Work/workbench

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.