July 4th, 2005

_Default

Screened comments not unscreened when replied to

Title
Screened comments not unscreened when replied to

Short, concise description of the idea
When the owner of a journal replies to a screened comment, the original comment remains screened. Also, the reply is automatically screened, too.

Full description of the idea
Basically, what's above. It's a very simple idea. Screening is generally used to keep conversations private, and it's more likely that the journal owner will want the conversation to continue being private rather than become public after the first reply.

The idea would be that the screened comments are visible to the two people holding the private conversation, unless the owner of the journal decides for his/her own comments to be invisible to the other person in the conversation.

The best idea, I think, is to let the journal owner decide if they'd rather have the current option as the default one, or the one I'm suggesting as the default one. It shouldn't be much more difficult to implement the new option and leave the current one than to implement the new one and get rid of the current one, and then everyone would be happy.

An ordered list of benefits
  • It's very annoying to have to rush to re-screen a comment after having replied to it, not to mention someone could see it during that time.
  • Only one step to reply to a screened comment without unscreening it, instead of three (reply, re-screen reply, re-screen original comment).

An ordered list of problems/issues involved
  • None that I can think of. Please let me know if there are any.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • I have no idea if this has not been implemented yet because it can't be done, because it seems more logical for screened comments to remain screened until specifically unscreened.
bubbles

Less terse confirmation emails

Title
Less terse confirmation emails

Short, concise description of the idea
Include the details of what you are seeking confirmation of.

Full description of the idea
Currently emails get sent out which are so terse that they do not provide enough information for the recipient to determine if they should confirm the change or not.

As an example:

Your email address has been changed, click on the link to confirm.

Has been changed from what to what. How can I know that I am confirming my own change or the guy who is sitting right behind me in the computer lab. My girlfriend took down our email server, she may have updated my account so I still get the LJ mails, but I wouldn't know because there is no information.

How about this:

Your email address has been changed from fred@nerks.com to boo@gallooo.com click on this link to confirm. To report a breakin please click the following link.

An ordered list of benefits
  • Significantly improved security.
    Significantly improved usability.

An ordered list of problems/issues involved
  • Every mailout form-letter needs to be reviewed and extra data added.

An organized list, or a few short paragraphs detailing suggestions for implementation
  • Sorry I can't hack php/whatever this is done in.
calm, thoughtful, nature

Email Entry Text to Community Poster upon Maintainer Deletion

Title
Email Entry Text to Community Poster upon Maintainer Deletion

Short, concise description of the idea
Email the entry to the poster when the maintainer deletes the entry, similar to when a moderator rejects a post in a moderated community. This preserves the entry text if the poster did not keep a backup of the text, and allows the poster to easily repost it with any suggested corrections.

Full description of the idea
Email the entry to the poster when the maintainer deletes the entry, similar to when a moderator rejects a post in a moderated community. Maintainers would also have the option to leave a short comment explaining why the post was deleted and offering suggestions to fix it. This email option would encourage community maintainers to use the delete opion more often if they knew the post was still going to be intact for the poster. It would also take up the same amount of bandwidth as a maintainer commenting to an entry explaining why it was deleted, and potentially shorten the time problematic posts are visible to other community members or the public.

An ordered list of benefits
  • Fewer inappropriate entries will stay up.
  • Fewer comments (and comment emails) from community members asking for corrections.
  • Posters will have copies of their entries to repost them.


An ordered list of problems/issues involved
  • Potentially more emails, since every post will produce an email.
  • Poster may never repost the corrected entry.
  • If the poster has email problems, they may never get the copy of the entry.
  • Drama (It's a community. There's always drama potential.)


An organized list, or a few short paragraphs detailing suggestions for implementation
  • Copy part of the moderation code to the maintainer entry deletion code.
  • Test.
  • Update documentation.