prose like prose, code like code - Dashboard
100%
timelapse Completion Rate
75
flag Completed
1,016
visibility Viewed
75
play_circle_outline Started
0
do_not_disturb_on Dropouts
31 mins
access_time Average Time
 
Countries Responses
US 50.67%
RU 8.00%
CA 6.67%
GB 5.33%
DE 5.33%
IL 4.00%
FR 2.67%
IE 2.67%
CN 2.67%
ES 1.33%
SE 1.33%
Unknown 1.33%
UA 1.33%
AU 1.33%
HU 1.33%
CH 1.33%
NL 1.33%
DK 1.33%
Total 100.00%
In general, your argument in this post aligns with my experiences and perspective
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 2 2.74%
Disagree 9 12.33%
Neutral 2 2.74%
Agree 34 46.58%
Strongly agree 25 34.25%
Other 1 1.37%
Total 73 100%
In general, your argument in this post aligns with my experiences and perspective - Text Data for Other
06/22/2020 71079587 I agree, but I just think its the nature of the beast, and always has been, and maybe always will be.
Code review tools (e.g., Review Board) tend to exclude non-engineers from the content review process
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 0 0%
Disagree 3 4.48%
Neutral 4 5.97%
Agree 23 34.33%
Strongly agree 35 52.24%
Other 2 2.99%
Total 67 100%
Code review tools (e.g., Review Board) tend to exclude non-engineers from the content review process - Text Data for Other
06/22/2020 71079587 I agree, but I think most people don't like to give reviews, regardless of the tools.
06/17/2020 69961167 non-engineers could use code review tools - but they are resistant to using them
Creating documentation isn't too different from the workflows in a creative writing workshops. In both cases, you write content and review with others, and then make updates based on the reviews. Write - review - update - repeat.
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 2 2.78%
Disagree 2 2.78%
Neutral 8 11.11%
Agree 37 51.39%
Strongly agree 22 30.56%
Other 1 1.39%
Total 72 100%
Creating documentation isnt too different from the workflows in a creative writing workshops. In both cases, you write content and review with others, and then make updates based on the reviews. Write - review - update - repeat. - Text Data for Other
06/22/2020 71079587 I agree, to a point. It depends on your specific workflow and requirements.
Gathering input and feedback from many different groups and perspectives is one of the most important techniques for creating good documentation
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 0 0%
Disagree 7 9.59%
Neutral 2 2.74%
Agree 21 28.77%
Strongly agree 43 58.9%
Other 0 0%
Total 73 100%
Gathering input and feedback from many different groups and perspectives is one of the most important techniques for creating good documentation - Text Data for Other
No Data To Display
Reviewing only the parts of docs that have changed by looking at file diffs isn't as effective because it doesn't present the changes in the context of the whole
Answer Count Percent
20% 40% 60% 80% 100%
Strongly disagree 0 0%
Disagree 8 10.96%
Neutral 6 8.22%
Agree 21 28.77%
Strongly agree 34 46.58%
Other 4 5.48%
Total 73 100%
Reviewing only the parts of docs that have changed by looking at file diffs isnt as effective because it doesnt present the changes in the context of the whole - Text Data for Other
06/19/2020 70202894 You can actually take a look at parts before and after. So it is not only about viewing only the diff.
06/17/2020 69981128 depends the review
06/17/2020 69961167 in my experience this is also true if someone isn't familiar with markdown syntax and cannot envision the formatting updates as well
06/17/2020 69952303 It depends on the nature of the revision