What are the contribution rules for this project?

[niACS]

I'd like to start the discussion on rules for code contributors to this project.

I believe our first rule should be "Do not introduce a change in existing AF behavior that will break existing systems."

We might someday allow exceptions, but they should be both extremely rare and of very high value. And not at all for our first few iterations.

Discuss.

[svelderrainruiz]

This is something i am responsible for and haven't finished, i have not been able to do this since the original intention for this initiative was to create the process by using the Icon Editor as a low risk playground to generate this process, and using that process for the rest of the open source initiatives.

Thank you for creating this discussion @niACS, i will be using the comments from this discussion to speed up creating this document.

[CaseyZS]

Are we talking more about rules for code functionality or the mechanics of how to contribute? Seems like guidelines for both are useful, though not necessarily in the same spot.

To Allen's original point, I agree with that first rule. Any PR that violates that would just be dismissed out of hand?

[svelderrainruiz]

To Allen's original point, I agree with that first rule. Any PR that violates that would just be dismissed out of hand?

I second this point.

I am wrapping up a draft on how external contributors can collaborate to our code base, putting here the part of the PR, but keep in mind this is subject to changes based on the feedback i am actively receiving from the subject matter experts i am consulting with:

1.- Changes to code meant to be a part of our codebase begins as a GitHub issue.
2.- The GitHub issue can be a new feature, bug, etc.
3.- When the subject matter expert (in this case @niACS and his team) determines that this is something we want to include on our next LabVIEW release, NI creates a feature branch assigned to that GitHub issue.
4.- Collaborators fork the repo, and work on the feature.
5.- When finished, a pull request is made and approve by subject matter experts.
6.- Once approved, the CI layer will decide if the pull request is accepted onto the feature branch.
7.- Merging from feature branch to develop is fully automated, and requires a more thorough CI layer.

I will rely heavily on subject matter experts to manually approve the pull request, however, i will create the infrastructure to ensure you can automate certain tasks that will make your life easier, but i will need subject matter experts help me identify which ones they are.

Some things i can automate on the repo that i believe could be handy are:

1.- Automating building the AF package and adding it as repo artifacts, this to eliminate human error.
2.- Having a set of very old and very new AF based LabVIEW projects, that i can use to create a unit test that ensures they are not being broken after installing the newly release VI package.

These unit tests can be available for external contributors to run on NI infrastructure when they try to submit a pull request.

[niACS]

Also, at this time, contributions are in LabVIEW 2020 SP1, which is the earliest version that cleanly supports interfaces in AF. (Straight 2020 had a couple of bugs.)