SortingHat: Wizardry on Software Project Members

Moreno, David; Dueñas, Santiago; Cosentino, Valerio; Fernández, Miguel Angel Castro; Zerouali, Ahmed; Robles, Gregório; González-Barahona, Jesús M.

doi:10.1109/icse-companion.2019.00036

Cited by 4 publications

(2 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The tools that we studied are Codeface [11], Codeface4Smells [23], GrimoireLab [18,7] SmartSHARK, [25,24] and PyDriller [22]. We now present our observations regarding the strengths and weaknesses of these tools in terms of their design choices and note, throughout the work, lessons learned by the authors of Alitheia Core [10] presented in [16].…”

Section: Studied Tools and Lessons Learnedmentioning

confidence: 99%

“…As a means to mitigate this risk, relying on and contributing work to open source communities that more carefully assess the health of projects and try to maintain them, such as the Apache Software Foundation, ROpenSci 16 , and CHAOSS 17 may be an important consideration. For example, ROpenSci accepts R packages via a streamlined peer review process and, for accepted packages, provides community support, package promotion, and fast-track publication to journals 18 .…”

Section: Other Design Decisionsmentioning

confidence: 99%

See 1 more Smart Citation

Building the MSR Tool Kaiaulu: Design Principles and Experiences

Paradis

Kazman

2022

Software Architecture

View full text Add to dashboard Cite

Background: Since Alitheia Core was proposed and subsequently retired, tools that support empirical studies of software projects continue to be proposed, such as Codeface, Codeface4Smells, Grimoire-Lab and SmartSHARK, but they all make different design choices and provide overlapping functionality. Aims: We seek to understand the design decisions adopted by these tools-the good and the bad-along with their consequences, to understand why their authors reinvented functionality already present in other tools, and to help inform the design of future tools. Method: We used action research to evaluate the tools, and to determine a set of principles and anti-patterns to motivate a new tool design. Results: We identified 7 major design choices among the tools: 1) Abstraction Debt, 2) the use of Project Configuration Files, 3) the choice of Batch or Interactive Mode, 4) Minimal Paths to Data, 5) Familiar Software Abstractions, 6) Licensing and 7) the Perils of Code Reuse. Building on the observed good and bad design decisions, we created our own tool architecture and implemented it as an R package. Conclusions: Tools should not require onerous setup for users to obtain data. Authors should consider the conventions and abstractions used by their chosen language and build upon these instead of redefining them. Tools should encourage best practices in experiment reproducibility by leveraging self-contained and readable schemas that are used for tool automation, and reuse must be done with care to avoid depending on dead code.

show abstract