-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathWSL_reviews_AA_distributed_dev.txt
152 lines (81 loc) · 7.14 KB
/
WSL_reviews_AA_distributed_dev.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
RESPONSE
Dear Carlos,
We have addressed the suggested modifications in the attached manuscript,
as described below. We thank the reviewers for their comments, which
helped bring the quality of the manuscript to another level.
Suggestion: As a reviewer requested, it would be interesting if the authors could
provide some comparisons between the use of AA and the approaches used by
some large FOSS projects (see reviewer's comments for details). This could
be done in the discussion section.
Response: We have addressed this point across the entire paper. We have
improved overall textual clarity regarding the place of AA in the
context of existing FOSS practice. In the previous work section, we included a
review of the practices of a few large FOSS projects, mentioning drawbacks
and how AA fits in. We have improved the description of AA in section 2 so
people can see this more easily.
Suggestion:
Also, it has been mentioned that the
paper needs an English revision. Please do a final review on grammar and
clarity issues.
Response: We have performed a careful and thorough revision to this
Suggestion: Provide "evidence that these projects have used the AA methodology"
Response: We modified the text to include references to this.
Suggestion: Expand the list of references as it is
rather short. A few examples of papers that could be considered are
http://dx.doi.org/10.1016/j.jsis.2012.07.004,
http://revistas.facecla.com.br/index.php/reinfo/article/view/751/pdf_9,
http://misq.org/value-cocreation-and-wealth-spillover-in-open-innovation-alliances.html,
Kevin Crowston and James Howinson's work, and Siobhan O'Mahony's as well.
Response: we have expanded the references section in view of
these references.
Suggestion: Finally, consider changing the tile as reviewer 2 requested. As of now, it
seems like a grammar mistake. I recommend "The Algoritmic Auto-regulation
Software Development Methodology".
Response: Done, but removed the hyphen in "Auto-regulation"
http://www.merriam-webster.com/medical/autoregulation
We have also addressed the remaining suggestions from the reviewers by
incorporating improvements throughout the text.
Best regards,
____________________________________
For RESI, editor asked:
As a reviewer requested, it would be interesting if the authors could
provide some comparisons between the use of AA and the approaches used by
some large FOSS projects (see reviewer's comments for details). This could
be done in the discussion section. Also, it has been mentioned that the
paper needs an English revision. Please do a final review on grammar and
clarity issues. Furthermore, please provide "evidence that these projects
have used the AA methodology", and expand the list of references as it is
rather short. A few examples of papers that could be considered are
http://dx.doi.org/10.1016/j.jsis.2012.07.004,
http://revistas.facecla.com.br/index.php/reinfo/article/view/751/pdf_9,
http://misq.org/value-cocreation-and-wealth-spillover-in-open-innovation-alliances.html,
Kevin Crowston and James Howinson's work, and Siobhan O'Mahony's as well.
Suggestion: Finally, consider changing the tile as reviewer 2 requested. As of now, it
seems like a grammar mistake. I recommend "The Algoritmic Auto-regulation
Software Development Methodology".
Response: Done, but removed the hyphen in "Auto-regulation"
http://www.merriam-webster.com/medical/autoregulation
////////////////////////////////////////////////////////////////////////////////////////////////
REVIEW0:
The paper introduces a methodology to be applied to GSD and distributed software development environments.
All in all, the contribution is very promising. It includes a methodology and a (free software) tool that has been already tested. The part that is missing to be a complete study is an evaluation of the tool; I encourage the authors to perform it to further this research.
I would recommend the authors to change the title. As by now it seems like a typo with the "AA". A better one would be "The AA Distributed Software Develompent Methodology" or even better "The Algoritmic Auto-regulation Software Development Methodology".
I have a bunch of questions after reading the paper:
* It is not clear to me why the methodology has only to be followed during two hours and not during the complete working session.
* How is the review performed? Do developers get a bunch of status messages from their peers at once every day or every once and then?
I don't understand what Tables 1 and 2 add to the paper. Yes, the development team is very experienced... but what does this add to AA?
The conclusion is sometimes repetitive and could be shortened.
Regarding footnotes: Footnotes belong just after the last word; don't leave a space before a footnote and don't put a colon in between.
The English needs some polishing, especially have a look at the "to" and "on", etc.
REVIEW1:
This is an interesting paper about the AA methodology and its application to several Global Software Development Projects. The methodology is supported by experience reporting, which can be viewed on the Web. This reviewer likes the demonstration of the idea in addition to the idea itself.
Section 2 on related work could be strengthened. It devotes too much space to the GSD concept, and only cites three other methodologies for distributed development.
In a future version of the paper, it would be useful to see some comparisons between the use of AA and the approaches used by some large FOSS projects. Does AA help new project members learn the code more quickly? Can existing team members find problems in the code by reviewing the material submitted by a team member? Does AA impose a significant overhead cost for each developer on the project, both on creating his own logs and on reviewing the material created by his teammates? This evaluation process would be highly valuable.
Unfortunately, the writing needs a lot of English language editing to make it suitable for final publication. In its current form, the paper could be used for workshop discussion, but it can't be published more widely without improving the quality of the writing, inserting the references, and correcting GCD to GSD, among other things.
If the PC can help the authors with their writing, then I would like to see this paper be accepted.
REVIEW2:
The article presents a methodology, called AA, for coordinating distributed team work. My recommendation for this article was mildly rejected due to the following problems:
* The article does not make it clear how the AA methodology can help a free software community that alreaady uses a bugtracker system + mail lists + IRC + version control.
* Table 1 lists applications and commiters. From this table it is not possible to infer the quality of the contributions or how the AA methodology have influenced the processes.
* Table 2 lists projects created by Lab Macambira. There is no evidence that these projects have used the AA methodology.
* The bibliography contains only 9 references and most of them are outdated.