I know this has the potential to turn into a huge topic. Also, it’s going to be hard to track specific items in this list. So, as we uncover new “trackable” things, we should also be opening github issues to, you know, track them.
I’ll lay out some quick ground rules for adding technical debt topics here.
Rule #1: No fingerpointing
I don’t often see this anyway. But, I thought it was important enough to call out first. The code is the code. We’re not looking for who to blame about the current status of the code. Instead, we’re looking for ways to improve the code.
Rule #2: You don’t need a solution…but it helps
Don’t feel like you cannot point out an area that needs improvement unless you’re bringing a solution to the table. Part of the purpose here is to uncover areas that need help. There is a lot of code in ManageIQ. And, there’s going to be places where some of us have never even been before. If you run across something and want to call it out, feel free to comment on it here.
That being said, if you have a solution, post it!
Rule #3: Github issues are great…just make it consumable
The end goal for each area of technical debt uncovered here is to open a github issue to track the work that needs to be done to clean it up.
However, let’s not create a bunch of open ended github issues. The issues that come from this topic should be concise and easy to tackle. This article talks about creating specific tasks that can actually be accomplished. We should avoid github issues like: “Refactor controllers”. And, instead favor tasks such as: “Extract the #blabla method from seven controllers into a single mixin”.
The main reason behind this is to take it out of your own head and allow anyone to be able to accomplish the task. This isn’t always easy. But, it’s necessary.
The one caveat here is that if you can simply fix it, then do it and create a pull request. It’s always better to discuss a solution when a solution is actually presented.
Feel free to add additional rules (or mangle my rules) in the comments.