I've worked in July in a new simplified Git workflow to use GitHub like we use Gerrit or Phabricator (see below for more context).

That makes me think about two things:

1. We need to express our model a simple way: we work with CHANGES and not BRANCHES. A change is a mutable work-in-progress commit we amend until it's ready to be added to the main branch.
2. The How to contribute code document has become operator/maintainer notes more than newcomer onboarding guide

The criticism of the particular harshness of onboarding isn't a new discovery, it has been made vocal several times by @ieli for several years.

Yet, our workflow isn't fundamentally more complicated than GitHub (and I can reproduce it easily at work with GitHub):

Branch → commit → arc diff → review → amend → arc diff → land

I want to reorganize Nasqueron's documentation for contributing code:

• The How to contribute code should be more approachable for a newcomer while preserving the existing technical knowledge and our actual workflow
• The "tour of the Nasqueron's entire infrastructure before making their first contribution" can be exiled on another page.
• No information should be deleted, there are important, but as they are for different audiences (newcomers / developers who contribute / developers who maintain / ops), we can split the page into several ones with pages like "Advanced", "Troubleshooting", or "Project-specific workflow".

The desired outcome is that a newcomer can follow the happy path without reading the entire Nasqueron documentation universe, while an experienced contributor can still find the detailed operational knowledge when needed.

Primary page:
https://agora.nasqueron.org/How_to_contribute_code

Context: I've asked GPT-5.6-Sol to review my personal git-* commands and to prepare a documentation page on https://agora.nasqueron.org/User:Dereckson/Devserver/Git

That documents my commands, mainly to be efficient syncing operations branches between let's say my workstation and Complector, it's not intended to be a general-purpose tool but it would be the foundation of a tool I'd like to write to replace arc.

At the same time, I recognize the number of commands to reimplement an arc (Phabricator) or git-review (Gerrit) workflow in pure sh is a complex machinery and here at Nasqueron there are exceptions and peculiarities than make them even more complex.

That triggers the idea / opportunity to revisit the How to contribute guide to split our two intents: onboarding guide vs troubleshoot the machinery