[wp-meta] [Making WordPress.org] #5093: Proposal to allow users to remove URLs that they have added to their posts in the support forums

[Making WordPress.org]

#5093: Proposal to allow users to remove URLs that they have added to their posts
in the support forums
----------------------------------+---------------------
 Reporter:  carike                |       Owner:  (none)
     Type:  defect                |      Status:  new
 Priority:  normal                |   Milestone:
Component:  Support Forums        |  Resolution:
 Keywords:  needs-privacy-review  |
----------------------------------+---------------------

Comment (by carike):

 > Excluding links to wordpress.org, stackexchange.com, etc. ?

 While some answers to questions in the support forums contain links to
 wordpress.org, stackexchange.com and the like on a relatively regular
 basis, I have only seen it in an OP's post on rare occasions.
 I believe that, on a balance of probabilities, the benefit should go to
 the OP requesting the removal of the link in this case.

 > My preferred solution is to no-index all topics when the first post is
 over X days old, where X is probably around 180.

 I can't say I disagree with no-indexing topics older than 6 months (for
 more reasons than just this one - consolidating / reducing content is
 actually likely to lead to a better user experience by means of
 facilitating more efficient search in this case), but this is not a
 sentiment shared by a number of forum volunteers and I'd like to
 acknowledge that.
 However, I do not think that no-indexing alone is a sufficient solution to
 this particular problem.

 > If I quote a URL from the OP in one of my replies, is that edited too?

 I thought about that, based on a recent incident.
 I don't think it should be included in this proposal.
 Personally I have been using
 {{{
 https://example.com/wp-admin/ (replace "example" with your own domain
 name)
 }}}
 in my replies to forum users.
 While I do not think this practice must be required, I think it should be
 highly encouraged.
 Again, there will be one or two edge cases that won't be covered, but our
 aim here is to reduce the issue as much as possible, not to chase
 perfection we can never achieve within the constraints.

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