RFC Process

All significant changes to the Galileo Luxury Standard go through the Request for Comments (RFC) process. RFCs ensure that modifications are thoroughly documented, reviewed by the community, and approved through a transparent process.

When is an RFC Required?

An RFC is required for:

New features or capabilities (30-day review)
Non-breaking modifications to existing features (30-day review)
Breaking changes to existing features (60-day review)
Minor clarifications or editorial improvements (2-week review)

An RFC is notrequired for typos, grammar fixes, and formatting changes — these can be submitted as direct pull requests.

Who Can Submit?

Anyone. The Galileo Luxury Standard operates under an Open Contribution model. No membership is required to submit an RFC. RFCs are evaluated on technical merit, not submitter status. Organizations of any size, from artisan workshops to major maisons, are welcome.

RFC Lifecycle

1. Draft

The author prepares the RFC using the RFC template. Key sections include:

Summary— One-paragraph overview
Motivation— Why this change is needed
Guide-level explanation— How adopters will use this
Reference-level explanation— Technical specification
Alternatives— Other approaches considered
Compliance impact— Regulatory implications (ESPR, GDPR)
Backward compatibility— Impact on existing implementations

2. Submitted

The author opens a Pull Request against the governance/rfcs/ directory. The PR title should follow the format: RFC: [Short descriptive title].

Note: Draft RFCs use placeholder XXXX in the filename. RFC numbers are assigned only when accepted, not at submission.

3. Champion Assigned

A TSC member is assigned as the RFC's champion. The champion:

Shepherds the RFC through the process
Ensures timely review and feedback
Facilitates discussion and resolution of concerns
Presents the RFC for TSC decision

This prevents RFC abandonment and ensures all proposals receive proper attention.

4. Review Period

The RFC enters a public comment period based on change type:

Minor (non-breaking clarifications): 2 weeks
Major (new features, enhancements): 30 days
Breaking (backward-incompatible): 60 days

During this period, community members comment on the PR, the author responds and may revise the RFC, and the champion tracks open concerns.

5. Decision

After the review period, the TSC decides:

Accepted— RFC approved for implementation in target version
Rejected— RFC not accepted (rationale documented)
Deferred— RFC postponed for future consideration

Decision Mechanisms

Lazy consensus— If no objections by the review deadline, the RFC proceeds to acceptance
Explicit vote— For contested RFCs, TSC members vote explicitly
Breaking changes— Require veto-free TSC approval. Any TSC member may exercise a veto on breaking changes (see Governance Charter Section 6)

6. Implementation

Accepted RFCs are:

Assigned an RFC number (sequential: 0001, 0002, 0003...) — numbers are assigned when accepted, not at submission
Merged into the rfcs/ directory
Implemented in the target specification version
Status updated to "Implemented" upon release

RFC Statuses

Draft— Work in progress, not yet submitted
Submitted— PR opened, under review
Accepted— Approved for implementation
Implemented— Released in a specification version
Rejected— Not accepted (rationale preserved)
Withdrawn— Author withdrew the proposal
Deferred— Postponed for future consideration

RFC Template

Every RFC must include the following sections:

# RFC-XXXX: [Title]

- RFC Number: XXXX (assigned upon acceptance)
- Author: [Your Name (organization)]
- Champion: [TSC member - assigned after submission]
- Status: Draft
- Created: [YYYY-MM-DD]
- Review Deadline: [calculated from submission]
- Spec Version Target: [e.g., 1.3.0]

## Summary
One-paragraph overview of the proposal.

## Motivation
Why is this change needed? What use cases does it enable?

## Guide-level explanation
How adopters will use this, with examples.

## Reference-level explanation
Technical specification details, schema changes.

## Drawbacks
Why should we NOT do this?

## Rationale and alternatives
Why is this the best design among alternatives?

## Prior art
How do other standards handle this?

## Compliance impact
ESPR, GDPR, and other regulatory implications.

## Backward compatibility
Is this a breaking change? Migration path?

## Unresolved questions
Questions to resolve during RFC review.

How to Submit an RFC

Fork the repository
Copy 0000-template.md to XXXX-your-title.md
Fill in all sections of the template
Open a Pull Request with title RFC: [Your Title]
Engage with feedback during the review period

Language

All RFC text, discussions, and decisions are conducted in English. The English version is authoritative. Community translations are encouraged for accessibility but are non-authoritative.