Create ROADMAP.md

[arkodg]

A document about the project roadmap helps users understand

• WHAT - future scope and deliverable for the project
• WHEN - timelines for delivering these milestones / also helps with GH project visibility
• HOW - procedure for users to request & upvote new items into the roadmap

[danehans]

IMHO creating a ROADMAP.md will depend on the following:

1. An agreed-upon release schedule.
2. Creation of GH milestones based on a release schedule.
3. A backlog (Issues) that is groomed by the EG community, e.g. accomplished during a community meeting.
4. Groomed backlog Issues/PRs that are assigned to milestones.

xref: #15

@mattklein123 should we have #15 and this issue resolved before the public announcement? Feel free to share any additional thoughts on this topic.

[danehans]

@arkodg @LukeShu @alexgervais @skriss when you have a time, please begin creating issues for future EG features so we can create a backlog. When we establish our release process, we'll groom the backlog so we can develop a roadmap.

[arkodg]

will create an epic for each component once #16 is merged :)

[mattklein123]

Optimally both would be resolved but I don't think we absolutely have to have releases for the announcement. I think a roadmap should be done though.

[danehans]

The community decided that a release plan is not required for the public announcement. I have added the roadmap to the agenda for next week's meeting.

[danehans]

Thoughts for a potential high-level project roadmap:

Phase 1 (v0.2.0): Establish a Solid Foundation.

• Complete core implementation Engineering Decisions to Prepare Implementing Design Doc #60
• Establish initial testing, e2e, integration, etc. Create Initial Tests #64
• Envoy docs integration Docs Publishing Strategy #17
• Achieve Gateway API conformance (e.g. routing, LB, Header transformation, etc.) Initial Gateway API Conformance #65
• Setup CI Initial CI Environment #63

Phase 2 (v0.3.0): Drive Advanced Features through Extension Mechanisms.

• Global Rate Limiting
• AuthN/AuthZ
• Lets Encrypt Integration

Phase 3 (v0.4.0): Manageability and Scale

• Tooling for devs/infra admins to aid in managing/maintaining EG
• Support advanced provisioning use cases (e.g. multi-cluster, serverless, etc.)
• Perf testing (EG specifically)
• Support for Chaos engineering?

Note: Aside from phase 1, all phases have no associated issues. At this time, v0.0.3 and beyond are general targets that will be used for discussion purposes.

@mattklein123 @arkodg @youngnick @skriss @LukeShu @alexgervais thoughts?

[zinuga]

looks directionally right to me.

[alexgervais]

Phase 2 is going in the right direction. Everything after 0.0.2 is too fuzzy right now.
I would try and avoid using a version scheme for milestones tho, as we might want to release incrementally in between 0.0.2 and 0.0.3.

[skriss]

Couple thoughts:

• I'd switch the version numbers to v0.2.0, v0.3.0, etc. since they'll be more than bug-fix releases (ref. https://semver.org/)
• Getting to passing Gateway API conformance is (a) a pretty big chunk of work; and (b) a moving target since the conformance tests are actively under development. We might want to split this milestone up a bit, perhaps by targeting a specific subset of conformance tests for the first release, or in some other way.

[danehans]

@alexgervais @skriss thanks for the feedback. I've updated the ^ roadmap accordingly and provided add'l conformance details in #65.

[danehans]

My biggest issue with adding a static roadmap is that it tends to become stale and cause confusion. I like using the GH project tooling to provide a roadmap. We could use the milestone description to provide details for the intended release.

[mattklein123]

I tend to agree that a checked in roadmap gets out of date. I would also rather see us create milestones and track issues within those milestones.

[youngnick]

Big +1 from me for using milestones, but I think @danehans' rough outline is pretty good. I think that @skriss point about conformance being a moving target is a good one too, so we should mark a Gateway API release as the first target, and work towards that. (Perhaps v0.4.3, the current release, or v0.5.0, due soon, that will move some resources to v1beta1.)