(airflow-steward) branch main updated: docs(MISSION): normalize dev-cycle / dev-loop usage to "development cycle" (#168)

[po...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow-steward.git


The following commit(s) were added to refs/heads/main by this push:
     new 8699309  docs(MISSION): normalize dev-cycle / dev-loop usage to "development cycle" (#168)
8699309 is described below

commit 869930938a716b656abe965725b1b771c6b6047a
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Fri May 15 18:55:32 2026 +0200

    docs(MISSION): normalize dev-cycle / dev-loop usage to "development cycle" (#168)
    
    Line 64 described Pairing as "developer-side dev-cycle skills",
    the only "dev-cycle" in the doc. Rather than match the informal
    "dev loop" / "dev-loop" used in four other places, normalize all
    five informal references to the canonical heading style
    ("Development-cycle" — already used in the H4 heading at line 70
    and the listing at line 39):
    
    - Line 64: "developer-side dev-cycle skills"  → "developer-side development-cycle skills"
    - Line 70: "own dev loop:"                    → "own development cycle:"
    - Line 79: "contributor dev loop,"            → "contributor development cycle,"
    - Line 97: "developer-side dev-loop skills"   → "developer-side development-cycle skills"
    - Line 97: "their *own* dev loop:"            → "their *own* development cycle:"
    
    Generated-by: Claude Code (Claude Opus 4.7)
---
 MISSION.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MISSION.md b/MISSION.md
index e01da4e..19101f4 100644
--- a/MISSION.md
+++ b/MISSION.md
@@ -61,13 +61,13 @@ Open-source projects share the same shape of problem: contributors keep arriving
 
 Four design choices set the project apart from "just bolt a code-review bot on it":
 
-**Project autonomy is the structural starting point — and "project" includes non-ASF.** Five modes — **Triage**, **Mentoring**, **Drafting** (agent-authored fix with human review), **Pairing** (developer-side dev-cycle skills with mentorship intrinsic), and **Auto-merge** (narrowly-scoped fix-and-merge) — ship as separate, independently-toggleable skills. Each project picks the modes that match its culture and risk tolerance. ASF integrations (private lists, Vulnogram CVE flows, PMC role [...]
+**Project autonomy is the structural starting point — and "project" includes non-ASF.** Five modes — **Triage**, **Mentoring**, **Drafting** (agent-authored fix with human review), **Pairing** (developer-side development-cycle skills with mentorship intrinsic), and **Auto-merge** (narrowly-scoped fix-and-merge) — ship as separate, independently-toggleable skills. Each project picks the modes that match its culture and risk tolerance. ASF integrations (private lists, Vulnogram CVE flows,  [...]
 
 **Security-issue handling is a load-bearing use case, not a footnote on triage.** The work that became `<PROJECT_NAME>` started as a framework for handling ASF security reports — high-stakes, high-procedure, every-step-needs-an-audit-trail flows that turn out to be exactly what agent-assisted-with-human-gates is good at. Every mode has to clear the security-flow bar (private content stays private, every outbound draft has a human signature, every state change is logged) before it ships.  [...]
 
 **Mentoring is a first-class mode, not a side-effect of triage.** The lever the ASF — and the wider open-source world — actually needs and the one off-the-shelf agent tooling skips. Meets new contributors where they are, explains conventions, points at the relevant prior PR, asks the clarifying question *before* a reviewer burns time on it. This is where the Responsible AI Initiative's contributor-empowerment goal gets operationalised: the mode that produces the outcomes RAI is trying to [...]
 
-**Development-cycle skills sit alongside maintainership skills, with mentorship intrinsic to them.** Maintainers also write code; contributors live the development side of every project. The same agentic primitives that triage an inbound report or mentor a new contributor compose into a committer's or contributor's own dev loop: multi-agent review pipelines that catch issues before submission, self-review patterns that pre-flight a PR against project conventions, scoped agent-drafted pat [...]
+**Development-cycle skills sit alongside maintainership skills, with mentorship intrinsic to them.** Maintainers also write code; contributors live the development side of every project. The same agentic primitives that triage an inbound report or mentor a new contributor compose into a committer's or contributor's own development cycle: multi-agent review pipelines that catch issues before submission, self-review patterns that pre-flight a PR against project conventions, scoped agent-dr [...]
 
 ## Initial Goals
 
@@ -76,7 +76,7 @@ Four design choices set the project apart from "just bolt a code-review bot on i
 - Get **Triage**, **Mentoring**, and **Drafting** running against **3–4 friendly pilots within 3 months** — at least one ASF PMC running the full security-issue flow (Airflow, given the project's lineage), one ASF PMC running just Triage + Mentoring (Arrow or ATR), and **at least one non-ASF project from day one** (Python core has folks interested). Non-ASF in the first cohort, not later — the project-governance-agnosticism claim is only worth what it can prove.
 - Cut a first Apache release through the standard process within 3 months of resolution adoption, with artefacts usable directly by non-ASF adopters (no ASF-only assumption baked into the install path).
 - Wire **Triage**, **Mentoring**, and **Drafting** up to Apache Verum and Apache Caer findings, and to at least one non-ASF audit-tool equivalent (a CodeQL output stream is the likely first non-ASF case).
-- **Ship at least one Pairing skill family** in v1, with mentorship hooks intrinsic — multi-agent review or pre-flight self-review — demonstrated against a friendly-pilot project's contributor dev loop, so the maintainership-and-development scope claim and the human-relationship-preservation claim both have working code to point at.
+- **Ship at least one Pairing skill family** in v1, with mentorship hooks intrinsic — multi-agent review or pre-flight self-review — demonstrated against a friendly-pilot project's contributor development cycle, so the maintainership-and-development scope claim and the human-relationship-preservation claim both have working code to point at.
 - Settle on a contributor-sentiment evaluation methodology with Apache Plumb (separate proposal). Eval covers both ASF and non-ASF cohorts so the data isn't an internal-ASF artefact.
 - **Ship the privacy and security posture** as a release-blocking part of v1 — sandbox setup, clean-env wrapper, privacy-LLM gate, PII redactor, signed releases, pinned-tools manifest. Not a follow-up.
 - **Ship the maintainer-education stream** alongside v1 — pattern catalogue, "your first skill" path, first scheduled workshops. The platform is only as adoptable as the docs that go with it.
@@ -94,7 +94,7 @@ A platform substrate — issue and PR ingestion, GitHub API write-back, conversa
 
 **Drafting** — agent-authored fixes with human review. The agent drafts a fix for a well-scoped problem (a tracked issue, a triaged security report with team consensus on scope, an Apache Verum or Apache Caer finding, a failing test with an obvious cause, a documentation hole) and opens a PR. Every PR is reviewed and merged by a human committer; the agent never merges its own work. For security PRs the public surface strips CVE / private context per the project's disclosure policy, so th [...]
 
-**Pairing** — developer-side dev-loop skills, mentorship intrinsic. Beyond the project-side modes above — which describe the project's agent presence on its own infrastructure — the platform also ships skills that maintainers and contributors run in their *own* dev loop: multi-agent review pipelines, self-review and pre-flight patterns, scoped fix drafting under the developer's driver's seat. Pairing skills don't make state changes on behalf of the project; they're the developer's indivi [...]
+**Pairing** — developer-side development-cycle skills, mentorship intrinsic. Beyond the project-side modes above — which describe the project's agent presence on its own infrastructure — the platform also ships skills that maintainers and contributors run in their *own* development cycle: multi-agent review pipelines, self-review and pre-flight patterns, scoped fix drafting under the developer's driver's seat. Pairing skills don't make state changes on behalf of the project; they're the  [...]
 
 **Auto-merge** — narrowly-scoped fix-and-merge. Auto-merge restricted to objectively boring change classes — lint fixes, dependency bumps inside an allow-list, license-header insertion, formatting, broken-link repair. Per-project AND per-class opt-in; every auto-merged change is reversibly logged. **Not turned on** until Triage, Mentoring, Drafting, **and Pairing** have been running for two quarters and contributor-sentiment data says the project is healthier, not just faster. Security-c [...]