Final Submission TODOs

[eddieantonio]

• [x] Compare online version to offline version and merge (2 hrs)
• [x] Add missing references (4 hrs)
  • [x] code_swarm http://dl.acm.org/citation.cfm?id=1638611.1639212
  • [x] Gource http://dl.acm.org/citation.cfm?id=1869554
  • [x] SourceVis http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6650527
• [x] Clarify how long it takes to run (2 hrs)
• [x] Fix typographical errors (2 hrs)
• [x] Manual author merging (#35) (10 hrs)
• [x] Explain the paper's motivation (lack of semantically aware evolution) (2 hr)
• [x] Emphasize visualization choices {make it a VISSOFT paper!} (4 hrs)
  • [x] Take a read of the code_swarm paper
  • [x] Why did we choose these visualizations?
  • [x] Why did we chose the colours?
  • [x] Use of axises for time and type.
  • [x] Why does time increase from left to right?
  • [x] Why are types sorted from top-to-bottom in decreasing order of usage?
  • [x] Why are the bars stacked?
  • [x] Why aren't they presented in a different way?
  • We may want to cite some Edward Tufte stuff.
  • [x] Method of subselection and visualization of type change?
• [x] Explain why our method is more effective than others (e.g., GitHub) [4 hrs]
• [x] Explain how the technique scales for projects of large lifespans (2 hr)
• [x] Explain our assumption about merge commits, and why it's okay to make such an assumption {perhaps find a reference on what happens inside a merge commit} (2 hrs)
  • Explain that this is not affected by fast forward (no commit is made)
  • Differentiate this between a true merge
  • Go through merge cases case by case
  • no merge conflict (fast forward or trivial merge)
    • case 1: count the merge => double count parents
    • case 2: do not count the merge => changes recorded in parents
  • merge conflict
    • case 1: count the merge => double count parents
    • case 2: do not count the merge => we miss changes fixing the merge, we often results in DELETED from one of the branches
• [x] Fix poor wording (2 hrs)
  • [x] "our technique can be adapted to other languages"
• [x] [Decompose] Provide screenshots of TypeV (4 hrs)
• [x] Chose a different focus for evaluation? (4 hrs)
• [x] Discuss runtime type inference
• [x] Clarify that Git and GitHub are different, and that GitHub tools are just available {current wording is inappropriate} (2 hrs)
• [x] Explain the full capability of the file format? (2 hrs)
• [x] Fix missing footnote {apparently?} (2 hrs)
• [x] Remove paragraph explaining lack of class knowledge
• [x] "It is not clear even if these visualizations are effective for software visualization" We'd need a user study, which we don't really have time for!
• [x] Explain the density plots in the text or remove them altogether (4 hrs)
• [x] Revamp the anecdotal section (make it flow better) (2 hrs)
• [x] Update screenshots
• [x] Incorporate author merging into the paper
  • [x] Update tables with right number of authors
• [x] Make references to all research questions when they are answered
• [x] Optional "hanging" deletions view to match GH's code frequency view
• [x] Add a screenshot of author merging
• [x] Write a summary of what has change to the shepard.

---

• [x] After deadline Make a narrated screencast #29

[mdfeist]

For the missing references the first two for sure. They are the other visualizing tools that Ian talked about and showed during our presentation. I think they are cited but improperly, since I believe Ian cited the website instead of the article.

[eddieantonio]

SourceVis should be cited for sure because of its package (SPEV) and system class evolution (SCEV) views. These are most similar to TypeV in function, and should be at least mentioned in our paper.

[eddieantonio]

Also, we may want to cite:

• J. Sillito, G. Murphy, and K. De Volder. Questions programmers ask during software evolution tasks. In Proc. of FSE. ACM, 2006.

@inproceedings{sillito2006,
  location = {{New York, NY, USA}},
  title = {Questions {{Programmers Ask During Software Evolution Tasks}}},
  isbn = {978-1-59593-468-0},
  url = {http://doi.acm.org/10.1145/1181775.1181779},
  doi = {10.1145/1181775.1181779},
  abstract = {Though many tools are available to help programmers working on change tasks, and several studies have been conducted to understand how programmers comprehend systems, little is known about the specific kinds of questions programmers ask when evolving a code base. To fill this gap we conducted two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a medium-sized code base. The other study involved industrial programmers working on their own change tasks on code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on howthey go about discovering that information. Based on this analysis we catalog and categorize 44 different kinds of questions asked by our participants. We also describe important context for how those questions were answered by our participants, including their use of tools.},
  timestamp = {2016-06-15T15:12:17Z},
  booktitle = {Proceedings of the 14th {{ACM SIGSOFT International Symposium}} on {{Foundations}} of {{Software Engineering}}},
  series = {SIGSOFT '06/FSE-14},
  publisher = {{ACM}},
  author = {Sillito, Jonathan and Murphy, Gail C. and De Volder, Kris},
  urldate = {2016-06-15},
  date = {2006},
  pages = {23--34},
  keywords = {change tasks,development tools,empirical study,grounded theory,program comprehension,software evolution}
}

[mdfeist]

Latex warnings:

Warning--empty year in sourcevis Warning--empty journal in codeswarm Warning--empty year in codeswarm Warning--empty year in gource

[eddieantonio]

@mdfeist @watts1 Do you reckon it's done?