4 ms·

> That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you

> That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.

trueno 2mo ago
yeah it's definitely confusing messaging i can't imagine being a community contributor there and saying "ok im gonna help implement this thing that they just described as not a good fit for their thing". i think being under resourced or whatever or just not having anyone on the team that would be able to pull this off is a fine thing to be forward about, but it gets confusing because they kinda frame it like it's the wrong thing to do then leave the door open for someone else to do it. if they didn't beat around the bush perhaps they'd have encryption on this already.
- LoganDark 2mo ago
  I prefer when projects say "we don't have the resources for this but we agree it would be nice" because then I actually feel like it would be worth the PR. but this project makes me feel like they don't want the change which means I don't want to put in the work
  - deleted 2mo ago
    [deleted]
embedding-shape 2mo ago
> hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest. What is there to hate here, I don't understand? They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it". They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged. This seems like the ideal solution? What would be better here?
- LoganDark 2mo ago
  First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
  - embedding-shape 2mo ago
    > First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is. If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?
    - LoganDark 2mo ago
      there is another interpretation indeed, that is simply: "the Direct IP feature wasn't designed to be secure so we don't recommend using it right now, but if you contribute improvements we might accept them" but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? "stop asking, do it yourself" which I hate just as much as hiding your real response behind recommendations.
      - embedding-shape 2mo ago
        > but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming. Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario? I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?

trueno 2mo ago

yeah it's definitely confusing messaging i can't imagine being a community contributor there and saying "ok im gonna help implement this thing that they just described as not a good fit for their thing". i think being under resourced or whatever or just not having anyone on the team that would be able to pull this off is a fine thing to be forward about, but it gets confusing because they kinda frame it like it's the wrong thing to do then leave the door open for someone else to do it. if they didn't beat around the bush perhaps they'd have encryption on this already.

LoganDark 2mo ago
I prefer when projects say "we don't have the resources for this but we agree it would be nice" because then I actually feel like it would be worth the PR. but this project makes me feel like they don't want the change which means I don't want to put in the work
- deleted 2mo ago
  [deleted]

embedding-shape 2mo ago

> hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest. What is there to hate here, I don't understand? They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it". They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged. This seems like the ideal solution? What would be better here?

LoganDark 2mo ago
First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
- embedding-shape 2mo ago
  > First they say they do not want the feature: "we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default." Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is. If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?
  - LoganDark 2mo ago
    there is another interpretation indeed, that is simply: "the Direct IP feature wasn't designed to be secure so we don't recommend using it right now, but if you contribute improvements we might accept them" but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? "stop asking, do it yourself" which I hate just as much as hiding your real response behind recommendations.
    - embedding-shape 2mo ago
      > but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming. Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario? I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?