I can assure you that it’s fairly easy to keep track of architectural musings like this.

For one thing, the Jazz project is composed of a set of small, highly modular teams, so it’s relatively straightforward to keep track of in-flight ideas. For instance, there are exactly four people (myself included) who directly care about the idea I mentioned above.

Also, we do our work in 4-8 week milestones and each component lead reviews each of his/her open tracking items (bugs, enhancements, etc.) at the beginning of each new milestone.

You raise some good points on why your idea shouldn’t be implemented “right now.” The current environment certainly doesn’t call for it, and I think you would be adding in a higher maintenance cost which is NOT “a good thing.”

I hope the Jazz team has an “ideas on pause” repository for situations like this. I think you need a better holding space for the idea than just a bug report, imho. Bug reports tend to get lost in the noise and don’t highlight the fact this was really an enhancement instead of a bug fix.

Your idea is still good and valid. And there may be a time when the performance increase really is needed. That’s when it would be a good time to dust off the high level design you put together and revisit the idea. Our products change with time, so yesterday’s bad idea might be tomorrow’s good idea. Matter of fact, I think it’s worthwhile to document why the enhancement wasn’t done at this point in time. In two years, you’re not going to remember the details of the conversation, so it’s worth adding a note to the high level design indicating why it was mothballed.