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
What are your opinions about this?