publish support commitments

[turbobobbytraykov]

Situation

The readiness assessment of IgniteUI.Blazor.Lite 0.1.1 raises three support requirements, all sourced from the same evidence record: a bounded search of the public repository documentation and workflows found no support service level agreement, no end-of-life notice period, and no named package owner or escalation contact.

ID	Requirement	Assessed as
SUP-01	Active maintainer / support owner is identified.	maintainer evidence required
SUP-03	Response SLA is published.	defect
SUP-06	Public EOL notice precedes support termination.	defect

Two related requirements are already satisfied and should not be reopened. SUP-02 (public contact) and SUP-08 (coordinated disclosure) are met by SECURITY.md, and SUP-04 (supported versions) is met by its supported-versions table.

The objection raised during review — that this is a free, open-source package and therefore carries no contractual SLA — is correct and is not in dispute. It does not, however, dispose of the requirement. The rubric asks whether a commitment is published, not whether it is contractual. A published statement that support is best-effort, with a target rather than a guarantee, satisfies SUP-03 in a way that publishing nothing does not, because a consumer evaluating the package can currently form no expectation at all.

SUP-06 is the more consequential of the three. It is the only one that constrains what we may do to consumers in future: without a published notice period, dropping support for a version is unannounced by default.

There is a secondary consideration worth deciding deliberately rather than by omission. Ignite UI for Blazor also ships as a commercial product with real Infragistics support entitlements. Whatever we publish for the free Lite package needs to state the boundary clearly, or it will be read as either over-promising (free package inherits commercial support) or under-promising (paying customers get GitHub best-effort).

Options

Option A — publish a SUPPORT.md with best-effort targets

A root SUPPORT.md, discovered automatically by GitHub and surfaced in the issue-creation flow, stating:

• Ownership. The Ignite UI for Blazor team at Infragistics, reachable through the repository's issue tracker; a GitHub team handle (for example @IgniteUI/blazor) as the escalation path rather than a named individual, so the record does not go stale when people move.
• Response target. An explicit best-effort first-response target for issues — expressed in business days, explicitly not a contractual SLA, explicitly distinct from the security acknowledgement and triage windows already in SECURITY.md.
• Boundary with commercial support. A short statement that commercial Ignite UI for Blazor entitlements are handled through Infragistics support cases and are unaffected by anything in this file.
• End-of-life notice period. A minimum advance notice before a version stops receiving fixes, published in the changelog and the release notes.

Closes all three requirements. Cost is one file plus the decisions below.

Option B — ownership and EOL only, no response target

The same file, minus any response-time number. Closes SUP-01 and SUP-06; leaves SUP-03 open with a stated rationale rather than silence.

This is the defensible middle if we are unwilling to publish a number that a single busy month would falsify. It is materially better than the status quo, because SUP-06 — the requirement that actually protects consumers — gets closed either way.

Option C — decline, with the rationale recorded

Publish nothing and record the reasoning against SUP-03 and SUP-06 in the assessment response. Requires no repository change and closes nothing. Only sensible if we conclude the requirements are misapplied to a free package, which is not currently our position on SUP-06.

Decisions needed before this can be implemented

1. First-response target, if any. A number in business days, or an explicit "no target published".
2. End-of-life notice period. A minimum, in months, before a version stops receiving fixes.
3. Escalation identity. GitHub team handle, shared mailbox, or both.
4. How the free/commercial support boundary is worded, and who signs off on that wording — it is customer-facing and reaches beyond this repository.

Recommendation

Option A, with a conservative response target rather than an ambitious one. Failing that, Option B — SUP-06 should be closed regardless of what we decide about SUP-03, because it costs nothing to publish and it is the one consumers are actually exposed by.