From c0e02bf37bd1d136eb46dd3a2003e75e726e0f1a Mon Sep 17 00:00:00 2001 From: Victor Julien Date: Fri, 5 May 2023 20:28:12 +0200 Subject: [PATCH] doc/readme: spelling --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 25b34b931a..436dc5ce82 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,7 @@ For this reason, we have developed a QA process that is quite extensive. A conse On a high level, the steps are: -1. Github-CI based checks. This runs automatically when a pull request is made. +1. GitHub-CI based checks. This runs automatically when a pull request is made. 2. Review by devs from the team and community @@ -91,11 +91,11 @@ A: It depends, if it's a major feature or considered a high risk change, it will __Q: Why was my PR closed?__ -A: As documented in the Suricata Github workflow here https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Github_work_flow, we expect a new pull request for every change. +A: As documented in the Suricata GitHub workflow here https://redmine.openinfosecfoundation.org/projects/suricata/wiki/GitHub_work_flow, we expect a new pull request for every change. Normally, the team (or community) will give feedback on a pull request after which it is expected to be replaced by an improved PR. So look at the comments. If you disagree with the comments we can still discuss them in the closed PR. -If the PR was closed without comments it's likely due to QA failure. If the Github-CI checks failed, the PR should be fixed right away. No need for a discussion about it, unless you believe the QA failure is incorrect. +If the PR was closed without comments it's likely due to QA failure. If the GitHub-CI checks failed, the PR should be fixed right away. No need for a discussion about it, unless you believe the QA failure is incorrect. __Q: the compiler/code analyser/tool is wrong, what now?__