Current Time
22:14
Central European Standard Time
17:14
Eastern Daylight Time
From 48379d8ac1cbdc20d14d4c4574d99b7bdd443165 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Fri, 1 Nov 2024 21:17:41 +0000 Subject: [PATCH] deploy: e12668606961d7dbed98d0725f532604b952ce0f --- 404.html | 2 +- community.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/404.html b/404.html index 88d763f01..3b54fa573 100644 --- a/404.html +++ b/404.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 Standard 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 Standard 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: