Adding Categories

Adding Categories - we didn't discuss it in class, but the consensus on AUGI is no consensus. There are ardent believers in allowing it, and ardent believers in leaving it alone... I'm going to try and find an official list of all the classes (categories) IFC lists as an example, but no luck yet. I'm a big fan of adding a discrete set of user requested categories based on a petition process or something like that. I don't think a free for all is warranted, but I also don't think never adding a category is a good solution either. My two cents...

Families / Types / Instances

The issue here is where does the "category" property reside? Does it remain at the family level as it does now resulting in duplicated families (and duplicated updates, etc...) or does it reside at the Type level allowing a single family to have types in multiple categories. This means we have a single family to update with changes. No one thought the category residing at the instance level made any sense. This would allow instance level overrides of categories and that just sounded too unruly to everyone...

Switching Categories

Switching categories wasn't covered directly, but we discussed it in the modeling tools section since it was pretty critical to achieving the second modeling option (model first, assign categories later). No one raised any major objections to this. Execution wasn't discussed in detail, but basically we talked about the category-ness parameters being removed and the new category-ness parameters being assigned. All other parameters are unchanged. There's more to discuss, but that's the skinny...

Modeling Tools

Modeling tools were perhaps the most contentious discussion. Most people agreed that the modeling tool and the category weren't related, however the execution of this in the project environment brought out some vehement disagreement. Mainly, this revolved around whether or not to have a "Second" way of modeling that was category neutral allowing assignment of categories after modeling was completed. Should these objects go into generic models? Should it have a null value and be unscheduleable and unexportable, etc...

Hosting

For Hosting we also agreed what we have is insufficient. I think we all agreed on the goals, but we didn't get into a deep discussion on a solution. Darn time...

Visibility

So, Visibility issues abound. We had great consensus that this isn't how things should work. However, we did have a few issues agreeing on how exactly it was best resolved...

Publish Post

Problems

Begin with the beginning! Here are the list of issues as stated at the beginning of the class. If you've got anything to add, comment away!