Improving project setup for (external) contributions

[GwnDaan]

Hi! To optimize the current workflow of PR's and keep it neat, such that we prepare for more contributions in the future, I propose we change the following:

• Combine the workflow action cmake.yml and sonar.yml, since sonar.yml is only a extension on top of cmake.yml. They both build the stack and execute tests, and sonar does some analysis on top of that.
• SonarCloud analysis is not executed on PR's from external forks, this due to the sonar secret not accessible in it's workflow run. pull_request_target should be able to fix that (source)
• Secure secrets from abuse when using pull_request_target with environment protection rules (reference)
• Automatically assign reviewers to new PR's, this should be doable by defining so called 'code owners'

We also might wanna look into moving this repo to an organization profile, I see a few benefits for it:

• Use the name 'isobus++' for the organization which I think would result in more (google/github/etc.) search hits than only having ISO11773-CAN-Stack.
• Being able to extend to multiple projects in the future (e.g. VT server app, object pool creator, utility programs, etc.) while keeping it under the familiar name 'isobus++'. Which could also increase brand awareness if done right.
• Sounds to me like it's easier to manage permissions for contributors, though I'm not sure on this one

[ad3154]

One easy branding-win would be to rename the repo to isobus++ (or isobus-plus-plus if github doesn't allow '+'?). According to this https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository renaming the repo will not break access that is using the old name

[GwnDaan]

One easy branding-win would be to rename the repo to isobus++ (or isobus-plus-plus if github doesn't allow '+'?). According to this https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository renaming the repo will not break access that is using the old name

I agree with that! That would be a good first step I think.

[GwnDaan]

Most of the things related to this issue has been done in some way or another. Should we close this issue? The (rather vague) things mentioned which we haven't dealt with yet:

• Automatically assign reviewers to new PR's, this could be doable by defining so called 'code owners'
• moving the repo to an organization profile

I'd love to hear your thoughts

[ad3154]

Hmm, it does seem like an organization is the way most multi-repo projects (or large projects) do it. That would streamline things a fair bit I'd say. I can look into transferring this repo when I have some time. It seems like it will not break anything....

Code owners is a great feature. I can see it being useful for hardware plugin review especially

[GwnDaan]

Suggestion has been mostly completed, only thing left was adding the 'code owners' feature, but that won't really have much benefit for now with only a handful contributors. Hence I'm closing this issue