[BlenderBIM] development roadmap dashboard

edited June 2022 in General

@duncan moved this discussion here. The original poster is @Nigel

After reading your previous post I was thinking about BlenderBIM, there are so many simultaneous work streams, and I thought of a 'dashboard' showing status and what was currently needed to progress. something like this maybe?

It is just a 'sketch' of the idea however it would be a public and visual call to the willing and capable coders and creatives amongst us

magicalcloud_75Coen

Comments

  • Maybe you could visualize all the git commits in the different branches/repos with a Google Gannt chart?

    Nigel
  • @Coen & @Nigel we support free/libre software here at OSArch because we believe that you own your data and should be the only person to decide what happens to it. That also means we would typically avoid Google products since most of them do not respect your privacy or digital sovereignty.

  • @duncan said:
    @Coen & @Nigel we support free/libre software here at OSArch because we believe that you own your data and should be the only person to decide what happens to it. That also means we would typically avoid Google products since most of them do not respect your privacy or digital sovereignty.

    Yes, I agree, there must be something in the FOSS world that can do the trick? or is that a project new :)

  • @duncan said:
    @Coen & @Nigel we support free/libre software here at OSArch because we believe that you own your data and should be the only person to decide what happens to it. That also means we would typically avoid Google products since most of them do not respect your privacy or digital sovereignty.

    Good point, I looked into it and found this
    https://stackoverflow.com/questions/5311704/is-data-sent-to-google-when-using-the-google-visualisation-api

    They have some very nice charts free of use
    https://developers.google.com/chart

    But if there is a FOSS option I would also use this :-)

    Anyway, how would one measure the progress in certain fields of the BlenderBIM add-on, for me, it's not very clear.. I sometimes look at the git commit history and have no idea what I'm looking at and what is being developed. Also what is being prioritized.

  • I suggest a manual evaluation with each (or most) release(s) against a roadmap. Anything else is too complex and wouldn't reflect real-world experience. But this is a discussion to have with someone who knows the roadmap, the repository and the code well - @Moult

  • I've been wondering if BBIM should be descriptively split into the distinct functions it has. Then each of those could be manually versioned. while they still have dates as versions though we should remember that they are alpha and the focus is on developing them - not describing them. But as I understand it some functions are quite stable and should maybe be pushed up to a beta status. Keeping the whole of BBIM as alpha software doesn't really reflect the reality of the bredth of functions. It will be many years before they all come out of alpha, so maybe some more finegrained versioning could be useful. I have no idea this is right, possible or worth the effort, but it's a thought I've now had a number of times. I want to be able to tell people "you can use BBIM for this 1.xx.xx function since that is regarded as stable, 0.1.xx is til beta - just don't invest too much effort learning all the 0.0.xx functions" Does this make sense @Moult ? I feel it would help push adoption.

    Coen
  • I do have the plan to more categorically document the features. See this mockup https://github.com/IfcOpenShell/website/issues/2#issuecomment-1134243056 - where there are 8 broad categories of functionality:

    Within these 8 categories there would undoubtedly be subusecases within them. Like Audit and analyse is a big topic, covering BCF, clashes, CSV extracts, regular geometric viewing, properties and relationships, IDS, etc. Authoring is a huge thing by itself, including libraries, parametric geometry, type instancing, editing properties, etc etc it's huge. You get the idea.

    I feel the best way to show that a feature has matured is that you can start writing docs for it. For example, simple IFC exploration is now mature, I'd say. Quite confidently you can throw any IFC at it and it'll just work and you can explore: https://blenderbim.org/docs/users/exploring_an_ifc_model.html . Checking and correcting georeferencing is another mature feature: https://blenderbim.org/docs/users/georeferencing.html - I use it on every single project at work to ensure coordinates are correct.

    In short: if you think a function is mature, let's write docs for it.

    paulleetlangGorgiousNigelAceCadGiruJesusbillCoenbitacovir
  • @Moult said:
    I do have the plan to more categorically document the features. See this mockup https://github.com/IfcOpenShell/website/issues/2#issuecomment-1134243056 - where there are 8 broad categories of functionality:

    Within these 8 categories there would undoubtedly be subusecases within them. Like Audit and analyse is a big topic, covering BCF, clashes, CSV extracts, regular geometric viewing, properties and relationships, IDS, etc. Authoring is a huge thing by itself, including libraries, parametric geometry, type instancing, editing properties, etc etc it's huge. You get the idea.

    I feel the best way to show that a feature has matured is that you can start writing docs for it. For example, simple IFC exploration is now mature, I'd say. Quite confidently you can throw any IFC at it and it'll just work and you can explore: https://blenderbim.org/docs/users/exploring_an_ifc_model.html . Checking and correcting georeferencing is another mature feature: https://blenderbim.org/docs/users/georeferencing.html - I use it on every single project at work to ensure coordinates are correct.

    In short: if you think a function is mature, let's write docs for it.

    This makes sense. In recommending the software one could therefore say xyz is matured and useful for real life project deployment

    Nigel
  • edited July 2022

    @Moult said:
    I feel the best way to show that a feature has matured is that you can start writing docs for it. ... In short: if you think a function is mature, let's write docs for it.

    I'm not sure this really addresses the issue I have which is more about pushing the software in an organization even thought I personally am not the expert. What I'm looking for is not so much 'is it documented' (ie. popular and active) but rather 'is it stable'. It may be that the basic stable functions don't get documentation because the people who use them don't feel a need to describe functions they regard as easy and obvious to use. Avoiding this problem would requiring a documentation team to watch the forums for what people are asking about - so maybe that's a focus the project needs along with the eight others. Either way I would support thinking about a more fine grained versioning system for the existing clusters of functionality.

Sign In or Register to comment.