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.
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
- 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.
Here's a question I have. It seems like we could approach this in two
- 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