I think we should break up SIG-Content

[monroegm]

The scope of SIG-Content is too big to allow for efficient operation of the SIG.

• Over 40% of all O3DE issues fall under SIG-Content, the most of any of the 12 SIGs.
• Even after increasing triage frequency from one to two 30-minute sessions per week, the amount of issues needing triage remains stagnant from week to week.
• We could continue increasing triage frequency but that would increase meeting overhead for individual SIG members. Breaking up the SIG would increase triage frequency without increasing individual overhead.

We could break up SIG-Content into 3 SIGs:

• SIG-Editor: Core editing frameworks, components and user interfaces
  • Examples: Viewport, Qt components, Reflected Property Editor
• SIG-Content-Tools: Content creation tools that have their own editors and/or behave like standalone tools
  • Examples: EmotionFX (Animation Editor), LyShine (UI Editor), Script Canvas, Lua, Project Manager
• SIG-Content-Systems: Systems particularly focused on enhancing content-creation workflows
  • Examples: Prefabs, Terrain, Vegetation

[AMZN-daimini]

As discussed during the sig-content meeting, we should define the details of how the transition would work.

@monroegm suggested to add all current sig-content members to all new sigs created after the split, and allow them to opt out of the ones that they are not interested in. I second this approach.

[AMZN-daimini]

I'm thinking the proposed break up is not super clear and may lead to confusion in triage.
Since we're striving to create no more than 3 sigs out of content, this is my proposal

• SIG-Editor: Core editing frameworks, components and user interfaces

  • Examples: Viewport, Qt components, Reflected Property Editor

• SIG-Content-Tools: Content creation tools

  • Examples: EmotionFX (Animation Editor), Project Manager, Terrain, Vegetation

• SIG-Game-Logic: Systems related to game logic

  • Examples: Prefabs, LyShine (UI Editor), Script Canvas, Lua

Very open to discuss naming and grouping, as there's definitely no right answer and my subdivision mostly comes out of trying to ease the triage process, while matching areas that have a lot of interaction in terms of code (with the exception of Tools that is quite loose :D )