4 ms·

Sucks to hear about your experience. Like you said yes arrow functions are slated for the next major release. As for the process, I think it has become a littl

Sucks to hear about your experience. Like you said yes arrow functions are slated for the next major release. As for the process, I think it has become a little more stringent for sure. To submit a request for consideration you’d need to submit a proposal on GitHub with attention paid to impact to existing code and impact on future Haxe features- perhaps your feature request wasn’t deemed to be thought out enough? It also looks like you’d get more explicit consideration if you are a sponsor of the language (https://haxe.org/foundation/support-plans.html https://haxe.org/foundation/support-plans.html) So yes, while it isn’t a completely open vote, I also think most languages’ directions are decided by committee in a similar way. I’m sure the Haxe community would love to see examples of other communities with better practices to learn from.

GordonS 8y ago
> perhaps your feature request wasn’t deemed to be thought out enough? In which case surely it should be discussed, rather than shut down with "no"? This thread had me interested in Haxe, but reading these comments about the unfriendly, negative responses to proposals has put me right off.
- dyarosla 8y ago
  To play devils advocate: if every feature request had to be thoroughly discussed you’d never get anywhere.. the onus should be on the proposer. That said, you can always file an issue in github and have a discussion there. For Haxe it’s a very active location for discussion there.
  - bendmorris 8y ago
    >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?
- fileeditview 8y ago
  I just checked the link to the proposal and I don't think there was anything wrong. A little discussion about the proposal. Some didn't seem to like it because of 'language clarity'. Some group of core developers discussed it and rejected it. I don't know what one expects but I have seen quite some language proposals (rejected) and this didn't seem inappropriate to me. They don't want it.. accept it or move on. They gave a reason. If you think it's sufficient is another thing and mostly about opinion.
deleted 8y ago
[deleted]
bendmorris 8y ago
>perhaps your feature request wasn’t deemed to be thought out enough? Why the automatic defense of the Haxe team? Frankly, small communities like this sometimes come across as cult-like in their response to criticism, and it isn't a good look. Here's the proposal in question: https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51 Here's the process which wasn't followed: https://github.com/HaxeFoundation/haxe-evolution https://github.com/HaxeFoundation/haxe-evolution. Very little discussion, no public vote, even though the proposer put in the effort and clearly wanted to engage. When someone puts in the effort to make a proposal like this, this bait and switch is not a way to keep them around, and insulting them in HN comments isn't any better.
- dyarosla 8y ago
  Where’s the insult? I can’t speak for the community or who did what. If anything I’m looking to see what can be done going forward.
  - bendmorris 8y ago
    To quote you again: >perhaps your feature request wasn’t deemed to be thought out enough? Why jump to finding fault with the OP, rather than accepting feedback about the process? AFAICT you didn't actually check OP's proposal before assuming it was lacking. And OP's experience isn't unique. You're evangelizing Haxe in this thread, but here you just paper over valid criticism: - "arrow functions are slated for the next major release": sure, it only took four years! - "I also think most languages’ directions are decided by committee in a similar way": I'm not aware of any other language that has a proposal process inviting community participation, but doesn't follow it and discusses those proposals in private. Point me to one. Surely you can understand that this can be frustrating when someone tries to participate and is shut out. - "I’m sure the Haxe community would love to see examples..." I would be pleasantly surprised if I saw the Haxe Foundation engage in some introspection and actually take steps to change or at least be more transparent. So far I don't see any introspection, only defensiveness. And FWIW, I used to be part of that internal Slack channel for team members and was a Haxe contributor. I tried to make progress on these issues for years before giving up.

GordonS 8y ago

> perhaps your feature request wasn’t deemed to be thought out enough? In which case surely it should be discussed, rather than shut down with "no"? This thread had me interested in Haxe, but reading these comments about the unfriendly, negative responses to proposals has put me right off.

dyarosla 8y ago
To play devils advocate: if every feature request had to be thoroughly discussed you’d never get anywhere.. the onus should be on the proposer. That said, you can always file an issue in github and have a discussion there. For Haxe it’s a very active location for discussion there.
- bendmorris 8y ago
  >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?
fileeditview 8y ago
I just checked the link to the proposal and I don't think there was anything wrong. A little discussion about the proposal. Some didn't seem to like it because of 'language clarity'. Some group of core developers discussed it and rejected it. I don't know what one expects but I have seen quite some language proposals (rejected) and this didn't seem inappropriate to me. They don't want it.. accept it or move on. They gave a reason. If you think it's sufficient is another thing and mostly about opinion.

deleted 8y ago

[deleted]

bendmorris 8y ago

>perhaps your feature request wasn’t deemed to be thought out enough? Why the automatic defense of the Haxe team? Frankly, small communities like this sometimes come across as cult-like in their response to criticism, and it isn't a good look. Here's the proposal in question: https://github.com/HaxeFoundation/haxe-evolution/pull/51 https://github.com/HaxeFoundation/haxe-evolution/pull/51 Here's the process which wasn't followed: https://github.com/HaxeFoundation/haxe-evolution https://github.com/HaxeFoundation/haxe-evolution. Very little discussion, no public vote, even though the proposer put in the effort and clearly wanted to engage. When someone puts in the effort to make a proposal like this, this bait and switch is not a way to keep them around, and insulting them in HN comments isn't any better.

dyarosla 8y ago
Where’s the insult? I can’t speak for the community or who did what. If anything I’m looking to see what can be done going forward.
- bendmorris 8y ago
  To quote you again: >perhaps your feature request wasn’t deemed to be thought out enough? Why jump to finding fault with the OP, rather than accepting feedback about the process? AFAICT you didn't actually check OP's proposal before assuming it was lacking. And OP's experience isn't unique. You're evangelizing Haxe in this thread, but here you just paper over valid criticism: - "arrow functions are slated for the next major release": sure, it only took four years! - "I also think most languages’ directions are decided by committee in a similar way": I'm not aware of any other language that has a proposal process inviting community participation, but doesn't follow it and discusses those proposals in private. Point me to one. Surely you can understand that this can be frustrating when someone tries to participate and is shut out. - "I’m sure the Haxe community would love to see examples..." I would be pleasantly surprised if I saw the Haxe Foundation engage in some introspection and actually take steps to change or at least be more transparent. So far I don't see any introspection, only defensiveness. And FWIW, I used to be part of that internal Slack channel for team members and was a Haxe contributor. I tried to make progress on these issues for years before giving up.