Introducing Structural Classes for Speckle!

Making Speckle
1

Hi everyone! As some of you may have noticed… we have now added structural classes to the default Objects kit! Many thanks to Arup (@daviddekoning, @jenessa.man) for leading this effort, and thanks also to the many members of the Speckle community (including @kelvin, @Rob, @MdeLeur, @pieter, @JdB, @dtnaughton) who provided their feedback and expertise during development. These classes will serve as the foundation for conversion routines used in upcoming structural software connectors (ETABS and Oasys GSA connectors that will be released soon :tada:, and SAP2000 and Trimble connectors down the line).

How were the class definitions put together?

Flexibility is one of Speckle’s main benefits, and we took this as a guiding principle as we developed the structural classes, and–more importantly–the framework for their continued development. To allow teams to move forward with their own work while still contributing to a common structural data format, we borrowed a high-level structure from Figure 7 of the April 2020 buildingSmart Technical Roadmap. With this approach, the broadness of applicability of an object determines whether the object should be considered common and therefore appropriate for standardization. In other words, the “more generic and broadly used” an object is, the more it should be standard. The use of this hierarchy is intended to balance the “amount of consensus that can be reached, the adoption of the [classes], and how many specific use-cases” the classes can support (1). Application of this concept to structural analysis model data produces the hierarchy of standardization depicted below:

str-kit-pyramid
str-kit-pyramid2205×1035 100 KB

The hierarchy of standardization pyramid (or, the Amazing Technicolour Dream Triangle of Interoperability™)

The most basic information in a structural analysis model is geometry. Thus, the highest level of standardization for structural objects is geometry (the red layer). These are the Speckle structural object definitions, so we follow the geometry laid out in the Objects.Geometry classes.

The next level of standardization represents the minimum information required to communicate the intent of a structural analysis model (the purple layer). This encompasses geometry-based objects (i.e. nodes and elements), loads, releases, restraint conditions, and material names and property names. Working with material or property names, rather than fully-defined material or property objects, lessens the burden on the user and the classes to identify and agree on the common definitions of material or property (as structural software take very different approaches in defining the material models and section profiles and properties they use!). This “layer” forms the basis of the new structural classes, and these items have been added to the Objects.Structural namespace.

The next level of standardization applies to application-specific definitions (the green layer). These are objects which are native to specific structural software and allow completely lossless transfer to and from the same application (i.e. GSA-specific items like assemblies, application-specific material models). We have added portions of this “layer” to the classes in the Objects.Structural.ETABS and Objects.Structural.GSA namespaces. We expect users of particular software or developers of a particular connector to build and maintain the relevant application-specific definitions.

The final level of standardization (yellow) applies, of course, to the most specific entities - in this case, data specific to a particular project or client. These items are not suited to standardization and should be managed by each individual user on a case-by-case basis using Speckle’s powerful custom property mechanism.

These levels are not static and over time and we will continually review the developments in each layer to see what data and types are mature enough to move up to a high level of standardization.

This hierarchy provides enough common ground to allow different applications to communicate with each other, while still allowing them to move forward and innovate quickly!

Interested in a deeper dive into the (many) various structural data formats used in the AEC industry? Check out this recent blog post by @daviddekoning. These existing schemas were reviewed in writing the new structural classes.

What is the scope of the new structural classes?

Currently, the structural classes contain all required objects for specifying a basic, generic structural analysis model (including geometry, loading, properties, and materials information), classes for specifying an Oasys GSA structural analysis model, and some preliminary classes for describing general structural analysis results.

Explore the structural classes
  • Analysis
    • Model
    • Model description & project info
    • Model settings
    • Model units
  • Structural Geometry
    • Axis
    • 1D element
    • 2D element
    • 3D element
    • Node
    • Restraint
  • Loading
    • Load case
    • Load combination
    • Node load
    • Beam load
    • Face load
    • Gravity load
  • Material
    • Concrete
    • Steel
    • Timber
  • Property
    • 1D property
    • 2D property
    • 3D property
    • Damper property
    • Mass property
    • Spring property
    • Section profile (ex. ISection, Rectangular, Circular)
  • Results
    • 1D result
    • 2D result
    • 3D result
    • Nodal result
    • Global result
  • Application-specific objects

How will the new structural classes fit in with the other components (ex. BuiltElements) of the Objects kit?

Currently, all geometry-based structural objects (ex. Element1D, Element2D, Node) inherit from Objects.Geometry class. All non-geometry-based objects inherit from the Speckle Base class. We plan to add some structural objects which inherit from Objects.BuiltElements class, but these additions are forthcoming (ex. a Storey object which inherits from the BuiltElements Level object). Conversion methods to/from Objects.Structural objects and native objects will be added to support the translation of analytical elements (ex. Revit Analytical Stick or Analytical Surface) to structural elements in the near future as well.

Contributing to the object model :building_construction:

As we continue to develop the structural components of the Speckle ecosystem, we hope to see the structural classes evolve to suit, and for this evolution to be informed and driven by the Speckle community. As with contribution to all other parts of Speckle, the golden rule is to discuss first! Before embarking on any development, make a post in the community forum to share the changes or additions you’d like to make. Be sure to tag @jenessa.man and @Reynold_Chan, who will be shepherding the whole set of classes to full maturity. Add a structural tag to the post so that everyone will get notified as well! We’ll discuss what’s proposed as a community and together determine how things will fit within the hierarchy of the object model and Speckle as a whole. Some of the key things we want contributors to think about are:

  • Is the proposed addition/change generic and broadly applicable (ie. suitable for standardization, belonging to the purple layer), is it more specific to a particular software (ie. suitable for standardizing in the context of the specific software, belonging to the green layer) or is it specific to a project/client (ie. not suitable for standardization, yellow layer)?
  • Is the proposed addition/change applicable to other definitions in the object model? Applicable across application-specific definitions? (If we want to add a property to the GSA-specific definition of a concrete material that is also applicable to the ETABS-specific definition of the analogous concrete material, should we also “promote” this property from the green layer of standardization to the purple layer add it to the base definition of the concrete material?)

Looking ahead :eyes:

Keep an eye out for upcoming Oasys GSA and ETABS connectors! If you’re keen to keep track of the ongoing development of these connectors, visit the GSA work-in-progress repo here and ETABS work-in-progress branch here.
Finally, as always, feedback is very much welcomed, so please go ahead and check out the new classes on GitHub and let us know what you think! :star2:

Staying in the Loop

If you haven’t done so already, you can also set tags within your discourse user setting here. This way you can get notified of the structural classes and updates here:

image
image1147×897 40 KB

References

  1. buildingSMART International. (2020). Technical Roadmap buildingSMART Getting ready for the future [PDF file]. Retrieved from https://buildingsmart-1xbd3ajdayi.netdna-ssl.com/wp-content/uploads/2020/09/20200430_buildingSMART_Technical_Roadmap.pdf
10 Likes
2

@Rob (20 characters required)
Edit: Rob was already tagged… But great to see Structural Classes are supported now!

4 Likes
3

Hello all,
Regarding added cruciform, ellipse, C, Z, IAssymetric, RectoEllpise, SecantPile… by kpne · Pull Request #763 · specklesystems/speckle-sharp · GitHub
I’ve expanded the list of section profiles types to include:

  • Cruciform,
  • Ellipse,
  • C,
  • Z,
  • IAssymetric,
  • RectoEllipse,
  • SecantPile,
  • SheetPile,
  • Stadium,
  • Trapezoid

I believe this addition is applicable to the purple layer, as these section types are typical (albeit can be with different naming of course) across different FE programs. The additions do not break any of the existing code.

5 Likes
4

Hi Kristjan !

Thanks for the contribution. So other than the C section which is represented by the channel section class already. I think the other ones are new ones here.

IAssymetric can be somewhat integrated into ISections actually since it’s just a more general definition of ISections. Likewise with ellipse and circulars?

Trapezoid sections ~ are they supposed to be concrete sections ? or weird hollow sections?

The rectoellipse section also feels a bit way too specific to ever be used. Not sure how I feel about stadium sections? never seen them and secant pile sections … Not sure they exist in non-section profile designer context either.

Wondering whether we should store these more peculiar ones in an application-specific section designer context since you’ve mentioned they’re for adsec. What are your thoughts?

5

Hi Reynold
To clarify, the C-section has ‘lip’ properties that are missing in the existing Channel section definition.

I’m perfectly happy for both C and IAssymetric to inherit from the Channel and ISection respectively.

Trapezoidal sections are filled, yes, I’m also perfectly happy to add a field for wall thickness to make it a voided profile and set that field to zero by default (like for circular and others).

I would add all profile types (no matter how often they may be used) to the purple layer. If you want to rename them (agreed ‘Stadium’ may not be a self-explaining term) I’m happy to change, but I think it should all be in the same layer. Even if the profile types do not often exist outside a non-section profile designer context, I don’t see why the purple layer should only be for other applications. As an example, the secant pile could be something that you would have in a Revit model but not in a FE model (in the FE model they would perhaps be replaced/represented by a spring support or just a regular support), and then they would again exist in a section design context, with geometry from Revit but internal force from FE model reactions.

6

Hi @kpne. I’ve just had a read through this thread and I feel as though the structural objects should be kept as lean as possible on the purple layer. Can these sections be incorporated further down the pyramid?

7

So the purple layer is the minimum information required to understand all basic FE analysis software, as of now I’m not sure whether I would categorize section designer programs in the same world as these other programs. And like you kinda pointed out with your example of the secant pile how it can already exist in a Revit context and not exist in an analysis model perspective, I don’t really see that as a purple layer as a minimum but as a green layer.

Add on-top of the fact that my experience with section designer programs is that they never always have the same sections as each other … i.e some might support cruciform while others might do some weird plate thing… I just don’t see the justification for it to be in the purple since it’s not minimum. The idea of the pyramid is to kinda keep things to a bare minimum. Section designers also come in much later in a general workflow perspective.

Yes if you can have C section and IAssymetric to inherit from those for now… I think that would be the best way to approach this one.

8

Hi Reynold and Daniel,
Thank you for your comments. I hear what you are saying, I also want this lean and clean - it is just a question where we hide the mess, haha.

So, I can see we have different understandings of the Amazing Technicolour Dream Triangle of Interoperability™ :laughing: We are trying to co-create a structural schema that will allow seamless interoperability between the different structural software packages, that being BIM, FE or section checks, right? If I’ve misunderstood that then all good - I’ll just stick everything in the green layer in my own branch.

If the purple layer is the “standard”, e.i. the structural schema, the important thing would be that there is no conflict between software packages, so if I stream a cruciform profile to both GSA and ETABS it stays a cruciform profile and isn’t changed to a triangle in one of them. It might be changed to an explicit profile representing the cruciform shape but not a triangle.

There’s therefore nothing wrong with having a lot of stuff in the purple layer, as long as it is not conflicting with something. In a very idealised world, we would want everything to be in the purple layer, no? Raymond, I think I would therefore have to disagree with the way you interpret the definition that the purple layer is “minimum information required”. Minimum information required is the minimum agreeable information, in the example of the cruciform that is the shape - if some programs then define that as an explicit list of points or as two flanges and two webs then that is no longer minimum information but a software-specific way of defining it. But, to me, just because all software packages doesn’t include a definition for cruciform does not mean that it doesn’t belong in the purple layer.

What would you suggest as the alternative? Consider two scenarios for streaming a cruciform profile:

  1. From Software A that can handle cruciform to Software B that doesn’t know what a cruciform is
  2. From Software A that can handle cruciform to another Software C that can handle cruciform

I would say that 1) can be solved by having a conversion to explicit in place for Software B that doesn’t recognise cruciform. I would say that it would be a loss of information if I for 2) needed to convert to explicit because cruciform wasn’t allowed in the purple layer, and it would be less lean overall solution if I had to rely on catching this scenario and convert to my own schema in the green layer, just to avoid loss of information, but for other scenarios where I have a rectangle profile I do not rely on my green layer schema.

Then I also think that we need to exactly consider the whole workflow, not just the FE interoperability. I again have to disagree that the purple layer is only for FE analysis software, no it should consider all aspects of a structural engineering workflow and section design is a big part of that. I want to be able to pick up a stream with results and run section analysis on it automatically in the cloud.

All that said (sorry got a bit long), I am up for finding a solution that works for all of course.
Best, Kristjan

9

So this is the basic intent of the pyramid.

the Purple layer is "minimum information" required to understand the model. So this is kinda why section property names, material names are here but not the actual definition of the materials/sections.

In reality, it means that a lot of connectors will actually end up in the green layer including section definitions.

I agree to look at things from a workflow perspective but it’s also considering things from how do programs interact with each other. That’s the essential driving aspect of this pyramid. To help facilitate these conversations. Btw from a workflow perspective as well, you’ll still have access to all your schemas and stuff in grasshopper ! So it’s not like you won’t be able to solve your problem. Just need more user facilitation. And there have been discussions about flagging conversion errors as well more visibly so problem #2 might not be as big of a problem in the future. Personal opinion; but I actually prefer not being able to solve problem #2 over #1 … That way if I know a certain section isn’t supported, I know to always look out for those sections as opposed to hoping that the certain software supports that section and finding later down the line that it doesn’t.

When the program is really niche (i.e adsec sections) I think they should belong in the green more than the purple. What do you think ? Of course, if other people in the community can chime in and show to me that these adsec sections are pretty popular in other structural software… we can move them up and down as needed :slight_smile:

Note : Another thing is that there will be a community review of this pyramid which will be quarterly. They’ll be one before the end of this year for everyone to discuss this more in-depth.

3 Likes
10

So if I understand you correctly, this means that to have interoperability between different software we would need to write specific converters between each of them:

  • AdSec to/from GSA converter
  • AdSec to/from Etabs converter
  • AdSec to/from Karamba converter
  • AdSec to/from Sofistik converter
  • GSA to/from ETABSconverter
  • GSA to/from Karamba converter
  • ETABS to/from Karamba converter
  • etc

I think that is a lot of effort that could be easily avoided. And, to me, it will also be confusing because some things in your converter, even for simple things like profile, will live in the purple layer and some in the green layer.

The alternative that I propose is that we have an overarching schema (purple layer with all in it) so that you just write your converter to that schema once. And you dont have to write a converted based on the purple layer for a rectangle profile and based on green layer for a trapezoidal profile.

  • AdSec to/from SpeckleStructural
  • GSA to/from SpeckleStructural
  • ETABS to/from SpeckleStructural
  • Karamba to/from SpeckleStructural

To me it is more important to be able to send “niche” cross-sections between two programs without losing information (if trapezoid exists in both AdSec and Karamba I don’t want it to come out as explicit). That comes with the slight downside that the codebase is perhaps not “neat”, but once this is implemented it is hopefully not to be touched that often so is that really an issue?

11

You’re writing conversion statements for the most part to the purple layer and writing explicit green layers when needed. I.e Pier/spandriels for ETABS will never be supported in GSA. likewise, some of the adsec sections won’t be supported in a lot of programs… (I’ve never even heard of a stadium section until now) So I will write a specific class for these programs in the green layer. Even in ETABS to SAP … composite beams aren’t supported in SAP.

This only occurs when you’re specifically requiring an explicit conversion between specific applications. So there are two ways for this to be handled… i.e by user facilitated input or by codebase. The reality is most of these conversions might not actually occur. A trivial example would be something like a BREP being sent from Rhino to ETABS. Those are specific things to the nature of the program and doesn’t make sense to convert them either. There might be a select few very niche programs that support BREP objects in structural connectors, but a majority of them don’t. Hence why they are left in the green layer. If two programs are found to have green layer objects that match well together, then you can write an explicit conversion for them. But in reality, it won’t happen as often as you think. I.e the case of a stadium section… it really isn’t supported in a majority of programs… so it just won’t be brought into the program and it’s non-sensical as well. You might bring the name of the section profile into each of the programs, but that’s about it in terms of the support you can get from one program to the next. This is inherently already supported since objects should be inheriting from the purple layer regardless

A similar approach can be seen in our BuiltElement kit. There are common definitions inside the BuiltElement kit and then there are specific definitions unique to the application like Revit in where it will never appear most likely outside of a Revit context.

3 Likes
12

Hi @Reynold_Chan, @kpne,

just my quick two cents here :wink:

I.e the case of a stadium section… it really isn’t supported in a majority of programs…

I do not know about ETABS, but I really hope you can define stadium sections in most of the available structural software. You definitely can in the one I use most (Sofistik). There is probably only an explicit stadium section in AdSec/GSA, but in most section editors you can basically create any crazy custom section you can think of (also stadium sections). So there is definitively the need for a custom section object. And why not have a stadium section as well? You will loose information converting it to a custom section.

There might be a select few very niche programs that support BREP objects in structural connectors, but a majority of them don’t.

Why is that an argument?
Also this seems to be a very subjective perspective. Again, Sofistik can work with BREPs (also very subjective).
But why would we create such limitations ourselves? I thought speckle was created because of all the limitations that we have to deal with all day long… :wink:

1 Like
13

For explicit sections, we have the custom section profile. Called Perimieter . So if you’re defining something explicit, then it should go here. This class is meant to support those section editor sections.

I think perhaps what I’m not communicating effectively enough here is just because it’s in the green layer, does not mean that there is a limitation on the communication. The purpose of the pyramid is really to help facilitate this type of communication in the case of what happens when there are niche classes so that you don’t lose the information in the speckle world, but can’t necessarily bring it into the program that you need it cause it doesn’t support that type of work. Otherwise, we wouldn’t have a green layer at all and everything would be just purple. The reality is that there is too much software out there with their own support for certain features, and that’s the motivation for the green layer.

Ah cool never knew Sofistik works with BREPS… That’s confusing if someone sends a convoluted BREP from Rhino. Can I send a bunny from Rhino into Sofistik then Hehe :slight_smile:

1 Like
14

Hi all! Since I am the one who originally suggested the pyramid, I thought I should jump in to this discussion :slight_smile:

The key thing that I would like to add is the dimension of time: the layers in the triangle are not meant to be static, so when items are introduced into the application-specific layer (green), two things are acheived:

  1. that application’s connector can move ahead with transfering data via Speckle without waiting for coordination across all other programs in that domain, and
  2. those items are proposals for the community to discuss

Interoperability between different applications is from the purple and red layers - this is the data that everyone has agreed on. Rather than set up (for example) specific ETABS to GSA conversion routines that understand each application’s specifc data (green), the goal is to regularly discuss (as @Reynold_Chan mentioned) what properties and classes should be promoted from green (app-specific) to purple (domain-wide) layers.

The statement “minimum information required to understand the model” was our aim for v1.0 of the schema - going forward it will grow.

However, I do not expect many (or any!) new data types and properties to go directly into the domain-wide (purple) layer. The application-specific (green) layer is a pressure-release valve to allow connector developers to move quickly, and then follow up with standardization.

3 Likes
15

Hi @daviddekoning, @Reynold_Chan,

Thanks for clarifying the intentions; we aim to (over time) have everything in the purple layer as an agreed schema and we are only to write conversion routines to/from the purple layer - sounds good.

I appreciate the need for a green “temporary” layer where developers can dump their stuff when they are under time pressure, or when trying to implement things like materials (where there is pretty much a different schema for each program :face_with_raised_eyebrow:).

I do not understand why some items shouldn’t be allowed to go straight into the purple layer. We can still make proposals here for the community to discuss - I mean the proposals will always go into a pull request first so the code can still be discussed… :slight_smile: Some contributors may not be in a time-rush and only want to write their conversion routines once and not come back in, say, March to add the few missing items that weren’t already in purple. As @tlmn said, why are we making limitations to ourselves, there is already enough of that in AEC :laughing: - shouldn’t this be flexible for both cases?

And in the case of section profiles that we were discussing above, in my view, this is purely expanding on the existing schema, not making any changes. I’m happy to discuss the naming of things, to me also “Stadium” doesn’t make sense until you see the profile. And all of these AdSec specific profile types are typical in the construction industry.

What do you suggest as a guideline for writing conversion routines for (temporary) stuff in the green layer? As an example, can I write a conversion now between my AdSec.Profile.Stadium object to Speckle.Objects.Structural.AdSec.Properties.Profiles.Stadium object and then expect this to be an easy rename of the namespace when we agree to add my green layer-specific object to purple? Or will I have to rewrite it (thus I’d rather wait)?

1 Like
16

The conversion routines won’t change whether it’s in the purple layer vs the green layer if it’s the same definition. The difference is whether every other program needs to incorporate that change into their conversion routines as well. By immediately pushing an item into the purple layer, we’re taking a stance that we believe the item is common/standardized enough that a majority of programs should support them. This again is a problem because maybe that isn’t truly the case. As @daviddekoning said:

. You’re always welcome to make a pull request so it can be discussed. Expanding/changing the schema is still adding more stuff to the purple layer which again needs to be discussed. Again everyone else kinda needs to agree on it first that these changes are common enough.

Even though they might be somewhat typical in the industry. They are not necessarily typical in the software right now. I just really need more evidence that these are supported in a lot of programs before reconsidering some of these sections. If you can show that to me , then we are good. (i.e more than just revit and one/two program)

Write it like you normally would. If your class definition is good enough, it will just be a simple rename of the namespace. There’s no guarantee that there won’t be any changes when the time comes, but it shouldn’t be a big change anyway. At least that’s hypothetical assuming that your class is written in a way similar to the rest of the classes and contains really standard/generic properties.

1 Like
17

Hey @Reynold_Chan.
I think the core of this discussion is whether or not everything is (eventually) allowed into the purple layer, and I think that what @daviddekoning meant was to avoid custom/green layer conversions.

_

I still do not understand the premise of keeping some stuff out of the purple layer (non-conflicting stuff that is, I get the point of a green layer to have unique ETABS and GSA material definitions)? @dtnaughton expressed a wish to keep the purple layer lean (which I also want of course), but I tried to argue that having it further down the pyramid might overall result in a more messy codebase (with a lot of “custom” green-to-green conversions).
Are there any obvious reasons for filtering that I just can’t see (I may very well be overseeing something and apologies for going on about this - I just want a good speckle structures schema like you all)?
_

Some thoughts on two examples we can perhaps explore?

  • Object unique to 1 program: Let’s say AdSec Stadium profile is only ever going to be defined in AdSec. What are the potential downsides of having it in the purple layer?

  • Rare Object used by only a few programs: Trapezoidal profile is defined in both Karamba and Adsec (maybe more). I would have to write conversion directly between custom green layer Speckle.AdSec.Trapezoid to custom green layer Speckle.Karamba.Trapeziod. The downside of not having it in purple is both who is responsible for writing these conversions (AdSec developer or Karamba developer?) and what happens when, say, Sofistik comes late to the party and also supports Trapezoid (do the AdSec and Karamba developer then need to keep an eye on other developers stuff in green layer?).

What would, in your view, be the threshold for something to be allowed in the purple layer?
_

As you can tell, I think that everything should (over time) be allowed in the purple layer as it makes it much easier to manage as an open-source project with (hopefully) many contributors - as long as things aren’t conflicting (material definitions is a different story than profile types) I think we should reasonably quickly (of course with a good discussion and proper consideration) allow content into the purple layer.

18

The green layer by definition exists as an extension of the fact that programs have unique features that aren’t supported by others again. I don’t think David meant we can avoid custom/green layer conversions completely. It’s inevitable that there will be some things that just are going to be hard to standardize.

The green layer is specifically meant for objects unique to one program. Having it in the purple layer as I’ve said requires other programs to support that instance as well. Meaning you should almost be writing most of the conversion routines to everything inside the purple layer for your program if you want interoperability with all the other structural programs.

Layers will be moved up and down as needed based on standardization. If it is found to be common, it will be moved up to purple layers to avoid these green to green conversions.

The pyramid again is not static and will be pending review. But there’s no harm in having it in the green layer first. If it’s found to be common, it will move up. Like David said, nothing goes directly into the purple layer without existing in the green layer first. If you’re worried about messy codebase because of writing conversion routines, let’s just go through this process first, and then I think you will see later down the line how common it might be, and then you can submit a PR and we’ll move it up. But just wait and see first okay? In terms of responsibility, no there’s no need for the person to write these explicit conversions unless they want to. They are responsible for everything being pulled into their own space and being sent out of their own space. I.e the adsec developer will write the karmaba to adsec conversion if they chose to, and the karamba developer will write the adsec to karmaba conversion if they chose to.

So I think this is probably where we might be misconstruing the intention of Speckle altogether. Speckle isn’t meant to replace IFC or be a kit in where we are just another extension of trying to define a schema that is better than IFC. Speckle is meant for you to have access to your data in a common data environment. The Speckle object. We support this by allowing people to write custom objects and custom kits. The pyramid supports people getting their data into the Speckleverse via the green layer/purple layer. Interoperability is one of the aspects of the schema, but it’s not the only aspect which is why not everything will be in the purple layer by definition. I’ve pointed out the case of the BREP in a rhino being sent to ETABS. This by definition doesn’t make sense. But by having access to your data in a more streamlined format, you now have the power to create workflows that didn’t exist before.

You need to get the rest of the community to agree these items are common enough across a lot of software, and that the definition is a good definition. My role is to facilitate these discussions more and approve them if I see enough sound support. Again we will have quarterly review of these with the community to revise classes.

I think we’ve both reiterated ourselves enough in regards to this pyramid. I will be ending this discussion in regards to the pyramid now. I think if you still have questions about the pyramid it’s best for you to discuss it internally with @daviddekoning.

19

Happy Saturday, gents! I feel like I’m having an out of body experience reading your guys discussing what I did or didn’t mean :slight_smile:

Rather than continuing to trade essays, why don’t we organize a call, hash all this out, then come back here with a clear way forward?

6 Likes
20

Hey all,
Call organized this Friday: 2021-11-12T13:00:00Z
Link to MS Teams meeting
Feel free to join if you have any interest!

1 Like