Hi All, In terms of the reviewing PR I generally try to review in 2 parts, is this technically correct? (FSIP, no depricated method, cognitive complexity) - I tried partially in the repos that I am maintaining, (restrict new violation in terms of custom linting) and add existing separation (a json which tracks existing technical debt) when someone do refractoring. The also need to prune supressions. So that code debt only decrease.
As for functional part. I ask usecase or try marking for functional review. (Ai can check for functional red flags.) -- this is the part we need to be careful about. Or try posting in dev list/matrix for more help. (This sometimes scares me away from reviewing.) If we can master the functional part then we can deliver faster review. Regards, Aman On Tue, 13 Oct, 2026, 10:19 pm Adam Monsen, <[email protected]> wrote: > +1 to all previous comments. > > It's useful to think of AI as a mad genius developer with zero executive > function. It'll do whatever you tell it to. Improving docs/skills will help > direct it at particular chunks of work, but we tell it what to do and why, > the same as we do ourselves when we work on Fineract. To better direct AI > (and ourselves) we need a better plan. > > So just what is our plan? What are we doing, why, and (roughly) when? Who > are the key people guiding big chunks of work? What are we *not* doing? > Where do the in-flight FSIPs fit into our plan? We need more high-level > leadership and coordination. *We need a roadmap*. > > We also need to bravely and responsibly remove/modularize stuff that isn't > used/useful. > > All of the above requires user (installer/vendor/implementor) involvement. > Voting on issues, sponsoring work, feedback, testing, qa... dogfooding. > > In summary, I think our key growth areas are: > > 1. leadership > 2. user involvement > >
