)]}'
{"specs/policy/tech-debt-tracking.rst":[{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"c93a37e59b29855dff99d5dce3dc3c7e63f2ba04","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Problem Description"},{"line_number":12,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"During the development of TripleO, sometimes tech debt is acquired due to time"},{"line_number":15,"context_line":"or resource constraints that may exist. Without a solid way of tracking when"},{"line_number":16,"context_line":"we intentially add tech debt, it is hard to quantify how much tech debt is"},{"line_number":17,"context_line":"being self inflicted. Additionally tech debt gets lost in the code and without"},{"line_number":18,"context_line":"a way to remember where we left it, it is almost impossible to remember when"},{"line_number":19,"context_line":"and where we need to go back to fix some known issues."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Proposed Change"},{"line_number":22,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_41081b27","side":"PARENT","line":19,"range":{"start_line":14,"start_character":0,"end_line":19,"end_character":54},"updated":"2018-02-19 10:26:17.000000000","message":"The original text describes a problem clearly and briefly. Could you please do the same for the updated version? What are exactly problems (comparing to the original version of the policy!) we want to solve with the proposed change? Could you please put it in the first line, as a brief summary, e.g.:\n\nThe existing process of tracking and addressing technical debt poses the following problems:\n\n* when tracked as a bug, it might stay unresolved for years\n* it\u0027s hard to follow lifecycle of bugs, when applied for tech debt items\n* there is no enforcement possible\n...\n\nso we could discuss each of the problem statements in details and the proposed solutions for those on which we would agree.","commit_id":"412f2c8ca7b763858660d746c5f1ea0ede5572bc"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":32,"context_line":"Difference between Bugs and Technical Debts"},{"line_number":33,"context_line":"-------------------------------------------"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Bugs are not TD. A bug is a lack of functionality or error that makes the"},{"line_number":36,"context_line":"product less viable for use, less efficient, or plain broken."},{"line_number":37,"context_line":"Bugs are usually fixed or not fixed. Their urgency doesn\u0027t change often and"},{"line_number":38,"context_line":"dramatically over time."},{"line_number":39,"context_line":"TD are usually shortcuts in implementation. They offer same level of"},{"line_number":40,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":41,"context_line":"productivity, because of extra costs they allocate on the future in the form of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_8373a74d","line":38,"range":{"start_line":35,"start_character":0,"end_line":38,"end_character":23},"updated":"2018-02-16 18:04:34.000000000","message":"I disagree with this statement. Bugs and tech debt can share similar lifecycles in that bugs can either become more of an issue (increase in proritiy) or go away (be fixed, obsoleted due to refactoring).  A bug that is currently a Low because the community does not rely on a specific feature can become critical later if that functionality becomes a must have over the life of the project.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Bugs are not TD. A bug is a lack of functionality or error that makes the"},{"line_number":36,"context_line":"product less viable for use, less efficient, or plain broken."},{"line_number":37,"context_line":"Bugs are usually fixed or not fixed. Their urgency doesn\u0027t change often and"},{"line_number":38,"context_line":"dramatically over time."},{"line_number":39,"context_line":"TD are usually shortcuts in implementation. They offer same level of"},{"line_number":40,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":41,"context_line":"productivity, because of extra costs they allocate on the future in the form of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_8e2427b1","line":38,"updated":"2018-02-16 23:49:17.000000000","message":"I think if a bugs is allowed to stay for years without getting fixed , it means that the code just doesn\u0027t consider some corner cases, and that matches more the definition of technical debts.\nDrawing a line is really important for this, once you start considering the impact of a bug and you make\nthe analysis cost/benefits to understand IF to fix it and not just WHEN, I think it has to be considered in the technical debt group.\nI\u0027d say, if a problem breaks something that is part of the requirements, it\u0027s a bug. You prioritize when to fix it, not if, because otherwise you don\u0027t meet the requirements.\nIf it\u0027s not in the requirements, then it\u0027s maybe a corner case, something that wasn\u0027t considered priority, and you have to decide if you live with it or not, it may be better described as technical debt.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d8f303cd7826b0825c0fa026746734defcb2895c","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Bugs are not TD. A bug is a lack of functionality or error that makes the"},{"line_number":36,"context_line":"product less viable for use, less efficient, or plain broken."},{"line_number":37,"context_line":"Bugs are usually fixed or not fixed. Their urgency doesn\u0027t change often and"},{"line_number":38,"context_line":"dramatically over time."},{"line_number":39,"context_line":"TD are usually shortcuts in implementation. They offer same level of"},{"line_number":40,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":41,"context_line":"productivity, because of extra costs they allocate on the future in the form of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_3e12de59","line":38,"updated":"2018-02-17 04:27:11.000000000","message":"This reply makes a lot of sense, explains a lot of choices, and yet creates even more doubts. You say that in opensurce poroject we have to accept the trade offs every day. This is the most clarifying answer I got since starting to deal with technical debts. Yet you wouln\u0027t certainly accept a patch that messes up the code so you can just add a new feature. Even if you accept it, you want to know how messed up the code is. This is probably why you created this policy in the first place. But the line that separates these two aspects is not well defined. Beyond which point you stop caring about the importance of a contribution and start caring about the problems it may create in the maintenance of the code ?\nMy exact point is to facilitate the acceptance of a patch, not block it, but in the same time be aware of its consequences.\nI assume the original goal of this policy was to track TD so every one of this exceptions made to accept contributions can be addressed again at a later time. If not, why create a tech debt policy in the first place ? Can we define this line then ?","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"488cc744c35419c29f6615f7ca1dfb289377cef4","unresolved":false,"context_lines":[{"line_number":35,"context_line":"Bugs are not TD. A bug is a lack of functionality or error that makes the"},{"line_number":36,"context_line":"product less viable for use, less efficient, or plain broken."},{"line_number":37,"context_line":"Bugs are usually fixed or not fixed. Their urgency doesn\u0027t change often and"},{"line_number":38,"context_line":"dramatically over time."},{"line_number":39,"context_line":"TD are usually shortcuts in implementation. They offer same level of"},{"line_number":40,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":41,"context_line":"productivity, because of extra costs they allocate on the future in the form of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_2edcf372","line":38,"in_reply_to":"3fa0c359_8e2427b1","updated":"2018-02-17 00:38:23.000000000","message":"You assume that someone can enforce people addressing bugs. bugs are allowed to stay open because of the nature of the opensource project. We don\u0027t have folks stepping up to address long standing issues so only things that are \"current priorities\" get resolved.  Only in a perfect world would we be able to dictate that all bugs be resolved by X time.  In reading this proposal, it seems to be requiring dictating  and being heavy-handed than allowing for flexibility that may be necessary to ensure the software still functions.\n\n\nEveryday we have to make trade-offs to ensure that the project is making some incremental progress.  It\u0027s not ideal but it\u0027s the nature of working in opensource.  I don\u0027t want to drive away potential contributors by applying super strict processes and reducing possible velocities.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":36,"context_line":"product less viable for use, less efficient, or plain broken."},{"line_number":37,"context_line":"Bugs are usually fixed or not fixed. Their urgency doesn\u0027t change often and"},{"line_number":38,"context_line":"dramatically over time."},{"line_number":39,"context_line":"TD are usually shortcuts in implementation. They offer same level of"},{"line_number":40,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":41,"context_line":"productivity, because of extra costs they allocate on the future in the form of"},{"line_number":42,"context_line":"increased cost of change during evolution and maintenance."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_2e3b93d1","line":39,"updated":"2018-02-16 23:49:17.000000000","message":"I will change \"shortcuts\" with \"trade-offs and oversights\"","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":36,"context_line":"product less viable for use, less efficient, or plain broken."},{"line_number":37,"context_line":"Bugs are usually fixed or not fixed. Their urgency doesn\u0027t change often and"},{"line_number":38,"context_line":"dramatically over time."},{"line_number":39,"context_line":"TD are usually shortcuts in implementation. They offer same level of"},{"line_number":40,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":41,"context_line":"productivity, because of extra costs they allocate on the future in the form of"},{"line_number":42,"context_line":"increased cost of change during evolution and maintenance."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_03b6b7da","line":39,"range":{"start_line":39,"start_character":0,"end_line":39,"end_character":44},"updated":"2018-02-16 18:04:34.000000000","message":"This is not necessarily true. TD can be made because a larger refactor will significally derail a project or is not something that is currently feasible with the given architecture/technologies. It doesn\u0027t mean that it\u0027s a shortcut in implementation.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":68,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Tracking Code Tech Debt"},{"line_number":72,"context_line":"-----------------------"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"When a TD is identified in an implementation, or even when the implementation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_a35ee342","line":71,"updated":"2018-02-16 18:04:34.000000000","message":"Given how terrible we have been with tracking bugs over time, I\u0027m not sure anyone will be able to also want to track techdebt as a separate item.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d8f303cd7826b0825c0fa026746734defcb2895c","unresolved":false,"context_lines":[{"line_number":89,"context_line":"                   of technical debt"},{"line_number":90,"context_line":"     Analysis: Degree to which the development approach"},{"line_number":91,"context_line":"               (design consideration/limitation) meets"},{"line_number":92,"context_line":"               stakeholder needs or expectations"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_5e0d6a33","line":92,"updated":"2018-02-17 04:27:11.000000000","message":"Can you be more specific on what is not friendly ? The description, or the format ? With less and less support on development of new tooling, I would agree to try to implement the register on LP at this point, even if I\u0027m not completely sure it will provide all the elements needed.\nBut what to put into the bug then ?\nIf the 5 lines description and analysis of the problem the code is going to create is not friendly enough, I\u0027m not sure what information needs to be put in a tech-debt bug to be useful.\nABout the analysis, I\u0027m not sure why we prefer not to address the duality of our project.\nTripleO is an opensource project. True.\nIt\u0027s also a single vendor project. I have no idea how many non vendor contribution are made on it, and how many of these are from people who don\u0027t have a team behind them, but the main contributor is the vendor which has a set of very structured teams that support it.\nThis is a project that already requires a high and specific level of knowledge to interact with it \nI\u0027m trying to look at this as a pure opensource developer, but I really can\u0027t,  I\u0027m not doing volunteer work, I have a team and the team has people whose role is to define priorities.\nI have endured a long onboarding process to contribute, which I don\u0027t envision being possible for people without\nspecific interest in the project.\nIf a tech debt comes from a team member, I know I can count on someone making this analysis. If it doesn\u0027t, maybe\nnot, but maybe we can do it for him/her anyway.\nShould we really limit this policy on the case of single casual contributor that offered his help only yesterday ?\nTo be honest I also think that clean code is one of the main incentives for new contributors to join.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":89,"context_line":"                   of technical debt"},{"line_number":90,"context_line":"     Analysis: Degree to which the development approach"},{"line_number":91,"context_line":"               (design consideration/limitation) meets"},{"line_number":92,"context_line":"               stakeholder needs or expectations"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_4e361fea","line":92,"updated":"2018-02-16 23:49:17.000000000","message":"I don\u0027t see this process much different than what we usually do, and what we\u0027re also doing right now. I proposed something, this something is written in a shared place, for everyone to see and modify, but not lost inside a huge thread of discussion. A single point where to put all the modifications that are ruadually added by the discussion.\nAfter I put my proposal I also wrote an email to the ML to bring attention to the topic.\nAlso, my first attempt at this took 5 minutes to write https://review.openstack.org/#/c/542311/18/designnotes/designnotes.rst\nit doesn\u0027t follow exactly this I proposed, byt I was testing alternative way to convey the same message.\nI wanted to see how it looked like, even if it not adhered to the existing policy.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":78,"context_line":"This description takes the name of TD item."},{"line_number":79,"context_line":"The initial TD item creation must contain these fields::"},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"  id: UUID, to be added as comment in the relative code as a reverse reference"},{"line_number":82,"context_line":"  Description:"},{"line_number":83,"context_line":"     Symptoms: Observable qualitative or measurable consequence"},{"line_number":84,"context_line":"              (type of issue and analysis implications of design)"},{"line_number":85,"context_line":"     Consequences: Effect on value, quality, or cost of the system"},{"line_number":86,"context_line":"                   in the form of accumulation; additional costs due"},{"line_number":87,"context_line":"                   to reduced productivity, induced defects, or loss of"},{"line_number":88,"context_line":"                   quality incurred by software depending on an element"},{"line_number":89,"context_line":"                   of technical debt"},{"line_number":90,"context_line":"     Analysis: Degree to which the development approach"},{"line_number":91,"context_line":"               (design consideration/limitation) meets"},{"line_number":92,"context_line":"               stakeholder needs or expectations"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_432fdff5","line":92,"range":{"start_line":81,"start_character":0,"end_line":92,"end_character":48},"updated":"2018-02-16 18:04:34.000000000","message":"I think if you\u0027re going to spend the energy to do all this, it owuld be better to send a communication (either via ML or irc meeting) to bring up this issue for discussion. If you\u0027re about to do something significant, it would be beneficial to have the group weigh in on options rather than doing this in a vacuum.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"488cc744c35419c29f6615f7ca1dfb289377cef4","unresolved":false,"context_lines":[{"line_number":89,"context_line":"                   of technical debt"},{"line_number":90,"context_line":"     Analysis: Degree to which the development approach"},{"line_number":91,"context_line":"               (design consideration/limitation) meets"},{"line_number":92,"context_line":"               stakeholder needs or expectations"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_ae2d6347","line":92,"in_reply_to":"3fa0c359_4e361fea","updated":"2018-02-17 00:38:23.000000000","message":"This is not very new developer friendly. It also assumes too much about a persons knowledge about the overall system. Who is to do this analysis?  We hardly have time to address the open bugs and you\u0027re proposing that we take time to come up with extended analysis of tech debt for a given change.  My issue is with the formality being proposed.  Given the nature of some folks contributions I\u0027m hesitant to add this extra overhead which may cause even more folks to do drive-by contributions.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"},{"line_number":96,"context_line":"the code in the form of a comment::"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"  # TD(author): UUID"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During the review, all the people involved can analyse the TD and decide"},{"line_number":101,"context_line":"whether it\u0027s more convenient to contract the TD, or fix it right away and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_2305f37a","line":98,"range":{"start_line":98,"start_character":0,"end_line":98,"end_character":20},"updated":"2018-02-16 18:04:34.000000000","message":"I don\u0027t think it\u0027s beneficial to add this to the code because if I\u0027m working on the project this UUID means nothing to me. I think it would be better to actually add the explaination of the issue in the code itself than a reference that means nothing without knowing where to go look it up.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"d8d95c553ce4b98ecb74c6d8277b3b7e574ef173","unresolved":false,"context_lines":[{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"},{"line_number":96,"context_line":"the code in the form of a comment::"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"  # TD(author): UUID"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During the review, all the people involved can analyse the TD and decide"},{"line_number":101,"context_line":"whether it\u0027s more convenient to contract the TD, or fix it right away and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_a139dfa3","line":98,"range":{"start_line":98,"start_character":4,"end_line":98,"end_character":6},"updated":"2018-02-19 10:32:06.000000000","message":"The \u0027FIXME(nick)\u0027 rule would fit the tech debt case better (IMHO). And yes, please put LP# or something clickable instead of UUIDs.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"},{"line_number":96,"context_line":"the code in the form of a comment::"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"  # TD(author): UUID"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During the review, all the people involved can analyse the TD and decide"},{"line_number":101,"context_line":"whether it\u0027s more convenient to contract the TD, or fix it right away and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_ee34cbe0","line":98,"updated":"2018-02-16 23:49:17.000000000","message":"The previous policy considered doing something similar with LP bugs. It\u0027s implicit how a LP bug id is made and where to look at to find its definition. It\u0027s not something it has to be written every time.\nThis is just a reference on the TD registry.\nin my first attempt at this at \nhttps://review.openstack.org/#/c/542311/18/playbooks/multinode-overcloud-upgrade-new.yml@26\nThe ID was the title of the class of technical debt I was referencing, and I added a note to check\nthe documentation\nIf the whole explanation is added here, a report on active TD would be really hard to extract, and the code would be polluted with comments.\nI think we at least agree that leaving a reference in the code is useful for at least warning the future developers that they may be implement something over a TD","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d8f303cd7826b0825c0fa026746734defcb2895c","unresolved":false,"context_lines":[{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"},{"line_number":96,"context_line":"the code in the form of a comment::"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"  # TD(author): UUID"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During the review, all the people involved can analyse the TD and decide"},{"line_number":101,"context_line":"whether it\u0027s more convenient to contract the TD, or fix it right away and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_fe1b1670","line":98,"updated":"2018-02-17 04:27:11.000000000","message":"This makes sense. A new tool should consider a list of project associated and create report for all of them. Not sure how does the PTL deal with reno for all the projects at this point, but I can agree that developing an ad hoc tool is less and less feasible at this point.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"488cc744c35419c29f6615f7ca1dfb289377cef4","unresolved":false,"context_lines":[{"line_number":95,"context_line":"After the TD item has been added to the register, a reference must be added to"},{"line_number":96,"context_line":"the code in the form of a comment::"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"  # TD(author): UUID"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During the review, all the people involved can analyse the TD and decide"},{"line_number":101,"context_line":"whether it\u0027s more convenient to contract the TD, or fix it right away and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_2e7dd31b","line":98,"in_reply_to":"3fa0c359_ee34cbe0","updated":"2018-02-17 00:38:23.000000000","message":"So I don\u0027t want UUIDs because it gives no context when working with code.  LP# should also be accompanied with some form of comments indicating the details.  As a PTL it is beneficial to have a single view of things which is why being able to reuse bugs its beneficial for tracking purposes because we can trend bugs/techdebt/promotion issues/etc from a single source of data. Moving TD to a single repository (or worse many repos) makes it harder to track and would require folks actually pay attention \u0026 curate this. I don\u0027t see this being viable given the scale of TripleO as well as our current contributor base.\n\nYes a reference is good, having to hunt down a reference that has no specific location context is not great.  LP# at least references launchpad. A UUID does not provide much else.\n\nTo the comment about being able to report on active TD, that can be simply addressed by asking for the comment to be #TODO or FIXME which is already an established pattern elsewhere. I\u0027m not sure why we should use #TD.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":120,"context_line":"Once the decision of contracting the technical debt is made the following"},{"line_number":121,"context_line":"fields will have to be added to the TD item::"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"  Repayment Type: [REPAY, CONVERT, IGNORE]"},{"line_number":124,"context_line":"  Date contracted:"},{"line_number":125,"context_line":"  Finder: Who identified the technical debt"},{"line_number":126,"context_line":"  Borrower: Who contracted the technical debt"},{"line_number":127,"context_line":"  Intentional: if the technical debt was contracted intentionally or identified"},{"line_number":128,"context_line":"               after (we may have already payed interests)"},{"line_number":129,"context_line":"  Status: [REPAYED, OUTSTANDING, DEPRECATED/REMOVED]"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"After it has been contracted, there will be three ways to deal with a TD:"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_43183fd2","line":129,"range":{"start_line":123,"start_character":0,"end_line":129,"end_character":52},"updated":"2018-02-16 18:04:34.000000000","message":"I find this concept far too heavy for the opensource project.  Given that folks come and go, it\u0027s not something that we can formally adopt.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d8f303cd7826b0825c0fa026746734defcb2895c","unresolved":false,"context_lines":[{"line_number":126,"context_line":"  Borrower: Who contracted the technical debt"},{"line_number":127,"context_line":"  Intentional: if the technical debt was contracted intentionally or identified"},{"line_number":128,"context_line":"               after (we may have already payed interests)"},{"line_number":129,"context_line":"  Status: [REPAYED, OUTSTANDING, DEPRECATED/REMOVED]"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"After it has been contracted, there will be three ways to deal with a TD:"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_1e17e247","line":129,"updated":"2018-02-17 04:27:11.000000000","message":"I would argue that code is of high quality when productivity remains high in the presence of change in team and goals. And this is true for every project, not only for project of this nature. And this is achieved with good planning, but no planning can make an implementation reach perfection. A proper planning would anyway include technical debts, because there\u0027s never time to do everything, and that\u0027s where the analysis is important. In fact I think the best design is the one the considers all the technical debts possible and makes decision early on which to ignore, which to convert, which to repay in full later, and which to absorb directly in the code to not create technical debt.\nWhen time is limited, in which direction you move the effort of closing which issue first ? What tech debt to address next ? Work together to improve which part of the project ? You need analysis.\nAssuming a detailed analysis is not possible in our situation, I have to ask again. Why do we want to track the technical debt, and what to we plan to do with these informations ?\nIt\u0027s easy to ignore a loose policy, and end up with no relevant data to work on. I\u0027ve counted 31 bugs with the tag tech-debt since its creation, all where marked as CRITICAL, which doesn\u0027t match my definition of TD\nIf no analysis is made on them, if they have no effect in my life as a developer, I don\u0027t even see why I should create a tech-debt bug.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":126,"context_line":"  Borrower: Who contracted the technical debt"},{"line_number":127,"context_line":"  Intentional: if the technical debt was contracted intentionally or identified"},{"line_number":128,"context_line":"               after (we may have already payed interests)"},{"line_number":129,"context_line":"  Status: [REPAYED, OUTSTANDING, DEPRECATED/REMOVED]"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"After it has been contracted, there will be three ways to deal with a TD:"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_0e3017e8","line":129,"updated":"2018-02-16 23:49:17.000000000","message":"The important part here is really to mark a resolution for the TD. Will it be ignored, converted or repayed. The rest could be good for statistics.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d3a1da017d6b114980c56d9c805522659fd05f14","unresolved":false,"context_lines":[{"line_number":126,"context_line":"  Borrower: Who contracted the technical debt"},{"line_number":127,"context_line":"  Intentional: if the technical debt was contracted intentionally or identified"},{"line_number":128,"context_line":"               after (we may have already payed interests)"},{"line_number":129,"context_line":"  Status: [REPAYED, OUTSTANDING, DEPRECATED/REMOVED]"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"After it has been contracted, there will be three ways to deal with a TD:"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_f2a1f396","line":129,"updated":"2018-02-19 13:15:27.000000000","message":"This is why I asked above, I\u0027m not sure I want to create any mark to separate vendors and non-vendors, I\u0027ve never seen something like that in a project, I\u0027d just like to not ignore a large portion of the contributors.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"488cc744c35419c29f6615f7ca1dfb289377cef4","unresolved":false,"context_lines":[{"line_number":126,"context_line":"  Borrower: Who contracted the technical debt"},{"line_number":127,"context_line":"  Intentional: if the technical debt was contracted intentionally or identified"},{"line_number":128,"context_line":"               after (we may have already payed interests)"},{"line_number":129,"context_line":"  Status: [REPAYED, OUTSTANDING, DEPRECATED/REMOVED]"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"After it has been contracted, there will be three ways to deal with a TD:"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_2ecb9353","line":129,"in_reply_to":"3fa0c359_0e3017e8","updated":"2018-02-17 00:38:23.000000000","message":"Given the nature of the project, there\u0027s no guarantee that the person making the tech-debt will be here tomorrow to clean it up.  This concept makes sense if we can dictate resources and priorities for folks, but we\u0027ve seen that is not a thing in the community (nor should it/can it be this way).\n\n\nIt would be better to take the effort being proposed to actually closing issues, addressing the tech-debt or working together to improve the project than requiring folks jump through hoops to make incremental changes.\n\n\nI think some of the tech-debt we\u0027ve incurred has been due to lack of proper planning and communication of end goals for the overall structure or planning when implementing features.  I would rather spend the time on improving those aspects with communication and planning than argue over tech-debt when trying to make progress.  Yes tech-debt is important. Yes we should track it, but it shouldn\u0027t require new tooling, new data structures, additional resources to manage and actively block the progress of the project as a whole.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"a64a62d0c477347eb067593878cd0eec4da98dbe","unresolved":false,"context_lines":[{"line_number":120,"context_line":"Once the decision of contracting the technical debt is made the following"},{"line_number":121,"context_line":"fields will have to be added to the TD item::"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"  Repayment Type: [REPAY, CONVERT, IGNORE]"},{"line_number":124,"context_line":"  Date contracted:"},{"line_number":125,"context_line":"  Finder: Who identified the technical debt"},{"line_number":126,"context_line":"  Borrower: Who contracted the technical debt"},{"line_number":127,"context_line":"  Intentional: if the technical debt was contracted intentionally or identified"},{"line_number":128,"context_line":"               after (we may have already payed interests)"},{"line_number":129,"context_line":"  Status: [REPAYED, OUTSTANDING, DEPRECATED/REMOVED]"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"After it has been contracted, there will be three ways to deal with a TD:"},{"line_number":132,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_e1fcc7b6","line":129,"range":{"start_line":123,"start_character":0,"end_line":129,"end_character":52},"in_reply_to":"3fa0c359_43183fd2","updated":"2018-02-19 10:43:55.000000000","message":"\u003e I find this concept far too heavy for the opensource project. \n \u003e Given that folks come and go, it\u0027s not something that we can\n \u003e formally adopt.\n\nI fully agree that won\u0027t work for contributors driven opensource projects. That might work though for the established on a constant basis teams assigned and managed by *vendors*. If we see a mismatch, shall we introduce the vendor term alongside to contributor? And shall we please add that to the problem description section and try to address here as well? F.e.: *contributors* shall follow the lightweight tech dept reporting form: \n\nFIXME(nick) LP# ref and brief description\n\nthen the *vendor(s)* assigned/managed expert teams would later expand on to the required scope of details.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":173,"context_line":"- automatically add or change fields like `status` or `date`"},{"line_number":174,"context_line":"- manage uuid creation and references inside the code"},{"line_number":175,"context_line":"- create reports on the status of active TD, their interest cost payed, and"},{"line_number":176,"context_line":"  future costs."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Alternatives"},{"line_number":179,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_ae4c8376","line":176,"updated":"2018-02-16 23:49:17.000000000","message":"I consider the use of a register inside the code because TD is part of the code, it\u0027s part of choices made, really close to design principles.\nTo reprise the discussion on bugs vs TD, you don\u0027t deliberately decide to leave a bug in the code.\nYou may leave a TD instead. If you find a bug in the code while you write it, I don\u0027t think is an option to leave it unfixed. That\u0027s why it sound logical to me that bugs are tracked externally, because they don\u0027t belong in the code, you don\u0027t want them in the code in the first place.\nKeeping the TD in the code is because you decided to live with them at least for a while, and it may be desirable you find them around while you code instead.\nThe boy scout rule for example, suggest to alwasy leave the code in a better state than how you found it. TD are wonderful opportunities to apply this rule.\nRegarding reno, I had a similar objection from my team. We don\u0027t use that much for the release notes, how do you convice the others to use it for TD ?\nI think release notes have an unclear audience, it\u0027s unclear when and how they would be read, and used. TD notes are needed by the people to make decision on what to leave in the code and what to fix instead. I see it as a more vital set of informations, people would be more encouraged to write them, they are needed for decision making, and to prioritize the work. Also -2 when you don\u0027t do that! :)","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":173,"context_line":"- automatically add or change fields like `status` or `date`"},{"line_number":174,"context_line":"- manage uuid creation and references inside the code"},{"line_number":175,"context_line":"- create reports on the status of active TD, their interest cost payed, and"},{"line_number":176,"context_line":"  future costs."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Alternatives"},{"line_number":179,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_23c65318","line":176,"updated":"2018-02-16 18:04:34.000000000","message":"The reason why the original policy referenced bugs was because that is an established concept that exists outside of the project and is something that a new contributor can easily pick up and work on. I don\u0027t think we should be adding even more tooling around this. We have enough work today without adding such a heavy process to development of TripleO and a call to yet development/manage/maintain even more tooling.   While what you propose would be similar to reno in tooling that could be used across projects, we\u0027ve seen where reno isn\u0027t well adopted by new contributors and there is a significant about of effort to reinforce the usage of new tools.  I would hesitate to do that for TripleO specific things given our already complex development process requirements.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d8f303cd7826b0825c0fa026746734defcb2895c","unresolved":false,"context_lines":[{"line_number":173,"context_line":"- automatically add or change fields like `status` or `date`"},{"line_number":174,"context_line":"- manage uuid creation and references inside the code"},{"line_number":175,"context_line":"- create reports on the status of active TD, their interest cost payed, and"},{"line_number":176,"context_line":"  future costs."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Alternatives"},{"line_number":179,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_be27ceb6","line":176,"updated":"2018-02-17 04:27:11.000000000","message":"This is probably the point in which we disagree the most. If you leave a bug in the code, it\u0027s probably something that doesn\u0027t break completely everything, so if it doesn\u0027t limit functionality, and it\u0027s left there because it leaves open only secondary problems, to me it matches the definition of technical debt, not bug. It\u0027s perfectly fine to do it, but I would like to understand if it does cause another team to circle around when that secondary problem appears.\nHow do I understand it before I merge this code and notify that team that I had to make this choice ?\nCI is in direct contact with every other team, our TD audience is very large.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"488cc744c35419c29f6615f7ca1dfb289377cef4","unresolved":false,"context_lines":[{"line_number":173,"context_line":"- automatically add or change fields like `status` or `date`"},{"line_number":174,"context_line":"- manage uuid creation and references inside the code"},{"line_number":175,"context_line":"- create reports on the status of active TD, their interest cost payed, and"},{"line_number":176,"context_line":"  future costs."},{"line_number":177,"context_line":""},{"line_number":178,"context_line":"Alternatives"},{"line_number":179,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_6e9e7b08","line":176,"in_reply_to":"3fa0c359_ae4c8376","updated":"2018-02-17 00:38:23.000000000","message":"You can totally deliberately leave a bug in code. If it\u0027s functionality that is in use or by fixing it causes even more pain.  \n\nRelease notes don\u0027t make sense in quickstart because there aren\u0027t really regular releases. It would be helpful if we did have regular releases because then we can establish stable interfaces.  Release notes are very important for other parts of the TripleO project so we learn when things are changing based on versions. The consumers are other developers (other project devs), deployers, and end users.  Tech-debt the target audience is generally just developers of this project (or maybe just the single repo in the case of TripleO) and PTL.  But in this case the target audience of TD is not cross project developers or PTLs. It\u0027s something we would take on as a project and without a majority wanting to implement this or another project wanting to share the tooling, I\u0027m not sure we should be taking on this effort.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":6926,"name":"Bogdan Dobrelya","email":"bdobreli@redhat.com","username":"bogdando"},"change_message_id":"4b602714febac8cd12a11e595e59593797d02a54","unresolved":false,"context_lines":[{"line_number":226,"context_line":"Implementation"},{"line_number":227,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"No TD should be left untracked once discovered. Any TD is adding cost to"},{"line_number":230,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":231,"context_line":"full consequences."},{"line_number":232,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_e1bfe7a7","line":229,"updated":"2018-02-19 10:48:32.000000000","message":"Given my previous comments, I suppose there is only way to enforce this policy: the vendor driven expert teams following SLAs. It can not be enforced for contributors reporting (or asked to report in code review) lightweight tech debt items.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d3a1da017d6b114980c56d9c805522659fd05f14","unresolved":false,"context_lines":[{"line_number":226,"context_line":"Implementation"},{"line_number":227,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"No TD should be left untracked once discovered. Any TD is adding cost to"},{"line_number":230,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":231,"context_line":"full consequences."},{"line_number":232,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_129d7f56","line":229,"updated":"2018-02-19 13:15:27.000000000","message":"I\u0027ve never seen anything like this before in a project. I wouldn\u0027t want to get to that.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"6678550d8dd1bbe9988b195e9d04fb0becd91228","unresolved":false,"context_lines":[{"line_number":229,"context_line":"No TD should be left untracked once discovered. Any TD is adding cost to"},{"line_number":230,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":231,"context_line":"full consequences."},{"line_number":232,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":233,"context_line":"feel free to -2 any patches that are adding tech debt without proper"},{"line_number":234,"context_line":"analysis."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Author(s)"},{"line_number":237,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_1e27ecb8","line":234,"range":{"start_line":232,"start_character":0,"end_line":234,"end_character":9},"updated":"2018-02-16 18:04:34.000000000","message":"I\u0027m hesitant to propose -2 around this. While TD is bad, I think it needs to be more of a conversation which is where -1\u0027s should be used rather than just straight up blocking.  We generally do not merge things that have -1s from other reviewers unless there is a good reason.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"d8f303cd7826b0825c0fa026746734defcb2895c","unresolved":false,"context_lines":[{"line_number":231,"context_line":"full consequences."},{"line_number":232,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":233,"context_line":"feel free to -2 any patches that are adding tech debt without proper"},{"line_number":234,"context_line":"analysis."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Author(s)"},{"line_number":237,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_de2ada7c","line":234,"updated":"2018-02-17 04:27:11.000000000","message":"I\u0027m not particularly attached to using -2, I just wanted to send a strong signal. Anyway, in most of the cases, if I can work with the patch owner to mitigate the impact, or if we can really find an alternative solution, there\u0027s probably no need to even create a technical debt. The problem arises when I request a change, and the patch owner or I have absolutely no time to fix the issue. What happens then ? I don\u0027t want to block the progress, but I also don\u0027t want the issue to be forgotten. Why is not very collaborative to request a description of the problem then, and is very collaborative to leave something in the code that will burden its maintenance for the near future ?","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"cab9fa034cdbc1db69e58e42393b32cf78417e44","unresolved":false,"context_lines":[{"line_number":231,"context_line":"full consequences."},{"line_number":232,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":233,"context_line":"feel free to -2 any patches that are adding tech debt without proper"},{"line_number":234,"context_line":"analysis."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Author(s)"},{"line_number":237,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_ce4f8f68","line":234,"updated":"2018-02-16 23:49:17.000000000","message":"Once a TD is discovered, it must be tracked. We could use a -1 to start the discussion after the identification\nIt\u0027s perfectly fine to merge a TD after we realize it\u0027s the best thing to do. But if after the identification the TD is not properly described, I would put a -2. I wouldn\u0027t merge something that impacts my future work and doesn\u0027t leave a trace.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"488cc744c35419c29f6615f7ca1dfb289377cef4","unresolved":false,"context_lines":[{"line_number":231,"context_line":"full consequences."},{"line_number":232,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":233,"context_line":"feel free to -2 any patches that are adding tech debt without proper"},{"line_number":234,"context_line":"analysis."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Author(s)"},{"line_number":237,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3fa0c359_ae624315","line":234,"in_reply_to":"3fa0c359_ce4f8f68","updated":"2018-02-17 00:38:23.000000000","message":"I think you overestimate the clearness of tech-debt.  The problem with -2ing it is you are blocking other people because it might impact you rather than working with the patch owner to try and mitigate the impact or perhaps come up with an alternative solution. -2s really should be a last resort and only be used if it\u0027s going to break something now or is just plain wrong.  Using -2 because it might impact your future work doesn\u0027t seem very collaborative or community friendly.","commit_id":"4c09751bdb5150eb5ee2401e06bba85752ebaae6"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"ea676ad5c0a4723744d0cc5da0b7c1064902858f","unresolved":false,"context_lines":[{"line_number":21,"context_line":"implementations and a clear process to make the management as much informed,"},{"line_number":22,"context_line":"transparent and efficient as possible."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When such a suboptimal implemenation is merge into the code, it means that we"},{"line_number":25,"context_line":"have contracted a technical debt."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"The problem with technical debts"},{"line_number":28,"context_line":"--------------------------------"},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"It may not immediately apparent when a decision to contract a TD is really"},{"line_number":31,"context_line":"beneficial."},{"line_number":32,"context_line":"Contracting TD is an important decision, it allocates time for the future on"},{"line_number":33,"context_line":"you, your team or even a different team, time that will have to be spent to"},{"line_number":34,"context_line":"redo part of the same implementation, and should not be taken lightly."},{"line_number":35,"context_line":"This time is called Debt Repayment"},{"line_number":36,"context_line":"If this decision leads to also having to spend time over time to workaround the"},{"line_number":37,"context_line":"parts someone has not implemented, or manually fix problems in the system"},{"line_number":38,"context_line":"caused by this, it means that the TD is also incurring interests costs."},{"line_number":39,"context_line":"To make an efficient decision on whether it\u0027s more convenient to contract or not"},{"line_number":40,"context_line":"TD, the possible TD must be appropriately described."},{"line_number":41,"context_line":"After the decision of contracting a TD is made, it must be correctly tracked to"},{"line_number":42,"context_line":"eventually reevaluate the total cost, that is the repayment cost, plus the cost"},{"line_number":43,"context_line":"times frequency of the interests."},{"line_number":44,"context_line":"If hidden, interest costs may end up clogging the backlog of feature, and bring"},{"line_number":45,"context_line":"the project to serious delays."},{"line_number":46,"context_line":"Every unsolved TD should be taken into consideration while planning future"},{"line_number":47,"context_line":"tasks, because it may lead to unrealistic expectations on the time available to"},{"line_number":48,"context_line":"accomplish them."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Difference between Bugs and Technical Debts"},{"line_number":51,"context_line":"-------------------------------------------"},{"line_number":52,"context_line":""},{"line_number":53,"context_line":"TD are usually trade-offs and oversights in implementation. They offer same level of"},{"line_number":54,"context_line":"funcionality as an optimal implementation, but determine a loss in future"},{"line_number":55,"context_line":"productivity, because of extra costs they allocate on the future in the form of"},{"line_number":56,"context_line":"increased cost of change during evolution and maintenance."},{"line_number":57,"context_line":"A bug is a lack of functionality or error that makes the product less viable"},{"line_number":58,"context_line":"for use, less efficient, or plain broken."},{"line_number":59,"context_line":"Both can probably change their urgency over time, on TD can even change"},{"line_number":60,"context_line":"dramatically, depending on a precise set of parameters: the interest costs and"},{"line_number":61,"context_line":"frequency, and the alterations in their repayment cost (see below)"},{"line_number":62,"context_line":"TDs are expressions of the \"what if\"s. We don\u0027t usually merge something that"},{"line_number":63,"context_line":"doesn\u0027t work, but we may decide to merge something that might not consider all"},{"line_number":64,"context_line":"the cases."},{"line_number":65,"context_line":"When one of these \"maybe\" becomes reality, happens in a way that is notable and"},{"line_number":66,"context_line":"really distrupts someone\u0027s work, we have to deal with it, and that\u0027s not a"},{"line_number":67,"context_line":"technical debt anymore, it becomes a bug."},{"line_number":68,"context_line":"The resulting bug in that case is the descripion of what happened, not what"},{"line_number":69,"context_line":"*could* have happened"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Proposed Change"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_6e8ded79","line":69,"range":{"start_line":24,"start_character":0,"end_line":69,"end_character":21},"updated":"2018-03-28 09:55:04.000000000","message":"Can we please remove the highlighted chunk? We need the policies as brief as possible so that people read them.","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"b1470925e4b72000a2cc76c29af1ba805184909b","unresolved":false,"context_lines":[{"line_number":66,"context_line":"really distrupts someone\u0027s work, we have to deal with it, and that\u0027s not a"},{"line_number":67,"context_line":"technical debt anymore, it becomes a bug."},{"line_number":68,"context_line":"The resulting bug in that case is the descripion of what happened, not what"},{"line_number":69,"context_line":"*could* have happened"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Proposed Change"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_69139c5d","line":69,"updated":"2018-03-28 16:02:56.000000000","message":"OK, good, suggestion, let\u0027s be extremely practical. I am a developer, I\u0027m reading this policy because a) I want to identify my technical debts, b) as a core, I want to also identify someone else\u0027s technical debts, b) someone identified a technical debt in my code and pointed me to this so I can follow the right process. in case a) and b) I want to understand exactly what the community considers a technical debt, in case c) I may want to wonder why my code was considered technical debt. In all the cases we need at least a shared definition of what this project considers technical debt. Does the removal of all this part provide with all the information I need to understand this ? Maybe not, so we would think about replacing all this huge explanation with less explanation. The fact is, TD has no easy definition. I lloked at probably 20 documents that deal with TD and found 20 different and yet valid definitions. If we want to keep this simple, and we make the definition so generic that one may want to look at some document to better understand what is considered TD, we defeat the purpose of simplicity anyway. So removing this may leave people with a lot of questions. Replacing it with an effective definition of what is TD in tripleo may be a better solution, but we have to agree on what TD is first. This is the discussion that I would like to have the most.","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"032985fe2c799a765127262f66889c786f56d2a1","unresolved":false,"context_lines":[{"line_number":66,"context_line":"really distrupts someone\u0027s work, we have to deal with it, and that\u0027s not a"},{"line_number":67,"context_line":"technical debt anymore, it becomes a bug."},{"line_number":68,"context_line":"The resulting bug in that case is the descripion of what happened, not what"},{"line_number":69,"context_line":"*could* have happened"},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Proposed Change"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_bd974e3a","line":69,"in_reply_to":"bf659307_69139c5d","updated":"2018-04-03 16:12:13.000000000","message":"Yea i agree, some people would benefit from reading it. However, the issue i have with putting all the wide context information right here is that it makes the policy less approachable/actionable. IMO it would be nice to have the policy as much of an \"actionable cookbook\" as possible.\n\nPersonally i think the first paragraph, which i didn\u0027t highlight, states the problem enough. The highlighted content here seems more fitting for a knowledge base of some sort. E.g. we also don\u0027t have a policy on bugs, defining what a bug is (i bet the answer could be complex too), and IMO we don\u0027t need it.\n\nWe could move this info somewhere else and link to it, or ideally we could just link to wikipedia, which does talk about tech debt and its impacts. https://en.wikipedia.org/wiki/Technical_debt\n\n(I think a rough common idea of what a tech debt is should be enough for us to roll forward in practical matters, we don\u0027t have to codify a single precise-to-the-word definition IMO.)","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"ea676ad5c0a4723744d0cc5da0b7c1064902858f","unresolved":false,"context_lines":[{"line_number":76,"context_line":"-----------------------"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"When a TD is identified in an implementation, or even when the implementation"},{"line_number":79,"context_line":"is created with the TD in mind, a new bug must be created in launchpad with the"},{"line_number":80,"context_line":"tag `tech-debt`."},{"line_number":81,"context_line":"The TD description should contain at least two sections sections:"},{"line_number":82,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_0ed31162","line":79,"range":{"start_line":79,"start_character":42,"end_line":79,"end_character":46},"updated":"2018-03-28 09:55:04.000000000","message":"should","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"ea676ad5c0a4723744d0cc5da0b7c1064902858f","unresolved":false,"context_lines":[{"line_number":82,"context_line":""},{"line_number":83,"context_line":"1) Debtor design: What did we do that is less than ideal ?"},{"line_number":84,"context_line":"2) Motive: Why didn\u0027t we pursued the ideal implementation in the end ?"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"After the bug has been created, a reference must be added to"},{"line_number":87,"context_line":"the code in the form of a standard openstack FIXME comment::"},{"line_number":88,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_8e2881e2","line":85,"updated":"2018-03-28 09:55:04.000000000","message":"I\u0027d add points 3 and 4 from the next section here as optional / lower priority. Point 5 can probably be dropped (should be covered by point 3).","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"ea676ad5c0a4723744d0cc5da0b7c1064902858f","unresolved":false,"context_lines":[{"line_number":83,"context_line":"1) Debtor design: What did we do that is less than ideal ?"},{"line_number":84,"context_line":"2) Motive: Why didn\u0027t we pursued the ideal implementation in the end ?"},{"line_number":85,"context_line":""},{"line_number":86,"context_line":"After the bug has been created, a reference must be added to"},{"line_number":87,"context_line":"the code in the form of a standard openstack FIXME comment::"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"  # FIXME(\u003cauthor\u003e): tech-debt LP#\u003cbug number\u003e"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_8ec6419a","line":86,"range":{"start_line":86,"start_character":44,"end_line":86,"end_character":48},"updated":"2018-03-28 09:55:04.000000000","message":"should","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"ea676ad5c0a4723744d0cc5da0b7c1064902858f","unresolved":false,"context_lines":[{"line_number":86,"context_line":"After the bug has been created, a reference must be added to"},{"line_number":87,"context_line":"the code in the form of a standard openstack FIXME comment::"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"  # FIXME(\u003cauthor\u003e): tech-debt LP#\u003cbug number\u003e"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The commit message for the code should also contain the Relate-Bug tag::"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_4e226902","line":89,"range":{"start_line":89,"start_character":9,"end_line":89,"end_character":19},"updated":"2018-03-28 09:55:04.000000000","message":"Author info is not important (we share the code), and can be looked up in git if necessary.","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"b1470925e4b72000a2cc76c29af1ba805184909b","unresolved":false,"context_lines":[{"line_number":86,"context_line":"After the bug has been created, a reference must be added to"},{"line_number":87,"context_line":"the code in the form of a standard openstack FIXME comment::"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"  # FIXME(\u003cauthor\u003e): tech-debt LP#\u003cbug number\u003e"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The commit message for the code should also contain the Relate-Bug tag::"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_890e3030","line":89,"updated":"2018-03-28 16:02:56.000000000","message":"This uses the same syntax as the TODO syntax policy generally accepted in the openstack community. You maybe deem it superfluous because it\u0027s already in the bug, but I\u0027m not sure if there is a policy that forbids this (I didn\u0027t find any policy for the TODO either to be honest).","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"032985fe2c799a765127262f66889c786f56d2a1","unresolved":false,"context_lines":[{"line_number":86,"context_line":"After the bug has been created, a reference must be added to"},{"line_number":87,"context_line":"the code in the form of a standard openstack FIXME comment::"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"  # FIXME(\u003cauthor\u003e): tech-debt LP#\u003cbug number\u003e"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The commit message for the code should also contain the Relate-Bug tag::"},{"line_number":92,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_fd2dc6fd","line":89,"in_reply_to":"bf659307_890e3030","updated":"2018-04-03 16:12:13.000000000","message":"Ack sorry, it is actually still enforced by pep8 in some projects, so let\u0027s keep this. (I recall a discussion on the dev list about this being useless but can\u0027t find it either, nevermind.)","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"ea676ad5c0a4723744d0cc5da0b7c1064902858f","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"  Related-Bug: #1234567"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":""},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Technical Debt Evaluation"},{"line_number":98,"context_line":"+++++++++++++++++++++++++"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During or after the review of the debtor code, an evaluation may take place to"},{"line_number":101,"context_line":"add further informations to aid in the management of the technical debt. The"},{"line_number":102,"context_line":"evaluation should at least add two other sections to the bug description."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"3) Consequences: How might this debt impact us going forward? How much is"},{"line_number":105,"context_line":"probable to hit these consenquences in the future ?"},{"line_number":106,"context_line":"4) Full repayment cost: What effort would be required to pursue the ideal implementation ?"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"other sections may be useful for the justification of the evaluation"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"5) Component importance: how much do we really care this component to have as"},{"line_number":111,"context_line":"much ideal implementation as possible."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"A separate document might be created with the most common forms of TD so 3), 4)"},{"line_number":114,"context_line":"and 5) may be omitted, and a TD type in the document referenced from the bug,"},{"line_number":115,"context_line":"further reducing the time required to opend the bug."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Technical Debt Management"},{"line_number":118,"context_line":"+++++++++++++++++++++++++"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"After it has been contracted, there will be three ways to deal with a TD."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"- IGNORE: The cost of the Full Repayment is much higher than the interests, the"},{"line_number":123,"context_line":"  TD item will be ignored until reevaluated, and the interests will be payed for"},{"line_number":124,"context_line":"  the time being."},{"line_number":125,"context_line":"  The bug should be marked as LOW and WONTFIX."},{"line_number":126,"context_line":"- CONVERT: If the cost of the Full repayment is high, but the interest"},{"line_number":127,"context_line":"  represent a tangible threat, a partial fix will be put in place, that doesn\u0027t"},{"line_number":128,"context_line":"  take the time of the full repayment but lowers the interests costs or"},{"line_number":129,"context_line":"  frequency."},{"line_number":130,"context_line":"  The bug should be marked as MEDIUM before the conversion, and LOW/WONTFIX after."},{"line_number":131,"context_line":"- REPAY: the TD will have to be completely fixed, contracting it now"},{"line_number":132,"context_line":"  is a necessity, but the interests will cost too much to keep it for long."},{"line_number":133,"context_line":"  The bug should be marked as HIGH"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Technical Debt Reevaluation"},{"line_number":136,"context_line":"+++++++++++++++++++++++++++"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"After the code will be merged, additional comments should address the"},{"line_number":139,"context_line":"variations in cost for the interests or the full repayment."},{"line_number":140,"context_line":"For example, if we hit the consequences more often and/or they have a large"},{"line_number":141,"context_line":"impact than anticipated, a comment may say so and request a reevaluation."},{"line_number":142,"context_line":"In other cases, when a new, different implementation is built over a code that"},{"line_number":143,"context_line":"has been marked as FIXME: tech-debt, one may want to comment on the bug, to"},{"line_number":144,"context_line":"warn that the cost of a REPAY is going to increase heavily, since now the"},{"line_number":145,"context_line":"repayment must take into consideration the new code build over it."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Reporting Tech Debt"},{"line_number":148,"context_line":"+++++++++++++++++++"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"With the `tech-debt` tag on bugs, we should be able to keep a running track"},{"line_number":151,"context_line":"of the bugs we have labeled and should report on this every release milestone"},{"line_number":152,"context_line":"to see trends around how much is being added and when. As part of our triaging"},{"line_number":153,"context_line":"of bugs, we should strive to add net-zero tech-debt bugs each major release if"},{"line_number":154,"context_line":"possible."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Alternatives"},{"line_number":157,"context_line":"------------"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Alternatively the TD may be tracked inside the code, on a file or directory"},{"line_number":160,"context_line":"dedicated to implement a Technical Debt Register. The register would contain"},{"line_number":161,"context_line":"entries with fields similar to the ones in launchpad, and should be managed"},{"line_number":162,"context_line":"with a specific tool or by enhancing an existing too such as Reno"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Implementation"},{"line_number":165,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"No TD should be left untracked once discovered. Any TD is adding cost to"},{"line_number":168,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":169,"context_line":"full consequences."},{"line_number":170,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":171,"context_line":"feel free to -1 any patches that are adding tech debt without proper analysis."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"Author(s)"},{"line_number":174,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_4e77c903","line":171,"range":{"start_line":95,"start_character":0,"end_line":171,"end_character":78},"updated":"2018-03-28 09:55:04.000000000","message":"I\u0027d also drop all the changes on this highlighted part. The change to the \"tracking code debt\" part, which recommends what info we should put into the TD bug, should be enough to get the necessary info across.","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":10022,"name":"Gabriele Cerami","email":"gcerami@redhat.com","username":"panda"},"change_message_id":"b1470925e4b72000a2cc76c29af1ba805184909b","unresolved":false,"context_lines":[{"line_number":168,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":169,"context_line":"full consequences."},{"line_number":170,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":171,"context_line":"feel free to -1 any patches that are adding tech debt without proper analysis."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"Author(s)"},{"line_number":174,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_291da465","line":171,"updated":"2018-03-28 16:02:56.000000000","message":"The verbosity is probably a side effect of the discussion. There are no replies in the email thread, and the comments in gerrit are a difficult way to discuss, SO I put most of the ideas here. Maybe an etherpad would have been a better way to start the discussion and build the shared solution.\nWith regards to dropping all of this, I think part of the reason why the original policy was not much used, was because it wasn\u0027t clear what to do with the informations provided. It goes to motivation. In the scenarios a) and b) from above, I would care to see how my information is then processed. If I have to spend time in opening a bug that is really just there to make me declare that my code is not optimal, I\u0027d like to know if and how those informations are used. From another perspective, in scenario b) from above (the core) I would like then to know what to do with the information provided in the TD. What should I do with those bullet points ? How do I deal with TD ? What is the purpose of this process ? I have a bunch of TD in my queue, what now ? Is there a better place to write this ? Or we want to leave the second part to the experience of the bug evaulator ? I\u0027d like to discuss and write about the whole process of fixing a TD.","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"032985fe2c799a765127262f66889c786f56d2a1","unresolved":false,"context_lines":[{"line_number":168,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":169,"context_line":"full consequences."},{"line_number":170,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":171,"context_line":"feel free to -1 any patches that are adding tech debt without proper analysis."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"Author(s)"},{"line_number":174,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_f8d4f449","line":171,"in_reply_to":"bf659307_291da465","updated":"2018-04-03 16:12:13.000000000","message":"Personally i\u0027d prefer to leave it out of the policy, or if need be i\u0027d really slim it down to a few sentences. (We also don\u0027t have a policy describing bug lifecycle AFAIK and i don\u0027t think we miss it.)\n\nTS;WRM (too short; wanna read more):\n\nThe described TD workflow of \"ignore/convert/repay\" is pretty much the \"ignore / partial fix (could call it \u0027convert\u0027 too) / fix\" workflow we\u0027ve been applying to bugs already. It\u0027s also common that people add more evaluation info or new insights on existing bugs, retarget/reprioritze, all of this is emergent/natural behavior where we haven\u0027t had a need for policy so far. And i hope the same would emerge with TD as well (with the catch that TD is likely to get somewhat less attention overall, similarly to bugs that don\u0027t outright break the world).\n\nAlso TBH i don\u0027t see a clear boundary between reporting and evaluation as you put it, IMO the evaluation info (points 3, 4, 5) can be provided right away when reporting, or it can also be provided later, in case the reporter doesn\u0027t have enough info or context. The same is already happening with bugs too.\n\nFrom my view, the most troublesome thing, which is hard to put in policy, is whether someone actually *carves out the time* for addressing the tech debt with \"wontfix/semi-fix/fix\" activities.","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"},{"author":{"_account_id":8042,"name":"Jiří Stránský","email":"jistr@redhat.com","username":"jistr"},"change_message_id":"f2affeab05f6a9a461cda0676d766559ce13804f","unresolved":false,"context_lines":[{"line_number":92,"context_line":""},{"line_number":93,"context_line":"  Related-Bug: #1234567"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":""},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Technical Debt Evaluation"},{"line_number":98,"context_line":"+++++++++++++++++++++++++"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"During or after the review of the debtor code, an evaluation may take place to"},{"line_number":101,"context_line":"add further informations to aid in the management of the technical debt. The"},{"line_number":102,"context_line":"evaluation should at least add two other sections to the bug description."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"3) Consequences: How might this debt impact us going forward? How much is"},{"line_number":105,"context_line":"probable to hit these consenquences in the future ?"},{"line_number":106,"context_line":"4) Full repayment cost: What effort would be required to pursue the ideal implementation ?"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"other sections may be useful for the justification of the evaluation"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"5) Component importance: how much do we really care this component to have as"},{"line_number":111,"context_line":"much ideal implementation as possible."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"A separate document might be created with the most common forms of TD so 3), 4)"},{"line_number":114,"context_line":"and 5) may be omitted, and a TD type in the document referenced from the bug,"},{"line_number":115,"context_line":"further reducing the time required to opend the bug."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Technical Debt Management"},{"line_number":118,"context_line":"+++++++++++++++++++++++++"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"After it has been contracted, there will be three ways to deal with a TD."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"- IGNORE: The cost of the Full Repayment is much higher than the interests, the"},{"line_number":123,"context_line":"  TD item will be ignored until reevaluated, and the interests will be payed for"},{"line_number":124,"context_line":"  the time being."},{"line_number":125,"context_line":"  The bug should be marked as LOW and WONTFIX."},{"line_number":126,"context_line":"- CONVERT: If the cost of the Full repayment is high, but the interest"},{"line_number":127,"context_line":"  represent a tangible threat, a partial fix will be put in place, that doesn\u0027t"},{"line_number":128,"context_line":"  take the time of the full repayment but lowers the interests costs or"},{"line_number":129,"context_line":"  frequency."},{"line_number":130,"context_line":"  The bug should be marked as MEDIUM before the conversion, and LOW/WONTFIX after."},{"line_number":131,"context_line":"- REPAY: the TD will have to be completely fixed, contracting it now"},{"line_number":132,"context_line":"  is a necessity, but the interests will cost too much to keep it for long."},{"line_number":133,"context_line":"  The bug should be marked as HIGH"},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"Technical Debt Reevaluation"},{"line_number":136,"context_line":"+++++++++++++++++++++++++++"},{"line_number":137,"context_line":""},{"line_number":138,"context_line":"After the code will be merged, additional comments should address the"},{"line_number":139,"context_line":"variations in cost for the interests or the full repayment."},{"line_number":140,"context_line":"For example, if we hit the consequences more often and/or they have a large"},{"line_number":141,"context_line":"impact than anticipated, a comment may say so and request a reevaluation."},{"line_number":142,"context_line":"In other cases, when a new, different implementation is built over a code that"},{"line_number":143,"context_line":"has been marked as FIXME: tech-debt, one may want to comment on the bug, to"},{"line_number":144,"context_line":"warn that the cost of a REPAY is going to increase heavily, since now the"},{"line_number":145,"context_line":"repayment must take into consideration the new code build over it."},{"line_number":146,"context_line":""},{"line_number":147,"context_line":"Reporting Tech Debt"},{"line_number":148,"context_line":"+++++++++++++++++++"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"With the `tech-debt` tag on bugs, we should be able to keep a running track"},{"line_number":151,"context_line":"of the bugs we have labeled and should report on this every release milestone"},{"line_number":152,"context_line":"to see trends around how much is being added and when. As part of our triaging"},{"line_number":153,"context_line":"of bugs, we should strive to add net-zero tech-debt bugs each major release if"},{"line_number":154,"context_line":"possible."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"Alternatives"},{"line_number":157,"context_line":"------------"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"Alternatively the TD may be tracked inside the code, on a file or directory"},{"line_number":160,"context_line":"dedicated to implement a Technical Debt Register. The register would contain"},{"line_number":161,"context_line":"entries with fields similar to the ones in launchpad, and should be managed"},{"line_number":162,"context_line":"with a specific tool or by enhancing an existing too such as Reno"},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"Implementation"},{"line_number":165,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"No TD should be left untracked once discovered. Any TD is adding cost to"},{"line_number":168,"context_line":"the project, and contracting it cannot be done without understanding the"},{"line_number":169,"context_line":"full consequences."},{"line_number":170,"context_line":"Core reviewers should request that any tech debt be appropriately tracked and"},{"line_number":171,"context_line":"feel free to -1 any patches that are adding tech debt without proper analysis."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"Author(s)"},{"line_number":174,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bf659307_dd12a909","line":171,"range":{"start_line":95,"start_character":0,"end_line":171,"end_character":78},"in_reply_to":"bf659307_4e77c903","updated":"2018-03-28 12:36:43.000000000","message":"As with nearly anything, i don\u0027t mean to be absolute about this :) But the current state of the patch seems indeed way too verbose. I don\u0027t think we need to explain things like what tech debt is etc. Let\u0027s think that a developer posted a patch and was told they need to track related tech debt, and got referred to this policy -- what would be the (minimal) thing they need to read to progress forward? That\u0027s how i\u0027d approach it, anyway..","commit_id":"62b59fb43ca206fcf0553f4f6bf4b7a20769bb12"}]}