Replies: 3 comments
-
I do have concerns. As creating a proposal for new AssetProcessor GUI features or AssetBrowsing features would have to go through 2 sig groups to get the proposals invoked. Out of the two Sig-Core and Sig-Content groups, I lean more towards SIG-Content for Asset Pipeline, since I can see all the features of the Asset Pipeline fitting within SIG-Content. The current SIG-Content responsibilities of Asset Editor, Asset Browser and "Asset PRocessor reporting console tool" doesn't fit in SIG-Core |
Beta Was this translation helpful? Give feedback.
-
I would prefer if everything I worked on was under one single sig. Splitting between two sigs like you've mentioned above is going to make it challenging to track which sigs I need to involve in work I do. |
Beta Was this translation helpful? Give feedback.
-
I'm a bit concerned about an "everything under the kitchen sink" charter for sig-content (and I don't think I'm alone, see #22). How would we feel about having a separate sig-assets? |
Beta Was this translation helpful? Give feedback.
-
According to the above charters, SIG-Core is responsible for "asset catalog, asset processor, and builder systems and framework" and SIG-Content is responsible for Asset Editor, Asset Browser and "Asset Processor reporting console tool". The distinction seems to be that SIG-Core owns the backend frameworks and systems and SIG-Content owns the user-interactable tools built on top of them.
Are there any concerns with this structure? Please, comment below.
Beta Was this translation helpful? Give feedback.
All reactions