marahmarie: (M In M Forever) (Default)
[personal profile] marahmarie

Title:
Unscreen your comments from Post Comment Success page

Area:
entry comments

Summary:
Dreamwidth screened comment settings currently entail screening our own comments when we choose to screen all comments on our journals (I'm not sure if this behavior is the same for communities). I'd like to suggest we save time for journal owners, specifically, by allowing them to unscreen their own comments from the Post Comment Success page.

Description:
Dreamwidth screened comment settings currently entail screening our own comments when we choose to screen all comments on our journals (I'm not sure if this behavior is the same for communities). I'd like to suggest we save time for journal owners, specifically, by allowing them to unscreen their own comments from the Post Comment Success page (https://www.dreamwidth.org/talkpost_do). This saves time - no more going back to the entry or your DW Inbox or off-site email to find and unscreen the comment you just replied made in reply to someone.

Poll #18202 Unscreen your comments from Post Comment Success page
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

Should be implemented as-is.
18 (52.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (47.1%)

(Other: please comment)
0 (0.0%)

marahmarie: (M In M Forever) (Default)
[personal profile] marahmarie

Title:
Show poster is banned from quickreply

Area:
quickreply

Summary:
In quickreply there is nothing stating a user's ban status. If a user types a comment in a journal or community from which they have been (perhaps unknowingly) banned, if they use quickreply to do so they won't realize (or recall, if they've forgotten) their ban status until they try to post their comment or else if they click through to the "more options" full-size comment box before posting.

Description:
Quickreply (the instant comment box you get on the reading page under each entry if you click "reply" from the entry linkbar) doesn't currently show relationship status to other users or communities. While kludging in the entire relationship status functionality might be a bit much for a simple reply box, it would be helpful to know if you're wasting your time writing the Gettysburg address in reply to someone, only to realize at the last second, when you try to post, that you've been banned from the journal or community in question.

While I'm not sure how it might be done, my thought is to make ban status (if applicable) visible so it can be seen before you try to post from a quickreply box. While I don't see a lot of room for it as I look at a quickreply box as I type this up, I'm thinking in addition to* the JS usericon-picker saying "Browse" in big, bold letters when you hover over it, it could say "You have been banned from this community/journal" as well.

*An earlier version of this said "While I don't see a lot of room for it as I look at a quickreply box as I type this up, I'm thinking instead of the JS usericon-picker saying "Browse" in big, bold letters when you hover over it, it could say "You have been banned from this community/journal" instead", then I realized, after posting, that "in addition to" would be better than "instead of".

Poll #18125 Show poster is banned from quickreply
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

Should be implemented as-is.
16 (47.1%)

Should be implemented with changes. (please comment)
3 (8.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (38.2%)

(Other: please comment)
2 (5.9%)

blackorange: (Default)
[personal profile] blackorange

Title:
posting a comment

Area:
comments

Summary:
is it possible to implement a worldwide hotkey ctrl+enter for posting a comment?

Description:
is it possible to implement a worldwide hotkey "ctrl+enter" for posting a comment?

Poll #18024 posting a comment
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

Should be implemented as-is.
2 (5.9%)

Should be implemented with changes. (please comment)
4 (11.8%)

Shouldn't be implemented.
8 (23.5%)

(I have no opinion)
20 (58.8%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Art: self-portrait (Default)
[personal profile] ninetydegrees
Lightboxes are a bad idea so I've submitted a new suggestion to improve our current preview pop-ups. Please comment on this one instead once it's approved. :)

Title:
Have previews load on same page in small pop-ups

Area:
entries, comments

Summary:
We have wonderful magic for Quick Reply and a nice pop-up for browsing icons. I'm thinking that something along these would be nice for previews too. So no more loading the preview in the same tab (like DW does for comments) or even loading it in a new window (like DW does for entries). Just a small pop-up you could post your entry and comment from if you're happy with what you see or with a link to go back to the editing page, which would close the pop-up (it is currently not possible to post an entry from its preview page or go back to editing from there; you can only close the window). This type of previews is already implemented on several sites.

Description:
On the Comments preview page, there is additional info (such as which HTML tags are allowed). I think this info should be accessible before you click preview (I don't see how you're supposed to know you have to click on preview to get it in the first place). It could be via a ? button or a text link.

Feel free to suggest better implementation! There may be even better preview magic I haven't seen yet :)

Poll #18018 Have previews load on same page in small pop-ups
Open to: Registered Users, detailed results viewable to: All, participants: 29


This suggestion:

View Answers

Should be implemented as-is.
3 (10.3%)

Should be implemented with changes. (please comment)
3 (10.3%)

Shouldn't be implemented.
14 (48.3%)

(I have no opinion)
9 (31.0%)

(Other: please comment)
0 (0.0%)

[personal profile] zaluzianskya

Title:
Allow linking to parent comment with only one child thread

Area:
Comments

Summary:
I guess this would be sort of like reddit's context links: A way to view a comment's parent comment, but without any other children of that parent.

Description:
Sometimes I want to link to a specific comment or thread, but there's important context in that comment's parent. However, the parent comment might already have tons of other children. Especially when those other children are above the one I'm linking to, that's really inconvenient for the person I'm sending the link to!

Some way to show just the comment I want along with the parent comment would be a godsend. Preferably with some way to indicate that this isn't the entire thread (possibly with some kind of [click here to see X number of other comments] link, or some other indication).

Poll #18012 Allow linking to parent comment with only one child thread
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

Should be implemented as-is.
15 (44.1%)

Should be implemented with changes. (please comment)
4 (11.8%)

Shouldn't be implemented.
3 (8.8%)

(I have no opinion)
11 (32.4%)

(Other: please comment)
1 (2.9%)

alierak: (Default)
[personal profile] alierak

Title:
Improve OpenID claiming

Area:
OpenID

Summary:
Claiming your OpenID may help with future imports that bring over your comments, but there are other areas it does not cover.

Description:
We have a mechanism where a DW user can "claim" an OpenID identity (e.g., an LJ account that has been used to post comments elsewhere on DW). That records the claim in a table and kicks off a job to change ownership of all the OpenID identity's previous posts. Thereafter, if an import of some other journal is going to bring over comments owned by that user on the remote site (which would normally be shown using their OpenID identity), ownership is changed to reflect the DW user during the import. However: - I don't think the claim relationship is shown anywhere in the DW profile or metadata for the OpenID userid. Perhaps the profile for that userid should just redirect to the claimant anyway, like a renamed user. - I think it's still possible for the user to log in and comment using OpenID, and then those new comments cannot be changed over to the DW user because that OpenID identity is already claimed. Like the importer, comment posting probably ought to check claimed_by first. - We don't update the circles of everyone who has trusted the OpenID identity. This could probably be done in the same worker that changes ownership of posts. These things are probably all unexpected behavior if you're migrating from another site to DW. Thoughts?

Poll #17823 Improve OpenID claiming
Open to: Registered Users, detailed results viewable to: All, participants: 17


This suggestion:

View Answers

Should be implemented as-is.
8 (47.1%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (5.9%)

(I have no opinion)
8 (47.1%)

(Other: please comment)
0 (0.0%)

azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] azurelunatic

Title:
Expiration warning for feed account comments sections

Area:
feeds

Summary:
Display a notice in the comments section of feed accounts about the 14 day expiration of the entry. This would serve as a reminder that all things are ephemeral, and if the user wanted their comment saved, they could go to the original (settings allowing) or manually save it somewhere.

Description:
There's been some previous discussion around comments on feed accounts. Currently, comments are enabled on feed accounts as a courtesy to Dreamwidth users who would like a forum, however ephemeral, to discuss the feed amongst themselves, particularly when the source does not allow comments (such as XKCD).

However, it's not immediately obvious to someone who is unfamiliar with feed accounts that the comments won't be sent back to the original source of the feed, and that the comments will vanish when the feed entries vanish after 14 days.

I suggest a notice, to be displayed on the entry page above the comments section (so it's visible to readers and to people using quickreply), and on the reply page. It would say something like: Only feed entries from the last 14 days are displayed on Dreamwidth. Comments left on feed entries will not be saved after the entry is gone.

(People using quickerreply from their reading pages probably wouldn't have that notice visible.)

Users would be given enough information to decide for themselves whether to try to leave their comment on the source, or whether it's more appropriate for the comments on the feed. It could feel unnecessary or annoying to users who are already aware, and would introduce another little delay for screen reader users to try to skip over.


(If implemented cleverly, this could possibly be reused to support comment policy notices for communities and personal journals.)

Poll #16990 Expiration warning for feed account comments sections
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

Should be implemented as-is.
40 (83.3%)

Should be implemented with changes. (please comment)
3 (6.2%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (10.4%)

(Other: please comment)
0 (0.0%)

omnipotent: (Default)
[personal profile] omnipotent

Title:
Random Icon Chooser for Quick Reply

Area:
Entries, Friends Lists

Summary:
The random icon chooser was a nifty feature that allowed one to utilize all their icons. However, it is not available via the "Quick Reply" option on one's reading page.

Description:
The summary pretty much describes it, but I was just curious if there are any plans to add the random icon chooser as an option while replying to an entry without leaving the Reading Page. Currently, to access the chooser, I have to leave the Reading page by clicking "More Options". Unfortunately, when I do this, if I have typed anything in the comment box, it is erased! That's genuinely the only reason I'm asking; it sucks to write a well-thought out comment, want to choose an icon and be able to see which icon I'm choosing, and then lose the text!

Poll #16840 Random Icon Chooser for Quick Reply
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

Should be implemented as-is.
25 (58.1%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
3 (7.0%)

(I have no opinion)
15 (34.9%)

(Other: please comment)
0 (0.0%)

batrachian: A frog, probably of South American vintage (Default)
[personal profile] batrachian

Title:
Allow Markdown in site-based comments

Area:
Comments

Summary:
Expand markdown support to cover all areas of user input - comments currently may only use markdown if they are posted by email.

Description:
Markdown is a cool thing! We can use it (or not) in entries, and post-by-email comments are always using it, but there's no way to use Markdown in comments made directly on the site. This is a thing that we ought to be able to do.

Poll #16839 Allow Markdown in site-based comments
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

Should be implemented as-is.
24 (51.1%)

Should be implemented with changes. (please comment)
9 (19.1%)

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
13 (27.7%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Art: self-portrait (Default)
[personal profile] ninetydegrees

Title:
Admin posts: connect 'as admin' post with 'admin' icon keyword

Area:
icons, communities, entries, comments

Summary:
If one has an icon with the 'admin' or '_admin' keyword automatically select it when making a post or a comment as an admin (I meant when you tick the 'as admin' checkbox).

Edit: looks like _admin or something even more unusual would be better as there would be a good chance *only* users who wanna have this would.

Description:
Not sure automatic selection is possible in which case it could be automatically use (so you wouldn't even have to select an icon the way it works at support). The latter could be problematic if you wanted to use a different icon for once.

Poll #15508 Admin posts: connect 'as admin' post with 'admin' icon keyword
Open to: Registered Users, detailed results viewable to: All, participants: 35


This suggestion:

View Answers

Should be implemented as-is.
9 (25.7%)

Should be implemented with changes. (please comment)
1 (2.9%)

Shouldn't be implemented.
2 (5.7%)

(I have no opinion)
22 (62.9%)

(Other: please comment)
1 (2.9%)

[personal profile] zaluzianskya

Title:
Allow ticking of mod hat from quick reply

Area:
Replies

Summary:
Currently the "comment as admin" feature can only be activated from "more options". This is inconvenient!

Description:
I went to reply to a post in a community I maintain so I could try out the new "comment as admin" feature, but I couldn't find it anywhere. Just as I was about to give up, I clicked the "more options" button on a whim and there it was. As someone who almost never uses "more options", I would never have expected to find it there.

It would definitely be a lot more convenient to have the option available when quick-replying, too. As an example, I see a lot of blank space to the right of the Post Comment/Preview/More Options boxes; maybe it could go there, next to "check spelling"?

Poll #13977 Allow ticking of mod hat from quick reply
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

Should be implemented as-is.
34 (69.4%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
2 (4.1%)

(I have no opinion)
13 (26.5%)

(Other: please comment)
0 (0.0%)

aedifica: Me with my hair as it is in 2020: long, with blue tips (Default)
[personal profile] aedifica

Title:
When posting a new comment to a collapsed thread, automatically expand that comment and its parent

Area:
commenting, entries

Summary:
On collapsed comment threads, when you post a new comment you should see it expanded, not collapsed, and also the comment it's a reply to.

Description:
The current behavior for comment-heavy posts is that if you make a comment on a collapsed thread, when you hit "Post Comment" the next thing you see is that collapsed thread, with your comment also collapsed.

I propose that instead, when you hit "Post Comment" you then see everything collapsed (everything that would normally be collapsed, at least) except your new comment and the comment you were replying to. That way you can make sure you commented where you meant to and have a chance to notice all the typos that you never see until after you post.

(This is superficially similar to another suggestion, http://dw-suggestions.dreamwidth.org/1360804.html , but not identical to it or any other suggestion I've seen.)

Poll #13644 When posting a new comment to a collapsed thread, automatically expand that comment and its parent
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

Should be implemented as-is.
34 (73.9%)

Should be implemented with changes. (please comment)
5 (10.9%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (13.0%)

(Other: please comment)
1 (2.2%)

killing_rose: Raven on an eagle (Default)
[personal profile] killing_rose

Title:
Ability to freeze comments to an entry

Area:
entries, managing comments

Summary:
I think it'd be useful to have the ability to freeze <i>all</i> comments to an entry at once, instead of manually doing so.

Description:
Occasionally, you want to disable the ability of people to leave comments without destroying those already there, and quite frankly, going through and manually freezing each thread is a) time consuming, and b) a little annoying. If there was a way to mass-freeze all threads so that new comments couldn't be added, it'd be useful. The options to delete, screen, and unscreen en masse are already there, after all. I'd be a whole lot more likely to mass freeze all comments rather than delete them, but I have the functionality to do the latter and not the former

Poll #13464 Ability to freeze comments to an entry
Open to: Registered Users, detailed results viewable to: All, participants: 70


This suggestion:

View Answers

Should be implemented as-is.
58 (82.9%)

Should be implemented with changes. (please comment)
3 (4.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (8.6%)

(Other: please comment)
3 (4.3%)

montuos: cartoon portrait of myself (Default)
[personal profile] montuos

Title:
Save selected icon when having to re-login to post a comment

Area:
commenting, icons

Summary:
When you get logged out while you're composing a comment so you have to re-login to post the comment, I think the comment form should save the icon you've selected (the same way your comment text is saved) instead of reverting to your default icon.

Description:
My login cookie expired/disappeared (I forget the exact wording of the error message) while I was composing a comment, so I got sent to another page to sign back in to post the comment. It was really nice that my comment text was saved, but my default icon was used instead of the other one I had selected when composing my comment.

I think it would be better if the log-back-in-to-post-your-comment page remembered the selected icon instead of reverting to the default one.

Poll #13095 Save selected icon when having to re-login to post a comment
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

Should be implemented as-is.
38 (76.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (24.0%)

(Other: please comment)
0 (0.0%)

[personal profile] thomasneo

Title:
Replace the existing spaces between the brackets in the comment form to non-breaking spaces

Area:
Comment Form Design

Summary:
Same as title.

Description:
Some layouts in Dreamwidth—especially the non-fixed width types—don't specify a width for the brackets in the comment form, so the brackets get wrapped like this.

(http://z5.ifrm.com/30174/148/0/f5154599/SS1.jpg)

I presume this is an oversight, since the brackets do align correctly when viewed in site skin.

(http://z5.ifrm.com/30174/148/0/f5154600/SS2.jpg)

Hence, I suggest to replace the existing spaces between the brackets to non-breaking spaces.

(http://z5.ifrm.com/30174/148/0/f5154601/SS3.jpg)

Advantages:
- A better looking comment form

Disadvantages:
- May break some users' layouts
- May break some Dreamwidth layouts

Poll #12199 Replace the existing spaces between the brackets in the comment form to non-breaking spaces
Open to: Registered Users, detailed results viewable to: All, participants: 40


This suggestion:

View Answers

Should be implemented as-is.
23 (57.5%)

Should be implemented with changes. (please comment)
1 (2.5%)

Shouldn't be implemented.
2 (5.0%)

(I have no opinion)
14 (35.0%)

(Other: please comment)
0 (0.0%)



Edit: Images are now fixed.
kate_nepveu: sleeping cat carved in brown wood (Default)
[personal profile] kate_nepveu

Title:
view screened comment upon posting in the same manner as unscreened comments

Area:
comments

Summary:
When you post a screened comment, you're taken to a page that says your comment posted, it's screened, and you can view it at this link. This requires an additional click to check the comment for typos, make sure it threaded properly, etc. You should instead be taken to the comment in the same way you would be if it were not screened.

Description:
DW's reply-but-keep-screened setting is awesome but conducting conversations in screened comments is still more cumbersome than it could be because of this intermediate success-but-screened page. The indication on the entry page itself that a comment is screened should be sufficient to notify the commenter.

Poll #11814 view screened comment upon posting in the same manner as unscreened comments
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

Should be implemented as-is.
42 (66.7%)

Should be implemented with changes. (please comment)
4 (6.3%)

Shouldn't be implemented.
6 (9.5%)

(I have no opinion)
11 (17.5%)

(Other: please comment)
0 (0.0%)

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
[personal profile] tim

Title:
Screen comment edits when comments are screened

Area:
comments

Summary:
Right now, if I set comments to screened-if-not-in-my-circles and I unscreen a comment, then the author edits a comment, the edit appears immediately without being screened.

Description:
I have screening enabled by default in my journal for comments from people not on my access list. Suppose "Alice", who's not on my access list, leaves a comment, and I unscreen it. If "Alice" edits the comment afterward, her edit appears immediately -- I don't have to unscreen the new edited version.

This is weird. When I saw this happening, fortunately the edit was just a typo fix. But in general, a commenter could abuse the editing feature to sneak in an edited version of the comment that the journal author wouldn't have unscreened.

I think when someone edits a comment in a context where screening is active, their edit should be like a new screened comment: that is, the old version should appear until the journal owner unscreens the edit (at which point the old version goes away).

Poll #11717 Screen comment edits when comments are screened
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
27 (50.9%)

Should be implemented with changes. (please comment)
9 (17.0%)

Shouldn't be implemented.
2 (3.8%)

(I have no opinion)
15 (28.3%)

(Other: please comment)
0 (0.0%)

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise

Title:
Discuss removing "check spelling" from quick-reply commenting form

Area:
commenting

Summary:
This suggestion is for informational purposes: we're in the first steps of redesigning the commenting form to make a bunch of things possible that would be VERY HARD right now, and we're trying to figure out which bits are utterly useful and which can safely be removed.

Description:
So, we want to add a few things to the quick-reply comment form (the inline one that shows up when you hit "comment to this entry", NOT the one that you get when you hit "more options" that's a separate page). Because it's been years since the commenting workflow has been touched -- I think the last time it got any attention was when the inline quick-reply form was first introduced and I'm pretty sure that was in like 2004 -- and we've tried to shoehorn in a few things since then, the existing inline commenting form is kind of dire.

(The big thing we're aiming at is working up some way that will let you comment as one of your other accounts without logging out of the account you're in now and having to log into that one, and allow you to specify icons other than the default, the way you can't if you use the "comment as other user" on the More Options page. But there are a few other things we could do if we did a redesign.)

Fu and I are in the very very very first stages of sketching possibilities and discussing what the revision should look like, but one of the things we're sticking on is that it's hard to add the "check spelling" option logically: it doesn't quite fit no matter where we put it, and task-wise, it's pretty isolated (it's the only thing that brings you to a separate screen other than the "More Options" button). So, I figured I would toss up this suggestion, and float the idea, and if people hate it that will tell us something. :)

The proposal, to be clear: remove the "Check spelling" checkbox from the inline commenting form, NOT from the full form that shows up when you hit "More Options", to give us room to redesign the inline commenting form in some more radical (and radically useful!) ways. At the time the inline comment form was designed, browser-based spellcheck was not as good as it is now, and people felt that having to visit the More Options page to spellcheck was really inconvenient, but these days I think it's at the point where browser-based spellcheck is so much better that I think it would be less of a concern now.

I could be entirely wrong, mind you! Hence running it by suggestions to see what people's quick gut reaction is.

Poll #11699 Discuss removing "check spelling" from quick-reply commenting form
Open to: Registered Users, detailed results viewable to: All, participants: 87


This suggestion:

View Answers

Should be implemented as-is.
66 (75.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
2 (2.3%)

(I have no opinion)
19 (21.8%)

(Other: please comment)
0 (0.0%)

azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] azurelunatic

Title:
Sitewide antispam capability: comment CAPTCHAs for inactive accounts

Area:
comments, anonymous users, inactive users, antispam

Summary:
When an account becomes inactive (discussion of what constitutes "inactive" for the purposes of this concept to follow), require any anonymous comments to fill out a CAPTCHA. If/when the account becomes active again, revert to the user's settings. This would not delete anything already in the journal, would not stop logged-in users from commenting, and would allow anonymous users who could solve the CAPTCHA to comment.

Description:
Spun off the comments on http://dw-suggestions.dreamwidth.org/1374810.html --

Spam comments are a woe that should be discouraged, while not discouraging comments of legitimate discourse from real sentient beings.

Most comment spam on Dreamwidth is anonymous. One of the places that spammers strike is the accounts of people who have become inactive. If someone's not around for any particular reason, they generally can't get rid of any spam that shows up in their journal. Emboldened by the way their first overtures have not been repelled or cleaned up, the spammer strikes again, and again, and again.

Anonymous spam is present until cleaned up by the journal owner (or someone logged in as them). Registered user/OpenID spam is only present until someone (someone else hit by the spammer, or a good neighbor) reports the spammer and the spammer is suspended; all of the spam comments left by that user will then go away across the site.

For this reason, it is more important to attempt to repel anonymous spam in the event that the journal owner is not around and therefore not able to take action.

When the journal owner becomes inactive, and the journal allows anonymous comments, and the journal owner does not already present anonymous comments with a CAPTCHA, and anonymous comments are not screened by default (screening leaves the anonymous comments invisible to search engines unless the journal owner comes through and unscreens them, and by that time first the owner is active, and second, the owner is hardly going to unscreen spam on purpose unless there's a bigger problem) then there should be a sitewide setting to put up a CAPTCHA upon the attempted anonymous comments to those journals.

Now the definition of "inactive" for the purposes of probably not actively gardening journal comments. This should be something that can be adjusted on the administrative end of things should it not be got right on the first try. As a first attempt:

No new or edited entries in personal journal
No new or edited community entries? (Can we track this?)
No new or edited comments (from the journal, not to the journal, either in their own journal or abroad) (can we track this?)
No active login sessions

... for at least 60 days? Doing anything that touches one of the above things would start the clock over again. If someone logs in, leaves a comment in a community, deletes the comment, and logs out, that would restart the clock. If someone leaves themselves logged in after doing that, they would have until that login automatically expires before the clock starts.

Poll #11570 Sitewide antispam capability: comment CAPTCHAs for inactive accounts
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

Should be implemented as-is.
39 (72.2%)

Should be implemented with changes. (please comment)
8 (14.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (13.0%)

(Other: please comment)
0 (0.0%)

waterbends: (Default)
[personal profile] waterbends

Title:
Disabling the automatic population of "re:" in comment subjects.

Area:
comments

Summary:
Dreamwidth is a site heavily utilized by the online RP community. The "re:" that populates automatically in subject headers can be really annoying, and we would love the chance to disable them!

Description:
Is there any sort of option for us to turn off the automatic "re:" that appears in subject headers? If not -- is it possible at all to create that option for us?

Take a look at the RP-based post here: http://adstringendum.dreamwidth.org/414634.html

Every single one of the almost 300 comment replies has had to manually remove the "re:" that automatically populates in the subject header, and it's a pain in the butt to have to do it when you're replying via phone. It gets really, really tedious, especially when you're churning out dozens of tags in a sitting.. and the header itself is necessary, because the mode of communication is something that's important to keep track of. Having a way to disable that would be just plain AWESOME!

Thank you so much.

Poll #11270 Disabling the automatic population of "re:" in comment subjects.
Open to: Registered Users, detailed results viewable to: All, participants: 116


This suggestion:

View Answers

Should be implemented as-is.
66 (56.9%)

Should be implemented with changes. (please comment)
4 (3.4%)

Shouldn't be implemented.
23 (19.8%)

(I have no opinion)
23 (19.8%)

(Other: please comment)
0 (0.0%)

Profile

Dreamwidth Suggestions

December 2018

S M T W T F S
      1
23 45678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom