Docs userguide we to you 6406 v2

[Cherrypick14]

Make sure these boxes are checked accordingly before submitting your Pull Request -- thank you.

Contribution style:

• I have read the contributing guide lines at
  https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html

Our Contribution agreements:

• I have signed the Open Information Security Foundation contribution agreement at
  https://suricata.io/about/contribution-agreement/ (note: this is only required once)

Changes (if applicable):

• I have updated the User Guide (in doc/userguide/) to reflect the changes made
• I have updated the JSON schema (in etc/schema.json) to reflect all logging changes
  (including schema descriptions)
• I have created a ticket at
  https://redmine.openinfosecfoundation.org/projects/suricata/issues

Link to ticket: https://redmine.openinfosecfoundation.org/issues/6406

Describe changes:

• Removed ambiguous "we" usages from userguide documentation across 5 files.
• Updated quickstart.rst with imperative forms ("Install" instead of "We recommend").
• Updated rules/intro.rst to use passive voice and system-focused language.
• Updated code-style.rst to clarify project policy ("Suricata uses" instead of "We use").
• Fixed grammar error in file-extraction.rst ("will be placed" instead of "we be placed").
• Updated flow-keywords.rst to replace user-referring "we" with direct "you" or passive voice.

Provide values to any of the below to override the defaults.

• To use a Suricata-Verify or Suricata-Update pull request,
  link to the pull request in the respective _BRANCH variable.
• Leave unused overrides blank or remove.

SV_REPO=
SV_BRANCH=
SU_REPO=
SU_BRANCH=

[jufajardini]

Thanks for your contribution, there's progress here :)

Please check the inline comments, and also:

• for the quickstart file, I'd say that likes 85 and 95 could also be adjusted
• in the rules/intro.rst, section Direction could be worked upon, too
• flow-keywords: did you review the other we usage cases? I see other sections with a similar situation

Since we know this touches many files, I would say that once we manage to complete the work started on these files, this can be seen as a first batch.

We will need a next iteration following our Code submission guidelines, especially with regards to commit message format and commit separation.

[jufajardini]

Good catch! As this is as typo fix, could you please put this (and any other such fixes) in a separate commit, and clearly state that it is a commit fixing typos?

[Cherrypick14]

Hi @jufajardini sure, I'll do this. I think this is where I will have to leverage the cherrypick command right?

[jufajardini]

The cherry-pick command is more for when you want to bring a commit from a different branch to your branch.

In this case, two things can be done:

• you can use git commit --amend to modify the last commit you've worked on
• and you can use git commit --fixup to merge commits together

[jufajardini]

I think this one isn't needed. We as the team are indeed recommending that the user/ reader installs jq.

The purpose of the ticket is to remove ambiguous usages of we (where it isn't clear whether it refers to the team, or the user). This one isn't ambiguous, so it can stay. :)

[Cherrypick14]

Well noted.

[jufajardini]

I'm thinking that maybe (this is a bit of polishing, but, still):

Suggested change

	fails per connection, but has a vulnerability where an attacker can
	fails per connection, but there is a vulnerability where an attacker can

[jufajardini]

Since we're here, how about we improve:

Suggested change

	continue to login after that five attempts and you need to detect
	continue to login after those five attempts and you need to detect

This could go in the typo-fixing commit ;)

[Cherrypick14]

I see another cherrypick usage here . Thanks for pointing this out.

[jufajardini]

This proposal doesn't look correct, and is not needed (similar explanation as in the other inline comment).

[Cherrypick14]

Got it. Will preserve the original wording.