prose like prose, code like code - Dashboard
2,440
visibility Viewed
88
Total Responses
88
flag Completed
100%
timelapse Completion Rate
0
do_not_disturb_on Dropouts
29 min
access_time Average Time
 
Countries Responses
US 52.27%
RU 7.95%
CA 5.68%
DE 5.68%
GB 5.68%
IE 3.41%
IL 3.41%
CN 2.27%
FR 2.27%
HU 1.14%
CH 1.14%
NL 1.14%
DK 1.14%
Unknown 1.14%
ES 1.14%
SE 1.14%
AU 1.14%
UA 1.14%
BR 1.14%
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 3 3.49%
Disagree 11 12.79%
Neutral 2 2.33%
Agree 38 44.19%
Strongly agree 31 36.05%
Other 1 1.16%
Total 86 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 1 1.28%
Disagree 4 5.13%
Neutral 4 5.13%
Agree 27 34.62%
Strongly agree 40 51.28%
Other 2 2.56%
Total 78 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.35%
Disagree 3 3.53%
Neutral 10 11.76%
Agree 43 50.59%
Strongly agree 25 29.41%
Other 2 2.35%
Total 85 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/21/2021 116651885 Also: The work is time-and-content sensitive; and you have to use the tools, processes, and environments required for intake, source control, single sourcing, task tracking, SLAs, doc builds, and so on.
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 8.14%
Neutral 2 2.33%
Agree 27 31.4%
Strongly agree 50 58.14%
Other 0 0%
Total 86 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
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 9.3%
Neutral 9 10.47%
Agree 25 29.07%
Strongly agree 40 46.51%
Other 4 4.65%
Total 86 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