search

o3de / tsc

Technical Steering Committee
Apache License 2.0
4 stars 5 forks source link

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

Open lemonade-dm opened 1 year ago

lemonade-dm commented 1 year ago

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 commented 1 year ago

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: https://github.com/o3de/sig-docs-community/issues/72

hultonha commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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!