This should not change. Not sure why it did.

s/FreeBSD/&os;/

This is a whitespace change. Phabricator is helpfully making sure I can't really tell which kind, but possibly a blank line with just a tab.

Whitespace changes are bad, mkay?

Use the serial/Harvard/Oxford comma:
s/policies/policies,/

The "while not" construct is kind of esoteric. Consider non-native English speakers and translators. Also, "will apply" is kind of passive. The first half of this sentence can possibly be removed: `Every project participant...`

Indent error. Because this is inside a new tag, needs another level of indent:

refer to the <link
  xlink:href="http://www.freebsd.org/internal/new-account.html">New
  Account Creation Procedure</link> page for guidance.</para>

A bit silly? Motivating? Dated?

s/tecnological/technological/

I'm not sure whether this is still the case. You might need to ask. I believe they are owned and operated by IXsystems now.

s/cloked/cloaked/

This sentence is really complicated. Please keep it simple. Some of us were edumacated in American schools. That also keeps it simple for non-native English speakers and translators.

This sentence can be simpler: "Commit bits are specific for certain parts of the repository." Although strictly speaking, we have three different repos.

Not sure what this means. "The areas associated with a bit"...

The colon is just a sentence splice here. When possible, use two shorter sentences rather than a long one spliced with something. Colons should introduce a list or conclusion. Semicolons are generally for fictional narratives.

I would remove "possibly" as it is always the case to mentor someone for a certain commit bit.

src committers can not commit to doc, they need a doc bit for that. With approval and review by someone that has a bit for that area, everyone may commit to that area. For example, a ports committer may commit a change for the porters handbook when this change was approved by someone with a doc bit.

doc is special in this: doc committers may make textual changes like typo fixes to comments and user visible output in src and ports (although the latter is even less common), but may not do any code changes. Even when a textual change is to be made, it is good practice to ask the responsible person (see MAINTAINERS file in the src repo) for permission. If no maintainer is listed, then ask the person that made the latest change to the code/file in question.

Please simplify this. Use small words and short sentences. It's not that the reader is stupid, it's that they have a lot going on.

Also not sure about the word "tree". I think we mainly refer to repositories here and elsewhere, and should be consistent.

Also also, be careful with "should" and "may". "May" generally implies permission: "You may now delete that code." while "should" is preferably only for recommendations: "But you should make a backup of it first."

(And yes, avoid "you" and "your" as informal. I know I did it just there. And I'd do it again.)

The second half of this sentence is not needed.
s/process,.*<\/para>/process.<\/para>/

"Tree" again.

s/doc/Documentation/

s/such as/including/

But I'm not certain about whether enumerating all the different types of files is useful here. Could say "Documentation committers can commit spelling, grammar, and text clarification fixes to the src repository." (although recommend review from a src committer).

I know what "non-mentored committer" means, but will a new committer? Is there a non-negative logic version of this?

'access' is a file, so should use <filename> tags and probably have more of a path.

s/ensue/begin/

But I think this is another section where shorter, simpler sentences would help.

I'm not sure about just "src", seems like that should be marked up in some way.

Likewise with "Approved by", which should probably be in <literal> tags.

This is wrong. Mentored committers must have an "Approved by:" line in their commits to indicate that their mentor (or another person with the same full commit bit) has seen and approved the commit.

You can break up this long line after "<link" and indent the following "xlink..." on the next line. Also, you can do a regular line break after "Installing" in the link description.

s/FreeBSD/&os;/

Missing an ending period on the line above, and the </para> needs to be against that rather than on a new line.

I'm not sure about the word "setup" here.

Please don't use quotes like this. There are markup tags for email addresses, and ways to use them that do not result in a mailto link: stupid phabricator link

I would also say not to use freebsd.org as the mail domain, but rather example.org.

I would write "... with your real name ..."
s/usrename/username/

Passive: s/Those who have been given commit rights/New committers/

s/!/./

The literal tags look like an artifact.

You can move the <xref part of the link to the line above and indent the "linkend= ..." on this line.

Maybe add <literal> tags around !ENTITY?

Definitely add <literal> tags around !ENTITY here.

<acronym>

s/missing/skipping/
Passive->active: s/will cause/causes/

Need tags on the domain, and it should be capitalized (@FreeBSD.org).

The ... belong to the line where the <screen> tag is.
<screen> is wrong here, use <userinput> instead. See:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/docbook-markup-block-elements.html#idp60204904

This </userinput> tag should not be alone on a line by itself. It should close the last line of text you are displaying that way.

This is not a quotation, but a literal text entry.

Maybe you can break this up into

"... of <filename>contrib.committers.xml</filename>, located in <filename>doc/head/.../articles</filename> to appear ..."

s/screen/userinput/

Like above, this needs to be on the line where the last ... is.

<literal>!ENTITY</literal>

Not <quote>.