4 ms·

>the onus should be on the proposer I'll bite: what should @Lerc have done differently in his proposal (https://github.com/HaxeFoundation/haxe-evolution/pull/5

>the onus should be on the proposer I'll bite: what should @Lerc have done differently in his proposal (https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51)?

dyarosla 8y ago
It seems like there’s some leeway in ‘After reaching general consensus or voting takes place, the PR is merged by someone from the Haxe developer team, and the proposal becomes "active". When merged, the proposal will receive its number from the corresponding pull request. If the proposal is rejected, the PR is closed with a comment explaining the reasons.’ I think general consensus was reached without a formal vote. Discussion was limited but explanation was given: language clarity would be impacted. A few main contributors agreed. @lerc didn’t provide much of a counterargument. That said, what would you have wanted to see done differently? A formal vote held? This proposal seemed to be a matter of preference, with no real consensus on clarity. Workarounds were even proposed. What would be your ideal resolution? Not shutting down the discussion as haphazardly? How much further should it have gone?
- Lerc 8y ago
  I didn't give much of a counterargument because there was hardly any argument to counter. If the issue had not have been closed so quickly I would have pressed people for specifics of what they thought were wrong. At the time I believed I was the person responsible for calling the vote so I was prepared to give them time to provide a coherent argument.
  - dyarosla 8y ago
    I think at the end of the day there was simply no interest in the proposal. Nadako was "not opposed to it" but that was about it. Personally, I would have liked to not have seen the conversation ended with a "that's what we decided elsewhere" message. That being said, this particular proposal seems like a matter of opinion (on the level of tabs vs spaces) to which no amount of argument would have really swayed people. Definitely something to learn from here. Thank you for sharing your story!
    - Lerc 8y ago
      I feel like you are missing the point here. Project maintainers can behave like absolute arbitors if they want to. Many projects successfully work by this mechanism. The issue as stake here isn't how they decided on the proposal but rather that the way that they decided on the proposal is different to the processes that they specified. They are soliciting contributions by promising an open process ( see https://github.com/HaxeFoundation/haxe-evolution#voting-process https://github.com/HaxeFoundation/haxe-evolution#voting-proc... ) but disregarding those processes when they feel like it. Ironically, the discussion we are having here is much closer to the level of engagement that should have happened there. As a sidenote, I'm just curious, what do you personally think of the proposal? Would you like to have the concise object literal notation in Haxe?
      - dyarosla 8y ago
        I think I posted in a parent comment that I think they did follow the (somewhat arbitrarily defined process) if you give leeway to the phrase "After reaching general consensus or voting takes place"; whereas it seemed like a general consensus was reached in that situation. I think a clearer process that's a little more transparent would definitely be beneficial, including clearing up that phrasing. On the sidenote, I personally don't run into many (if any) situations where I would use concise object literal notation. I'm on the fence as to the issue of clarity and whether it would help/detract/be neutral for Haxe. The style of concise object literals is fairly inconsistent with the rest of the language at the current time, and I could see how it could lead to clarity/confusion issues. Because I believe it's more of a syntactic sugar than anything else I am leaning to agree that macros may be the way to go for it.

dyarosla 8y ago

It seems like there’s some leeway in ‘After reaching general consensus or voting takes place, the PR is merged by someone from the Haxe developer team, and the proposal becomes "active". When merged, the proposal will receive its number from the corresponding pull request. If the proposal is rejected, the PR is closed with a comment explaining the reasons.’ I think general consensus was reached without a formal vote. Discussion was limited but explanation was given: language clarity would be impacted. A few main contributors agreed. @lerc didn’t provide much of a counterargument. That said, what would you have wanted to see done differently? A formal vote held? This proposal seemed to be a matter of preference, with no real consensus on clarity. Workarounds were even proposed. What would be your ideal resolution? Not shutting down the discussion as haphazardly? How much further should it have gone?

Lerc 8y ago
I didn't give much of a counterargument because there was hardly any argument to counter. If the issue had not have been closed so quickly I would have pressed people for specifics of what they thought were wrong. At the time I believed I was the person responsible for calling the vote so I was prepared to give them time to provide a coherent argument.
- dyarosla 8y ago
  I think at the end of the day there was simply no interest in the proposal. Nadako was "not opposed to it" but that was about it. Personally, I would have liked to not have seen the conversation ended with a "that's what we decided elsewhere" message. That being said, this particular proposal seems like a matter of opinion (on the level of tabs vs spaces) to which no amount of argument would have really swayed people. Definitely something to learn from here. Thank you for sharing your story!
  - Lerc 8y ago
    I feel like you are missing the point here. Project maintainers can behave like absolute arbitors if they want to. Many projects successfully work by this mechanism. The issue as stake here isn't how they decided on the proposal but rather that the way that they decided on the proposal is different to the processes that they specified. They are soliciting contributions by promising an open process ( see https://github.com/HaxeFoundation/haxe-evolution#voting-process https://github.com/HaxeFoundation/haxe-evolution#voting-proc... ) but disregarding those processes when they feel like it. Ironically, the discussion we are having here is much closer to the level of engagement that should have happened there. As a sidenote, I'm just curious, what do you personally think of the proposal? Would you like to have the concise object literal notation in Haxe?
    - dyarosla 8y ago
      I think I posted in a parent comment that I think they did follow the (somewhat arbitrarily defined process) if you give leeway to the phrase "After reaching general consensus or voting takes place"; whereas it seemed like a general consensus was reached in that situation. I think a clearer process that's a little more transparent would definitely be beneficial, including clearing up that phrasing. On the sidenote, I personally don't run into many (if any) situations where I would use concise object literal notation. I'm on the fence as to the issue of clarity and whether it would help/detract/be neutral for Haxe. The style of concise object literals is fairly inconsistent with the rest of the language at the current time, and I could see how it could lead to clarity/confusion issues. Because I believe it's more of a syntactic sugar than anything else I am leaning to agree that macros may be the way to go for it.