[racket-dev] bug reports: include prefs file?

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 <neil at 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/
>