| 7 Nov 2021 |
 tomberek | (anyone can answer, not quite directed to a single person) | 11:32:42 |
 Ellie | Personally, I wouldn't know where to begin quantifying that ahead of time, tomberek. If I, personally, am to be totally honest: if there was that massive wholesale level of rejection for these ideas, I would have to very very carefully consider my further involvement in the project, rather than trying to whittle things down to an "acceptable" skeleton | 11:34:42 |
 joepie91 🏳️🌈 | tomberek: I don't think that's the right way to look at it, honestly, as a hard quantifiable limit of disruption. the RFC isn't creating conflict, it is bringing existing conflict to the surface, and so in a very literal sense whatever conflict it digs up very likely needed to be dealt with anyway. I consider it far more important that all of those involved in the discussion, from any perspective, do their best to keep the conflict to that which is necessary to sort out, working towards a mutual understanding rather than a 'tribal war', and not constructing additional conflict to disrupt the process | 11:34:52 |
| tomberek | So no amount of concerns or feedback that is considered legitimate and real would be enough to go down the route of 114 instead? | 11:35:51 |
| joepie91 🏳️🌈 | 'conflict' is not really an objectively measurable unit, nor is 'acceptable conflict', and so we will have to rely on the good faith of all participants to do their part in reducing it as much as possible without burying it | 11:35:57 |
| joepie91 🏳️🌈 | tomberek: for me personally: not unless that feedback makes a plausible case for the fundamental approach of RFC 98 being a bad one and that of 114 being better | 11:36:39 |
| joepie91 🏳️🌈 | to be clear, I am sure that 114 will be much easier to get passed than 98. but that is not because I believe it's better at bringing the community together, but rather because it chooses to sweep more below-the-surface conflict under the carpet and not deal with it at all | 11:37:42 |
| joepie91 🏳️🌈 | solutions that address less problems are always simpler | 11:37:57 |
| joepie91 🏳️🌈 | * solutions that address less problems can always be simpler | 11:39:10 |
| joepie91 🏳️🌈 | (obviously I am speaking for myself here and not the rest of the community) | 11:39:53 |
| tomberek | I am stunned and shocked. | 11:40:17 |
| joepie91 🏳️🌈 | if it helps as an analogy: consider the various distros that are now trying to sorta kinda copy design properties of Nix, but without the whole structural model around it | 11:40:54 |
| joepie91 🏳️🌈 | as a result, they get some of the benefits of Nix, but many of them remain unachievable for those distros because their fundamental packaging model is still broken (or at the very least, suboptimal) | 11:41:20 |
| joepie91 🏳️🌈 | they have chosen a 'simpler' solution that solves less problems | 11:41:28 |
| joepie91 🏳️🌈 | whereas Nix approaches it from a much more fundamental perspective, having a solid and predictable foundation to build all these other constructs on top of, as a logical extension of the model | 11:42:00 |
| joepie91 🏳️🌈 | RFC 98 tries to do much the same, but for community management | 11:42:13 |
| joepie91 🏳️🌈 | and it therefore also has the same properties of "this is a bit painful to get used to at first and will require dealing with assumptions about existing systems that are not true in this one, but in the long term it works much better much more consistently" | 11:42:45 |
| tomberek | The amount of conflict caused by RFC98 will never be considered as a reason to attempt an alternative, but is instead seen as a signal that it is on the right track? | 11:47:08 |
| Ellie | In reply to @joepie91:pixie.town
tomberek: for me personally: not unless that feedback makes a plausible case for the fundamental approach of RFC 98 being a bad one and that of 114 being better (I'm not speaking for joepie91 🏳️🌈 here) I agree with all joepie91 🏳️🌈 said, and want to not that it doesn't at all preclude improving 98 by incorporating changes raised by constructive criticism | 11:47:13 |
| joepie91 🏳️🌈 | tomberek: no. the amount of conflict is not a signal to me at all; I do not consider it a relevant metric. what I care about is the type of conflict and the reason for it and, most importantly, whether it is resolvable | 11:47:54 |
 @asymmetric:matrix.dapp.org.uk | tomberek: what joepie91 🏳️🌈 is saying is that RFC98 didn't cause the conflict | 11:48:04 |
| @asymmetric:matrix.dapp.org.uk | and to an extent, i agree with that description | 11:48:37 |
| @asymmetric:matrix.dapp.org.uk | even though some of the language did cause quite some controversy | 11:48:49 |
| joepie91 🏳️🌈 | so far, most of the conflict that I have seen looks resolvable to me, and indeed I have been putting in a lot of work to resolve chunks of it - and my conclusion from that is that, overall, we are on a positive trajectory with RFC 98, even if we are definitely not at the end yet | 11:49:05 |
| @asymmetric:matrix.dapp.org.uk | so it's not 100% clear-cut imo | 11:49:10 |
| joepie91 🏳️🌈 | also, I should probably note that the model proposed in RFC 98 is definitely different from what I usually do when I get brought in as a moderator to clean up a community that has gone off the deep end - but from my observations so far, I believe that the NixOS community is in a healthy enough place that 98 can be made to work to roughly everybody's satisfaction | 11:50:51 |
| joepie91 🏳️🌈 | had I considered it to be unresolvable, I probably would have been arguing for a very different moderation model :) | 11:51:09 |
| @asymmetric:matrix.dapp.org.uk | could someone link to relevant posts of what's happening in the Scala community? | 11:51:15 |
| @asymmetric:matrix.dapp.org.uk | it seems to come up frequently as a comparison | 11:51:27 |
| joepie91 🏳️🌈 | asymmetric: this is the main one: https://contributors.scala-lang.org/t/politics-safety-and-the-future-of-scala/5317 | 11:51:28 |
