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.
Or.. something inbetween. If you have a preferences here, chime in on the list, or we can take this up in our IRC meeting at the beginning of December, too.
As an aside, it would be especially fun if we could keep track of our collective damage on some kind of scoreboard (it doesn't have to be automatic, even manual pen-and-paper would work) so we can produce a nice summary blogpost at the end and thus herald in 2016, a year of working code, less fires, and quiet mornings where we sip our coffee and read email.
-Ralph
[1] - http://threebean.org/presentations/debt-services-flock15/ [2] - https://apps.fedoraproject.org/calendar/meeting/3183/
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
Hey team,
As described here: https://fedoraproject.org/wiki/Infrastructure/Debt we're going to try to focus on taking on some of the technical debt laying around this week (after we recover from the holidays and get through our email.. ;p).
- I think we'll coordinate mostly throughout the week in #fedora-apps and #fedora-noc.
- As we finish tasks, let's try to remember to update the wiki page with a list of accomplishments so we can review it all at the end.
- If you want to help, but aren't sure what to work on, please ask in channel and we'll try our best to isolate something. If you're interested in a Python coding project, one of the most useful tasks with a relatively low barrier to entry would be to pick a single project, read the code over, and work at adding clarifying inline comments throughout as you come to an understanding about how it works.
OK -- assessment time. How did Tech Debt Week go?
There's a list at the bottom of the wiki page of the things we were able to accomplish: https://fedoraproject.org/wiki/Infrastructure/Debt
We got a good bit of ansible stuff cleaned up. Staging had a few sites that were broken and we fixed those in tandem with fixing rube, our staging-testing tool. We were able to silence some of the error emails that were unnecessarily coming out of the bodhi backend (thus raising the signal-to-noise ratio). And we were able to remove some of the code duplication around python-fedora (both server side components like flask_fas_openid and client-side components like the openidbaseclient). That's a good chunk, especially for a first try at organized tech debt fighting.
I'll note that participation was not up to the level I was expecting. It seemed like there was sizable interest at Flock and in infra meetings at the end of 2015, but there were only a few of us actually working on tech debt tasks during the week.
I've been thinking about it and trying to come up with possible explanations: - It was the first time we tried something like this. We weren't sure what to do and so we just need to try again until its comfortable. - It was too poorly defined. We were pretty vague about what was kinds of things to do. The intent was to open up people to pursue what they want to hack on, but perhaps it was a turn-off. - The first week of the New Year wasn't the best choice of time. Perhaps people were anxious to get the jump on other projects after the holidays and debt-wrangling wasn't attractive. - Others?
Should we try this again in a few months? If so, what should we try differently?
Cheers! - Ralph
On Mon, Jan 11, 2016 at 04:41:58PM -0500, Ralph Bean wrote:
OK -- assessment time. How did Tech Debt Week go?
There's a list at the bottom of the wiki page of the things we were able to accomplish: https://fedoraproject.org/wiki/Infrastructure/Debt
We got a good bit of ansible stuff cleaned up. Staging had a few sites that were broken and we fixed those in tandem with fixing rube, our staging-testing tool. We were able to silence some of the error emails that were unnecessarily coming out of the bodhi backend (thus raising the signal-to-noise ratio). And we were able to remove some of the code duplication around python-fedora (both server side components like flask_fas_openid and client-side components like the openidbaseclient). That's a good chunk, especially for a first try at organized tech debt fighting.
I'll note that participation was not up to the level I was expecting. It seemed like there was sizable interest at Flock and in infra meetings at the end of 2015, but there were only a few of us actually working on tech debt tasks during the week.
I've been thinking about it and trying to come up with possible explanations:
- It was the first time we tried something like this. We weren't sure what to do and so we just need to try again until its comfortable.
- It was too poorly defined. We were pretty vague about what was kinds of things to do. The intent was to open up people to pursue what they want to hack on, but perhaps it was a turn-off.
- The first week of the New Year wasn't the best choice of time. Perhaps people were anxious to get the jump on other projects after the holidays and debt-wrangling wasn't attractive.
- Others?
Should we try this again in a few months? If so, what should we try differently?
I kinda feel guilty on this to not have been of more help. One thing I have been wondering for this type of work is if we could approach it in a 'sprint' mode. Set-up a small meeting 15/30 minutes at the beginning of the day, review the tasks, everyone picks one, fix it and adjust the wiki. Being able to review the tasks, pick the most important and spread them among the group might allow us to get into a team effort spirit. Might help giving the feeling you're not the only one doing boring work and helps to see progress (just like when you do a bug-process week where you try to close as many tickets as possible, the more you close, the more progress you see).
Maybe an idea for next time :)
Pierre
On Fri, Jan 15, 2016 at 02:46:38PM +0100, Pierre-Yves Chibon wrote:
On Mon, Jan 11, 2016 at 04:41:58PM -0500, Ralph Bean wrote:
OK -- assessment time. How did Tech Debt Week go?
There's a list at the bottom of the wiki page of the things we were able to accomplish: https://fedoraproject.org/wiki/Infrastructure/Debt
We got a good bit of ansible stuff cleaned up. Staging had a few sites that were broken and we fixed those in tandem with fixing rube, our staging-testing tool. We were able to silence some of the error emails that were unnecessarily coming out of the bodhi backend (thus raising the signal-to-noise ratio). And we were able to remove some of the code duplication around python-fedora (both server side components like flask_fas_openid and client-side components like the openidbaseclient). That's a good chunk, especially for a first try at organized tech debt fighting.
I'll note that participation was not up to the level I was expecting. It seemed like there was sizable interest at Flock and in infra meetings at the end of 2015, but there were only a few of us actually working on tech debt tasks during the week.
I've been thinking about it and trying to come up with possible explanations:
- It was the first time we tried something like this. We weren't sure what to do and so we just need to try again until its comfortable.
- It was too poorly defined. We were pretty vague about what was kinds of things to do. The intent was to open up people to pursue what they want to hack on, but perhaps it was a turn-off.
- The first week of the New Year wasn't the best choice of time. Perhaps people were anxious to get the jump on other projects after the holidays and debt-wrangling wasn't attractive.
- Others?
Should we try this again in a few months? If so, what should we try differently?
I kinda feel guilty on this to not have been of more help. One thing I have been wondering for this type of work is if we could approach it in a 'sprint' mode. Set-up a small meeting 15/30 minutes at the beginning of the day, review the tasks, everyone picks one, fix it and adjust the wiki.
Being able to review the tasks, pick the most important and spread them among the group might allow us to get into a team effort spirit.
I like it! Timezones make it a little tricky since "beginning of the day" varies for everyone. But we could do something each day where people from one set of timezones could report "we did X today, we'll do Y tomorrow" and people from the other timezones could say "cool, we'll do Z today".
Might help giving the feeling you're not the only one doing boring work and helps to see progress (just like when you do a bug-process week where you try to close as many tickets as possible, the more you close, the more progress you see).
Maybe an idea for next time :)
Yeah. We should talk about a next time, too. Maybe late May or early June?
Pierre
infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
On Jan 15, 2016 10:17, "Ralph Bean" rbean@redhat.com wrote:
On Fri, Jan 15, 2016 at 02:46:38PM +0100, Pierre-Yves Chibon wrote:
On Mon, Jan 11, 2016 at 04:41:58PM -0500, Ralph Bean wrote:
OK -- assessment time. How did Tech Debt Week go?
There's a list at the bottom of the wiki page of the things we were able to accomplish:
https://fedoraproject.org/wiki/Infrastructure/Debt
We got a good bit of ansible stuff cleaned up. Staging had a few sites that were broken and we fixed those in tandem with fixing rube, our staging-testing tool. We were able to silence some of the error emails that were unnecessarily coming out of the bodhi backend (thus raising the signal-to-noise ratio). And we were able to remove some of the code duplication around python-fedora (both server side components like flask_fas_openid and client-side components like the openidbaseclient). That's a good chunk, especially for a first try at organized tech debt fighting.
I'll note that participation was not up to the level I was expecting. It seemed like there was sizable interest at Flock and in infra meetings at the end of 2015, but there were only a few of us actually working on tech debt tasks during the week.
I've been thinking about it and trying to come up with possible explanations:
- It was the first time we tried something like this. We weren't sure what to do and so we just need to try again until its comfortable.
- It was too poorly defined. We were pretty vague about what was kinds of things to do. The intent was to open up people to pursue what they want to hack on, but perhaps it was a turn-off.
- The first week of the New Year wasn't the best choice of time. Perhaps people were anxious to get the jump on other projects after the holidays and debt-wrangling wasn't attractive.
- Others?
Should we try this again in a few months? If so, what should we try differently?
I kinda feel guilty on this to not have been of more help. One thing I
have been
wondering for this type of work is if we could approach it in a
'sprint' mode.
Set-up a small meeting 15/30 minutes at the beginning of the day,
review the
tasks, everyone picks one, fix it and adjust the wiki.
Being able to review the tasks, pick the most important and spread them
among
the group might allow us to get into a team effort spirit.
I like it! Timezones make it a little tricky since "beginning of the day" varies for everyone. But we could do something each day where people from one set of timezones could report "we did X today, we'll do Y tomorrow" and people from the other timezones could say "cool, we'll do Z today".
Might help giving the feeling you're not the only one doing boring work
and
helps to see progress (just like when you do a bug-process week where
you try to
close as many tickets as possible, the more you close, the more
progress you
see).
Maybe an idea for next time :)
Yeah. We should talk about a next time, too. Maybe late May or early June?
In glad we got this first one on the books, and I have a few ideas for next time:
- badge for participation - promotional article on commblog - on-site satellite events, like the python3 porting hackfest in November 2015 - picking a day further from the holidays
This was on my radar, but I was still catching up on other loops. Def wanna help do more and promote more next time around.
Looking Forward, --RemyD.
Pierre
infrastructure mailing list infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
infrastructure mailing list infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
infrastructure@lists.fedoraproject.org
-
Pierre-Yves Chibon -
Ralph Bean -
Remy DeCausemaker