-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only one comment per viewpoint #35
Comments
It is a long standing wish to be able to refer to previous viewpoints in a comment: ISSUE
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. |
@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. |
@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. |
For what it's worth I agree with Matteo. 2014-07-24 16:33 GMT+02:00 Matteo Cominetti notifications@github.com:
Tomorrow's illiterate will not be the man who can't read; he will be the |
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". |
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?
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 |
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. |
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? |
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. 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 |
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 |
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. |
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. |
I personally don't see why a viewpoint should have multiple comments associated with it. This would lead to have different "discussions" within the same Issue, and some users might actually use the multiple viewpoints to create something like "nested issues", which is undesirable and creates confusion.
The structure of an issue should be linear like:
And not a three structure:
The text was updated successfully, but these errors were encountered: