BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//speaker//AWKFR
 J
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-europython-2026-BX77EE@programme.europython.eu
DTSTART;TZID=CET:20260717T125500
DTEND;TZID=CET:20260717T135500
DESCRIPTION:Maintaining CI/CD configurations across dozens of Python projec
 ts means copying the same `tox` invocations\, Python version matrices\, an
 d error-handling logic into every repository. This poster presents five ar
 chitectural patterns from the `reusable-tox.yml` project that eliminate th
 is duplication by applying familiar software engineering principles to Git
 Hub Actions workflows.\n\nEach pattern is illustrated with a before/after 
 YAML comparison and a Python code analogy\, making the design decisions im
 mediately recognizable to Python developers:\n\n* *Singular inputs* — ac
 cepting one Python version per workflow call instead of JSON arrays. Like 
 writing `def run(version: str)` instead of `def run(versions: list[str])` 
 — simpler to reason about\, test\, and compose via caller-side matrix st
 rategies.\n* *Caller-side matrix strategy* — separating "what to test" (
 the calling workflow's job) from "how to test" (the reusable workflow's jo
 b). The same Separation of Concerns you'd apply to Python modules.\n* *Thr
 ee-phase execution* — splitting `tox` runs into environment preparation 
 (`tox --notest`)\, main execution\, and debug rerun on failure. Like Unix 
 pipelines — each stage transforms data through a single responsibility\,
  improving cacheability and error diagnosis.\n* *Composite action hooks* 
 — providing extension points where projects inject custom setup logic wi
 thout modifying shared infrastructure\, discovered automatically via `hash
 Files()`. The Dependency Injection pattern applied to CI/CD.\n* *Explicit 
 over implicit* — refusing to auto-detect `tox` environments or infer con
 figuration. Predictable and debuggable beats magical and surprising.\n\nTh
 e poster includes a "Which pattern solves your problem?" decision flowchar
 t and a QR code linking to the open-source repository with ready-to-fork t
 emplates.\n\nBorn from maintaining dozens of Python projects including aio
 http\, CherryPy\, and pip-tools\, these patterns treat CI/CD with the same
  architectural rigor as application code.
DTSTAMP:20260524T121641Z
LOCATION:Poster Hall A
SUMMARY:reusable-tox.yml: Five Patterns to Eliminate CI/CD Boilerplate - Sv
 iatoslav Sydorenko (Святослав Сидоренко)
URL:https://programme.europython.eu/europython-2026/talk/BX77EE/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-europython-2026-ZHCNDY@programme.europython.eu
DTSTART;TZID=CET:20260717T153000
DTEND;TZID=CET:20260717T160000
DESCRIPTION:Open source maintainers are drowning in a new kind of noise. "A
 I"-generated pull requests — superficial\, poorly reasoned\, and submitt
 ed without genuine understanding of the codebase — are consuming review 
 bandwidth that was already scarce. These contributions range from cosmetic
  "improvements" that introduce subtle bugs to elaborate refactorings that 
 no one asked for\, all bearing telltale signs of LLM output: confident ton
 e\, plausible-looking code\, and zero awareness of project conventions.\n\
 nThis talk presents a practical\, battle-tested framework for combating "A
 I" slop without discouraging legitimate contributors. Drawing from real ex
 periences maintaining pip-tools\, aiohttp\, ansible-core\, CherryPy\, and 
 other Python projects\, I'll share concrete strategies that work today.\n\
 nFirst\, we'll dissect the anatomy of "AI" slop PRs — what they look lik
 e\, why they pass superficial review\, and the hidden costs beyond wasted 
 review time: CI compute waste\, security risks from plausible-but-wrong co
 de\, and the demoralizing effect on genuine contributors who see low-effor
 t submissions getting attention.\n\nThen I'll walk through a defense-in-de
 pth approach being developed across my projects: updating `CONTRIBUTING.md
 ` with explicit expectations about understanding the codebase before submi
 tting changes\; crafting repository-level LLM instruction files (like `AGE
 NTS.md`/`CLAUDE.md`) that steer "AI" tools toward project-specific convent
 ions\; configuring PR templates to require evidence of human reasoning\; a
 nd establishing community norms that set quality expectations without bein
 g hostile to newcomers.\n\nWe'll also tackle the harder questions: Where i
 s the line between "AI"-assisted (the human drives and understands the cha
 nge) and "AI"-generated (the human clicks "submit" on LLM output)? How do 
 we preserve the welcoming culture that makes open source special while def
 ending against low-effort spam? What should platforms like GitHub improve 
 for maintainers?\n\nYou'll leave with a ready-to-adapt policy template and
  configuration files for your own projects.
DTSTAMP:20260524T121641Z
LOCATION:Auditorium Hall (S1)
SUMMARY:Defending Open Source from "AI" Slop: A Maintainer's Practical Guid
 e - Sviatoslav Sydorenko (Святослав Сидоренко)
URL:https://programme.europython.eu/europython-2026/talk/ZHCNDY/
END:VEVENT
END:VCALENDAR