On Thu, Nov 19, 2015 at 02:14:50PM -0500, Ralph Bean wrote: > At Flock, we talked about scheduling some kind of regular > technical-debt-fighting week to happen every so often - some period of > time where we don't do any new features (and even try to de-prioritize > interrupt-driven stuff) and focus on shoring up, cleaning up, > tightening the bolts, etc[1]. > > Here are some things broadly to think about: > > - Add unit tests where there are none. Increase "code coverage". > - Write docs (and make diagrams!) where there are none. > - Reduce code duplication, and increase code re-use where appropriate. > - Break up ultra long methods, classes, and files into more > understandable chunks. > - Remove half-implemented features! > - Remove dead code!! > - Add comments where there are none, and correct inaccurate comments. > - Deal with the existential questions facing the code that none of us > wants to touch. > - Increase happiness and general zest for life. > > Time-wise, how about we try and schedule a week to try this on the > first week back from the holiday break -- a New Year, a New > Infrastructure(!) That would be January 4-8th[2]. > > Here's a question I have. It seems like we could approach this in two > different ways: > > - We could select one or two projects we want to prioritize, and try > to do *all* of the best-practices things to them. > - We could select one or two of the best-practices things, and try to > do them to *all* of our projects. I love the idea, one thought I had was: do we want to have all personnel on-board of the same project or do we want to make smaller team and split the projects among them? Say: 3 people on bodhi, 2 on pkgdb, 2 on badges and so on. Regarding the two ways I see pros and cons to either: - doing few best-practices on more projects might be more rewarding and faster, you know what you are targeting and by the end of the first or second day you're already faster to find and correct what you are looking for. - doing most best-practices on fewer projects might be better to gain a better insight on how the project works and is designed, and might results in more contributors in the long term (since more people know the code). So the first one might be more efficient, the second give a deeper insight on the project, on the other side the first approach should give a better overview of all the projects to more people. Maybe we should try one approach for the first and try the other for the next week :) Pierre
Attachment:
pgpJQOosq4dxG.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
