Experimental branches under a different organization

[svelderrainruiz]

This issues spawns from a point brought out by Casey May on the icon editor standup, where he asked about the process of submitting code to experimental branches.

The current process NI has is not optimized for scalability, because Sergio needs to create experimental branches on a case by case basis, meaning that only NI resources can be approvers, this process is fine with the 2 repos we have, but it is highly coupled to Sergio being available.

We want the technical steering committees from each of the repos to create to be able to assign themselves as approvers. Sergio will figure out automating signing a Contributors License Agreements by using a "bot", as well as working internally at NI to understand the legal hurdles.

We would need for the AF Guild to create an org that will fork the Actor Framework repo from the NI org, this way the NI repository wont have any experimental branches, since they will now be controlled by the AF Guild.

[CaseyZS]

I'm happy to create an AF Guild organization for GitHub. I think there still needs to be a bit of discussion about the process from there:

• Does the AF Guild add individual contributors so they can push directly to branches?
• Does the AF Guild simply "host" the experimental branches that others create PRs against?
• Some hybrid?

But this is a great start and means that any code that gets a PR from the AF Guild fork to the NI repo will have already gone through some level of quality checks.

[CaseyZS]

The AF Guild fork can be found here:
https://github.com/AF-Guild/actor-framework

[svelderrainruiz]

Does the AF Guild add individual contributors so they can push directly to branches?

Yes. I recommend you make a team on github, and give rights to the team, that is what Tim did.

Does the AF Guild simply "host" the experimental branches that others create PRs against?

You have an organization hosting a fork of the NI Actor Framework repo, that you will have full control of.

[svelderrainruiz]

One concern that will come up is that i have a tracking workflow that backs up the repo metadata that normally gets deleted after 14 days. This metadata could be used to take data driven decisions by NI, which i will have to do a workaround.

[svelderrainruiz]

After careful review with the organizational steering committee, having an NI repo forked by an association of people for mutual aid or the pursuit of a common goal such as the AF Guild that funnels all contributions into the NI org did not align with the process we are constantly improving.

Our plan all along has been to use the first open source LabVIEW project (icon editor) as a way to create a process, and now that the actor framework is being done in parallel, please expect to see changes to the process or ideas for both since the AF has unique scenarios that the icon editor does not use.

We will soon make the process public, and i will create an alternative that will enable long-term experiments which will be clearly delimited on that process, this will not be specific to the AF, but to any LabVIEW feature that NI decides to open source.

[CaseyZS]

So now I'm still left with the question of how experimental branches will work with features that need different "levels" of implementation and extension.

I'm going to be away for most of this week but I'm definitely interested in hearing more about NI's proposed workflow in the coming weeks.

[svelderrainruiz]

Answering how experimental branches should be handled is tricky without first establishing a clear methodology that demonstrates adherence to quality controls and proven processes. This is essential to maintain confidence from both internal and external stakeholders, which is one of the main directives i was given, and especially important on our first attempt to open source parts of our codebase.

I don’t recommend using a high risk project such as the Actor Framework as a platform for experimenting with integrating features from long-lived branches, or enabling the AF Guild to manage themselves by having their own org in a way that can adapt to NI's processes while we are creating them. This is precisely why we selected a lower-risk project that is safe to experiment on such as the Icon Editor.

One of my priorities is to ensure the AF is ready for release by LV2025Q3 at the latest. While long-lived branches that deviate from the GitFlow model can sometimes be necessary for highly complex projects like this one, they are not essential for achieving the 2025Q3 release goal.

Based on this, i will recommend to NI to:

1 Manage the AF repository under the NI organization at least until the LV2025Q3 release.
2 Define a process for external subject matter experts appointed by @niACS to participate as approvers for feature branch merges into the development branch.
3 Use the Icon Editor project to refine guidelines and better understand potential limitations when working with community forks outside the NI organization.

It’s important that we don’t unintentionally block collaboration on features meant for long-lived branches due to an overly cautious approach. The AF Guild can continue working from a forked repository and keep us informed via GitHub issues. This will allow us to:

1 Clarify the different levels of implementation and extension.
2 Prioritize effectively by assigning tasks to relevant milestones, guided by @niACS.