Hi everybody,
Below I tried to explain my idea (and ideals) about version control and I hope it’s clear what I mean, and what I think is needed in terms of addition to Speckle 
. (I searched around the forum for a similar topic but i couldn’t find anything this specific).
I’d like to be able to use version control in the Speckle environment to keep track of which version each commit is, for example P00.01, P00.02, P01, P01.01, etc.
I think that this is needed to be able to easiliy communicatie about different versions and to ultimately split WIP information from SHARED information.
In order to use this I think three parts are needed:
- Different roles in the Speckle environment, to control edit and read permissions, for example split into multiple Task Teams, where users can be assigned to.
- A metadata attribute to my Speckle commit to indicate what version it is, and also what information state the information is, based on the ISO 19650-Series.
- The ability to link different commits together to indicate that they are about the same information, but a different version (or is that the entire branch?).
At the moment I created four commits to my “ontwerpuitgangspunten” (design principles) stream and named them by hand: P00.01, P00.02, P00.03, P01. See my snippet below:
In my final “solution” i would like to have the possibility to (automatically) add metadata values such as my version and the corresponding information state (WIP, SHARED, PUBLISHED or ARCHIVED) to manage the read and write permissions for each commit.
I wouldn’t know if one should program this themselves or if it could be implemented across Speckle as a whole, but this is my first step in this process 
Kind Regards,
Daan
4 Likes
Hi @DaanSchlosser, this is very good feedback! We are still mulling on how implementing this would work best. We’re really excited about this kind of feedback, so keep it coming!
@simplynail had another related suggestion some time ago: Cross-stream commit binder. I’m definitively in favour of linking different commits together. @izzylys & @clrkng’s recent work on stream globals opens up some nice avenues in this direction - merging them into one parent commit could be quite easy to enable, albeit connectors will need to be able to easily just request specific sub-objects only (currently only gh and dynamo allow for this fully).
We’re thinking that commit labels (metadata) might be an option. Another way I was thinking that can integrate nicely with a new permissions role is something on the lines of Releases and an associated “Release Request” process. We can create a new role, let’s call it stream:coordinator which would sit in between owners and contributors, and that would have the required permissions to create and approve releases.
I’m quite excited. This will definitively make its way in a next sprint sometime soon!
1 Like
Hi @dimitrie (and also @teocomi & @izzylys ),
Glad to hear that you guys also like the idea!
However i don’t fully agree with you about the roles within Speckle. I think that the Owner of a Stream should be able to create roles theirselves and assign users to these specific roles with their respective read & write permissions (i.e. how Discord did this).
PS: I 100% agree with you about the other topics in this idea.
Can you describe this a bit more? You mentioned task teams earlier, but i don’t really fully understand it.
Our current roles allow for just that (full ownership, read and write data, read only).
Absolutely!
For context: This idea has emerged from my Bachelor Thesis research regarding the ideal Common Data Environment (CDE). For this specific topic i based my choices/ preferences on the ISO 19650-Series, especially the Guidance Part C created by UK BIM Framework:Guidance Part C (Quite an interesting read btw).
Many different concepts are described in the ISO 19650-Series, but for this topic the separation between WIP and SHARED, in combination with the Task Teams is the most important.
And in answer to your question about what a Task Team is/ contains:
It can be a projectdiscipline (as a team), or combinations between disciplines (as a team). Basically just a small team that makes a specific design component, for example a structural model. Each Task Team also has a Task Team Leader who is responsible for issuing information from (for example) WIP to SHARED.
And information inside this WIP-environment, for example a Speckle branch, should only be accesible by this Task Team to read and write in, other Task Teams should NOT be able to see this branch at all. In addition, the SHARED-environment is read-only for each projectmember regardless of their Task Team/ Role. The only people who can manage information in this SHARED-environment are the Task Team Leaders (and then only their own information).
So to be able to manage read and write parameters for individual Streams/ Task Teams, Steam Owners should be able to manage these theirselves.
1 Like
Okay, I understand it now. Forcing one collaborative pattern over another is ultimately detrimental to making data move faster across AEC stakeholders, and this is something I’ve argued against in my PhD.
Different design stages will require different approaches: for example, in early stages you don’t need to have a manager approving anything - you’re just sketching. Everything is WIP. There’s no need for any formal process. It’s actually also the key stage where you’d want feedback from others as the decisions made here have huge implications later down the line. The less red tape, the better.
Later stages would require a more rigorous approach to sharing data, but again there’s no one process to rule them all. Our goal is to allow multiple patterns to emerge and evolve - similar to how there’s no one way to work with git (e.g, theres TBD, Gitflow, and possibly more). There’s also various release cycle patterns - e.g., Node “cuts” a release every X time, there’s semver, etc.
IMHO, this is a productive conversation that forces us to think what we will enable and how regarding releases. There’s a lot development legwork behind everything you see in Speckle, and we need to quite smart about what we do, why and how (we’re six full time people fighting a bunch of giant monopolies here…).
Custom user defined roles a la Discord can add a lot of overhead (product complexity as well as dev work). We usually reply to opinions strongly expressed in this manner with “PRs are open, why don’t you go ahead and implement something?” - we’d be very curious to see how that would look like!
1 Like
The more I think about it and read different use cases from different people (also mine), to develop further my earlier shared idea on “cross-stream binder”
personally I think the most flexible (and therefore potentially able to satisfy many users) would be possibility to tag commits and then query Speckle GRAPHQL with tag filter applied (you filter by tag_id or “tag text contains” and it could return i.e dict(stream id)=commit_id).
Also to add some convinience endpoints (sorry I know they are called differently in GRAPHQL, but I guess you know what I mean): get all tags for the project, (…)
Speckle Frontend/admin would ideally suggest tags already used in the project when assigning the tag to avoid duplicates(sounds obvious but not always the case in apps:) )
If required later I guess this could be a good base for next (more specific) inbuilt functuonalities (ie internally Speckle could have some “service tags” normally not displayed/editable to the user, but used for Speckle engine purposes)
1 Like
I hadn’t thought about it that way! As soon as I have some more time I’ll try to develop something myself .
