prose like prose, code like code - Dashboard
3,137
visibility Viewed
92
Total Responses
92
flag Completed
100%
timelapse Completion Rate
0
do_not_disturb_on Dropouts
28 min
access_time Average Time
 
Countries Responses
US 51.09%
RU 7.61%
GB 6.52%
DE 6.52%
CA 5.43%
IE 3.26%
IL 3.26%
CN 2.17%
AU 2.17%
FR 2.17%
BR 1.09%
HU 1.09%
CH 1.09%
NL 1.09%
DK 1.09%
Unknown 1.09%
ES 1.09%
SE 1.09%
UA 1.09%
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 4 4.44%
Disagree 11 12.22%
Neutral 4 4.44%
Agree 38 42.22%
Strongly agree 32 35.56%
Other 1 1.11%
Total 90 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.22%
Disagree 5 6.1%
Neutral 4 4.88%
Agree 29 35.37%
Strongly agree 41 50%
Other 2 2.44%
Total 82 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 3 3.37%
Disagree 3 3.37%
Neutral 10 11.24%
Agree 46 51.69%
Strongly agree 25 28.09%
Other 2 2.25%
Total 89 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 7.78%
Neutral 2 2.22%
Agree 30 33.33%
Strongly agree 51 56.67%
Other 0 0%
Total 90 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 8.89%
Neutral 9 10%
Agree 27 30%
Strongly agree 42 46.67%
Other 4 4.44%
Total 90 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
Powered by QuestionPro