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

Title:
Include subscribers in "screen comments from people not on your access list"

Area:
comments

Summary:
Right now the options for comment screening are "never", "anonymous comments", "people not on your access list", or "always". I want to change "people not on your access list" to "people on neither your access list nor your subscriber list".

Description:
I'm not sure how other people use automatic screening, but I use it to discourage abusive / derailing comments. If someone is on *either* my access list or my subscriber list, I probably trust them not to make such comments. So I suggest, in the "Comment screening" menu in "My Account Settings", changing the "people not on your access list" option to also exempt people on your subscriber list from auto-screening.

An alternative suggestion is to just add one more option to the list: "people not on your access list or your subscriber list", and leave the other options as-is. I prefer the first solution for simplicity, but either way is OK.

I don't see any drawbacks to the latter option except that adding more options to the list makes that part of the account settings harder to understand. The drawback to the former option is that someone might want to auto-screen comments from people they subscribe to but who they don't trust enough to grant access to. However I don't know if anyone actually does want to or not.

Edit: Since this is apparently unclear, "your subscriber list" means the people you choose to subscribe to. You choose who to subscribe to. Everybody on your subscriber list is someone you chose to subscribe to and can unsubscribe from.

Poll #10451 Include subscribers in "screen comments from people not on your access list"
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
10 (17.5%)

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

Shouldn't be implemented.
30 (52.6%)

(I have no opinion)
11 (19.3%)

(Other: please comment)
3 (5.3%)

peacekeeper: (Default)
[personal profile] peacekeeper

Title:
Offical Account Trading system

Area:
usernames

Summary:
An officially supported account trading system (no money involved, or a paid service if needed) to improve the safety of account trading. Not because trading itself should be allowed, but because it WILL happen, so it's better to have secure account trading and lessen the impact of trading unsafely.

Description:
Account trading is always going to be a problem on a website where usernames are involved. I once enjoyed trading usernames on other websites, but won't do it on DW because of the strong stance against it. However, other people do and WILL continue to do so.

Real Money Trading (RMT) is a huge problem in MMORPGs, and CCP countered that in EVE Online by allowing players to purchase Pilot License Extensions (PLEX) which can either be used to increase their subscription time OR sold on the market to other players, thus meaning people could exchange their REAL cash for in-game currency in a safe and fully supported manner. This has vastly improved the RMT problem.

For this reason, I'd suggest perhaps having an account trading tool in DW that would allow users to trade usernames with another user safely, meaning that the original owner couldn't just claim back the journal using their originally registered email address. No money need be involved.

If money was to be involved, it could be a paid service akin to EVE Online's character transfer service. Both users could pay a small fee to trade their usernames with one another.

This would solve the problem of accounts being stolen from unsafe and unsupported trading practices, as why would people continue to trade the unsafe way when there's a perfectly secure method available? Of course, there'd still be some people who go the unsafe route, but I'd imagine this would drastically decrease the problem.

Poll #10249 Offical Account Trading system
Open to: Registered Users, detailed results viewable to: All, participants: 64


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
6 (9.4%)

Shouldn't be implemented.
22 (34.4%)

(I have no opinion)
20 (31.2%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Improve entry subscription notification - include title, introduce delay

Area:
notifications, entries

Summary:
When sending notifications of new entries, set a delay for most cases, and include the entry's title.

Description:
Currently, subscribing to be notified of new entries in a given community or journal results in a notification that there is a new entry, and a link.

It would be useful to the person getting the notification to include more information about that entry. However, the current lack of information is probably deliberate, because no matter how many things are done to make sure nothing is posted with the wrong security or -- well, any of the other possible scenarios where something that wasn't meant to be shared is shared -- no matter how careful Dreamwidth is to make such situations unlikely, they will still occasionally happen.

To further decrease the chances that someone who's not meant to see the entry will be notified that it exists, I propose to delay the sending of most new-entry notifications for about 5 minutes (the same delay before new entries appear on the Latest Things page), which gives time for someone posting an entry to notice and edit before a notification is sent. (People with very slow internet connections or who have been pulled away from the internet would still have a higher chance of something slipping through.)

In exchange for the delay, send the title of the entry along with the emailed notification, and perhaps the tags.

For community administrators with subscriptions to new entries in their own communities, would it be acceptable to send a notification immediately, and with title and tags?


(This suggestion brought to you by Azz's automatic paranoia that something horrible is happening when there is a new entry in dw_antispam while out-and-about with mobile email but crappy internet from the smartphone.)

Poll #9972 Improve entry subscription notification - include title, introduce delay
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
6 (12.8%)

Shouldn't be implemented.
4 (8.5%)

(I have no opinion)
17 (36.2%)

(Other: please comment)
2 (4.3%)

cesy: "Cesy" - An old-fashioned quill and ink (Default)
[personal profile] cesy

Title:
Option to show "originally posted as" on imported entries and comments

Area:
entries, comments, importing

Summary:
Expose "originally posted as" on imported entries and comments, as an option that can be added to styles if desired.

Description:
Some users would like to be able to see where a comment or entry has been imported from, if they are importing from several locations or different names, or wish to display the history in full on Dreamwidth. Other users would prefer to keep the current display. I propose that the importer is updated to preserve the username and site/OpenID name at the time of import, so that this information is available to style designers, who can then create styles with it displayed, or add it to their styles as an option for those who want to show it on their journals. For previously imported entries where the original import site has not been saved, this would display something like "Originally posted as: information not available".

Poll #9857 Option to show "originally posted as" on imported entries and comments
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

Should be implemented as-is.
22 (34.9%)

Should be implemented with changes. (please comment)
10 (15.9%)

Shouldn't be implemented.
7 (11.1%)

(I have no opinion)
24 (38.1%)

(Other: please comment)
0 (0.0%)

ciaan: revolution (Default)
[personal profile] ciaan

Title:
Privacy-lock icon by contact info on profile

Area:
profile, privacy

Summary:
Put a privacy-lock icon by the "other services" section in "connect" on the profile if these are visible only to access list.

Description:
There is a little lock icon that shows next to the "contact details" at the top of the profile page where the email address is listed, if that address is set to be visible only to the access list. However, there is more contact info shown on the profile page, in "other services" in the "connect" section, and there is no indication next to that section to remind/reassure the user that the info is only visible to the access list. I suggest adding another lock icon in that section immediately next to the title, the same as for "contact details".

Poll #9856 Privacy-lock icon by contact info on profile
Open to: Registered Users, detailed results viewable to: All, participants: 64


This suggestion:

View Answers

Should be implemented as-is.
57 (89.1%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (10.9%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Notifications for new popular-with-circle accounts

Area:
circles, discovery

Summary:
When there are changes to the lineup in http://www.dreamwidth.org/tools/popsubscriptions , there should be a subscription to be notified of what accounts were added.

Description:
http://www.dreamwidth.org/tools/popsubscriptions lists accounts that a lot of people in your circle subscribe to.

I'm not entirely sure how it is currently calculated, whether it is generated on demand as the page is loaded, or if it is regularly recalculated.

It would be pretty spiffy if something on the back end could check it on, say, a weekly basis, to see if there are any accounts newly appearing.

If a user is subscribed to notifications, the results of this would be sent to them in the usual ways (inbox, email).

The system should be smart enough to not highlight an account that has appeared on the list because the user just unsubscribed from them, and similarly not highlight any banned account.

Poll #9854 Notifications for new popular-with-circle accounts
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

Should be implemented as-is.
14 (25.5%)

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

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
40 (72.7%)

(Other: please comment)
0 (0.0%)

stillnathan: (Default)
[personal profile] stillnathan

Title:
Moving entire posts from one journal to another or a community

Area:
posting

Summary:
It would be really useful to be able to make a post, have comments on it, and finish it, especially for rpging, and then be able to move that entire post, with comments, over to a different comm. That would allow for pre-writing of events and scheduled things, and make for some really neat actions!

Description:
This idea would work well to enable people to pre-write things in their journal. Say a person wants to present a new effect, or a style, or a html code, or even just a paper with proper formats. They could do it in their own journal, set it up, make sure it works, and then enable this effect, and be able to just move the post over with a drop down 'post to' box.

This would be especially helpful for roleplayers, who often write stuff out ahead of time, trying to mesh schedules for large posts, or to allow for people in different time zones to complete something, then post it so it appears suddenly. With the ability to do this entire, a lot of that would become easier. In addition, those who accidentally post in the wrong community, and even have conversation back and forth before it is realized would be able to move the post, with those comments, to the correct comm.

Poll #9852 Moving entire posts from one journal to another or a community
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

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

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

Shouldn't be implemented.
16 (29.6%)

(I have no opinion)
25 (46.3%)

(Other: please comment)
1 (1.9%)

[personal profile] imaginemeandyuu

Title:
Thread Logging (or "Dreamwidth Journal History")

Area:
Threads / notifications

Summary:
It can be hard to track down all the posts you've made or threads you've started or replied to -- even with tags, commenting in your journal, other people's journals, communities, etc, can make it hard to have any kind of record of your own experiences on the site. If the site can record every one of your posts/top level comments (or the top-level comment you replied to) and report it (somewhere on your console, or into a specific entry in your journal) it will be much easier for people to reread their old posts/threads and track their life on DW.

Description:
Right now it's difficult to find everywhere you've posted or commented to and thus track your 'life' on this site. Basically, if someone wishes to do "thread logging", it all needs to be done manually -- you can track threads which sort of does it a little, but that again is a manual task. There's no automatic record, no recorded history, of where you've commented and what you've said.

Especially as the roleplay community gets larger this is something I feel will be more in demand (as rpers frequently like to reread the character development they go through, but sometimes this can be months or years of posts to wade through -- with an RP like CFUD, you've got six years of roleplay! Or, even if they're not fans of rereading, a lot of sites request you turn in your activity every month, which involves wading back through posts trying to find it, using tags liberally to help yourself keep track (but again, tags are added manually, which means human error). Thread-logging is standard but usually involves manual work.

Perhaps there can be an option on the site which outputs (into a console box or an entry that you set up and somehow mark as a "history" entry) the links for your comments/posts. Obviously doing every comment would be frustrating, so I'm thinking:
A) Any post you make, the post link would go in here.
B) If you make a comment, the History console identifies the top level comment in that thread (whether you started the thread or replied to it) and links it, discarding anything after. (Obviously in the case of B it would also check if it has already linked this thread and not link again if so).

Additional thoughts, details, and concerns:

- It would need to be arranged by date somehow, whether just a chronological order (top-down) or with datestamps of the toplevel comment beside them.

- Since what's just a list of links could become unwieldy fast it would be good for the user to either be able to convert into linktext instead of a plain URL, or at least have a field where the user could add a comment beside the link to identify the content if they choose to (ex: (LINK) - "Umeda and Akiha have a picnic. Mood crab sings them a song.")

- Having a list of the number of your total comments in the thread/post would probably be super useful to RPers (obviously this would mean that either it would have to dynamically update with each reply like the comment section in your profile OR the user could manually run to check for all updates you've made with that username).

- If this WAS going to be planned anyway, obviously the fact that people imported journals would make it difficult to have a 'full' list of their journal's history, unless there were a way to run the function to comb back through all appearances of the relevant username on DW (using their ID) and do a link dump. (This would be ideal for me, as a CFUDer who really wants to reread old threads). Since DW has such a strong search function I think this would theoretically be possible using something similar to the search functionality using the journalname ID, but I'm no programmer.

- Privacy issues -- if in a console you need to be logged into to see this isn't a concern, but if not, whatever journal entry this output into might need to be private by default (with the user able to make it public if they chose to?) in case you didn't want the whole world to see what that journal had been up to.

- This obviously wouldn't track anonymous comments, so if users can manually add extra threads (as in an editable entry) for any 'anon posts' they participate in, or if they did a 'bodyswap' with journals or so on, they could help keep track of these extra things as well. Not totally necessary as long as the journal name's history is added but it'd be a nice bonus for completion's sake.

- If this is impossible to do on the site itself, are there any programmers on the suggestions team or reading this otherwise who may be able to draw up an associated client that could run a similar function of outputting posts/the top comment of threads with a journal name? It's currently difficult to get full thread logs without having to manually keep track of things yourself, which is doubly difficult if you have multiple computers you thread from, if your game doesn't use tags, etc.

Poll #9801 Thread Logging (or "Dreamwidth Journal History")
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
11 (19.3%)

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

Shouldn't be implemented.
18 (31.6%)

(I have no opinion)
21 (36.8%)

(Other: please comment)
2 (3.5%)

kaberett: Overlaid Mars & Venus symbols, with Swiss Army knife tools at other positions around the central circle. (Default)
[personal profile] kaberett

Title:
Opt-in access filters

Area:
privacy, circle management, filters

Summary:
Many users have opt-in access filters, allowing their readers to specify which topics interest them. Currently this tends to involve a lot of work for a journal owner in terms of transcribing results from polls or views expressed in comments. An automated system allowing people on given journal owner's access list to opt-in to filters without requiring work on the part of the J.O. would be awesome.

Description:
Journal owners will often decide that they want to filter their posts according to subject - e.g. "knitting" or "offspring" or "local happenings" or "school" or "health"-related posts - so that their readers are not exposed to posts on topics they have no interest in. Currently, this is typically managed by the journal owner asking their access list/readers to leave a comment/respond to a poll indicating what the readers would like to see. The journal owner then needs to transcribe these results onto the circle management page - which typically involves repeatedly switching between browser windows/tabs.

It would be potentially useful if some of this process could be automated to reduce the amount of work the journal owner has to do.

I envisage something like:

1. J.O. creates an access filter, and specifies that it is an opt-in filter.
2. J.O. flags to readers that these opt-in filters exist/new subscribers are informed that these opt-in filters exist as they subscribe.
3. Readers tick some boxes that indicate "if I [have been/am in future] granted access, I wish to be included in this subset of opt-in filters"
4. J.O. receives a notification that Reader X wishes to be added to filters X,Y,Z. Notification includes links "click here to allow all" and "click here to edit" (for those cases where J.O. decides they really don't fancy having their family members on their sex filter, or what have you!)
5. Profit!!!

The main problem I see with this is that it causes many, MANY more options to become available, in ways that might be intimidating - which in turn makes me think that this might be a good feature to roll out as a perk of paid accounts.

Poll #9800 Opt-in access filters
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

Should be implemented as-is.
29 (47.5%)

Should be implemented with changes. (please comment)
6 (9.8%)

Shouldn't be implemented.
8 (13.1%)

(I have no opinion)
15 (24.6%)

(Other: please comment)
3 (4.9%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Log filter changes (user-viewably)

Area:
access filters, reading filters, user-facing logs

Summary:
Show a log of changes to filter membership (access and reading) over time.

Description:
Inspired by http://dw-suggestions.dreamwidth.org/385524.html, it would be nice to see at what point in time various users (or feeds/communities) were added to or subtracted from access and reading filters.

If this is logged now, it is not logged so a user can see it. It probably would not solve any real deep and pressing everyday problem for most people, but occasionally either something comes up, or there's a need to research. This could also be helpful in discovering the sneaky kind of account compromise where someone with unobserved physical access to a logged-in session quietly adds themselves to filters they were not in originally.

The log should probably stretch as far back as practical, paginate sensibly, and be able to be sorted and filtered.

It should be viewable by all filters, by only access or only reading, by any specific single filter, and by any user. (Anything else that would be helpful?)

If filtering, sorting, slicing, and dicing would significantly add to the complexity to implement or expense to run, it could be implemented with a basic view at first, or have advanced features be reserved as paid.

It should have appropriate contextual links to modify filters and membership.


I don't imagine that this would be any kind of pressing priority to implement, I just want it in Bugzilla so someday someone who's bored and cruising through can say "Oh boy! That sounds like great fun to code! I think I'll pick that!"

Poll #9496 Log filter changes (user-viewably)
Open to: Registered Users, detailed results viewable to: All, participants: 58


This suggestion:

View Answers

Should be implemented as-is.
29 (50.0%)

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

Shouldn't be implemented.
2 (3.4%)

(I have no opinion)
27 (46.6%)

(Other: please comment)
0 (0.0%)

skakri: (Default)
[personal profile] skakri

Title:
OpenGraph implementation

Area:
frontend, accessibility, cross-site data sharing

Summary:
It would be nice if sites, that use OpenGraph metadata, could use our provided data, instead of crawling the page in question and collecting arbitrary data (article image, article title, author, etc.)

Description:
Sites that support OpenGraph Protocol (http://ogp.me/), like Facebook and Google+ would benefit from already provided data; that would help those sites 1) categorize that data (entry title, tags), 2) provide correct information, when posting to FB or G+ (title, image), instead of full page title (username | post, for example).

Example - http://skakri.grab.lv/2360053.html (check source; done: profile username, entry image, entry title, publishing date and used tags). Could be implemented also in profile pages - user.domain.tld/profile

Poll #9490 OpenGraph implementation
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (7.7%)

(I have no opinion)
31 (79.5%)

(Other: please comment)
0 (0.0%)

[personal profile] the_cats_mother

Title:
Option to Hide Community Member List

Area:
Privacy

Summary:
I see a suggestion for invisibility for communities was rejected (sadly) but what about an option to hide the member list?

Description:
I'd like more privacy for members of communities with a sensitive subject matter or to avoid harrassment of members. I know you can opt not to subscribe to a community so that it doesn't show on your personal profile, but members of a community can still be identified from the profile of the community itself. Example; under another username on LJ, I belong to a small community which has attracted a very unsuitable would-be member. This person has been refused membership and is now pestering members to plead on his/her behalf, both on their journals and even by tracking them down on other sites via their profile pages. If DW would let us hide our member list, we could import to here knowing that even if our unwelcome guest found our community, s/he would'nt be able to see our (changed) usernames and start harrassing us again.

Thanks for reading. :)

Poll #9372 Option to Hide Community Member List
Open to: Registered Users, detailed results viewable to: All, participants: 95


This suggestion:

View Answers

Should be implemented as-is.
50 (52.6%)

Should be implemented with changes. (please comment)
23 (24.2%)

Shouldn't be implemented.
7 (7.4%)

(I have no opinion)
14 (14.7%)

(Other: please comment)
1 (1.1%)

thnidu: my familiar. "Beanie Baby" -type dragon, red with white wings (Default)
[personal profile] thnidu

Title:
Make the tag "security" label useful, or remove, or at least explain it

Area:
tags

Summary:
The "security" label on the tag management page is (1) redundant and (2) misleading. (1) It is simply the lowest level (highest line on the chart right above it) that applies to any post tagged with it. (2) By being there at all, it suggests that it is useful, e.g., a settable value for "who can see this tag".

Description:
See Request #12096, under "Site Interface". I asked about the tag, and was told
"Tag security is tied to entry security. If the posts used for those tags are public, then the tags will also be public."

My reply:

So, if I use a tag only for filtered posts, the page for that tag will say "Security: filtered". But the first time I use it for a public post, the "security" level will change to "public". In other words, it's exactly equal to the label on the lowest security level (highest line on the list just above it) with a non-zero count.

The screen is deceptive. Giving a "security" level for the tag strongly implies that there is a security level ASSOCIATED SPECIFICALLY with the tag, and that it can be set somehow. I've been assuming I can set security for any post independent of any other post and any other setting. This "security" field is not only useless -- totally redundant with the list above it -- but misleading as well. Either

1. make it meaningful -- e.g., by letting the user set "who can see this tag" (I may not WANT everyone to know that I've tagged a particular post as "love life", or that I have such a tag!)
2. or rename it, e.g., "lowest security level of posts with this tag", or something shorter that says the same thing, if you can think of a wording
3. or remove it entirely.

Is the meaning of this field described anywhere online? Unless you follow option 3, there should at least be a link on the "security" label to explain it.

My preference is #1. I know that would take more work than #2 (+ the info link), but that would be adding something useful.

Poll #9006 Make the tag "security" label useful, or remove, or at least explain it
Open to: Registered Users, detailed results viewable to: All, participants: 65


This suggestion:

View Answers

Should be implemented as-is.
28 (43.1%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
28 (43.1%)

(Other: please comment)
1 (1.5%)

fiddlingfrog: (Default)
[personal profile] fiddlingfrog

Title:
Send inbox notification to new OpenID accounts upon comment or entry importation

Area:
inbox, importer

Summary:
When the importer imports a comment, it should leave a notification in the inbox of the associated OpenID account stating "A comment you left at {original site} has been imported to {Dreamwidth journal/community name}."
When the importer imports an entry from a community import, it should leave a notification in the inbox of the associated OpenID account stating "An entry you wrote in {original community} has been imported to {Dreamwidth community name}.

Description:
Currently OpenID accounts have very little ability to find comments, and soon entries, that have been imported to Dreamwidth. The Recent Comments page only goes back 10 comments, and deleting one of those comments doesn't let another one slide in at the back of the list. Currently the search by poster function [http://foo.dreamwidth.org/?poster=] doesn't work for OpenID accounts, not by using the displayed name {bar.livejournal.com} nor by using the internal name {ext_###}. Unfortunately, it's too database heavy to try and search for all comments and entries an account made anywhere that isn't their journal, so my idea is to give the user a place to start looking themselves.

When the importer imports a journal or community, it should leave a notice in the Dreamwidth inbox of the OpenID account that's been created (or added to) stating what action just happened. It only needs to leave one notification per import.

Under this idea, a user from LiveJournal would log into Dreamwidth for the first time using their OpenID credentials and find an inbox with several notices already waiting for them, like this:

"Comment imported to {Journal A}"
- A comment you left in {Imported journal's original address} has been imported to {Journal A}
"Entry imported to {Community B}"
"Comment imported to {Community B}"
"Comment imported to {Journal C}"

Edit: It's one message per import, not one message per comment/entry.  If you count the community and comment import as a single job, it's up to two message per import.
For example, say somebody decides to import [livejournal.com profile] gardening to DW. In my OpenID account's inbox I'd get one notification saying that an entry or entries I posted there had been imported to DW. I'd get another notification saying that comments I had left there had been imported to DW. And that's it.

Upsides: OpenID users feel more in control of imported content.
Downsides: Will probably slow down the importer.

Poll #9001 Send inbox notification to new OpenID accounts upon comment or entry importation
Open to: Registered Users, detailed results viewable to: All, participants: 59


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
11 (18.6%)

Shouldn't be implemented.
5 (8.5%)

(I have no opinion)
25 (42.4%)

(Other: please comment)
0 (0.0%)

dragonfly: stained glass dragonfly in iridescent colors (Default)
[personal profile] dragonfly

Title:
Automatic timed change to a post's access level

Area:
posts

Summary:
Provide a setting that applies to all posts, changing their access level after some specified period of time.

Description:
I'd like to be able to set posts to change access level after a certain amount of time. That way they could, for instance, be public for a while but then automatically change to "access list" when the time is up.

There should probably be a place when posting that allows you to say "not this post, though," however.

Poll #8406 Automatic timed change to a post's access level
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

Should be implemented as-is.
20 (35.7%)

Should be implemented with changes. (please comment)
7 (12.5%)

Shouldn't be implemented.
10 (17.9%)

(I have no opinion)
19 (33.9%)

(Other: please comment)
0 (0.0%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Not-Publicly-Identified Commenting

Area:
comments, anonymous comments

Summary:
Comments where the username of the commenter is visible to the journal owner and/or community admins, but no one else. Journal owners/admins would be able to control this like any other commenting option, but would not be able to make the comment publicly display the username after the fact.

Description:
Assuming the journal owner has allowed it, a commenter would be able to select "Do not identify me publicly" (or some much smoother phrase) as an option when commenting, so that their comment is displayed as anonymous to everyone but the journal owner (or the community's admins).

This would allow many of the benefits of an anonymous discussion taking place in the public sphere (people who cannot for whatever reason allow their opinions or experiences to be traced to their Dreamwidth identity as far as the public is concerned) but would also allow the people moderating the discussion to confirm at least relative identity. (In a recent high-profile discussion, one person in the publishing industry was accepting comments by email to post anonymously with a description of that person's authority to be saying what they said.) It would also allow people to correct typographical errors or delete things that they had second thoughts about.

The commenter would have to trust that the journal owner/admin would not "out" them, which could be done deliberately (think screenshot), accidentally (referring to a person by name in a reply), or inadvertently (using information that they didn't think would be identifying, but was known to a third party witnessing the discussion). The commenter would also have to be careful of not sharing sufficient information to out themselves, and not anon-failing (posting fully identified in a forum where they had previously been posting anonymously).

This would be a possible workable way of allowing anonymity into locked entries. The usual problems with allowing anonymous comments on locked entries are mostly social - the journal owner would know that it's a small pool of potential commenters and can play matching games; the entry might be restricted to a very specific security group, such that someone might think themselves anonymous and comment, but could be the only person in the security group and therefore identifiable. However, with knowledge that their identity is visible only to the journal owner/admin(s), someone could comment "anonymously" with a more informed mindset (though fellows in the pool of people given access might still figure them out based on the fact that access is listed in the profile).

This would be great for anonymous games (anonymemes, kink memes, darkrooms, the pride thread). It would preserve accountability while retaining at least some part of the anything-goes spirit.

This was inspired by a locked discussion about drug use and abuse, which could possibly have used a feature like this. We're all there because we know the journal owner, not because we trust each other necessarily.

Poll #8393 Not-Publicly-Identified Commenting
Open to: Registered Users, detailed results viewable to: All, participants: 84


This suggestion:

View Answers

Should be implemented as-is.
44 (52.4%)

Should be implemented with changes. (please comment)
20 (23.8%)

Shouldn't be implemented.
7 (8.3%)

(I have no opinion)
13 (15.5%)

(Other: please comment)
0 (0.0%)

boundbooks: Zhang Ziyi (Default)
[personal profile] boundbooks

Title:
Set IP Logging to 'Opt-In' Rather than 'Opt-Out'

Area:
Entries and Commenting

Summary:
Currently, all newly created DW journals and communities have IP logging turned on by default. My suggestion is that IP logging should be turned off by default, with the ability to turn it on by 'opting-in' and enabling it.

Description:
While IP logging has it uses – namely, preventing sockpuppeting, discouraging trolling and ID-ing spam – it also comes with a high privacy cost. When making a comment on an IP logging post, one makes a wish: 'I will give this post my current location and hope that this information will never be used that against me.'

For the majority of DW journals and communities, default IP logging is over-kill. Most journals and communities are not experiencing continual sockpuppeting or trolling or other situations in which moderators would need to be able to pinpoint the address of a commentor in order to unravel what's occurring. Yet because IP logging is opt-out rather than opt-in, most DW journals and communities take this personal location information without thought and record it for as long as they exist.

I do not argue that IP logging should be removed as a service, but rather that it should be not be enabled as part of the default settings. Journal owners and communities should have that debate about privacy and moderation on their own and potentially with their community members. The removal of the privacy of their members and commentors should be a conscious, thoughtful decision, rather than simply one made by the default settings.

I am well aware that IP logging/IP address information is already being taken by Dreamwidth itself. However, I feel that there is a tremendous difference between these two states: 1) information existing on Dreamwidth's servers and accessible to Dreamwidth's employees/code volunteers 2) IP addresses being handed by default to all original posters, journal owners and community administrators.

The argument that 'one should never need to conceal an IP address, because one should know that IP addresses are always logged' fails to make a distinction between theoretical perfect privacy and practical privacy. It presumes that one is engaged in criminal activities that are pursued by the FBI rather than concerned about the kind of personally damaging information that participating in fandom activity or a complaint about a job situation can become in the hands of a malicious fellow-user. Making IP logging no longer enabled by default in created journals/communities is measurable progress towards practical, every-day privacy.

IP logging reveals sensitive information for all users, but the cost is even higher for rural users. If one's IP address simply reveals 'Chicago, Illinois, USA', it is unlikely that the contents of one's journal could be used to find a specific user. On the other hand, if one is a commenting from a small town, personal details as well as IP logging make it remarkably easy to whittle down and discover an identity. I myself live in a relatively rural area, and as such my cost of remaining anonymous is far higher than a fellow metropolitan-living friend. Information such as the name of my college, when combined with the name of my town, would whittle me down to a list of less than ten possible people in that town. Combined with gender and a rough age range, and the list becomes a list of one. As such, I am extremely cautious about anything I post. My city-dwelling friend, who actively gives college, gender and age range information, remains on a possible list of thousands of fellow alumni in their city.

My suggestion is intended to improve the privacy of Dreamwidth users, which I feel is in line with the goals of the Dreamwidth community. Since IP logging would remain as an 'opt-in' option for users or communities who needed this tool, the only problems I can think of would possible be things on the 'back end' of Dreamwidth, possibly if successful site-wide spam-reporting requires the majority of journals/communities to IP-log.

Poll #7707 Set IP Logging to 'Opt-In' Rather than 'Opt-Out'
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

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

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

Shouldn't be implemented.
35 (57.4%)

(I have no opinion)
10 (16.4%)

(Other: please comment)
1 (1.6%)

[personal profile] rho

Title:
Split comment screening into moderation and private comments

Area:
comments

Summary:
As it currently stands, comment screening is used for two very different purposes. It's used to allow the journal owner to check over comments before they are visible, and it's used to make private comments that are never intended to be seen by anyone other than the journal owner. I propose that this functionality be split in two.

Description:
[Based on http://dw-suggestions.dreamwidth.org/548634.html?thread=3291930#cmt3291930]

The original idea behind comment screening was that it should be like moderation. The journal's owner would have a chance to read over the comments before they were visible, and delete any that were incendiary, inappropriate or just plain spam.

What with users being users, a lot of people have found other uses to put this feature to, though, namely as a method of making private comments that aren't meant to be visible to anyone other than the journal owner.

While I always think it's great when people find unexpected uses for features, the problem here is that the two main uses are very different and have very different needs. Features that will benefit one usage can be to the detriment of the other.

The obvious example here is what happens when you reply to screened comments. In the original implementation, a comment would automatically be unscreened when you reply to it. This absolutely makes sense in the moderation model, but is disastrous for the hidden comments model. As a result, Dreamwidth no longer automatically unscreens comments when you reply to them.

What I'm proposing is that the overloaded concept of comment screening should be split into two. That is, we should have two features, one of which would be for comment moderation, and the other of which would be for making private comments. The biggest advantage to this would be that the two features could then be developed separately and in their own directions, without needing to worry about how they impact each other.

I think it would also be useful in terms of clarity of what the feature is for. There are also currently instances where it's not immediately obvious why the author is screening comments. For instance, if someone makes an emotional post about a controversial subject, they might want to screen comments to moderate out trolls, or they might want to screen comments because they don't have the emotional energy for public discussion. With the split, this would become much clearer.

The biggest disadvantage I can think of for this is the added complexity. this would especially be noticeable when posting entries, since there are already a lot of available options there.

The following are NOT part of this suggestion themselves, but are intended as examples of the sort of thing that could be done if this split were implemented.

* A reversion to the old behaviour of moderating comments automatically when they're replied to for moderated comments only.

* The implementation of comment moderation whitelists of people whose comments display without moderation (possibly based upon access lists).

* Allowing people to see how many comments are awaiting moderation on a post.

* The option for private comments to be truly private and not have any way of them being made public.

* Comments on an entry being able to be enforced public, enforced private or (the new setting) commenter chooses whether to be public or private.

* Giving the poster of a comment the ability to change the privacy status of their comments (if allowed in journal/entry settings).

Poll #7106 Split comment screening into moderation and private comments
Open to: Registered Users, detailed results viewable to: All, participants: 62


This suggestion:

View Answers

Should be implemented as-is.
30 (48.4%)

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

Shouldn't be implemented.
11 (17.7%)

(I have no opinion)
17 (27.4%)

(Other: please comment)
1 (1.6%)

stephenie_n_lamaina: (Default)
[personal profile] stephenie_n_lamaina

Title:
Alternate identy (aka) near user name

Area:
Header on comments

Summary:
In different blogs and forums I am know buy different user names. I would like to be able to put an aka near my user name.

Description:
I know the suggestion for automatic signatures of comments was already rejected and when I read through the comments I understood why.

When I started in fanfic/fandom, I picked a nom de plume which I became know by (been using it since the 80's). I used in all the places that I signed up for and then low and behold one day I go to sign up for whatever the new, hip, "in" site is and my name is not available. Now I need to pick something new. Do I add a little something to or pick something new? I always sign my posts/comments if it is not the same as my user name. It would be nice if I could put an aka near my user name so I could let it be know that both those identities are mine. I suggest making it text only with a limit to the amount of characters. I know I could make icons that addressed this but icons aren't something that I make so that leaves me with begging others.

Poll #7081 Alternate identy (aka) near user name
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
6 (11.3%)

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

Shouldn't be implemented.
16 (30.2%)

(I have no opinion)
26 (49.1%)

(Other: please comment)
0 (0.0%)

tima: (Default)
[personal profile] tima

Title:
The "screen" option for a comment you leave at someone's post

Area:
comments options

Summary:
Nice to have another option for a comment you leave at someone's post - screen the comment

Description:
Being in the LJ for 10 years I never understood why the "screen" option exists for an owner of a post only. People who comment someone's post do have an option "delete" for their comments, so why don't they have the "screen" option? To accomplish the same (in a way) result a commentator either has to send a private message directly to inbox or has to post a comment and immediately delete it to make it "invisible". Personally I hate to see a palisade of deleted comments mixed with still existing ones...

Poll #7079 The "screen" option for a comment you leave at someone's post
Open to: Registered Users, detailed results viewable to: All, participants: 59


This suggestion:

View Answers

Should be implemented as-is.
10 (16.9%)

Should be implemented with changes. (please comment)
7 (11.9%)

Shouldn't be implemented.
33 (55.9%)

(I have no opinion)
7 (11.9%)

(Other: please comment)
2 (3.4%)

Profile

Dreamwidth Suggestions

April 2017

S M T W T F S
      1
23456 7 8
9 101112131415
16171819202122
23242526272829
30      

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom