Differences

This shows you the differences between two versions of the page.

--- public:rem4:rem4-15:review_of_p5 [2015/09/28 11:08] – thorisson2
+++ public:rem4:rem4-15:review_of_p5 [2024/04/29 13:33] (current) – external edit 127.0.0.1
@@ Line 2: / Line 2: @@
-Example of an excellent Introduction:
+Example of a good Introduction:
+**Title**
+Analyzing Trends in User Attitude Towards Real-World Software: Do Users Hate Change?
+**Abstract**
+Today´s software rarely stays the same for very long.  Programs are constantly
+updated to fix bugs, add features, and clean up code.  One of the main goals of
+user-facing software should be to make its users happy, so it seems obvious that
+each update of a program should improve the software and make its users happier.
+However, in the real world software updates often seem to be accompanied by user
+complaints of needless change and new bugs.  For developers it can be difficult
+to tell whether these complaints come from a vocal minority or if they reflect
+the general feelings of users.  Much previous work has been done on mining social media to measure sentiment on specific topics (like tobacco products) and to track events over time (such as influenza cases).  However, to our knowledge no one has analyzed a large amount of social media data to determine if ongoing
+development of popular software products is actually making users happier.
+In this study we sampled a large amount of historical Twitter data about
+user-facing software such as Firefox, Tweetbot, and KDE.  We used sentiment
+analysis to gauge the happiness of users over time, and compared this with dates
+of product updates to test whether software updates affect the feelings of
+users.  The results are mostly disheartening: we found statistically significant
+negative spikes in sentiment shortly after releases for the majority of
+projects.  The projects whose updates did not cause negative sentiment spikes
+may warrant further investigation to uncover lessons about how to craft software
+that avoids angering its users.
+**Introduction**
 //Most user-facing software in the modern world requires constant maintenance. Software updates change programs in many ways, such as: adding new features, fixing bugs, patching security holes, improving performance, and cleaning up internal code.
@@ Line 23: / Line 52: @@
   * ... limited number of references (three - good number, and good places to give them), exactly the way this should be in the Intro.
   * Length of Intro just right.
-  * No repeating verbatim text from the Abstract.
+  * A bit too similar to the Abstract.
   * Perhaps a bit too much to have three paragraphs relating to the structure of the paper, but very well done and forgivable.
-  * Simply works!
 \\
 \\
@@ Line 74: / Line 103: @@
 Section~\ref{sec:conclusion}.//
+  * Clear motivation
+  * Clear and highlighted relationship to prior work (remains to be filled in, however - but idea is perfectly exemplified) while giving only a ...
+  * ... limited number of references, exactly as it should be in the Intro.
+  * Length of Intro just right.