Current Time
22:45
Central European Summer Time
16:45
Eastern Daylight Time
From 3dda9c3903098c03e0284a7d4b952d6b4bc75bd4 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 3 Sep 2024 14:28:38 +0000 Subject: [PATCH] deploy: 84cc30cf08f7de7038e5be5a98cb3f17c57ca9f3 --- community.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/community.html b/community.html index a9d7c3c73..2b32b4e6c 100644 --- a/community.html +++ b/community.html @@ -17,7 +17,7 @@
The Podman developers are generally around during CEST and Eastern Time business hours, so please be patient if you’re in another time zone!
Central European Summer Time
Eastern Daylight Time
Simply visit [the Podman mailing list website](https://lists.podman.io/) to browse or search previous postings to the Podman mailing list.
Don't include private / sensitive info in issues!
While bug fixes can first be identified via an "issue", that is not required. It's ok to just open up a PR with the fix, but make sure you include the same information you would have included in an issue - like how to reproduce it.
PRs for new features should include some background on what use cases the new code is trying to address. When possible and when it makes sense, try to break-up larger PRs into smaller ones - it's easier to review smaller code changes. But only if those smaller ones make sense as stand-alone PRs. Regardless of the type of PR, all PRs should include:
The Podman community has contributors from many different organizations, including:
The Podman developers are generally around during CEST and Eastern Time business hours, so please be patient if you’re in another time zone!
Central European Summer Time
Eastern Daylight Time
Simply visit [the Podman mailing list website](https://lists.podman.io/) to browse or search previous postings to the Podman mailing list.
Don't include private / sensitive info in issues!
While bug fixes can first be identified via an "issue", that is not required. It's ok to just open up a PR with the fix, but make sure you include the same information you would have included in an issue - like how to reproduce it.
PRs for new features should include some background on what use cases the new code is trying to address. When possible and when it makes sense, try to break-up larger PRs into smaller ones - it's easier to review smaller code changes. But only if those smaller ones make sense as stand-alone PRs. Regardless of the type of PR, all PRs should include:
The Podman community has contributors from many different organizations, including: