[wp-meta] [Making WordPress.org] #4915: Add comment or feedback section to End User Documentation page for low-friction interaction

[Making WordPress.org]

#4915: Add comment or feedback section to End User Documentation page for low-
friction interaction
--------------------------+---------------------
 Reporter:  bph           |       Owner:  (none)
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:
Component:  HelpHub       |  Resolution:
 Keywords:  needs-design  |
--------------------------+---------------------

Comment (by bph):

 Wow! Thank you, Estela! (@estelaris) This looks amazing. And thank for all
 the patience you have thinking this through.

 Although I like how the second more elaborate version, looks and feels, it
 might just be a step too complicated as the first version.
 My observations
 - The helpful/not helpful is only actionable when 'not helpful". I
 wouldn't want to hide the comment form. It might have some statistical
 value, if we can say: We had 1,500 people visit the page, 20 clicked on
 "helpful" 10 clicked on not helpful. We don't know what the other 1,470
 people think. We can assume they are also in the "helpful", but there is
 not actionable value.
 In essence, it's a goal to connect with users, who find the content on the
 page 'not helpful', in a meaning full way about why it wasn't helpful. I
 rather not assume anything about the silent majority.

 - I am sure plenty of people would just want to check things, and not
 write anything. I would be one of them. Offering pre-set 'failures' would
 take care of those group.  Great suggestions @milana_cap and @theMikeD.
 If we want a visitor leave us a note, there are plenty of reasons, why the
 documentation might not have been helpful. Reducing it to 3 options part,
 feels a bit prematurely to me. We don't know anything yet. I would like to
 gather real information before we put words into people's mouth.

 I have been involved in building software one way or other for a while
 now,  and it has been proven to me over and over again, that my
 assumptions about how end users feel and think are wrong the first time
 around.  I rather would like to listen first before making assumptions.

 Given the above, I would like to try it with first & plain version.
 Collect some data for 3 to four months and then see if we can add
 additional choices to the list of fly-by click reporting.

 For the **implementation**:
 - We would need this form to hooked up the overall .org **spam filtering
 tools
 - ** The comments are **not to be public** (already mentioned)
 - Should have an **enable/disable switch** on a page/article level (as not
 every author or would be ready to handle feedback, yet)

 **Feedback handling**
 - These are comments, they will be accessible through the WP-Admin, and
 have a reply feature, every comment should have a short reply to "Thank
 you for your comments, we will review etc. "
 - Block editor end user documentation project is managed on Trello with
 each page having it's own card.
 - When an issue come in it will be evaluated, and put into the queue:
 - typos are fixed  asap (as soon as possible)
 - other changes will be added as a to-do-item on the page card and
 priority will be moved up for an update.
 - If possible the feedback person will receive another notification that
 the reported issue is fixed with an expression of gratefulness,

 **Pilot Project**
 During the pilot project, I will keep track of how many feedback reports,
 on how many pages we get and  categorize the reason(s) in a weekly report.

 Going with the 'simple' comment form would also have an added value that
 it uses existing code base, with slight modifications on the copy, so the
 burden on contributors seems to be less than the other variation.

 I might be completely wrong about the whole thing, though. As always, I am
 ready to disagree and commit.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/4915#comment:23>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org