#fedicode #Scala #codeReview

Hello fediversian,
How do you handle the review process (as in "sharing knowledge and insights, getting feedback" on a very big PR?

OK, the best solution is "do not do big pr" and yes, scaling down the issue is generally a good advice (either by splitting the thing in an iterative process, or in several topic commit)
I did that, but the resulting change is still big (+30k/-100k of Scala) and impactful (switch a core part of the app), the two being of course intrinsically linked.
It could have been "work in pair", but that horse is far away already.

So, I did my homework (create arch docs and schema, document the change "how to get into that pr" way, tracked all the code change that made me pause in code log, added unit test to both demonstrate non regression on old behavior and new one, document code, etc) .

Still, such a change is frightening, just by the involvement and time needed to get at the "I can review" level.
But I really need to help them at that level, since the pr embed technical and functional knowledge important to be shared, even if not for getting feedback on the code now.

So: how do I help my team getting involved in that pr? It really looks like the next step must be interactive ("let me walk the changes with you, ask anything you want" like). Do you have any recommendations or guidelines about how to do that efficiently?

EDIT: thanks for feedback, it helps!
If people are interested, the PR is here: https://github.com/Normation/rudder/pull/5167

@JD557 for the general process, this a culmination of several months of shared work and PoC around and meetings on the subject, so the topic is known, there is no surprise the arch decisions which were collaborativelly built nor the goal reached here.
It's more to help engage with actual code/implementation