Thesis Meeting | Feb 24, 2024 - 2:30pm - Teams

[samm82]

Defining "Flaws, etc."

My work and next steps on #140

1. I want to use something like Table 4.3 to list how flaws manifest in the literature and reverse engineer our criteria for what a flaw actually is. Which is a better way to do this?
   1. Move this table to the Terminology section, expand on it, then reference it in the LaTeX Commands section
   2. Have two separate tables: one for defining these categories (in the Terminology section) and another for specifying the possible LaTeX codes (in the LaTeX Commands section)

2.
3. RE: the edge case when discussing a "flaw between two sources", I personally think we should stick with "discrepancy" here. "Inconsistency" is good, but not only is it similar to our existing "contradiction" specialization, it also implies that the only issue is that the two sources are different. I think using "discrepancy" would also cover the case where both sources are incorrect without specifying if this is the case (as this may require further investigation to establish). I will of course include this when define these terms in the Terminology section.

Low Priority

1. Is the forward reference in the Q3 screenshot above OK? Should I clarify it with "defined in" or something like that, or just say something like "software standards"?
2. Is it OK to use nameref in the context of tables/figures (such as the table screenshot above) for brevity?
3. Optional: Minor items from Implement Additional Feedback on Methodology Section #143

[samm82]

After a BIG bunny trail, we only resolved point 1! The rest are non-blocking and can be moved to next week's meeting, and our conversation has been documented in #140 and #153, so we can close this issue!

The main takeaway is that I should take approach 1.i, which will have the added benefits of:

• not putting orthogonal information side-by-side, and
• being able to use these codes in my thesis (as opposed to just behind the scenes) to improve readability (especially when describing flaws within subsets of testing such as compatibility testing).

While defining the two views of our flaws, I should really explain them in the context of "what question do these categorizations answer?" This will (hopefully) help us find better names than syntax/semantics. 😅 "Citation flaw" also got critiqued as being too vague/unclear; the process of defining these flaw types should help nail down a better term if there is one (one that just came to mind would be "traceability flaw").

---

When I get around to working on the "Observed Flaws" section, I should reformat the sections focused on subsets (e.g., compatibility testing) to reduce their walls of text, likely by using a more "formulaic" approach (e.g., Term: … // Def: … // Flaws: …). I could perhaps use color to emphasize points of interest, although one critique we got on our paper submission was that we shouldn't use color. 😂 I should also describe the flaws right off the bat instead of letting the reader figure them out (as I have been doing). 😬There are many ways to do this; right now, I think the best options are:

1. make mini-summary tables for these subsets, or
2. list all flaws found within the subset (e.g., one approach category contradiction, two synonym overlaps, and one synonym redundancy).