Without Field UI comment module presents a poor UX

I don't see how this is a bug, field.module is required.

The proper dependency makes sense in context of #2199637: Replace "required" flag of Field module with proper dependencies

The help text on "configure" route should explain the need in field_ui module

Now we have comment type that works without "field" module...

In #1805932: Resolve menu UI issues on 'Comment fields' tab of bundle field ui pages exposed idea to use "tabs" and we actually lacks consistency to enable commenting on entities.

At the same time all the need is to provide a page that lists content entities (with integer IDs ;) and their bundles as checkboxes to "enable commenting"...
The related issues #552604: Adding new fields leads to a confusing "Field settings" form & #1963340: Change field UI so that adding a field is a separate task

There's CommentManagerInterface::addDefaultField() to add default field.

The tricky part is "disable commenting" that could be released by re-using "locked and enabled" field properties. just do not delete the fields.

Also some contextual links (probably) with modal dialogs could be used to edit and delete comment

PS: the interesting part - are we able to use comment field as base entity field...

Initial stub for #6

Nice!

1. +++ b/core/modules/comment/src/Form/CommentingForm.php
   @@ -0,0 +1,157 @@
   +          // Create new comment type to prevent exception.
   +          // @see \Drupal\comment\CommentManager::addDefaultField()
   +          // @todo Is there a reason of comment type for each entity type?
   +          $comment_type = 'comment_' . $entity_type_id;
   +          $this->commentManager->addDefaultField($entity_type_id, $bundle, 'comment', CommentItemInterface::OPEN, $comment_type);
   

   Yes, its so we can make the entity_id field on comment an ER field (you need to set the entity-type of the ER field, and this can only vary by bundle)

2. +++ b/core/modules/comment/src/Form/CommentingForm.php
   @@ -0,0 +1,157 @@
   +        $this->entityManager->getStorage('field_instance_config')
   +          ->delete($comment_fields);
   

   There should be a confirm form here, along with a list of dependencies etc. As this will result in data loss.

I have no idea why this is doing this? We really shouldn't be creating UX hacks like this

@larowlan what do you mean with confirm form and dependencies?
@Bojhan I think 80% of users need just a simple interface to enable commenting

@andypost Yes, but this sounds very much like an anti-pattern. We don't have this for any of the other entities, and its basically a work around to the Field UI having such bad UX. I don't see how this helps users understand the concepts at play.

I am tempted to mark this won't fix, but it might be good if a committer chimes in. I'd rather have some help text here, than some funky custom UI.

Help texts should be added/fixed anyway in the issue, so no need to wontfix

Discussed with @catch at IRC, the suggestion to improve help texts

andypost> catch, please comment in https://www.drupal.org/node/2230177 is help text adjustments enough?
catch> andypost: generally I prefer relying on the Field UI, even if it's bad, than adding anything custom.
catch> andypost: so agree with Bojhan on adding help text.
catch> andypost: so there was a similar UX issue when taxonomy moved to a field in 7.x, but again we ended up leaving it just using Field UI.
catch> andypost: the idea being that 1. it's consistent 2. it provides some impetus to give Field UI better UX for tasks like this.

Is the revisit before release tag appropriate on this issue? The tag is generally used for issues that can't be fixed immediately but where a fix might be possible at a later date, or where a quick hack has been implemented with the intention of removing it before release.

I don't think there are any external factors preventing this from just being fixed.

Also it's really confusing to have "comment types" in Structure menu - it always takes a time to separate them from "content types" visually and sometimes leads to extra clicks because comments goes before content

added screens to summary and #16

Would be great to discus around DC

We discussed this with @webchick, @alexpott, @catch, and @effulgentsia -- we should definitely improve the hook help entry that exists and also add text in hook_help() to be shown on this page, but it's a straightforward UX/documentation bug so no need to "revisit" it.

@xjm suppose better to re-open #2091299: Update hook_help for Comment module and move the issue to 8.1 cos it's focused on Usability of comment management
Otoh we have no such interface in d7 so it's not a regresion like #1997692: Create contact form block

So maybe discus such sort of issues as RC-polishing stage?

Please open a new issue to improve the help, rather than reopening a fixed issue at this point. We do not normally want to reopen old issues that were fixed 11 months ago, to address newly discovered problems. We should open a new issue instead.

All hook_help issues should be listed with parent issue #1908570: [meta] Update or create hook_help() texts for D8 core modules please, or at least make sure that is listed as "related".

The extra help text was added in #2488078: Update hook_help for Comment module about field UI need to manage comment fields. Marking this as duplicate.