starred/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-02-05 00:29:55 +03:00
Code Issues 12 Packages Projects Releases 10 Wiki Activity

Add a contributions guideline document #591

New Issue
Closed
opened 2026-02-04 20:12:10 +03:00 by OVERLORD · 5 comments
OVERLORD commented 2026-02-04 20:12:10 +03:00
Owner
Copy Link

Originally created by @Starttoaster on GitHub (Mar 5, 2025).

🌟 Briefly describe the feature

Add a contributions guideline document

📝 Detailed description

When I look at an open source project for the first time, I look for a few things:

  • A history of solid activity implying active maintainership
  • Open Issues/Pull Requests
  • Commit activity on the trunk branch
  • How to contribute

I look at all of these things to get a lay of the land. It helps answer a few questions like "is this worth using", "is this worth contributing to", and "how do I contribute?"

When going through my normal checks, I noticed several commits in the trunk branch that reference a pull request... And then I began noticing several that didn't. I then looked for a contributions guide, and found there wasn't one. So I'm confused on what guidelines to follow if I were to contribute, but also how maintainers contribute.

Here's one such commit that appears as though it was put directly on main: 367dc0d78f

💡 Why is this useful?

A contributions guide gives a form of loose SLA on how contributions should be submitted, and under what conditions might they be accepted, and is something to point to when holding people accountable for going outside of those bounds.

Originally created by @Starttoaster on GitHub (Mar 5, 2025). ### 🌟 Briefly describe the feature Add a contributions guideline document ### 📝 Detailed description When I look at an open source project for the first time, I look for a few things: * A history of solid activity implying active maintainership * Open Issues/Pull Requests * Commit activity on the trunk branch * How to contribute I look at all of these things to get a lay of the land. It helps answer a few questions like "is this worth using", "is this worth contributing to", and "how do I contribute?" When going through my normal checks, I noticed several commits in the trunk branch that reference a pull request... And then I began noticing several that didn't. I then looked for a contributions guide, and found there wasn't one. So I'm confused on what guidelines to follow if I were to contribute, but also how maintainers contribute. Here's one such commit that appears as though it was put directly on main: https://github.com/community-scripts/ProxmoxVE/commit/367dc0d78fdcdab8f7fa2968ee58f795079fa259 ### 💡 Why is this useful? A contributions guide gives a form of loose SLA on how contributions should be submitted, and under what conditions might they be accepted, and is something to point to when holding people accountable for going outside of those bounds.
OVERLORD added the enhancement label 2026-02-04 20:12:10 +03:00
OVERLORD commented 2026-02-04 20:12:16 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Mar 5, 2025):

Hi,

Have you seen this?
https://github.com/community-scripts/ProxmoxVE/blob/main/.github%2FCONTRIBUTOR_AND_GUIDES%2FCONTRIBUTING.md

We have linked it in our Readme. It's not perfect, but it's a start.
In the meantime, there is also a 2nd repo that has not yet been mentioned. This one is for new scripts.

@MickLesk commented on GitHub (Mar 5, 2025): Hi, Have you seen this? https://github.com/community-scripts/ProxmoxVE/blob/main/.github%2FCONTRIBUTOR_AND_GUIDES%2FCONTRIBUTING.md We have linked it in our Readme. It's not perfect, but it's a start. In the meantime, there is also a 2nd repo that has not yet been mentioned. This one is for new scripts.
OVERLORD commented 2026-02-04 20:12:20 +03:00
Author
Owner
Copy Link

@Starttoaster commented on GitHub (Mar 5, 2025):

Ah there it is! It's pretty well buried in the file tree. I looked at the Community and Contributions header section in the readme, which didn't have it, but missed the contribute badge closer to the top of the readme. Anyway, that is a pretty good contributions document, thanks for linking it! Though it would seem like several of the commits made recently potentially violate the contribution process in this document? Is there a defined escalation procedure for when it's acceptable to circumvent contribution process?

In the meantime, there is also a 2nd repo that has not yet been mentioned. This one is for new scripts.

Sorry for being potentially thick, but I'm not entirely sure what this is alluding to.

@Starttoaster commented on GitHub (Mar 5, 2025): Ah there it is! It's pretty well buried in the file tree. I looked at the `Community and Contributions` header section in the readme, which didn't have it, but missed the `contribute` badge closer to the top of the readme. Anyway, that is a pretty good contributions document, thanks for linking it! Though it would seem like several of the commits made recently potentially violate the contribution process in this document? Is there a defined escalation procedure for when it's acceptable to circumvent contribution process? > In the meantime, there is also a 2nd repo that has not yet been mentioned. This one is for new scripts. Sorry for being potentially thick, but I'm not entirely sure what this is alluding to.
OVERLORD commented 2026-02-04 20:12:25 +03:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Mar 5, 2025):

I'm only mobile at the moment. I can answer more tomorrow (regarding the quickfixes / dirty fixes). On the subject of the second repo, very briefly:

We created this because new scripts in PR status were almost untestable, we had to fix the scripts again and again after the merge at short notice, which is firstly time-consuming and secondly affected the project structure (PR < commit). Many scripts did not run correctly, which of course makes it difficult to debug directly live. Therefore, the second repo was created to keep these problems to a minimum. Also for larger conversions - we move the script there because it is easier to adapt directly.

I hope you understand my intention behind this? Unfortunately, I'm not a DevOps Engineer, just a Lead Technical, so there are always improvements to be made. I can say here, I don't know if it's the right translation for it, "we act to the best of our knowledge and belief". Improvement requests are always welcome, as well as contributions, optimizations or other features/burganalytics.

@MickLesk commented on GitHub (Mar 5, 2025): I'm only mobile at the moment. I can answer more tomorrow (regarding the quickfixes / dirty fixes). On the subject of the second repo, very briefly: We created this because new scripts in PR status were almost untestable, we had to fix the scripts again and again after the merge at short notice, which is firstly time-consuming and secondly affected the project structure (PR < commit). Many scripts did not run correctly, which of course makes it difficult to debug directly live. Therefore, the second repo was created to keep these problems to a minimum. Also for larger conversions - we move the script there because it is easier to adapt directly. I hope you understand my intention behind this? Unfortunately, I'm not a DevOps Engineer, just a Lead Technical, so there are always improvements to be made. I can say here, I don't know if it's the right translation for it, "we act to the best of our knowledge and belief". Improvement requests are always welcome, as well as contributions, optimizations or other features/burganalytics.
OVERLORD commented 2026-02-04 20:12:40 +03:00
Author
Owner
Copy Link

@Starttoaster commented on GitHub (Mar 5, 2025):

We created this because new scripts in PR status were almost untestable, we had to fix the scripts again and again after the merge at short notice

Yeah, not being able to test a script properly does seem like a problem. If a script is installed like so bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/post-pve-install.sh)" you can change /main/ to /any-other-branch/ and test them there before they end up on main that way. GitHub's raw content links to branches other than the default branch as well :) I bet it would feel like less of a fire drill testing out scripts before they hit the main branch.

so there are always improvements to be made.

I do find this to be a universal truth everywhere, not something unique to this repository :)

@Starttoaster commented on GitHub (Mar 5, 2025): > We created this because new scripts in PR status were almost untestable, we had to fix the scripts again and again after the merge at short notice Yeah, not being able to test a script properly does seem like a problem. If a script is installed like so `bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/post-pve-install.sh)"` you can change `/main/` to `/any-other-branch/` and test them there before they end up on main that way. GitHub's raw content links to branches other than the default branch as well :) I bet it would feel like less of a fire drill testing out scripts before they hit the main branch. > so there are always improvements to be made. I do find this to be a universal truth everywhere, not something unique to this repository :)
OVERLORD commented 2026-02-04 20:12:47 +03:00
Author
Owner
Copy Link

@michelroegl-brunner commented on GitHub (Mar 11, 2025):

Yeah, not being able to test a script properly does seem like a problem. If a script is installed like so bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/post-pve-install.sh)" you can change /main/ to /any-other-branch/ and test them there before they end up on main that way. GitHub's raw content links to branches other than the default branch as well :) I bet it would feel like less of a fire drill testing out scripts before they hit the main branch.

Yep, that is true, but it breaks build.func and install.func, wich have the repo path coded in them.

But anyway, the docs got updated.

@michelroegl-brunner commented on GitHub (Mar 11, 2025): > Yeah, not being able to test a script properly does seem like a problem. If a script is installed like so `bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/post-pve-install.sh)"` you can change `/main/` to `/any-other-branch/` and test them there before they end up on main that way. GitHub's raw content links to branches other than the default branch as well :) I bet it would feel like less of a fire drill testing out scripts before they hit the main branch. Yep, that is true, but it breaks build.func and install.func, wich have the repo path coded in them. But anyway, the docs got updated.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Implemented in VED waiting push to Main
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
in project pipeline
invalid
investigation
json
maintenance
needs triage
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
🛑 Failure to comply with the guidelines
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#591
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?