Daniel Shahaf <d...@daniel.shahaf.name> writes: > Look, it's pretty simple. You said "We should do Y because it > addresses X". You didn't explain why X needs to be addressed, didn't > consider what alternatives there are to Y, didn't consider any cons that > Y may have… and when people had questions, you just began to > implement Y, without responding to or even acknowledging those > questions. > > That's not how design discussions work. A design discussion doesn't go > "state decision; state pros; implement"; it goes "state problem; discuss > potential solutions, pros, cons; decide; implement" (cf. [4, 5, 6]).
Well, I think it may not be as simple as it seems to you. Who decided that we should follow the process you're describing? Is there a thread with a consensus on this topic? Or do you insist on using this specific process because it's the only process that seems obvious to you? What alternatives to it have been considered? As far as I can tell, the process you're suggesting is effectively a waterfall-like process, and there are quite a lot of concerns about its effectiveness, because the decisions have to be made in the conditions of a lack of information. Personally, I prefer an alternative process that starts from finding out all available bits of information, which are then used to make informed decisions. The unfortunate reality, however, is that the only guaranteed way of collecting all information means implementing all (or almost all) significant parts in code. Roughly speaking, this process looks like a research project that gets completed by trial and error. Based on what you've been saying so far, I wouldn't be surprised if you disagree. But I still think that forcing the others to follow a certain process by such means as vetoing a code change is maybe a bit over the top. (In the meantime, I certainly won't object if you're going to use this waterfall-like process for the changes that you implement yourself.) Regards, Evgeny Kotkov
