What is the chapter's clear and approachable take away message?
“always consider the release process used by a software project, whichever software analytics task you are involved in.”
Accessible?
Is the chapters written for a generalist audience (no excessive use of technical terminology) with a minimum of diagrams and references?How can it be made more accessible to generalist?
Generally yes. The section “How the Version Control System can Help” is a bit hard to read though. For example, the reader might not understand the role of pre-release defects.
Size?
Is the chapter the right length?Should anything missing be added?Can anything superfluous be removed (e.g. by deleting some section that does not work so well or by using less jargon, less formulae, lees diagrams, less references).? What are the aspects of the chapter that authors SHOULD change?
The length is fine. I have only few comments: (1) The alternative title does not seem completely aligned with the chapter content as the whole chapter deals with defects models and not in general with software analytics. I would drop it or maybe compound the two titles into something like “How the Release Process Impacts on Defect Prediction Modeling”; (2) The paragraph at the end of the first section sounds a bit academic. I would anticipate it soon after the student’s case and rephrase it a bit explaining what is in general the problem in analyzing defect data across releases. Perhaps just removing the sentence “The following sections discuss how steps (1) and (2) can go wrong when the release process of a project is not taken into account, and what could be done to resolve these problems.” and rephrasing the second sentence can be enough. (3) I would suggest saying explicitly “file-level defect prediction model” (i.e., removing the brackets around “file-level”) as there are other defect prediction models that do not use file characteristics. (e.g., Lyu’s models). In fact releases can impact on other types of defect models too. Maybe I it would be good to stress that the file-level defect models are one example which releases have impact on.
Gotta Mantra?
We encouraged (but did not require) the chapter title to be a mantra or something cute/catchy, i.e., some slogan reflecting best practice for data science for SE? If you have suggestion for a better title, please put them here.
More than a mantra, I would suggest to align the title with the content of the chapter. For example “How the Release Process Impacts on Defect Prediction Modeling”
Best Points
What are the best points of the chapter that the authors should NOT change?
The student case and the last section “How the Version Control System can Help.”
Title of chapter
Are your Post-release Defects Post-al? (or: How the Release Process Impacts your Software Analytics)
URL to the chapter
https://github.com/ds4se/chapters/blob/d657de724e433d8a67c15aa1af3bd7da9e25586a/bramadams/releng.md
Message?
What is the chapter's clear and approachable take away message? “always consider the release process used by a software project, whichever software analytics task you are involved in.”
Accessible?
Is the chapters written for a generalist audience (no excessive use of technical terminology) with a minimum of diagrams and references? How can it be made more accessible to generalist? Generally yes. The section “How the Version Control System can Help” is a bit hard to read though. For example, the reader might not understand the role of pre-release defects.
Size?
Is the chapter the right length? Should anything missing be added? Can anything superfluous be removed (e.g. by deleting some section that does not work so well or by using less jargon, less formulae, lees diagrams, less references).? What are the aspects of the chapter that authors SHOULD change? The length is fine. I have only few comments: (1) The alternative title does not seem completely aligned with the chapter content as the whole chapter deals with defects models and not in general with software analytics. I would drop it or maybe compound the two titles into something like “How the Release Process Impacts on Defect Prediction Modeling”; (2) The paragraph at the end of the first section sounds a bit academic. I would anticipate it soon after the student’s case and rephrase it a bit explaining what is in general the problem in analyzing defect data across releases. Perhaps just removing the sentence “The following sections discuss how steps (1) and (2) can go wrong when the release process of a project is not taken into account, and what could be done to resolve these problems.” and rephrasing the second sentence can be enough. (3) I would suggest saying explicitly “file-level defect prediction model” (i.e., removing the brackets around “file-level”) as there are other defect prediction models that do not use file characteristics. (e.g., Lyu’s models). In fact releases can impact on other types of defect models too. Maybe I it would be good to stress that the file-level defect models are one example which releases have impact on.
Gotta Mantra?
We encouraged (but did not require) the chapter title to be a mantra or something cute/catchy, i.e., some slogan reflecting best practice for data science for SE? If you have suggestion for a better title, please put them here. More than a mantra, I would suggest to align the title with the content of the chapter. For example “How the Release Process Impacts on Defect Prediction Modeling”
Best Points
What are the best points of the chapter that the authors should NOT change? The student case and the last section “How the Version Control System can Help.”