./bener/bayesianNets.md

[andymeneely]

After review, relabel to 'reviewTwo'. After second review, relabel to 'EditorsComment'.

[andymeneely]

Title of chapter

The Bayes Factor in Software Engineering Practice

URL to the chapter

https://github.com/ds4se/chapters/blob/master/bener/bayesianNets.md

Message?

What is the chapter's clear and approachable take away message?

Bayesian networks are uniquely equipped to model causal relationships, which make them good choices for predicting SE data.

Accessible?

Is the chapters written for a generalist audience (no excessive use of technical terminology) with a minimum of diagrams and references?

Yes, it's pretty good for this.

How can it be made more accessible to generalist?

I think an interesting example at the beginning of causal relationships would be good. Most people don't think about such things. Like maybe: low atmospheric pressure causes storms, which in turn increases rainfall; which mean you can predict rainfall better by incorporating domain knowledge (in this case meterology) to individual factors relate to each other.

Size?

Is the chapter the right length?

Yep, right length

Should anything missing be added?

Need some section headers. Really short sections are okay for this kind of format.

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).?

I could use less on the details of the results so as to focus on the ideas.

What are the aspects of the chapter that authors SHOULD change?

Nothing glaring, just break it up with some headers and fill out the ideas in each section.

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.

If It's Software Engineering, It's (Probably) Bayesian

Best Points

What are the best points of the chapter that the authors should NOT change?

The idea of causal models as opposed to just regular correlations is really the most important idea here.

[abramhindle]

Daryl Posnett reviewed this in this issue: https://github.com/ds4se/chapters/issues/116

[lauriew]

@darylposnett review copied here by @lauriew

Title of chapter

The Bayes Factor in Software Engineering Practice URL to the chapter

https://github.com/ds4se/chapters/blob/master/bener/bayesianNets.md Message?

Bayes Networks are able to model causal relationships which could be useful in software engineering research. Accessible?

In general yes. Perhaps an example of causality may help to elucidate the chapter. Size?

The chapter is not too long, however, The text is dense in places and probably could either be broken up or thinned somewhat. the graph is somewhat complex and is not well explained. The text could be broken up somewhat with section headers and perhaps the graph could be incorporated into an example. Gotta Mantra? Best Points

Clearly causality is a key element. @abramhindle

[lauriew]

@aysebener You now have two reviews. As we said in a prior email, we are asking for new versions of the chapters by January 13.

Here are some comments I made while reading the chapter in addition to the other reviewers:

• I would not assume that people know the AI acronym. Why not just define it?
• I feel like a one sentence into to BN would be helpful for accessibility.
• "Earlier work on BNs in software engineering included validating dependability of software based systems, estimating system reliability, making resource decisions, modeling project trade-off, and estimation software effort [4, 5, 6, 7, 8, 9]." Have these all done the job of "predicting the future" as you describe in the prior paragraph? It would be good to clarify.
• Figure 1 is too fuzzy. "We built this causal network by modeling the relationship between major processes of a software development life cycle (SDLC) and residual defects (Figure 1). " Please explain Figure 1 much more than this one sentence, including the components and Model 1 versus Model 2 versus Model 3. It seems you just put that figure in there from some other source and it doesn't fit in this chapter unless you will explain it.
• Under Figure 1 -- surveys of what?
• "the effects of software processes and their relationships on software reliability are worth the investigation" -- what is your criteria/measurement for "worth the investigation"?
• "Our experience in building BNs in different organizations showed that there are not a specific set of metrics that should be used in any software development organization to predict reliability in terms of post-release defects. However, it would be useful to extract a common set of metrics that are significant indicators of post-release defects. " What is the different between "not a specific set of metrics" (which are said to be bad) and "a common set of metrics" (which are said to be good)? How would be know which was which?
• You don't say what Pred(k) is.
• "the findings of the systematic review" ... put [3] in the text. All in all, this chapter reads like you took another paper and deleted a lot of it to make it shorter. In teh process, this chapter is hard to read. Please take a step back and read this chapter with a "beginner mind."