@mi-hol can you please help?

why does that need specific documentation? why not just have instructions for how to contribute to the wiki?

@mck1117 are you looking to debate or help? Please use your best judgement if you are available to edit any relevant articles/pages.

Kind of relevant #165 but no idea what action if any is needed. Are we supposed to remember why things are done the way they are done or shall we keep the reasons written down?

@mi-hol can you please help?

Looking forward to contribute :)

Now a word of caution, I'll try to help, but without having any background I might make wrong assumptions or even upset a valued contributor.
Please bare with me and assume that I want to help with the best of my (limited) understanding.
Please consider that my native language is German and things are expressed very differently in English.
I prefer to get direct and honest feedback and can withstand a "no" but might ask for the reasoning to be explained in order to improve my understanding.

why not just have instructions for how to contribute to the wiki?

From my view this is the right approach but it moves the burden on to reviewers to only merge appropriate changes.
Defining review rules would allow for (partial) automation.
As example a rule like:

• enforce 4 eyes principle, author of change and person that merges a change can't be the same?

Suggestions very welcome

I am sorry I am barely engaging for multiple reasons :(

I am barely engaging for multiple reasons

is this due to "Andrey does not believe in text documentation on wiki" as mentioned in https://wiki.rusefi.com/Documentation-Strategy/ ?

Yes that's one of the reasons

rusefi/rusefi#4722 for instance is much higher priority

During my career as developer I had to learn the following principle in order to be successful and have time for new development.
The principles:

DRY means "Don't Repeat Yourself"
So when a piece of software was deployed its users came back with questions. Usually after a short period of the time the same questions came up again and again.
My strategy to have still time for new development was let users become experts for the piece of software themself by first asking: "Have you RTFM?"

RTFM means "Read The Fine Manual" obviously this required to create a manual during mainly the test phase of development too. And to update it when I would have provided an answer repeatedly.

I think we have agree on the principle see https://github.com/rusefi/rusefi/wiki/Contributors-please-work-smart

We are chatting via github which is not effective.

• we shall articulate fact that https://github.com/orgs/rusefi/teams/doc-team exists

@rusefillc this seems the last part to be documented before issue can be closed.

1. Topic I plan to add are:

• role of doc-team
• how to join doc-team
• how to leave doc-team

Any other topics missing?

2. I tried to get feedback from this team but only you and David ever replied.
   Should we remove "inactive" team members?

In my opinion we are too far in the wrong area of "content/progress made" (low) and process/policy/cleanup

As of Jan 2023 rusEFI is at least stagnating if not dead. I am excited to play with my test mules and make some progress in a few areas, I am absolutely not excited about process/policy/cleanup.

the frustration expressed should be discussed in a talk

as explained here this issue is blocked by a lacking decision from architect

Because of " I am absolutely not excited about process/policy/cleanup. " I'm removing myself from this topic