From the etherpad [1]
* We got a lot of value out of the ovo-ectomy and de-list. We're now at a stage where there is plenty more that could be done, but the choices are more subject to personal preference. * How (and should) we further split and shrink objects/resource_provider.py We got a lot of value out of the big refactoring the removed OVO and split objects/resource_provider.py into smaller files. It's also a stated goal that we should continue refactoring and continuously revisit existing code. However, we started to stumble because we had some disagreements on how to proceed. We should resolve those disagreements so we can proceed (he said, obviously). Questions that have come up (plus other ones I can think off the top of my head): * Is it worth reordering methods to some kind of arbitrary ordering? * If a method or module is "long" (by some definition) does that make it bad? * Where is the balance between backport hurting churn and keeping the mix fresh? * Should there be a more cleanly defined boundary between the methods that marshal data (the top-level methods in objects/*.py) and those that talk to the persistence layer (also in objects/*.py)? * Do we need to define (better) or document the layers/boundaries in the system? * How can we encourage a similar refactor/revisit-often attitude to the docs? There are plenty of other refactoring related thoughts too. Have at. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent