Only one comment per viewpoint

[buildingsmart]

Only one comment per viewpoint

[ErikPijnenburg]

It is a long standing wish to be able to refer to previous viewpoints in a comment:

ISSUE

• COMMENT 1 & VIEWPOINT-1
• COMMENT 2 & VIEWPOINT-2
• COMMENT 3
• COMMENT 4 & VIEWPOINT-1 (=reaction on viewpoint-1)
• COMMENT 5

The tree structure you describe is already the current case in Solibri. I think they are considering to change the presentation in the GUI into my example I just gave.

[pasi-paasiala]

@teocomi, in your first example, are there one or two viewpoints?

The reason we have multiple comments related to a viewpoint is that when an issue is discussed from different viewpoints it is good to make clear to which viewpoint a comment relates to.

[teocomi]

@pasi-paasiala I have updated my example since it was not clear. It is two different viewpoints.

I think people should be commenting on the issue and use viewpoints as a way to better explain what they refer to, instead than commenting on viewpoints. An issue should be a "single problem" that needs a resolution and not multiple problems grouped together in the form of viewpoints.

I understand the example from @ErikPijnenburg but having users commenting on different viewpoints (in this case different problems) from the same "thread" would just create a lot of confusion.

A simple solution to allow users to refer to a specific viewpoint is just to quote it in the comment body, no need to have "multiple comments per viewpoint".

I understand people have a different concepts of issue and use different workflows, but in my opinion this would be a better implementation.

[DuncanLithgow]

For what it's worth I agree with Matteo.

2014-07-24 16:33 GMT+02:00 Matteo Cominetti [email protected]:

@pasi-paasiala https://github.com/pasi-paasiala I have updated my
example since it was not clear. It is two different viewpoints.

I think people should be commenting on the issue and use viewpoints as a
way to better explain what they refer to, instead than commenting on
viewpoints. An issue should be a "single problem" that needs a resolution
and not multiple problems grouped together in the form of viewpoints.

I understand the example from @ErikPijnenburg
https://github.com/ErikPijnenburg but having users commenting on
different viewpoints (in this case different problems) from the same
"thread" would just create a lot of confusion.

A simple solution to allow users to refer to a specific viewpoint is just
to quote it in the comment body, no need to have "multiple comments per
viewpoint".

I understand people have a different concepts of issue and use different
workflows, but in my opinion this would be a better implementation.

—
Reply to this email directly or view it on GitHub
#35 (comment).

Tomorrow's illiterate will not be the man who can't read; he will be the
man who has not learned how to learn - Alvin Toffler

https://trustcloud.com/!/duncan.lithgow

[ErikPijnenburg]

I agree with Matteo they we should prevent having sub-discusions about viewpoints and that people should be commenting the "issue" instead of viewpoints. I am not arguing to have viewpoints to describe different problems in the same issue. And I also think that the current tree-like GUI in Solibri where you can have different comment-threads per viewpoint is not good. The comment-history should be leading in a GUI (just like here in git-hub).

But I do not agree to change the definition. It is very handy to have a more formal/structured way to reference to viewpoints to explain what you mean then to reference in the text with things like "the 3rd viewpoint" or "the viewpoint added by "name" on "date".

[gschleusner]

We are seeing a need for multiple issues per vieport so much so that the viewpoint itself isn't our primary focus as we are just looking for a way to quickly generate and then move the issues to the authoring tool.

So the workflow that we are developing is primarily based on the way Solbri handles the creation of issues so I'll let you decide if Solibri or BCF needs to change. I think both.

What we are doing is having team members take all the results from a particular check and make a slide at the second most granular level....IE not at the individual issue, but at the issues of that type per floor as example. We are doing this because they are all the same class of issue and we won't know what actually needs to happen until we get back to Revit and actually try to make the change.

Once they create the multi- element slide they then export a BCF per slide so one issue has a bunch of elements in it, but not very well related to one another because the issue "2nd Floor BEAM - Duct Clashes.BCFZIP' for example is specific but general.

We don't find it valuable to review the issues until we get into the software you can actually change them so we really want to have a bigger bucket for a type of issue but still be able to maintain "sub-issues" under one slide so we don't loose the connectivity between the "this duct and this beam".

So what am I asking for?

1. Solibri Change - When creating a slide from multiple checking results the slide should contain not only the elements in the results, but also the element to element relationships. Solibri could then export them as one or multiple issues. This would technically solve the problem but still create more work in closing all the issues.
2. BCF support a linkage between IDS in an individual issue so it can support a logical connection between the elements and create sub-issues per slide.
3. Expand on #2 in the future to support "Nouns and Verbs" that could be treated differently in downstream workflows. So in the future if Solibri or other tools were to associate a result and an action with a rule set we could leverage it in different ways automatically. That would translate into the BCF as logic strings like. Elem#1 Clashes with Elem#2...., or Elem#15 fails Check#15... This would enable a workflow that can be less reliant on people having to comment on each issue and being able to treat them as a class of similar issues. Having them all as generic issues isn't always that useful and there is no way to determine importance or priority outside of the issue name.

This workflow i'm describing is focused on Design coordination and not construction coordination where we have to be litigious about individual issues because there is going to be a construction sign off.

Our needs are to address larger buckets of issues because it might represent a wholesale change to the design and not one off changes.

I hope this makes sense.

Greg

[gschleusner]

Another way of thinking about what I'm suggesting is that for things that need to be fixed we should get the most out of the tools as possible. IE not introduce manual commenting processes when the computer has the ability to find, convey and communicate directly between tools. The only scenario that a person should have to intervene in the process of communicating issues is when the computer thinks something is wrong and the human needs to tell it, it isn’t, so it doesn't continuously show as an issue, or there is an individual issue that actually results in a design question.

Having to make a slide and issue per issue is adding unnecessary overhead to that communication. If there are 50 beam - duct intersections because the beams don't have beam penetrations in them my instruction to the structural engineer should be as simple as "Put beam pens in these beams" , if there then is a need to break out those 50 into 45 which are straight forward and the 5 that are actually design questions that that should be possible.

[ErikPijnenburg]

Greg, you touched a fundamental challenge with issue management. When you have related issues which could be solved all by one good central solution this challenge of automatic or manual 'grouping' or 'combining' of issues arises. Let's see if that influences BCF 2.0 definition or that this should be solved by new functionality in the BIM software.

Model-checking or clash-detection software could become smarter to recognize related issues automatically and combine them into one issue or create a group of issues. But at least offer functionality to do this manually: probably we need somebody to judge the situation and decide if we want to create one or more issues. Example: combine several clashes into one issue (a duct running thought multiple beams): all related elements could be included in the viewpoint. BCF 2.0 supports this.

BCF 2.0 also contains a possibility to define relations between issues. That could be used to group issues, Furthermore also here we need extra functionality in the checking software to make use of this functionality. The issue management software could offer functionality like ways to comment, resolve or close grouped issues at once. No need to change BCF 2.0 neither.

So I think you have set a challenge for the BIM software developers to offer smarter functionality to make use of the potential of BCF 2.0. Do you agree this has not much influence on the BCF 2.0 definition?

[gschleusner]

I agree with most points, but the one request I think would be valuable in the BCF itself is providing a more precise method of describing the interconnection between components in issues. To your point Solibri does a pretty good job of grouping issues automatically and provides a mechanism to manually add items to automatically defined issues.
If I was going to implement a change to keep backward compatibility and to allow tool to not have this level of granularity if it wasn't supported I'd add a file that held component level connections between items in one or more issues.

Like so;

This way the issues could be treated as large or small as the team wanted but still know "component 1 and component 2" actually intersection one another. So the issues could match the connections or an issue could encompass multiple "connections".

Greg

[gschleusner]

This approach would also allow more and more logic to be transferred between the two softwares without a person having to re-interpret the kind of item. It could include things like severity, a formal issue type like "Code, Clash, ..." or others as there began to be some agreement on functional terms.

Greg

[pasi-paasiala]

If there's a systematic error, for example, ceilings are at a wrong level and all mechanical components intersect with them, then that error should be reported. This is what we try to do in Solibri Model Checker by grouping issues together. To BCF only one topic should be created, since fixing the ceiling elevation should fix all these intersections. The individual intersections are then irrelevant, since they all should be fixed when the elevations are corrected.

[gschleusner]

My issue with this approach is assumes that it makes sense to group/sort and define the issues in the software were you found them only. That results in the BCF not transferring enough logic to make changes downstream when working through the issues. in your example...maybe the large majority of ceilings can be moved, but 5 require a mech. redesign. The BCF should have the logic in it to break out those five issues per the "connections" to make a new issues out of those. In the current BCF can't transfer that info correctly.

It doesn't seem appropriate to assume that there are only two workflows.