Proceedings of the Third International Workshop on Managing Technical Debt
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
Welcome to the Third International Workshop on Managing Technical Debt, MTD 2012, co-located with the 34rd International Conference on Software Engineering at Zurich, Switzerland. This is the second year that we are holding this workshop co-located with ICSE. The technical debt metaphor has gained significant traction in the software development community as a way to understand and communicate issues of intrinsic quality, value, and cost in the past few years. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a debt: on which has to be paid and which should be repaid at some point for the long-term health of the project. Little is known about technical debt, beyond feelings and opinions. The software engineering research community has an opportunity to study this phenomenon and improve the way it is handled. We can offer software engineers a foundation for managing such tradeoffs based on models of their economic impacts. The first workshop on technical debt was held at the Software Engineering Institute in Pittsburgh on June 2-3, 2010 with the goal of understanding open research questions related to managing technical debt in software. The goal of the second workshop in 2011 was to come up with a more in-depth understanding of technical debt, its definition(s), characteristics, its different forms. The discussions of the second workshop proved that there is an increasing need to formulate a clear research agenda that is well-aligned with the industry challenges. The goal of this third workshop is to discuss managing technical debt as a part of the research agenda for the software engineering field, in particular focusing on eliciting, visualizing debt, and creating pay-back strategies. The software engineering community is in the process of building the research agenda around managing technical debt. The purpose of these initial workshops is to bring forward work in progress and ideas from the entire community to collectively vet their validity for the future. In order to support this goal, submissions were open to the members of the program committee as well as the organizing committee. Following a conflict of interest policy, the papers were selected after a peer review by at least three members of the program committee. For this third workshop we accepted 7 full research and 4 short position papers. The accepted submissions cover a range of topics such as: estimating the size and cost of debt, eliciting and visualizing debt, the technical debt landscape ranging from technical debt in software ecosystems to requirements, design and build, and the relationship between code defects and debt. Managing technical debt is a broad concern of software engineering that blends research and practice. This can be seen from the program and those involved in the workshop program selection process. To encourage interactive discussion, foster brainstorming and community building the workshop will consist of only short presentations from the accepted papers. These short presentations will provide a basis for the participants to investigate further open research questions and challenges in practice. It is for that purpose the program includes sessions dedicated to open discussion.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.002 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.001 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.000 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it