Clarify repo where new Gems contributed to o3de should be added (o3de vs o3de-extras)

[lemonade-dm]

Now that o3de-extras is available for adding news gems, projects and templates outside of the main o3de repo, to the o3de-extras repo.

A conversation has come up about about contributing a gem from an external repo (https://github.com/RobotecAI/o3de-ros2-gem) to o3de and determining whether to add a gem to the core repo https://github.com/o3de or the extras repo https://github.com/o3de/o3de-extras.

Brought up in the discussions is determining the threshold for what makes a gem "core" vs "extra".
Would having some soft guidelines that sigs can agree upon be useful?

[chanmosq]

We'll also need an adjacent clarification on where docs for "extras" live - in the official O3DE Docs or the maintainer's own site (with a link to it from O3DE Docs).
We've gathered some points in a discussion here: o3de/sig-docs-community#72

[hultonha]

Related to this idea, as o3de-extras grows, I'd like to know how we'd like to structure the Gem and Template folder. Do we want to start using sub-folders for Gems (e.g. We'd have a Robotics folder for all the Robotics related Gems) or do we want to keep a flat structure and just signify what the Gem is related to in the name? It would be very helpful to get some guidance on this from the TSC/TAC. Tagging @michalpelka and @adamdbrw for visibility.

I'd be interested to hear what @lawsonamzn and @thefranke think of this. Thanks!

[thefranke]

Depends I guess if you want to have a cleaner code structure. I fear that we eventually run into a situation where a gem is neither this nor that, and either choice in which folder to put it will be a bad one, so I'd opt to keep it flat for now.

[hultonha]

Depends I guess if you want to have a cleaner code structure. I fear that we eventually run into a situation where a gem is neither this nor that, and either choice in which folder to put it will be a bad one, so I'd opt to keep it flat for now.

That's a great point, thanks for the feedback (this is why tags can be so much more effective for grouping/sorting, but this doesn't help a great deal with existing hierarchical folder structures). We'll leave it flat for now and try and keep the Gem name informative to distinguish what it relates to. Thanks!

[byrcolin]

Since both are canonical repos any new o3de object added to either needs to be approved by the TSC. By default though the new object should be mostly developed in a new repo. When the object is ready for either the o3de or extras repos an issue for the TSC should be entered in which the owner of the new object should present an argument that the object belongs in one or the other. It is highly unlikely that the new object is a core object, as a core object is an object that is either absolutely needed by the engine or so useful that nearly everyone would want it in there project. It is much more likely it is an extras object, and just needs a general consensus that this is a useful object that we want to maintain that many people would like to have. Otherwise it should stay in the development repo it is currently in. If that repo is not in a o3de repo already, we could make a new o3de repo and transfer it into that. Or the o3de could outright reject the object if we do not want ownership.