This repository has been archived by the owner on May 19, 2023. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 6
/
reviewer-response.txt
134 lines (72 loc) · 10.9 KB
/
reviewer-response.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
Dear Dr. Markel,
Thanks for your engagement with our paper, "Ten simple rules for collaborative lesson development." We appreciated the reviewer's engagement with the piece, and were gratified to see that the ideas generally resonated with them. Please accept our revised version and we look forward to hearing from you soon.
We have provided point-by-point reviewer responses below.
Sincerely,
Gabriel A. Devenyi, Rémi Emonet, Rayna M. Harris, Kate L. Hertweck, Damien Irving, Ian Milligan, and Greg Wilson
# Reviewer #1
Reviewer #1: The "Ten simple rules for collaborative lesson development" article presents a much needed perspective on teaching materials, and may be just the push needed to move lecturers to move their content online and open such that others may benefit from their materials.
Overall this paper is very well written and to the point. Only a few minor comments:
1) Line 21 - the authors should distinguish the academic setting from the academic teaching setting, since the academic setting does very well in open source software development.
**We have made this explicit.**
2) Lines 24-27 seem to be a personal statement against the academic system.
**We have removed the complaint component, and noted instead the divergence between sharing in academic research and the reluctance to want to do so in a teaching environment.**
3) It would be useful to provide the URL in the text for rule #3 since online best practices for lesson development circles back to online collaborative lesson development.
**We were not crystal clear on this suggestion. We did include a link to Software Carpentry here as we felt that would help people engage with it.**
4) line 141 - question their 'own' authority
**Fixed.**
5) In Rule #5, it would be helpful if the authors redirected to Rule #6 when discussing recognizing contributions.
**On reflection, we liked the division that we had between Rule #5 and Rule #6, and did not want to re-balance between the two rules. We considered adding some signposting between the two rules, but felt it was unnecessary given their proximity.**
6) Line 251, sustainable lessons 'in all domains'
**Fixed.**
## Reviewer #3
Reviewer #3: The authors of "Ten simple rules for collaborative lesson development" have compiled a very useful set of guidelines for successfully building training materials. I know I am going to use them!
I am very pleased with the contents and the way in which the manuscript highlights a number of very useful tricks to creating useful and valuable teaching material. It was not easy to find an area of the manuscript that could be improved, but I managed to spot a few, minor things and I am hopeful that my comments will be of use to polish up a bit what is already a great compilation of your expertise building these teaching materials.
I find Tip #3 a bit difficult to digest. The flow of the narrative becomes a bit cloudy when it turns into a 5-point lesson within the 10-point document. A reference has been made to a different publication, which should help - but a bit more clarity on how this collection of five points become "best practices" is necessary. Perhaps a paragraph that more clearly states the important content the authors extracted from Wiggins and McTighe and how they used them to develop these "best practices" would be easier to understand.
**Upon reflection, and given the positive feedback from other reviewers, we decided to leave Rule #3 as is.**
In Figure 1.
The images supporting Tip #7 are not very clear to interpret. I would think of something else here. Perhaps an old-style scale instead of 'great' and 'terrible'? Or something similar.
**We changed the figure to help with interpretability. In one sentence, we state the rule and some little extra bit of information that ties the image in the figure to the explanatory information in the body of the manuscript.**
**The figure also has the following modifications:**
- **modified the image for rule #7 to incorporate the above suggestion;**
- **Removed the PLOSlgo reference to our paper.**
- **Made more space around rules 1-4.**
- **Tweaked the icons for rules #3 and #6.**
Regarding Figure 2.
This diagram could be improved with a few arrow movements and slightly different wording. Active voice is always an efficient way to deliver information, so I kindly suggest that the authors could make a bit more fruitful use of it.
For instance, "Lesson materials are outlined and drafted via community input" could be more clearly stated by saying instead: "Outline and draft lesson materials with community input."
"Materials are updated continually" could also be switched into active voice.
"Lesson release..." --> "Release a stable version of the lesson."
Also, the arrow from 'recruit community..." into "Lesson materials..." could go and meet the arrow going from 'an individual or group...' towards 'Lesson materials...' It adds clarity.
**Figure 2 was updated to include boxes labeled in active voice and arrows between boxes that better represent connections among concepts. We also added a white background and added additional file formats.**
Finally, just a minor comment (not a request for review) that at first, the thought of inner references from one 'Tip' to the other was worrisome to me, but the authors were able to disperse those fears by the end of the article. I actually quite like the internal references to other points in the list. It is very useful!
That's all. Thanks for sharing this insight with the community. As I mentioned before, I am certain these Tips will be very useful to many!
## Reviewer #4
Reviewer #4: The authors present ten rules for successfully developing teaching materials in a collaborative, open framework. The idea of collaborative and open lesson development is an important and relevant one, and so in that sense this manuscript would be a useful contribution to the literature. The rules are generally well-chosen, and fit together well.
My major criticism of the paper is that it is overly sparse in its framing. This is especially true of the beginning (the abstract is currently too short to be very useful), but also at the end. I think that the authors could do a better job of 1) motivating the need for this new approach to instructional material design and maintenance and 2) addressing criticisms that more conventional practitioners might have. These concerns could include reservations about the accuracy of open lessons, the coherency of modules made by contributors that likely span a range of experience in a given discipline, the reluctance of academic administrators to have their students taught with course materials developed by third parties, etc.
We agreed with this criticism and revised the paper accordingly. We did this in two distinct ways.
**First, in the submission version, we had both an abstract and an author summary right after each other. We removed the author summary and worked the text into the abstract, fleshing things out. Given that our paper is not technical we did not believe that an author summary was warranted.**
**Secondly, we expanded the introduction itself. We did so by clarifying the criteria around open education projects, and further reinforced the benefits of this approach: noting higher-quality lessons, ensuring that lessons were up-to-date, and how individual time on behalf of authors is less. Some of this was in the lessons but we agreed that the introduction needed to frame.**
**We did not address concerns around how some might have reservations about "the coherency of modules made by contributors that likely span a range of experience" as we felt that coherence can come from Rule #3.**
**We did not address "the reluctance of academic administrators to have their students taught with course materials developed by third parties," because the paper is short, sharp and concise and generally avoids getting sidetracked on peripheral issues such as this.**
I recognize that there are word limits on manuscript of this kind, but I think that with further revision the writing could be tightened up a bit to allow for this additional framing and discussion. The authors have a chance here not only to show how to do this sort of lesson development, but also motivate people to consider doing it in the first place. Not everyone is ready to embrace this new way of producing pedagogical materials, but perhaps they would be if a stronger case were made. I guess all that is to say I'd prefer a bit more space spent on the 'why' instead of just on the 'how'.
I also think that the manuscript would be improved with another few passes to smooth out the text. There are a number of spots where transitions are a bit awkward. I also noticed a number of grammatical and proofreading errors that would need to be corrected before publication. I've pointed out some but not all of them below.
**We have done a pass, incorporating the flagged changes as well as other minor ones. Our sincere thanks for the close read.**
Specific comments:
Acknowledgements usually go at the end, not before the 10 rules?
**Fixed.**
Aside from their parenthetical mention at the end of the Introduction, neither of the figures is referred to in the main set of rules. I am not sure if both of these are necessary. Figure two, especially, encompasses a number of rather complex ideas about community building and lesson development that are not directly discussed at any length within the text. The second figure seems the more useful of the two, but in any event, I think both warrant more attention in the text or in captions if they are to be kept.
**Our intention for figure 1 was to provide a graphical abstract or a concise summary captures the content of the article in a single glance. We think it serves its purpose well. Similarly, Figure 2 covers the main rules and their interplay. Both figures are now explicitly referenced in the paper. We also provided in-depth captions for the figures which more strongly tie them into the paper.**
pg 2, line 50: who -> whom
**Fixed.**
pg 2, line 53: which -> that
**Fixed.**
pg 3, line 77: has -> have
**Fixed.**
pg 3, line 78: I'd say 'formal training' here. There are many ways to learn to do something. Without this adjustment you risk coming off as dismissive or even derogatory towards faculty, which I don't think is your intent.
**Agreed - we have made this change.**
pg 4, line 117: I'd also revise this bit about programmers 'looking down' on Google Docs and the like. It contributes to the notion that programmers think they are better than others, which is not something that belongs in a manuscript about inclusive lesson development. Recent versions of Google Docs also allow for 'suggesting' mode edits, which could be considered a version of 'pre-merge review', in that the changes can be discussed, accepted, or rejected after they are initially made/proposed.
**Agreed – we have revised this to note both suggest mode but also that the low barrier to entry for Google Docs can make it an attractive starting point.**
pg 5, line 168: look -> looks
**Fixed.**
pg 5, line 168: it has -> they have
**Fixed.**