@iSazonov I don't think merging partial classes makes any change to what is internal vs private. A partial class just means the class code is split between multiple files. The class can access its own members regardless of what file they are in. Private and internal would affect how the rest of the assembly accesses the class. I can look into it after the next set of cleanup PRs, but I don't think there will be any changes.

@markekraus I don't found any issues with internal-s.
Since the PR is re-formatting could you please correct XML public comments - start with capital, finish with dot and so on?
Also I think we always should move files in separate PR in future - it easy to review code changes.

@iSazonov I have that kind of clean up planned for another PR. Other than Partial, I really did not want to mess with the code with hopes that it would be easy to see that it was just lifted from one file and put in another.

As for move in separate PR. I asked before about this. I was told to do it in a single PR with 2 commits. The first commit is the merge, the second commit is the move.

It is ok if we have only two commits. If more a code review becomes difficult.
I think for such changes in future we should open an Issue with roadmap and implement it step-by-step.
It's a good reminder and it makes it easier to understand for reviewers whole process and it status. Thoughts?

I'm ok with that. It makes sense to me. Only reservation i have is that the commit history of the repo then has a bunch of janitorial commits.

Can I do anything to speed this PR along? I have been holding off on web cmdlets work because this will make them all have very odd rebasing.

@markekraus I am very sorry the PR is very large for me to review accurately line by line. 😕 If nobody grub this I'll try on next week. (Or maybe split it on some small PRs).

If you think splitting this into 2 PRs will speed up the process I will gladly do it. But if it will take 2 weeks for each PR, that wont help. I want to work on the web cmdlet back log for the holidays and this one needs to be cleared first, or I need to withdraw it completely and submit it later.

Also, if I am to split this into separate PRs, to save time can we all agree on just how I should do that? I'm thinking 3 PRs would be the easiest to review:

1. Drag and drop the code as is from one partial class file to another and add using statements without any reordering, sorting, etc. easier to see 1-to-1 lines moved between files. Put them directly at the bottom of the class file with a // TODO
2. Organize and clean the classes (sort methods, sort using statements, remove partial's, fix comments, formatting)
3. Move files

@markekraus I think the main reason for the delay in such changes is that any reviewer immediately realizes that he's going to spend a very long time.

I think the main problem with these changes is typos. We need at least two review to eliminate the risk of typos. We don't cover all the options with tests to fully trust them.

I think your plan is good, if we're going to remove by one class.

And yes - we're very slow. This is not only a problem of this open project. I guess it's a headache for the team. I don't know how to solve it, but we definitely have to do it if we want to use the resources of Komuniti to grow fast. /cc @joeyaiello @SteveL-MSFT

If I'm doing a lift and shift, is there a need to look for typos? Especially if there is a cleanup action to follow?

I understand some of the slowness and I'm aware of how rough this is for both us and the PS Team. I don't work in development or even close to it, so much of the entire process is new to me anyway. I'm not too concerned about that. My concern is how to use my time. The reason I mentioned this one being slow is because it is somewhat blocking to other things I could be doing. But if this will block for too long, I can just do those things now since I have time and save this for when I need a breather or don't have time.

I'm not sure of your situation, but for mine my work doesn't exactly me provide me time to spend on this project. I fit PowerShell work in the tiny gaps I have at work and then use much of my own time outside of work.

The minor improvement would be at least some communication on when certain PRs will take longer. That is some of my own inexperience in not knowing what is easier or harder to review and lack of familiarity with development processes. But that is also a problem when I have PRs that are sitting with passing tests and all comments addressed for long periods of time with no clue why. I don't want to bug or rush anyone, but I also don't want my PRs to fall through the cracks and be forgotten. Some back and forth communication in that regard would go a long way.

I will close this PR and break up the work.

#5610 to track this as separate PRs

I fit PowerShell work in the tiny gaps I have at work and then use much of my own time outside of work.

Full the same!!! Thank you for the exact wording. If we have an failure with CIs or a problem with build process, that time gaps is wasted, which is very pathetic.