Add initial PR for Contributing & Coding Standard

[MickLesk]

✍️ Description

• remove old contributing.md

• add new contributing.md

• First Draft, added some functionality and descriptions later

• Every @community-scripts/contributor are welcome to improve this PR

---

🛠️ Type of Change

Please check the relevant options:

• Bug fix (non-breaking change that resolves an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change unexpectedly)
• New script (a fully functional and thoroughly tested script or set of scripts)

---

✅ Prerequisites

The following steps must be completed for the pull request to be considered:

• Self-review performed (I have reviewed my code to ensure it follows established patterns and conventions.)
• Testing performed (I have thoroughly tested my changes and verified expected functionality.)
• Documentation updated (I have updated any relevant documentation)

---

📋 Additional Information (optional)

Provide any extra context or screenshots about the feature or fix here.

[michelroegl-brunner]

@se-bastiaan @andygrunwald Thank you to the both of you for investing time to read and improve these documents. I highly appreciate it! Some changes i have allready commited, i change the other things around in a few days when the holdays are over and íve got more sparetime. You are welcome to contribute and open a Pull Reqest against the contributer_guide branch if you have any more improvements/changes.

[andygrunwald]

I like the idea to start a new script from a template.
Why not going all in and providing the CLI commands for this?

If you plan to implement a new application script, use our templates to get a kickstart:

$ NEW_APP_NAME="my-script"
$ cp ct/AppName.sh ct/${NEW_APP_NAME}.sh
$ cp ...
$ sed ... (some git remote -v magic to get the fork path)

This way, folks can just copy / paste the commands and get going.

Additionally: Considering the CONTIRBUTING.md is the entry doc, this is the first time it is mentioned that we operate on a fork.
Maybe it is better to move this chapter to a

Guide: Create your own App Script

which starts with

1. Fork this Repository
2. Kickstart your app with your template
3. ...

[michelroegl-brunner]

There has been a proposal by @quantumryuu for this already, have a look here: https://github.com/community-scripts/ProxmoxVE/tree/new_script_testing/.github/CONTRIBUTOR_GUIDE/dev-scripts
I will start testing, experementing with this when the hollidays are over.

I also would love to have something simillar to this for Appname.sh and AppName-install.sh

[quantumryuu]

About the AppName.sh/AppName-install.sh we could modify the scripts I proposed into asking things like "Author", "Source", "AppName" I guess.

[andygrunwald]

Here i am a bit lost. Where do I start now to build my own script? Here or with the template of ct/AppName.sh and install/AppName-install.sh?

[andygrunwald]

Whats the purpose of this chapter?
What goes in here? What does not go in here?

I think all relevant pages are linked above in the respective context. I am suggesting to drop this chapter.

[quantumryuu]

As a general comment I think that it would be a good idea to enforce some of the rules using GitHub Actions workflows. I have seen that https://github.com/community-scripts/ProxmoxVE/blob/main/.github/check-script.yml exists, but it is not in the right folder so it will not be used.

It should be possible to programmatically check for rules that are set in the contributing guide. That script is already a good start. I would suggest splitting up the checks in steps and using an action to comment the results in the PR so that it is easy for people to understand why their pipelines are not passing.

So taken from the list in the markdown files and that script:

* Check if the Shebang is correctly set (`#!/usr/bin/env bash`) (already in the existing unused workflow)

* Correct link to _build.func_ (already in the existing unused workflow)

* Check for executable permissions (already in the existing unused workflow)

* Check for empty lines at the top (already in the existing unused workflow)

* Metadata (author, license) is included at the top.

* Variables follow naming conventions. (if possible somehow)

* Check if the update function exists.

* Run ShellCheck (already done)

* Run shfmt (this is what the vs code plugin uses under the hood): https://github.com/mvdan/sh#shfmt

By running all these checks a PR reviewer can be certain that the PR conforms to the basic guidelines. Without passing pipelines you don't need to review (although you may want to put that in the PR template and contributing guide so that people do no expect reviews for failing PRs)

About the Metadata (author, license) is included at the top. I created a workflow and tested it, can do a PR so the team can test it too!
It checks if these lines exist though, could probably incorporate that these lines exist on the top.

• # Copyright (c) 2021-2024 community-scripts ORG
• # License: MIT | https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE
• # Author: [Name] (also checks if there is text after the space"
• # Source: [Source] (also checks if there is text after the space"

@michelroegl-brunner if you're ok with the idea, shall I open a PR?

@se-bastiaan about the Variables follow naming conventions. (if possible somehow). Care to give some examples? All I can think of for a check could be the mysql setup probably (DB_NAME, DB_USER, DB_PASS).

[se-bastiaan]

@se-bastiaan about the Variables follow naming conventions. (if possible somehow). Care to give some examples? All I can think of for a check could be the mysql setup probably (DB_NAME, DB_USER, DB_PASS).

I really don't know what the examples would be, I've mostly read this contribution guide and according to the docs there would be a difference, I just don't know what they would be. However, to me this is the least important workflow that could exist.

I'm looking into creating a shfmt workflow however. There seem to be quite some actions available but none of them are very well maintained.

[quantumryuu]

Relevant PR for the metadata check is up with all the required checks (text & lines)

[MickLesk]

Reminder for me:

• add, that the CT and Install names must be declared in lowcase. F.e. google.sh and google-install.sh

[quantumryuu]

Reminder for me:

* add, that the CT and Install names must be declared in lowcase. F.e. google.sh and google-install.sh

@MickLesk should I create a workflow check for the lowercase files?

[MickLesk]

Reminder for me:

* add, that the CT and Install names must be declared in lowcase. F.e. google.sh and google-install.sh

@MickLesk should I create a workflow check for the lowercase files?

Yes you can do

[MickLesk]

We merge the actual state of PR, For now, we have something on which we can build further PRs