>>>> Now, others may think all of sandboxing is bad, but they should submit
>>>> a bug, accordingly.
>>>
>>> Half or more of your Change Proposal rationale is arguing that all of
>>> sandboxing is bad (most particularly, the part arguing that authors
>>> are too stupid to realize that using <iframe srcdoc sandbox> to
>>> display comments on their blog won't protect them against SQL
>>> injection when handling form submission of new comments). Â I would
>>> appreciate it if you would remove those sections and file bugs
>>> accordingly.
>>
>> Unless you've become the co-chair for this group, please refrain from
>> telling me to edit my proposals.
>
> That's the entire point of posting a Change Proposal to the group; we
> can suggest changes that would improve the document and hopefully come
> to an amicable resolution without having to solicit counter-proposals.
> Â This is also why we often formulate proposals on the wiki, so they
> can be altered easily, either by the author or by others.
>
Amicable resolution is based on mutually agreed upon course of action
that evolves naturally, not one person telling the other to do
something, disregarding the previous communications. For instance, in
Issue 92, you had a comment about the table footer in the example, and
I made a change.
> If you believe that your Change Proposals are perfect and inviolate
> when they are posted, you're doing it wrong.
>
As I just mentioned in Issue 92...
> Also, seriously, chill.
>
I believe I will, and the best way to do so is to stop responding to
your emails. I'll restrict my communications to you specifically to
proposals and counter-proposals. I'm sure that this would be a course
the co-chairs would recommend, and other team members would
appreciate.
> ~TJ
>
Shelley