Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: updated the general guidelines section #1221

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 1 addition & 35 deletions docs/CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,41 +23,7 @@ If you need help getting started,
feel free to ask for help on the `#help-contributing` or `#keptn-docs` channels on the [Keptn Slack](https://keptn.sh/community/#slack).
We were all new to this once and are happy to help you!

## Guidelines for contributing

* Always fork the repository then clone that fork to your local system
rather than clone `main` directly.
Keptn, like most open source projects,
severely restricts who can push changes directly to the `main` branch
to protect the integrity of the repository.
* Keep your language clean and crisp.
* Smaller PR's are easier to review and so generally get processed more quickly;
when possible, chunk your work into smallish PR's.
However, we recognize that documentation work sometimes requires larger PRs,
such as when writing a whole new section or reorganizing existing files.
* You may want to squash your commits before creating the final PR,
to avoid conflicting commits.
This is **not mandatory**; the maintainers will squash your commits
during the merge when necessary.
* Be sure that the description of the pull request itself
is meaningful and clear.
This helps reviewers understand each commit
and provides a good history after the PR is merged.
* If your PR is not reviewed in a timely fashion,
feel free to post a gentle reminder to the `#keptn-docs` Slack channel.
* Resolve review comments and suggestions promptly.

If you see a problem and are unable to fix it yourself
or have an idea for an enhancement,
please create an issue on the GitHub repository:

* Provide specific and detailed information about the problem
and possible solutions to help others understand the issue.
* When reporting a bug, provide a detailed list of steps to reproduce the bug.
If possible, also attach screenshots that illustrate the bug.
* If you want to do the work on an issue,
include that information in your description of the issue
or in a comment to the issue.
## [Guidelines for contributing](https://github.com/keptn/lifecycle-toolkit/tree/main/docs/content/en/docs/guidelines-for-contributing.md)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, don't use links in a header


## Building the documentation locally

Expand Down
35 changes: 35 additions & 0 deletions docs/content/en/docs/guidelines-for-contributing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
## Guidelines for contributing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, this file is in the wrong directory -- see comments in your PR for github. And that PR also includes the guidelines... So need to straighten this all out.


* Always fork the repository then clone that fork to your local system
rather than clone `main` directly.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After the github contributing page is merged, this should like to the appropriate subsection of that page for directions.

Keptn, like most open source projects,
severely restricts who can push changes directly to the `main` branch
to protect the integrity of the repository.
* Keep your language clean and crisp.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a docs-only guideline. This list should be for both software and docs. For guidelines specific to either software or docs, I think I like putting those right after this list but we could instead put them in the software and docs sections. What do you think?

* Smaller PR's are easier to review and so generally get processed more quickly;
when possible, chunk your work into smallish PR's.
However, we recognize that documentation work sometimes requires larger PRs,
such as when writing a whole new section or reorganizing existing files.
* You may want to squash your commits before creating the final PR,
to avoid conflicting commits.
This is **not mandatory**; the maintainers will squash your commits
during the merge when necessary.
* Be sure that the description of the pull request itself
is meaningful and clear.
This helps reviewers understand each commit
and provides a good history after the PR is merged.
* If your PR is not reviewed in a timely fashion,
feel free to post a gentle reminder to the `#keptn-docs` Slack channel.
* Resolve review comments and suggestions promptly.

If you see a problem and are unable to fix it yourself
or have an idea for an enhancement,
please create an issue on the GitHub repository:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
please create an issue on the GitHub repository:
please create an issue on the GitHub repository.


* Provide specific and detailed information about the problem
and possible solutions to help others understand the issue.
* When reporting a bug, provide a detailed list of steps to reproduce the bug.
If possible, also attach screenshots that illustrate the bug.
* If you want to do the work on an issue,
include that information in your description of the issue
or in a comment to the issue.