General / Custom Services Playbook

Playbook for maintainers and practitioners to collaborate on project-specific work that falls outside the defined OSS Wishlist service categories.

This playbook exists to ensure that important, real, and sometimes urgent work can still be supported even when it does not map to an existing rubric or impact model.

OSS Wishlist intentionally does not define, score, or market impact for these services.
Any impact definition or reporting belongs to the maintainer, practitioner, and any sponsoring party.

---

When to Use This Playbook

Use this playbook when:

• a project need does not align with an existing service rubric,
• the work is concrete and accountable (not exploratory only),
• the engagement is specific to one project’s context,
• or the service may be new, uncommon, or one-off.

Examples include (non-exhaustive):

• direct engineering contributions
• documentation or migration work
• program or project management
• release coordination
• infrastructure or tooling setup
• audits, assessments, or research
• community operations or contributor support
• bespoke advisory or implementation work

---

Process Milestones

Note: Some milestones may not apply in all cases.
When skipped, document the reason for clarity and future reuse.

1. Kickoff & Alignment

Maintainer meets with OSS Wishlist admin and practitioner to:

• describe the requested work
• confirm scope and boundaries
• clarify access, authority, and constraints
• agree on expected deliverables

2. Work Definition

Maintainer and practitioner jointly document:

• what work will be done
• what is explicitly out of scope
• what completion looks like

Any success criteria or metrics are defined by the parties involved, not by OSS Wishlist.

3. Execution

Practitioner carries out the agreed work, which may include:

• contributions to repositories or infrastructure
• coordination across contributors or teams
• creation of documentation, processes, or artifacts

All work should respect the project’s governance and norms.

4. Check-Ins (Optional)

Lightweight check-ins may be used to:

• validate direction
• adjust scope
• surface blockers early

Cadence is agreed between maintainer and practitioner.

5. Delivery & Handoff

Practitioner delivers agreed outputs, such as:

• merged contributions
• documentation or guides
• reports, plans, or operational artifacts

Ownership and next steps are made explicit.

6. Wrap-Up

Maintainer, practitioner, and OSS Wishlist admin meet to:

• confirm completion
• note unresolved items
• determine whether follow-on work is needed

7. Reflection (Optional)

Maintainer and practitioner may provide brief qualitative feedback on:

• clarity of the engagement
• usefulness of outcomes
• lessons for future collaborations

This reflection is not scored.

---

Documentation Expectations

At minimum, the engagement should leave behind:

• a description of the original request
• a record of deliverables produced
• references to where outputs live
• notes on decisions or assumptions that matter for continuity

Documentation supports maintainers and future contributors, not evaluation.

---

Resources

Resources are engagement-specific and may include:

• project documentation
• prior issues or proposals
• external tools or standards
• practitioner experience

Resources may be added during the engagement as needed.

---

Review Notes (Non-Scoring)

• Was the work clearly defined and delivered?
• Were the outputs usable by the project?
• Are there dependencies or follow-ups?
• Should this type of work be considered for a future service category?

---

Important Notes

• This playbook is intentionally impact-agnostic at the platform level.
• Work performed here may be measurable, but OSS Wishlist does not standardize or promote those metrics.
• This category exists to ensure important project needs are not excluded by predefined service boundaries.

---

Recurring custom services may later be proposed as rubric-based offerings, but are not required to be.