This issue proposes creating a PR that refreshes the OSPOlogyLive framework documentation
Context
Over the past year, the way we organize OSPOlogyLive activities has evolved, and a few signals suggest the current framework documentation may no longer fully represent how the program operates today or the constraints and opportunities offered outside Europe in 2026
Here are some observed changes to consider:
- Noticed a reduction in organizing team member participation/time during sync preparation calls with hosts, and a shift in the kinds of tasks the core team can consistently take on
- We don’t currently have a print-ready (or shareable PDF) information pack, nor a clearly documented process/template for issuing sponsorship calls beyond the github repo documentation. In 2025, this limited our ability to scale events through funding/support
- LF staff capacity and support patterns have changed compared to previous cycles, which affects what can be reliably staffed and what needs to be community-led
- Community interest and opportunities now extend beyond Europe, with growing momentum across APAC, especially Japan, South Korea, Taiwan, and China
- Noticed confusion when multiple labels in TODO are used for similar formats (OSPO BoF, OSPO local meetings, OSPOlogy Live), which can make it harder for participants to understand what to expect and for organizers / ambassadors to reuse shared resources consistently
Based on these inputs, this issue proposes to update the documentation to better reflect:
- Current workflows and capacity constraints,
- The expanded regional footprint
- A consistent branding under OSPOlogy umbrella brand
This issue proposes creating a PR that refreshes the OSPOlogyLive framework documentation
Context
Over the past year, the way we organize OSPOlogyLive activities has evolved, and a few signals suggest the current framework documentation may no longer fully represent how the program operates today or the constraints and opportunities offered outside Europe in 2026
Here are some observed changes to consider:
Based on these inputs, this issue proposes to update the documentation to better reflect: