Suggestions polls: not viewable to everybody?

[azurelunatic]

Title:
Suggestions polls: not viewable to everybody?

Area:
suggestions

Summary:
Would the quality of suggestions voting and discussion be improved if suggestions poll results were concealed?

Description:
Polling designed to get people's honest opinions about things can be subject to social chilling effects. If someone has an opinion that turns out to be the opposite of the crowd opinion, they may feel inclined to change their vote, or perhaps not speak up about their detailed thoughts about the feature.

Changing the poll insertion widget to make the results viewable to 'None' (actually the community admins and the person who posted the suggestion) could perhaps improve the frankness of the voting, and improve the quality of the discussion.

However, visible poll results can also be a boon to developers, who might decide to pick up one bug over another based on popularity.

Poll #4292 Suggestions polls: not viewable to everybody?

Open to: Registered Users, detailed results viewable to: All, participants: 55

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
29 (52.7%)

(I have no opinion)
14 (25.5%)

(Other: please comment)
1 (1.8%)

Full Export Tool

[azurelunatic]

Title:
Full Export Tool

Area:
exporting, interoperability, backups

Summary:
Create an interface/client with an easy way of setting up and later downloading a full backup of one's journal. This would be in a file format of one's choice, with entries, comments, icons, memories, and all.

Description:
Currently, one can back up one's journal through a scattering of mostly-legacy interfaces in different places. There are tools that were never exactly designed to work with Dreamwidth, such as LJ Archive. (While some of them work even most of the time, there are times that they do not, and I suspect Dreamwidth developers may not necessarily prioritize jumping in to third-party client code developed for another site, assuming the code is even open and available to be jumped into.)

There already exists a bug requesting a PDF export of one's journal: http://bugs.dwscoalition.org/show_bug.cgi?id=32

This would broaden the scope of the ability to export, so one could choose between, say, .pdf, HTML, plain text, rich text, comma separated values, tab separated values, and perhaps other formats (WordPress-friendly?) as developers see the need.

One could go to a page similar to the current import journal page, and select the date range (as for the existing spec for .pdf, whole journal or month by month), elements and file type that one wished to back up, and queue a download request. The system would queue the download request, and prepare it in a timely fashion, as other load allowed so as to keep things readable in other journals on the same cluster. (Paid users might be given priority in the queue, if there was a queue worth mentioning.) Similar to the importer, the page would show progress of the export file preparation when revisited, and offer a low-impact refresh option, because you just know that people are going to want to sit there and beam at the progress the first couple times they download. Once the files were prepared, in reasonable-sized chunks for downloading if it were a particularly large journal *cough*azurelunatic*cough*, a notification would be sent with a link to the download page, so the user would not have to sit on the page refreshing if they did not want to. There might also be a password challenge before downloading, to diminish the possibility that someone's theoretical nosy little brother could copy one's whole journal to a USB drive in an unguarded minute alone with the computer.


In addition to the web interface, there should also be an API that allows (at minimum) the same choices as the web interface, complete with full documentation. Perhaps there could even be official clients for a range of different platforms.

Poll #4293 Full Export Tool

Open to: Registered Users, detailed results viewable to: All, participants: 77

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
1 (1.3%)

(Other: please comment)
0 (0.0%)