Here is my review, along with some questions.

Section 1:
Is a GPG key still needed?

For Docker - I'm running Fedora 37 and podman was installed by default. Does it matter if they're using Docker or podman for this?

Section 2:
Creating a local subdirectory - I create the main directory, and then use the git clone command to create the directory for the repo. I'll show that in my notes for Section 3.

Create the main directory with mkdir DirectoryName (I'm using FedoraDocs)

Section 3:
I do this section a bit differently. My workflow works, but I'm not sure if it follows the conventions here. Hopefully more senior members here can evaluate this.

1. In GitLab, go to the upstream repo and create a fork. This forks the repo to your GitLab account.
2. In your forked repo, select the Clone button drop-down, and then select Clone with SSH. Copy that link to your clipboard.
3. Go to your main docs directory, and clone the repo.

cd FedoraDocs
git clone git@gitlab.com:username/documentation-contributors-guide.git ContributorsGuide (this creates a ContributorsGuide subdirectory and clones the repo into that directory)
cd ContributorsGuide
git status (shows the current branch, should be main or master)
git branch -v -a (shows all branches on the remote)
git checkout branch_name (your doc shows git checkout -b - the -b switch is used to create a new branch and switch to it, and will fail if the branch already exists)

Do work, commit as needed..

Section 4:
I do this section a bit differently too.
git remote -v (this will show the fork in your account as the origin)

origin	git@gitlab.com:username/documentation-contributors-guide.git (fetch)
origin	git@gitlab.com:username/documentation-contributors-guide.git (push)

Go to the upstream repo, and select the Clone button drop-down, and copy the Clone with SSH info.

Use git remote add upstream SSH URI

git remote add upstream git@gitlab.com:fedora/docs/community-tools/documentation-contributors-guide.git

git remote -v (this shows both origin and upstream)

origin	git@gitlab.com:username/documentation-contributors-guide.git (fetch)
origin	git@gitlab.com:username/documentation-contributors-guide.git (push)
upstream	git@gitlab.com:fedora/docs/community-tools/documentation-contributors-guide.git (fetch)
upstream	git@gitlab.com:fedora/docs/community-tools/documentation-contributors-guide.git (push)

To keep my fork in sync with upstream:
git checkout main
git fetch upstream
git pull upstream main(this gets most recent commits from upstream to my local branch)
git push origin main (this pushes to my fork in GitLab - refresh in GitLab to see the latest changes from upstream in my fork)

Section 6:
Are the build.sh and preview.sh still in use, or are they being deprecated for the docsbuilder.sh script?

Section 7: Question: git restore --staged <file> can undo any changes you've made to a file. Is there a reason for this command?

I do:
git status (to see my status)
git add .
git commit (I have a commit template I use for my commit messages)

git log works, but check out tig as a replacement.

git push origin branch_name (I think just git push origin will work also)

Go to GitLab, create the merge request.

Thanks for helping with editing the draft with clarity.

Some git commands I used are optional and I should have added comments.

For your questions,

A GPG key: I was told a GPG key is for signed commits. As a newbie, I wouldn't tell what is recommended and what is essential :)

For Docker/Podman: the article was intended to a broad audience who either uses podman or Docker. If that was unclear, I'll rephrase that.

I'll wait for a few days and catch up on next meeting.

Will follow through your workflow and get more used to the workflow. Thanks.

Updated.

Here is my updated review and comments.

If you want to work together on this - share screens and step through stuff - let me know. I'm US East Coast time and will be free over the weekend. I'm sure there is some kind of video calling / screen sharing application available on Fedora.

Section 3
This command: $ git clone -o upstream <GIT URL> doesn't really make sense in context. What this is doing is going to the remote and cloning that repo directly. That might make sense if you were using a bare repo on a server, but it doesn't really make sense when you're using a repo manager like GitLab or GitHub.

I know this came from the original source doc for this, but it didn't make sense in that doc either.

Instead, this step is handled when you fork the repo to your account, and then use git clone on your fork.

What I have in Section 3 in my original review is the best way to do this:

• Fork the repo
• Copy the SSH URI from the Clone drop-down in your fork
• git clone git@.... to clone the forked repo to your local computer

Actually, everything from the git clone -o... command all the way to the end of Section 3 doesn't seem like it would work. For example, I don't really understand what this means: From that directory, add your fork to the local checkout.

Section 7
For git add the -v switch means "verbose." Using git add -v as is will give you an error. You still have to specify files to add.
I usually use git add . to add all the files in the current working directory.

alanbowman@fedora ~/FedoraDocs/ContributorsGuide (main) $ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md
	modified:   modules/ROOT/nav.adoc

no changes added to commit (use "git add" and/or "git commit -a")
alanbowman@fedora ~/FedoraDocs/ContributorsGuide (main) $ git add -v
Nothing specified, nothing added.
hint: Maybe you wanted to say 'git add .'?
hint: Turn this message off by running
hint: "git config advice.addEmptyPathspec false"
alanbowman@fedora ~/FedoraDocs/ContributorsGuide (main) $ 

alanbowman@fedora ~/FedoraDocs/ContributorsGuide (main) $ git add .
alanbowman@fedora ~/FedoraDocs/ContributorsGuide (main) $ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md
	modified:   modules/ROOT/nav.adoc

alanbowman@fedora ~/FedoraDocs/ContributorsGuide (main) $

Working together by screen share will be great. Thank you for offering help with the workflow. I admit I most struggled with section 3 to compare various pages in Docs and Wiki.

Could we agree date and time on the Fedora chat in Fedora Documentation room? We can then connect to screen share. I'm on European time zone (UTC+1).

If opening video calls in public rooms is not permitted, I can send invite to personal chat room if that's okay with you.

I can be available on Saturday 3 December from 0800 (UTC -5, so 1400 your time) to 1200 (1700 your time). I can also be available on Sunday 4 December from 0800 (1400 your time) onward, but not past 2200 my time (0300 Monday your time).

We can use Google Meet or Jitsi or another private chat if you have it available.

Confirmed the commits to my fork of Contributors Guide repo.

Alan, thank you for offering help with the workflow. I've run the workflow a few times today and feel more informed.