sepdet: Samhain worshipping the veggies. Oooommm. (Okay, yes, catnip was involved.) (Default)
[personal profile] sepdet

Title:
Tweak login button for ham-fisted mobile users.

Area:
Control strip

Summary:
Reposition login/logout button with some space around it.

Description:
I'm not quite sure of the best way to fix this, but I keep hitting the Logout button when I try to click the "reading" link below it on the control strip at the top of my journal. I have arthritis and an iPad, so I'm testing accessibility and mobile issues for you at the same time!

For both audiences, it would be better not to have a frequently-accessed link right beneath "logout". Maybe the logout button could be moved to the right, as it's easier to hit the middle of the word "Reading" horizontally than vertically.

There's probably some way to tab to it, but I have a hunch this wouldn't be too hard to adjust. Of course, that brings in a bit of the dreaded whitespace, which makes sites easier to browse via mobile devices but tends to make pages look ugly.

Poll #9085 Tweak login button for ham-fisted mobile users.
Open to: Registered Users, detailed results viewable to: All, participants: 62


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
24 (38.7%)

(Other: please comment)
0 (0.0%)

momijizukamori: Green icon with white text - 'I do believe in phosphorylation! I do!' with a string of DNA basepairs on the bottom (Default)
[personal profile] momijizukamori

Title:
Increased font size on Tropospherical site scheme

Area:
Site scheme (Tropospherical)

Summary:
At the moment, Tropo shows entry and comment text at 75% of browser default. This winds up being a bit on the small side, compared to other similar websites, which leads to squinting and headaches after lots of site-schemed page reading for people who don't usually experience these problems, particularly as Tropo Red is the 'default' people who are new to the site see. Increasing this a bit (I would suggest 0.85em) would increase readability

Description:
This came about as a result of some of the LJ-migration recently, where a number of people who are not usually photosensitive mentioned getting headaches after browsing on both Tropo Red and Tropo Purple for a while. I did some poking about in CSS, and discovered that the 0.75em size scales text down to a bit smaller than the size I usually see on blogs or LJ's old site schemes. It's basically in that range of 'just enough change to cause problems, not enough change to be immediately noticeable'.

I wrote a quick Stylish script to increase font size to 0.82em (along with a slightly smaller line height, but I think it's the font-size that's the core issue) and got feedback that yes, it was a lot more readable that way. 0.82em is kind of weird, and I'd probably just say round up 0.85em to be neat about it.

The problem with writing it as a Stylish script, though, is that any time someone is not at their home computer, it's back to site default (and I do realize that there are other site schemes, but most people I've talked to don't like the horizontal navigation of Celerity and find black-background even harder to read). Increasing the font-size just a bit should be a fairly easy fix (unless it's not in CSS styling? I haven't had a chance to poke through files), and it's not a big enough change to negatively affect users who didn't have the problem with the smaller font size while helping people who do.

Poll #9005 Increased font size on Tropospherical site scheme
Open to: Registered Users, detailed results viewable to: All, participants: 81


This suggestion:

View Answers

Should be implemented as-is.
33 (40.7%)

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

Shouldn't be implemented.
8 (9.9%)

(I have no opinion)
17 (21.0%)

(Other: please comment)
0 (0.0%)

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

Title:
Mobile page/regular page toggle button

Area:
usability

Summary:
I think it would be a good idea to have a toggle button to switch back and forth between a mobile page and its regular counterpart.

Description:
It has been clearly demonstrated that different users and different mobile devices have different needs and requirements. Sometimes it is desirable to be able to switch back and forth between a mobile page and its regular counterpart (wherever different versions exist) quickly and easily. A toggle button at the top of the page could solve this.

See http://dw-suggestions.dreamwidth.org/1286067.html for comments regarding usage that spawned this idea.

Poll #8903 Mobile page/regular page toggle button
Open to: Registered Users, detailed results viewable to: All, participants: 79


This suggestion:

View Answers

Should be implemented as-is.
55 (69.6%)

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

Shouldn't be implemented.
1 (1.3%)

(I have no opinion)
22 (27.8%)

(Other: please comment)
0 (0.0%)

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

Title:
Link stats page

Area:
stats

Summary:
Link from www.dreamwidth.org/stats to www.dreamwidth.org/stats/site

Description:
The second page has a load of interesting statistics, but doesn't appear to be linked from anywhere, and I keep forgetting the URL. Cross-linking between the two pages would make it easier for people who like to browse that data occasionally.

Poll #8894 Link stats page
Open to: Registered Users, detailed results viewable to: All, participants: 62


This suggestion:

View Answers

Should be implemented as-is.
53 (85.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (12.9%)

(Other: please comment)
1 (1.6%)

vickyblueeyez: (Default)
[personal profile] vickyblueeyez

Title:
Paid Account Trial

Area:
paid time

Summary:
Give users the option to have paid time for a certain length of time so see if they like it.

Description:
LJ had a feature where for free, you get two weeks of paid time. I think this would be useful for DW. By having this, users can preview what it's like to have paid accounts and therefore, if they like it, they would be more inclined to buy it. I would like to preview what it's like myself but am hesitant because I do not want to end up wasting money if I don't like it.

Poll #8877 Paid Account Trial
Open to: Registered Users, detailed results viewable to: All, participants: 87


This suggestion:

View Answers

Should be implemented as-is.
21 (24.1%)

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

Shouldn't be implemented.
34 (39.1%)

(I have no opinion)
25 (28.7%)

(Other: please comment)
2 (2.3%)

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

Title:
Manage Circle: mark and set apart users you've banned

Area:
circle management

Summary:
In the People section, mark in some way, group together and set apart the users you've banned.

Description:
It would be awesome if it could also display the note you added or at least a link to Ban/Unban.

Edit: it would also be awesome if this section could be collapsible.

Poll #8848 Manage Circle: mark and set apart users you've banned
Open to: Registered Users, detailed results viewable to: All, participants: 60


This suggestion:

View Answers

Should be implemented as-is.
35 (58.3%)

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

Shouldn't be implemented.
3 (5.0%)

(I have no opinion)
16 (26.7%)

(Other: please comment)
2 (3.3%)

iosonochesono: (Default)
[personal profile] iosonochesono

Title:
Record of Point Usage

Area:
Payments/DreamWidth Shop Point History

Summary:
This would be a system to see the history of point transfers on DreamWidth, like being able to look up payment history except with point usage and transfers.

Description:
At the moment, there is no place to look up where shop points have been used on DreamWidth unless you have used them personally. (In which case, it shows up on Payment History.) If points you purchased are transferred to another user, there is no easily accessible record of that transfer.

I would like to see something like the payment history for transfers where the list of when and how many points and to whom are readily present, so if I'm wondering where shop points went I can easily look it up. Ideally, this wouldn't actually be in the same list as payment history, since that would get confusing.

Poll #8422 Record of Point Usage
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.4%)

(I have no opinion)
12 (28.6%)

(Other: please comment)
0 (0.0%)

helens78: Cartoon. An orange cat sits on the chest of a woman with short hair and glasses. (Default)
[personal profile] helens78

Title:
Add "ao3.org" to the sites that get custom userheads when linking with "user" tags

Area:
entries

Summary:
We already have "archiveofourown.org" user links (ie, entering "user name=user site=archiveofourown.org" gets you a link to user's AO3 profile and works list), but "ao3.org" redirects to the same domain and would benefit from having a custom userhead as well.

Description:
It may seem like saving 12 characters isn't much, but allowing users to interchangeably use both functional domain names for the AO3 user links would help users prone to typos, save time, and shouldn't affect current functionality (in other words, please don't take the archiveofourown.org option away!).

Poll #8408 Add "ao3.org" to the sites that get custom userheads when linking with "user" tags
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

Should be implemented as-is.
41 (83.7%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (16.3%)

(Other: please comment)
0 (0.0%)

[personal profile] josht

Title:
Support for HTTPS on all pages, including journal pages

Area:
security, privacy, https,

Summary:
I'd like to have the option of using HTTPS to access all dreamwidth pages, including journal pages as well as pages on dreamwidth.org itself.

Description:
Inspired by the HTTPS Everywhere addon (https://www.eff.org/https-everywhere), I started looking through the sites I regularly visit to find which ones have HTTPS support. I frequently read journals on dreamwidth, but dreamwidth doesn't support https on journal pages; the certificate only works for www.dreamwidth.org. Also, visiting https://www.dreamwidth.org/ redirects to the login page rather than serving the front page securely; changing an http URL to https should serve the same content securely, rather than changing the content served.

Having HTTPS on all pages would secure acccounts against session-hijacking, a particular concern when on more insecure Internet connections, such as public wifi, or university or corporate networks. HTTPS would also improve privacy. The web needs more encrypted packets and less plaintext.

Poll #8378 Support for HTTPS on all pages, including journal pages
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (32.4%)

(Other: please comment)
0 (0.0%)

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

Title:
Polls: display results on the same page

Area:
polls

Summary:
When clicking on 'see results' in a poll you haven't voted on you're brought to a new page; I'd like the results to be shown in the entry instead.

Description:
Apart from the AJAXification which is great in itself, one of the reasons I'd like this is that I often vote on a poll here in dw_suggestions because of this, not because I really wanted to vote on it (this is the case for my own suggestions or suggestions I don't have an opinion on for instance).

Poll #7864 Polls: display results on the same page
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.9%)

(I have no opinion)
13 (24.1%)

(Other: please comment)
1 (1.9%)

ratcreature: RatCreature's toon avatar (Default)
[personal profile] ratcreature

Title:
make the reading page's window title change when new entries have been posted

Area:
reading page

Summary:
I think it would be useful if the reading page changed its title with the number of new entries posted since you last reloaded, so if three people posted since I last reloaded my window title/tab name would say "ratcreature | Reading (3)" instead of just "ratcreature | Reading".

Description:
I reload my reading page fairly often, but frequently nothing has bee posted. OTOH my GMail inbox changes its window title and thus the tab name with the number of new messages in brackets, so I can see that new mail has arrived, and the Tumblr Dashboard does something similar in that a number appears over the Dashboard link and the also title changes with the number in brackets, so I can see something new was posted, even if I'm in another tab, and then reload the page to see the new content. Also, in Firefox I can change these to application tabs, and the small tab markers change color to alert me.

I think it would be useful if the Dreamwidth reading list also changed the title of the window if new posts appeared with the number of posts since I last reloaded the page.

I don't know how this kind of thing is realized on the technical side, so I'm not sure what the drawbacks would be. Maybe if it caused more server traffic the time interval in which the status is checked needs to be larger so that it wouldn't be nearly instantaneous, but it would still help if it only checked every couple of minutes (which is about the time interval I'm rechecking my reading list manually when I'm really bored and hope someone would post something already).

Poll #7837 make the reading page's window title change when new entries have been posted
Open to: Registered Users, detailed results viewable to: All, participants: 67


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
13 (19.4%)

Shouldn't be implemented.
9 (13.4%)

(I have no opinion)
18 (26.9%)

(Other: please comment)
0 (0.0%)

ivorygates: (Default)
[personal profile] ivorygates

Title:
Include Name of Journal Base Style and Theme In Credit Module in Journal

Area:
Styles

Summary:
By default, journal styles credit the designer or designers of the base style and the theme and display that information in one of the modules. What does not appear is the name of the base style or of the theme being used by the journal. It would be nice if that information also displayed.

Description:
When I read a journal displayed in the owner's style, there are many times when I would like to know what base style and what theme they have chosen. While there is a default module that appears in the journal [unless you select to remove it] that displays the names of the people who created the base style and the theme, neither the base style name nor the theme name is displayed in the module [at least in any of the journals I've looked at]. This is frustrating if you see a style/theme you think you'd really like and have to do a lot of trial and error on the "Select Journal Style" page to try to find it, and it would be nice if there were an option to display this information by default.

Since some people write their own style from scratch, or tweak the theme, or use their own resources for background images, it would probably also be nice if the module that displayed full style and color credits could automatically default to "Base style: DesignerName; Theme: JournalOwner; Resources: Journal Owner" in that case.

Poll #7105 Include Name of Journal Base Style and Theme In Credit Module in Journal
Open to: Registered Users, detailed results viewable to: All, participants: 51


This suggestion:

View Answers

Should be implemented as-is.
37 (72.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (25.5%)

(Other: please comment)
0 (0.0%)

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



EDIT: I think this is a duplicate of http://dw-suggestions.dreamwidth.org/369979.html. My apologies.

Title:
New notification: all comments made on entries tagged XYZ in journal (community?) W

Area:
notifications

Summary:
You can currently get notified of all comments made on a certain entry and track entries tagged with a specific tag. I'd like to be able to get notified of comments made on entries tagged with a specific tag in a given journal.

Edit: I forgot to specify that this would be on a journal-by-journal basis because it seems obvious to me. My apologies.

Description:
Should that be a paid-only feature?

Edit: paid users and members of paid communities can already track all comments made in a community; if this applies to communities only, it would be a more restrictive version of this existing tracking option.

Poll #6967 New notification: all comments made on entries tagged XYZ
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.8%)

(I have no opinion)
16 (44.4%)

(Other: please comment)
1 (2.8%)

stormy: ❪ 𝐍𝐎𝐓𝐈𝐂𝐄 ❫ 𝑫𝑶 𝑵𝑶𝑻 𝑻𝑨𝑲𝑬 𝑴𝒀 𝑰𝑪𝑶𝑵𝑺 ⊘ (Default)
[personal profile] stormy

Title:
Invite Code Automated Messages

Area:
invite codes, accounts

Summary:
Re: http://www.dreamwidth.org/manage/invitecodes
This suggestion has two parts:
1) A textarea that populates the code to share the complete of available codes on the page in the following format with 'Use this code' linking as it does on the invite page:
CAJ792MAXNHZRAAAFXXX Use this code

2) When you copy and paste that code on the site, Dreamwidth should be able to check if the code is used, and disable, gray out, or strike through the link if the code is used.

Description:
Many users have extra invite codes to share. When they do, they either manually copy the list of codes, or copy the available codes from http://www.dreamwidth.org/manage/invitecodes this page and paste it into the RTE. This two step process would not only speed up sharing codes, but also automate the process of displaying if a code has been used or not. It would make it easy to see what codes are available when people post to dw_codesharing. I'm not sure how difficult the backend would be on this as far as part 2 is concerned.

This suggestion has two parts:

PART 1) A textarea that populates the html to share the complete of available codes on the page in the following format with 'Use this code' linking as it does on the invite page:
CAJ792MAXNHZRAAAFXXX Use this code

PART 2) When you copy and paste that code on the site, Dreamwidth should be able to check if the code is used, and should disable, gray out, add a 'code used' indicator, or strike through the link if the code is used.

I don't see any downsides to this sort of feature. In the future, perhaps a suggestion to add a "add a code" button to the RTE (which provides checkboxes to share codes) could be added for those unfamiliar with HTML, and the same behavior applied to the code once posted.

Poll #6570 Invite Code Automated Messages
Open to: Registered Users, detailed results viewable to: All, participants: 35


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (42.9%)

(Other: please comment)
0 (0.0%)

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

Title:
Statistics: link /stats and stats/site

Area:
site

Summary:
There are two pages for stats: http://www.dreamwidth.org/stats and http://www.dreamwidth.org/stats/site. I wish there was a link from one to the other, and that the second page was added to the site map.

Description:
Well, I've said it all. :)

Poll #6527 Statistics: link /stats and stats/site
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

Should be implemented as-is.
48 (76.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (15.9%)

(Other: please comment)
1 (1.6%)

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

Title:
Serve icons from i.dreamwidth.org subdomain

Area:
icons, security, making things make sense

Summary:
Start serving icons from i.dreamwidth.org (or another reserved subdomain) instead of www.dreamwidth.org/userpic/.

Description:
"Userpic" is being phased out, and "icon" is being adopted (though it will probably take years for some of us to get used to it).

felicity_ in IRC pointed out that there are security reasons to prefer images being served from their own subdomain.

Dreamwidth has thoughtfully reserved single-letter subdomains, and in any case 'icons' is a community in active use, and 'icon' is a community as well (albeit private and unused by its creator). 'i' is a shorter subdomain in any case.

On the face of it it seems like making the change and going forward with it is probably a very good thing.

It would disrupt legacy links that people have made in the past to their icons (though service is in beta, luggage may shift during flight) unless backwards compatibility is put in. I don't know whether the security implications of user images served off the main domain applies if there's a redirect from the main domain to a subdomain.

Poll #5520 Serve icons from i.dreamwidth.org subdomain
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
28 (53.8%)

(Other: please comment)
1 (1.9%)

msilverstar: (Default)
[personal profile] msilverstar

Title:
inbox left categories: add crossposts link

Area:
inbox

Summary:
An option to show just crossposting notifications, instead of having them mixed in with everything else.

Description:
I really the Poll Votes and Unread filters on the the left navigation of the inbox. Adding Crossposts would let people just find those, so they can check for success and then delete them. LJ doesn't have the crosspost feature, and I really like it, but it can clutter up an inbox.

Poll #5514 inbox left categories: add crossposts link
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
41 (71.9%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (26.3%)

(Other: please comment)
1 (1.8%)

theplotbunny: (Default)
[personal profile] theplotbunny

Title:
theme blurbs to describe each theme for screen reader users

Area:
themes for DW journals and communities

Summary:
I often find that with a lot of blogs and such, that choosing themes can be difficult, especially as there is little if any description to help me decide. As I cannot physically see these, I'd love to see implemented a descriptive blurb giving a detailed and concise lay of the visual landscape so to speak, this would be most innovative and so cool!

Description:
1: I think by providing a blurb for each theme, this would allow blind users and those with some degree of sight loss the opportunity to be on a level with our fellow DW users, and why not, it is a wonderful opportunity to provide a great way to make DW more inclusive, perhaps with this extending to more visual landscapes over time we could find ourselves sought after by other blogs to incorporate such a landmark addition to the site.

Logistics, well I'm no tech minded person, but conceivably such blurbs could be placed under a link - cut of some kind, as blind users rely on keystrokes and not mouse usage, a simple html solution is a great way to make the site more fun and keeps everything neat and tidy for all of us.

I don't foresee any real disadvantages, I do see that implementation could start with current and future themes etc, and slowly over time, add this feature to all DW visual themes and perhaps this might be something to explore with other visual content where applicable and advantageous to members like me.

I humbly offer this as my contribution to DW access! ^_^

theplotbunny

Poll #5182 theme blurbs to describe each theme for screen reader users
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

Should be implemented as-is.
41 (87.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (12.8%)

(Other: please comment)
0 (0.0%)

[personal profile] zaluzianskya

Title:
Allow new users to purchase purged usernames outright

Area:
journal creation, renames

Summary:
We can buy purged usernames now. This is awesome! But if you want to use a purged username for a new journal, you have to register a throwaway name and then rename that. Not so awesome.

Description:
Let's say you have a username you really like -- let's call it "loveandkittens". You really want to register "loveandkittens" for your new journal, but it's been deleted and purged! Luckily, Dreamwidth now has journal renaming, which is highly nifty. But in order to rename to "loveandkittens", you need a journal to actually rename.

So, you register a journal to rename. It can have whatever name you want -- if you're savvy about how renames work, you'll probably register something like "sldjcw982198nfckj", something no one would be likely to ever pick in the future. But, alas, not everyone is so savvy. A lot of users, especially new ones, would pick something like "hateandkittens", and then rename that to "loveandkittens". This, however, causes a problem if someone else wants to come along and register "hateandkittens" later on: It's either now a deleted and purged username, and the whole process starts aaaall over again, or it's a permanent redirect to "loveandkittens", which is even worse.

I'm not suggesting that we do away with having to pay for purged usernames; obviously, that's necessary. However, there should be a way for brand new journals to register these usernames without having to register a throwaway name first. They would be asked for payment up-front, and then some behind-the-scenes process would do whatever it has to do to move all of "loveandkittens"'s former activity over to "ex_loveandk123" so the new journal can be "loveandkittens". My suggestion is to register a journal with a username of the form "ex_123456789", and then apply the rename to it without the user ever seeing it.

And, obviously there'd have to be a link to some page explaining why you have to charge $15 for a brand new journal, and explaining that they're free to pick a different username instead if they don't want to fork out the money, but that's just standard for all rename-related shenanigans.

Poll #5132 Allow new users to purchase purged usernames outright
Open to: Registered Users, detailed results viewable to: All, participants: 82


This suggestion:

View Answers

Should be implemented as-is.
71 (86.6%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (12.2%)

(Other: please comment)
1 (1.2%)

popelaksmi: (Default)
[personal profile] popelaksmi

Title:
Crossposting a place-holder or link only

Area:
crossposting

Summary:
Ability to crosspost either a placeholder or link only, instead of the whole body of a journal entry.

Description:
It would be nice to have the capabilty/ option of crossposting a placeholder or link only instead of the whole body of a journal entry for those of us who would like to post more content on DW and as little as possible on the other site (like LJ) yet let friends reading those other journals know when a new post has been made.

Poll #5107 Crossposting a place-holder or link only
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

Should be implemented as-is.
35 (67.3%)

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

Shouldn't be implemented.
1 (1.9%)

(I have no opinion)
6 (11.5%)

(Other: please comment)
2 (3.8%)

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