starred/ProxmoxVE

Fork 0

mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-04-25 17:26:03 +03:00

[GH-ISSUE #2850] Add a contributions guideline document #591

New issue

Closed

opened 2026-02-26 12:46:00 +03:00 by kerem · 5 comments

kerem commented

2026-02-26 12:46:00 +03:00

Owner

Originally created by @Starttoaster on GitHub (Mar 5, 2025).
Original GitHub issue: https://github.com/community-scripts/ProxmoxVE/issues/2850

🌟 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: github.com/community-scripts/ProxmoxVE@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). Original GitHub issue: https://github.com/community-scripts/ProxmoxVE/issues/2850 ### 🌟 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.

kerem

2026-02-26 12:46:00 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 12:46:01 +03:00

Author

Owner

@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.

kerem commented

2026-02-26 12:46:01 +03:00

Author

Owner

@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.

kerem commented

2026-02-26 12:46:01 +03:00

Author

Owner

@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.

kerem commented

2026-02-26 12:46:01 +03:00

Author

Owner

@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 :)

kerem commented

2026-02-26 12:46:01 +03:00

Author

Owner

@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.

kerem referenced this issue

2026-02-26 13:31:24 +03:00

[PR #591] [MERGED] New script: Part-DB #2798

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ProxmoxVE#591

No description provided.

Rows
Columns