> On the module level, we could think about adding two instability metrics:

1. Let `No` be the number of module-to-module references from the module to other modules and `Ni` be the number of those from other modules to the module. The metric would be `No/(Ni+No)`.

2. Let `Fo` be the number of members of the module depending on members of another module and `Fi` the number of members of other modules depending on members of the module. The metric would be `Fo/(Fo+Fi)`.

Updated LibGit2Sharp to version v0.24.0 API changed: -> repository.commit() now mandates 'author' and 'commiter' as two distinct parameters. I pass into both the same value by default. -> repository.Stage() passes to the static class 'Commands' taking the repo as a first parameters. -> repository.Pull() undergoes the same change -> repository.Checkout() also -> repository.Remove() also

-> repository.Fetch() takes the biggest changes. -It now requires by default a refSpec. As we will usual

@NelsonVides You made a commit to the Rubberduck repository, github.com/rubberduck-vba/Rubberduck/commit/… , but when you did that commit the git config for your user.email does not match your Github account email, so github doesn't know what github user did this commit

> Currently the abstract class only requires IVBE, but from what I see, almost all, if not all, derived classes require the use of RubberParserState class, leading to duplicated code in all derived classes. That should be refactored into their abstract base class to cut down on the construction noise.

@Vogel612 / @Mat'sMug reading that issue, I'm a bit surprised it's reported to fail. Using generic class should not by itself cause runtime error. It's legal to use generic Access.Form and be able to reference members that only exists on Form_xxx using the dot operator. Is that not so with Userforms?

hmm, the Move module-level variable to smaller scope inspection might not be appropriate in situations where the variable is assigned a WithEvents reference (and thereby only referenced in a single procedure, where you'd want the reference to survive the procedure terminating.

I * think* RD should be able to determine that kind of assignment? The inspection could be made more robust?

> That's by design actually; the inspection explicitly only looks at procedure-scope variables. Arguably the issue is the same at module-scope, but it was thought that a module-level variable declared `As New` pretty much implied that it means to live as long as the class it's declared in.

I guess it wouldn't hurt to enhance the inspection to also look at module scope... The meta/descriptions need to be updated too.

> Maybe split it into 2 inspections? The descriptions could vary by module/procedure scope, with differing levels of severity and caution/advice to the user? Likewise, the inspections could then be disabled per scope.