Maintaining a list of the preference keys that might contain more and less sensitive information is more than I'm willing to do, I'm afraid. Status quo sounds best.
Unless you think I should remove the names of the collections. Robby On Tue, Sep 27, 2011 at 10:31 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > Right now, there are two big text fields: "Description", and "Steps to > Reproduce". > > How about changing it to be 2-3 big text fields, but one of them defaults to > having all this synthesized info in it in plain-text form, and then the user > is free to edit it, or even expected to? > > This removes more GUI than it adds. > > Perhaps 3 fields, with the new one being "Additional Information", and > something like the format below. > > If someone wants to do this, I will write the procedure to sort out the > preferences and generate this text. > > INTERACTION HISTORY: > (display "Hello, world!") > (+ 1 2 3) > > POSSIBLY MORE-SENSITIVE PREFERENCES: > ... > > COLLECTIONS: > ... > > LINKS: > ... > > OTHER PREFERENCES: > ... > > HUMAN LANGUAGE: english > > VERSION: 5.1.3.10--2011-09-24(09b0a46/a) > > ENVIRONMENT: unix "Linux matthias 2.999-686 #1 SMP Fri Sep 2 20:66:05 UTC > 2025 i686 GNU/Linux" (i386-linux/3m) (get-display-depth) = 32 > > MEMORY USE: 94206368 > > > Neil Van Dyke wrote at 09/27/2011 11:09 PM: >> >> The prefs seem potentially more sensitive than the info traditionally >> hidden behind "Show Synthesized Info". >> >> I'd like to see the "Show Synthesized Info" button go away, if you're >> going to include sensitive prefs in the info. Either the information should >> be exposed while user is writing bug description, or there should be a >> confirmation step after submitting, that pops up a window that presents this >> info that will be added to the bug report and gives them a chance to edit or >> opt-out of it. An advantage of exposing during writing bug description is >> that the user then knows what info is provided automatically, so they don't >> waste time on it. Implementing the confirmation dialog seems easiest right >> now, because you can mostly just take the code for "Show Synthesized Info", >> and you don't have a UI design&implementation problem for how to expose the >> info while writing description. >> >> I'm not only being a privacy hippie here. I know of Racket projects in >> which the collects info alone (which Dr* has long included in bug reports) >> could threaten business opportunities of the owner of the code, would raise >> concerns about security that people would then be obligated to examine, and >> could also constitute the bug submitter violating an NDA or other >> restrictions on how they handle certain info. >> >> Robby Findler wrote at 09/27/2011 10:37 PM: >>> >>> Would you think it unwise if it was another field behind the >>> "synthesized info" button? (Perhaps with some other name, but in >>> roughly the same manner.) > > > -- > http://www.neilvandyke.org/ > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev