Add contributing guidelines (community standards) #33
Conversation
paulo-ferraz-oliveira
changed the title
|
@wojtekmach, this can potentially be merged as-is, and adapted after #1 is merged with the actual commands that can be run. Or we can wait... |
|
Here as well some coordination to have the projects aligned (besides the technical details that will be different) could make sense. Oidcc uses the following: https://github.com/erlef/oidcc/blob/main/.github/CONTRIBUTING.md |
wojtekmach
force-pushed
the
main
branch
4 times, most recently
from
9f7e03f to
9815e12
Compare
paulo-ferraz-oliveira
force-pushed
the
feature/contributing-guide
branch
from
8c76136 to
3948229
Compare
|
This is rebased on top of the default branch while we wait on a better way to do it. |
paulo-ferraz-oliveira
force-pushed
the
main
branch
3 times, most recently
from
805b320 to
e416e5e
Compare
|
A security pointer? I'm not sure this'll get accepted as-is, given @maennchen's comment about standardization, which I also believe should exist. I can close it or keep it open longer for comments (?) |
|
@paulo-ferraz-oliveira I’d like to define templates for the contributing file soon. But that shouldn’t stop you from merging a file now. We can revisit the standardization later as we’ll have to do with various ither projects anyways. |
paulo-ferraz-oliveira
force-pushed
the
feature/contributing-guide
branch
from
3948229 to
fa6164b
Compare
There was a problem hiding this comment.
The repo has changed quite a bit since this PR was opened. I'm assuming it was copy-pasted from another repo because some of the things mentioned here do not apply.
If erlef will have org-wide CONTRIBUTING.md anyway I personally wouldn't pursue it here but if it's important to have something in the meantime then I'm not opposed to that.
| `otp_builds` is not perfect software and will be buggy. | ||
|
|
||
| Bugs can be reported via | ||
| [GitHub issues: bug report](https://github.com/erlef/otp_builds/issues/new?template=bug_report.md). |
There was a problem hiding this comment.
We don't have a bug report template. I don't think we need it either, let's see what kind of issues we will be getting and adjust then.
There was a problem hiding this comment.
Not that it matters much, but it's "just naming". The link still works and would adapt to a potential future template.
| _bleeding edge_). | ||
|
|
||
| If this is done, open up a | ||
| [GitHub issues: feature request](https://github.com/erlef/otp_builds/issues/new?template=feature_request.md). |
There was a problem hiding this comment.
We don't have a feature request template either.
There was a problem hiding this comment.
Same.
|
|
||
| ## License | ||
|
|
||
| `otp_builds` is licensed under [Apache License Version 2.0](LICENSE.md) License, for all code. |
There was a problem hiding this comment.
| `otp_builds` is licensed under [Apache License Version 2.0](LICENSE.md) License, for all code. | |
| `otp_builds` is licensed under the [Apache License 2.0](LICENSE.txt). |
| `otp_builds` is not perfect software and will be buggy. | ||
|
|
There was a problem hiding this comment.
| `otp_builds` is not perfect software and will be buggy. |
There was a problem hiding this comment.
I'm not really sure this is desired or undesired, but we're setting a bar. It's not perfect and it may contain issues. Which is an opener for the next line.
|
|
||
| - search, in existing [issues](https://github.com/erlef/otp_builds/issues) (open or closed), whether | ||
| the feature might already be in the works, or has already been rejected, | ||
| - make sure you're using the latest software release (or even the latest code, if you're going for |
There was a problem hiding this comment.
latest software release?
There was a problem hiding this comment.
I'm not sure how the repository will progress, but it's surely possible to imagine multiple version of the images, and if an image failed locally before opening a pull request / bug report the poster should figure out if the image they're using has not been recreated.
| We try to have as many of `otp_builds`' features tested as possible. Everything that a | ||
| user can do, and is repeatable in any way, should be tested, to guarantee backwards compatible. |
There was a problem hiding this comment.
We have no tests. Which, while I'm obviously biased, is fine, this is the type of the project which is kind of hard to test in automated way.
There was a problem hiding this comment.
We might not have tests on the script themselves, but on the result we do: test_otp. That, combined with linting, should be enough as a starter.
|
|
||
| ### What checks do you perform | ||
|
|
||
| Check the `.github/workflows` elements for the checks we perform, if you want to do them locally. |
There was a problem hiding this comment.
Users can't easily run checks locally though, i.e. people need to read through all workflows and actions that we might be using. I mean, sure, we're saying exactly that but still. What would be more helpful is something like scripts/test or scripts/lint that we run on CI and people can run themselves. But that's tricky because on CI we install linters through actions and locally people would have to install linters themselves. Anyway if such scripts are even worth pursuing they are definitely out of the scope of this PR.
There was a problem hiding this comment.
Yeah, I'm convinced it should be simpler. I like to have a task ci, or make ci, that runs the same both locally and in remote CI, but we don't, so...
|
I'm closing this, for now. There'll potentially be an upstream (ErlEF) template or guidelines, and it's not like it's getting a lot of issues / feature requests. We'll guide people as we go. |
This:
LICENSE.mdwhich is not yet present- fulfils the gap in the pull request template, that points to a file that doesn't exist (it'll be this one)bug_report.mdandfeature_request.mdto exist (even though the links won't "fail" - we'll not have these for now, but keeping the link should be Ok)Closes #19.