Feature Request - Per SIG Feature Grid

[OBWANDO]

Hello everyone,

The TSC is proposing a Feature Grid to allow members to understand the maturity and state of our documented and undocumented features. Currently, we really have no way to understand what is usable and what needs work.

Please be sure to look at the example below to understand what we are trying to accomplish.

Below, we have a first sample of a grid that we are iterating from and would love to have some of your comments.
The idea is so that a studio, company, developer or member can look at this grid, and understand the state of the modules that are important to them. This also helps serve as a guide to where we need to focus our efforts and not duplicate work. The initial proposed tables are for Feature maturity, Code maturity, and Binary Maturity.

A feature may be incomplete, partial, complete and so forth. Code may have some of the same states, but also be volatile, deprecated, unstable and so forth. Release may follow the same patterns. We are iterating on the terminology and invite you to put your thoughts in as well. Please use this issue thread for your comments.

We intend to keep a running "Development" grid for each subsystem. When we get to stabilization and release, we will clone the grid and it will become an artifact of the release documentation. We will also be iterating on how it will be updated and maintained with the least amount of effort.

---

But, to do this we need the help from each sig to produce the first two columns (Subsystem, and Detail) for each element that we have documented. Please look at the table and click on the "Link" in the Doc column to see an example.

Optionally, if you have the documentation link and any RFC/comments links, please put them in as well.

As for a format, do not worry about trying to build a table, feel free to use Google sheets, CSV, markdown, or carriage returned outline text. Just as long as it is similar to the first two columns (We can determine that the feature called "HLSL" belongs under the "Shaders" subsystem).

Please let us know by tagging the TSC or myself (Royal O'Brien) so that we can take your list and build a grid out of it.

---

Example for the SIG-Graphics area for Graphics Rendering Subsystem that would be published from its own GitHub file for discussion:

Graphics Rendering Subsystem

Subsystem	Detail	Feature	Code	Release	Link	Doc
Rendering
	Directx12				RFC/Detail	Link
	Vulkan	🟡 Partial	🟢 Stable	🟠 Volatile		Link
	Metal	🟡 Partial	🔴 Unstable	🔴 Untested		Link
	UberRender	🟠 Basic	🟠 Volatile	⭕ Unknown		Link
	Nanite-ish	⭕ In Research	❌ Not Started	❌ Not Started
Raytracing
	Directx12					Link
	Vulkan					Link
	Metal					Link
Anti-Aliasing						Link
	MSAA
	SMAA
	TAA
Shaders
	HLSL
	AZSL
	OLDZSL	🟢 Complete	🟤 Deprecate	🟢 Released
Global Illumination
	Forward+
	Deferred
	Hybrid
Lighting
	Directional
	Point
	Global Sky
	Area
	Forward shading
	Diffuse Probe Grid
	Reflection Probes
	Subsurface Scattering
	Exposure / Eye Adaptation
	HDRI Skybox
	Decal
PostFX
	Tonemapping
	Color Grading
	Post-Process Volumes
	Bloom
	Deferred Fog
	Depth of Field
	SSAO

Unicode Colors and objects that work in Github Markdown
🔴🟠🟡🟢🔵🟣🟤⚫⚪🔘🛑⭕❌
🟥🟧🟨🟩🟦🟪🟫⬛⬜🔲🔳⏹☑✅❎
❤️🧡💛💚💜💙🤎🖤🤍♥️💔💖💘💝💗💓💟💕❣️♡
🔺🔻🔷🔶🔹🔸♦💠💎💧🧊
🏴🏳🚩🏁
◻️◼️◾️◽️▪️▫️
https://unicode-table.com/en/emoji/symbols/

[sptramer]

• I believe I raised this on the original TSC/TAC proposal, but "API stability" is a separate category of "code stability". It also came up that volatile could mean any of three states: Pre-development/planning, API instability, or stable APIs but heavy implementation work. These all have implications for accurate documentation so would need to be tracked on this chart or through some other system.
• So long as volatile retains multiple meanings, it's possible for a feature which is previously locked and stable to become volatile because of major code changes. Whether or not this is a desirable consequence of these definitions is up to the discretion of the TSC, sig-docs-community has no advisement in particular.
• sig-docs-community would recommend adding "API documentation" as a tracked area by the SIGs themselves, similarly tracked to engineering work. This year we are hoping to start an RGY dashboard for API docs coverage which could integrate with this chart in some way to help automate that reporting.
• sig-docs-community would also recommend tracking in some way our own coverage of features on a corresponding chart if this is implemented.

[lmbr-pip]

@OBWANDO - We need a better method of communication if you have a need for all SIGs to look at and contribute to this. Without the needs-triage label, this issue does not show up at SIG issue triage. I had no idea this issue existed on behalf of SIG-Network/SIG-Security, I only discovered it through casual browsing of our backlog. This should have been pinged in each SIG channel at a minimum so SIGs can organize around request.

[lsemp3d]

sig-content feature matrix first pass: o3de/sig-content#36

[lmbr-pip]

sig-network matrix first pass:

Networking

Sub Feature	Feature	Code	Release
Transport API	Complete
Multiple network interface support	Complete
Compression (TCP/UDP)	Complete
Metrics support	Complete
UDP	Complete
UDP: DTLS support	Complete
UDP: Reliable queue support	Complete
UDP: Fragmentated packet support	Complete
TCP	Complete
TCP: TLS Support	Complete
TCP: Ringbuffer support for package transmission	Complete

Multiplayer

Sub Feature	Feature	Code	Release
Multiplayer component API	Complete
Local Prediction	Complete
Server Side Rollback	Complete
Play in Editor Mode	Partial
Hosting/Joining a Game	Complete
Network property support	Complete
RPC support	Complete
Network Input support	Partial
ScriptBind support	Partial
Netbound entity support [NetBindComponent	Complete
Entity replication support	Complete
Network Prefab Spawning	Partial
Networked Animation	None
Network Audio Support	None
Network Simulation (Physics)	Complete
Quality of Service	Partial
Debugging Tools -	Partial
Metrics	Partial

Cloud Services

Note this needs work, as its very AWS centric.

Sub Feature	Feature	Code	Release
HTTPS Support	Complete
Restful API Support	Partial
AWS C++ SDK Support	Complete
Client Side Identification and Authentication	Partial
Runtime Metrics	Partial
Amazon GameLift Support	Partial

[OBWANDO]

Thank you, this is exactly what we needed to start from.

Json created and configurable in table editor.

[sptramer]

@OBWANDO Please take into account the sig-docs-community recommendation from the initial feature RFC (??? - it was a comment left on @jeremyong's original proposal, it looks like the comments/requests were split) that docs be a sub-table of each feature set, not just a docs link. For example, I know that the networking and multiplayer API documentation is YELLOW (partial coverage / not sufficient for users) and RED for just about everything else in docs (except maybe autocomponents, which is YELLOW.) After feature graphs are completed and there is a sig-docs audit we will have our own enormous tables and dashboards.

[OBWANDO]

@sptramer The code will be published for anyone to modify/update for their needs. This is a quick first pass to at least get something started. I understand you want another array inside of the docs JSON structure as noted by your response from #6703 :
"Docs might want to provide an alternate structure here (for extensibility purposes), so "Doc": { /* TBD */ }. We've got a lot of information we could throw up per-sig or per-module if we can get RGY coverage dashboards working."

You gave an idea on adding an array, but no definition on how it would be edited or presented, and what level of complexity it may add to the presentation for usability. I took the original JSON structure, made the appropriate changes so that any SIG can have a single page view to find a feature and glance at its current state.

The format I assembled is very simple where someone can click on a pulldown, change state, and export the JSON to do a PR or possibly allow it to be used as a GitHub app and use their permissions to update or auto-produce a PR.

If you have more feedback and a mockup (preferred) on what you are looking for with a view of how it would be used, please send it over and I can look at how it will impact the JSON structure and the presentation layer.

Alternative... anyone from the community can do this as well. I am simply helping move this from a conversation into an action.

[OBWANDO]

First pass - https://o3de.github.io/community/features/form.html
There is a lot of functionality under the hood, and it can go in any direction.

I do not get a lot of dev time myself, so If any Javascript devs are up to expanding its capabilities, the source is in the o3de/community/features repo. Anyone else willing to give some feedback, please do.

I opened a discussion thread for feedback here:
o3de/community#113

[Kadino]

SIG-Testing has filled out https://o3de.github.io/community/features/form.html

Removing sig-testing from issue labels, as this keeps coming up in our triage.