Feedback - contributions from the public

[zzap]

Issue Description

We need to provide the way for contributing with content for users without edit post permissions. On DevHub it's been handled with comments functionality and it looks like a good start for HelpHub as well.

Do not confuse this with #7. This is a completely different functionality.

Sometime in a far future, it is planned to replace this functionality with direct content editing on the frontend (with revisions and Gutenberg), which would be replicating Codex' editing experience. For now, we are going to settle with collecting feedback through commenting system.

Any brilliant idea how to do this in a different way?

Slack discussion

[atachibana]

As the first step, I like the comments functionality. Even PHP manual is doing well with this method
http://php.net/manual/en/language.variables.basics.php, though some watchdog must be required, of course.

[softservenet]

Experimenting with a couple things on inline commenting on a Gutenberg block, Will post back if I can get something interesting by Monday...

[softservenet]

Have what may/could be a rough starting point. Was trying to take both the initial rollout of a Comments unit and ultimately, a more sophisticated Management unit per some of the conversations thus far.

These are all basically just concepts.

---

COMMENTS REVISION SUGGESTION

*it seems like regular comments aren't really necessary on these pages, so there
could still be something similar to "Add/View Revision Suggestions" that could
just open up the thread.

*top suggestion vote could also go to the top

-Tab for Regular Comments (Default)
*not sure if this is even necessary, but may be
in some cases?

-Second Tab (Dynamic) for Suggestions

-Upvoting for Suggestions
*similar to Stack Overflow

VOID
The void is that the upvote system is good, but when/if we go to inline block editing, then we lose that traction with the votes. We could do something like putting blocks inline with comments to merge the two, but that is pretty new and innovative.

TO HANDLE: Eventually, the Blocks that are in the Edit Suggestions - NEW could show here (content from block submitted).
*see below
*Approved, Denied could fall off
*people could still vote for the Active Suggestions

---

ADVANCED EDIT SUGGESTIONS W/GUTENBERG BLOCKS

FRONTEND

*above, block opens when "edit" icon is clicked

BACKEND

*note that rather than appending the suggestions below the actual editor, the sidebar is utilized to maintain the focus on Distraction Free Writing.

WHY NOT USE A FULL POST AND REGULAR REVISIONS

-Not Streamlined from a Management Perspective

-Doesn't Segregate into a Sectional Structure as Well

[softservenet]

These are some original notes as I was looking into some workflow that might be reasonably achievable.

-Open Block
--only the single block
--with content and a block editor

-Edit Block

-Submit Block

*Block Ends up as Attachment to Post Editor
*in it's own Gutenberg sub-block under post editor
(adapted to Sidebar for Distraction Free Writing)
(but not as part of the post)
SIMILAR TO A CUSTOM FIELD

WE PROBABLY COULD MOVE INTO A SWAP X BLOCK FOR Y BLOCK
AT SOME POINT

---

FULL PAGE REVISION: This would work and there have already been pretty decent adaptations for this such as Tom J Nowell's "Frontenberg." From a content editing perspective, getting a full page revision and comparing it and deciding what to adapt on approval and merging that could become somewhat cumbersome. Most submissions should be on a per block basis to particular items based on the block the content is in within the overall post...not exactly "inline" per line, but as a paragraph, block, unit, etc, so that would isolate the items.

It seems like the best idea to get away from full page revisions and piggybacking on that system. It certainly could be done and the revision probably could be marked up, but this loses the sort of sectional management which would make the process much easier.

ATTACHMENT BLOCKS: With attachment blocks, these could be reviewed on a per block basis visually in the main editor. They would be in a block respectively, just not part of the Live post, so it would be easy to copy and paste and make revisions as needed to the post editor above.
*would include submission details collected with submission, datestamp
*there should be a way to delete attachment blocks, keep them and mark them approved with date
(or mark them denied with date)

[softservenet]

(Post Notes from HelpHub Meeting):

DevHub Suggestion Piece: Since the Gutenberg Attachment Blocks piece might take longer than utilizing the existing DevHub piece, timewise, it seems to make sense to implement DevHub solution first.
https://github.com/WordPress/meta-environment
*will need to reference DevHub Repo
*isolate code to be used to add feature

Gutenberg Attachment Blocks: Will continue to technically outline this and move forward. Team decided to require a user to be logged in to submit a suggestion vs. being able to do so without being logged in from the front end.

[softservenet]

@Kenshino Do we pick the code on our own, or should we reach out to who worked on this?

[softservenet]

Believe we've found the code here:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-developer#inc

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-developer/inc/user-content.php

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-developer/inc/user-content-preview.php

[softservenet]

Here's a better Illustration of the elements of this piece:

MAIN
includes/user-content
user-content.php
user-content-preview.php

/js
user-notes.js
user-notes-feedback.js
user-notes-preview.js

FROM FILES

user-content.php

-ENQUEUED SCRIPTS

--function-reference.js
---array jquery, syntaxhighlighter-core, syntaxhighlighter-brush-php

--user-notes.js
---array jquery, quicktags

--user-notes-feedback.js
---array jquery, quicktags

-INCLUDE STYLESHEET DIRECTORY
/stylesheets
--editor-style.css

-ENQUEUED STYLES
--syntaxhighlighter-core
--syntaxhighlighter-theme-default

user-content-preview.php

-ENQUEUED SCRIPTS

--tabs.js
---array jquery

--user-notes-preview.js
---array jquery, wporg-developer-function-reference, wporg-developer-tabs