@safe/DIP1028 explained in meme form

[Gregory]

On Thursday, 28 May 2020 at 17:38:15 UTC, Mike Parker wrote:
> On Thursday, 28 May 2020 at 17:21:05 UTC, Gregory wrote:
>> On Thursday, 28 May 2020 at 16:27:56 UTC, Mike Parker wrote:
>>> On Thursday, 28 May 2020 at 14:56:14 UTC, Gregory wrote:
>>>>
>>>>
>>>> There's a clear problem with the current DIP process. 
>>>> DIP1028 has made that clear.
>>>
>>> I disagree. The process itself is working as intended.
>>
>> Responses like this are part of the problem (similar to 
>> Walter's responses).
>>
>> If you want to explain how the above 2 paragraphs you cropped 
>> out aren't problematic, then I might be willing to reconsider 
>> my viewpoint. But as you've demonstrated, the problem extends 
>> fast past Walter.
>
> I repeat: the process is working as intended. That no one 
> succeeded in convincing the DIP author to revise the DIP is not 
> a failure of the process. That the decision to approve is 
> unpopular is not a failure of the process.
>
> Whether or not the language maintainers should be evaluating 
> their own proposals is an issue with the decision making, not 
> with the entire process.

Let me try and make it simpler for you so you can understand, 
answer this question only, and if you talk about anything about 
the process you've failed.

The fact a major part of the reasoning behind DIP1028 (aka 
greenwashing) wasn't brought up for criticism as part of the 
debate until after the DIP was already accepted, do you see this 
as a problem? Yes or no?

> That no one succeeded in convincing the DIP author to revise 
> the DIP is not a failure of the process.

Read this for a second. The *AUTHOR* of a DIP wasn't convinced 
their own idea wasn't good enough to write a DIP for. This is the 
equivalent of having a jury start with a presumption of guilt, 
where the jury is the victim.