Speckle projects! I’m excited to see you are planning to add support for “projects”, especially since it is a long requested feature! A lot of people around me have been asking about it: “Where are the projects from V1?”. We have developed a pragmatic workaround, but a proper integrated solution would be a major improvement and seriously enhance maturity of Speckle, at least from a corporate point of view.
The main features that I think would be great to see in projects:
Store fixed project information
Multiple project owners can add users and streams to a project
Project overview page (easy to find project streams and collaborators)
Additional brain dump
Additional brain dump for other features for further defining and scoping:
When comments are further enhanced, have a comments overview page to see which comments are urgent and not yet solved
Set federated model views (select which commits to overlay in the viewer, ideally from multiple streams)
In the project, maybe show a table with certain commits and an assigned status (wip / delivered, date x / stage 1 / etc.)
Maybe differentiate between a WIP project page for the team and a client project page so the project owners can define which streams or up to which commits a client can see?
Okay I’ll stop now…
Pragmatic workaround
The good old wd40 and duct tape. We’ve developed a separate web app as a workaround for Speckle projects. The user can select a project from our internal project database. This will present an overview page where you can see the streams “assigned” to the project and the Speckle accounts including their collaboration role. The user can add an existing stream or create a new one. The project data is populated in the globals branch of the stream (we have set default globals on our Speckle server). The project number and project name are retrieved from the project database + optionally users can define: region, office and discipline, which are also selected from the options present in the project database.
What do others think about projects? @pieter and @MdeLeur could you maybe share your current thoughts on projects?
In the project, maybe show a table with certain commits and an assigned status (wip / delivered, date x / stage 1 / etc.)
As Speckle is an object-oriented database, maybe more interesting to do an object-oriented status. Not per stream/document, but really on objects. and track when changes to the objects are made, so statusses can be automatically reverted. I have some workflows for this already and we have developed an IFC-based tool for this. I will check if I am allowed to share this info.
additional: definitely workflows to get information approved through the project (either on stream lvl or on object lvl)
Also very cool to have is a functionality which automatically enforces identity data on the objects that are going through a stream (either based on mapping, or adding them as ‘empty’ to objects with no data at all
And a mapping table for the different properties through different software. e.g. in civil3d propertysets and their properties are declared differently than in Revit and multiple properties can exist along eachother. Within a property you can define a mapping definition: which propertyset/property is used for what parameter in the other software.
At my studio (which is a fairly large Architectural Office), we are working on our own Project system, using some Speckle Infra as the communication layer for an App that control almost everything (from Rhino/Grasshopper modifications, Revit Extraction Data to the General Data/Parameters of each Project). Since, usually projects gets huge (and have a long duration) so we focus more in enforcing certain rules to the end users to comply with (Like commits and branch names must have a certain pattern, because other tools required them to be that specific pattern).
We are experimenting with categories of branches which allow us to quickly understand where are the studies, permanent things and the archive elements. This created a mess in terms of the amount of branches each project had, so a branch and sub branch system was created. We have three layers of data that allow us to organize each stream. In addition we are working in a back-end system that cleans things and report the “health” of each branch. Same things goes for inside each branch. This give us the flexibility to move things in a fast pace while still being able to track and know where everything is.
This allow us to have Speckle as a support of our workflow and not the other way around. For me this is, by far, one of the qualities that Speckle is better than anything else out there.
I think this kinda systems works better for smaller studios, where the workflow is more flexible and could use a certain system. The first diagram @Dickels112 has a lot of similarities with the architecture we are thinking of in terms of the system.
We still are counting on having a 3d model software for federating the geometry (Depending on which phase and scale the project is, could be Rhino with worksessions or Revit), and the in house tool to keep the data federated in real time, across all the tools. One of our branches should be allocated to federating some elements for specific stakeholders, so we can display the things that are relevant specifically to them.
So, going further, if the first image ‘federation stream’ would be replaced with e.g. ‘Navisworks’ (I know navis connector can only send atm) it is quite similar then?
In general terms yes! We do use streams as projects and branches with sub branches as what you have as stream and branches. Mostly for flexibility purposes.
To be honest the biggest Flaw I see is that it can get fairly easy to have an unworkable amount of branches (that’s why we are working on this backend cleaning, health status and additional levels of organization for them). I would say that’s the cost of having something flexible.
Once again, I did some thinking about the ‘speckle projects’, now starting from the commits, and I came up with a new scenario, keeping in mind the ISO19650 as well. (This is going to be a long entry, sorry. TLDR in the end of the post)
In my opinion ISO19650 roughly states the following (keeping this in lame-man’s terms):
Each information container contains an identifier providing the user insight in what use the information is suited for. Each suitability change might imply a status change as well
Each (set of) information container(s) can have a ‘Status’ assigned to it, allowing it to be visible to one or more parties. In which:
‘WIP’ status allows only insight within the team itself (task team)
‘Shared’ status allows insight between teams, within the contract, where the information container has no contractual status. (Delivery team)
‘Published’ is the status where the client has accepted the information and distributes it within all parties of the contract as ’contractual information’ (project team)
So in general, a ‘suitability’ value is just a more specified identifier of the ‘Status’.
Next, looking at the commits on Speckle, I identified the following:
Commits are unique within streams and thus within server
Access to commits is now based on ‘Stream access’ allowing the following states:
Manage (full control)
View+Edit (branching, commit, objects)
Review (view + download + comment)
Speckle already tracks recipient receipts, identifying who is pulling what from the commit
Knowing this, it we can state:
1 team should only work on 1 stream at the same time
Rights are assigned by stream admin
Teams are only allowed to edit their own information
Information needed from other teams:
Needs to be included in the stream
Thus is ‘borrowed’
Can only be used once authorized by the other team
Information needed by other teams
Needs to be included in other streams,
Thus is ‘Shared’
Can only be used once authorized by its team
Let’s say each team itself works on 1 stream, as it is only allowed to edit its own information.
In my opinion now we have most of the ingredients to create proper collaborations, but we miss some pepper and salt
To me, it makes sense to add a status to a commit itself, since this is an information container, and the information container is distributed through the stream
Next, a ‘stream group’ can be created, which identifies which streams can communicate together.
Based on the ‘stream group’ we can automatically create a read-only branch for the main branch of each other stream in the ‘stream group’
Then, each commit has by default the status WIP/S0, until a point is reached for it to allow sharing. After review, the status of a commit can be changed to ‘Shared’/suitability changed to a value that triggers this merge. This commit will then be merged to the Main branch, and the ‘Main’ will thus represent the latest shared state of the design of a stream.
Next, other parties can ‘borrow’ the commits on the ‘Main branch’ which are automatically connected. (‘Guest/triage’ role is not defined)
Events can be triggered, notifying the team on a new version of the main
Comments on the WIP branch will stay on that branch, only comments created on the ‘main’ branches will be communicated
This will allow everyone to work on the Single source of truth of different branches, ánd warrant ownership of the information by the teams.
_
This gives us a lot of opportunities
Creating stream groups, allows you to have group policies on the group as well
Within one speckle project, multiple stream groups can be created, giving you the opportunity to only group the parties that should communicate together.
Using the ‘Diff’ tool, other parties can see the changes on the borrowed commits as well.
Using recepient receipts, coordination is better as you can see whether the correct version is used
TLDR:
Combine streams based creating Stream Groups
Connect main branches of streams in Stream groups together (kind-of like Forking) to allow borrowing of main branch by other teams
using suitability on a commit to identify status and thus if it can be shared> merge on Main branch
but I have a plane to catch 
