5 ms·

> It's unacceptable for you to demand that open source developers spend their time addressing your concerns for free. Period. Do you understand the difference

> It's unacceptable for you to demand that open source developers spend their time addressing your concerns for free. Period. Do you understand the difference between that and general criticism of a project? If you had to write guidelines on criticizing a project like Gnome in an acceptable way, what would they be? My suspicion is that you think any criticism is unacceptable, but if you have some actual guidelines other than "people are mean to Gnome" I would be interested in hearing them. Personally I think you've been very disrespectful during this thread, but as I generally enjoy debate I've been willing to put up with it until now.

QUrprUd1nCeicw 4y ago
I think I've already explained multiple times what good criticism is. I'll repeat it with some other tips. Always present criticism in a helpful way. Be as respectful as possible every time. Only give feedback that you yourself would be willing to hear from someone else. Make sure the other person is comfortable with you before offering criticism. Never offer criticism unless you're also willing to offer to help. Acknowledge that sometimes your criticism could be wrong and apologize when it is. Accept that sometimes you have no useful criticism to give and in those cases, the best course of action is to stay quiet. Present new information each time instead of repeating old information. Use the "feedback sandwich" and always pair your criticisms with equal or higher amounts of praise. Avoid criticizing in areas that you're not qualified in. For code, that means don't talk about it unless you've personally studied that code in detail. Avoid personal attacks. Avoid trash talking. Avoid starting fights. Avoid continuing old fights. Avoid holding grudges. Avoid rumors and hearsay. Avoid "ranking" people against each other. Never look at anything in terms of "opposing sides." Avoid creating situations where one person wins and the other loses. Remember that everyone is on the same team and as a good community member, the ultimate goal of your criticism is to support others and create situations where everyone can win. This is fairly generic advice and it all isn't even related to GNOME. This is a general guideline for any healthy community. You can read about all this in random books about community building. If you want to be part of open source you just have to be a good community member, there's literally nothing else to open source. That's why I say it's unacceptable to do those negative things. There just isn't any other way this works. These are communities of equals, you aren't the boss and no one else is your boss either, so it's on you to manage your own conduct. I'm trying to be kind to you but you're making it difficult when you lead by saying nasty things about people I know, like they're acting shitty just because they declined to implement a feature that you were personally invested in and they weren't. And you keep insisting that they have to do this or they deserve it or something like that. Please just don't do that, it makes it extremely hard to engage with you when I have to keep going through this wall of "but don't you see this other person sucks" or that type of thing. You're automatically putting everyone else on defense when you do that and it messes up the whole conversation.
- traverseda 4y ago
  That's how you criticize a person, sure. How do you criticize Adobe for the issues around Pantone support? How do you criticize wizards of the coast for the OGL issues that are going on right now?
  - QUrprUd1nCeicw 4y ago
    I don't see how these questions are related. Those are businesses. Volunteer open source projects aren't businesses. There's no barriers for anyone to join the project and start changing it from the inside. And they're specifically set up so you don't have to boycott them when disagreements happen, you just fork the project.
    - traverseda 4y ago
      >There's no barriers for anyone to join the project and start changing it from the inside. There are a bunch of barriers, you don't have to go far to see people asking if pull requests would be welcomed for a particular feature. The gnome foundation may be largely volunteer run, but it is a business and people do get paid to work on it. I don't think it gets a pass just for being open source, any more than the linux kernel or Wikipedia does.
      - QUrprUd1nCeicw 4y ago
        >There are a bunch of barriers, you don't have to go far to see people asking if pull requests would be welcomed for a particular feature. That isn't a barrier and you don't need to do that. You just implement the feature in your own fork. I can tell from this you're not a developer because this is a common confusion. When you ask for a pull request you're not trying to get through a social barrier. You're actually asking someone else to do you a huge favor by taking time out of their day to review your code for free. And then if they merge it you're also asking them to maintain it for free and fix future bugs in it for free. Normally you would have to pay to get other developers to do that. >but it is a business No, this is false and you're getting confused again. Some businesses can contribute by volunteering their employees' time, but that's different from the project itself being a business. The project itself (as in the collection of all the contributors) isn't deciding what those people are paid or what they work on. The project itself doesn't have the customers or answer to them, the business does and that's a separate entity both legally and functionally. Do you see how this is fundamentally different from a business? >I don't think it gets a pass just for being open source, any more than the linux kernel or Wikipedia does. A pass on what, exactly? You're coming back to this combative language again, please stop.

QUrprUd1nCeicw 4y ago

I think I've already explained multiple times what good criticism is. I'll repeat it with some other tips. Always present criticism in a helpful way. Be as respectful as possible every time. Only give feedback that you yourself would be willing to hear from someone else. Make sure the other person is comfortable with you before offering criticism. Never offer criticism unless you're also willing to offer to help. Acknowledge that sometimes your criticism could be wrong and apologize when it is. Accept that sometimes you have no useful criticism to give and in those cases, the best course of action is to stay quiet. Present new information each time instead of repeating old information. Use the "feedback sandwich" and always pair your criticisms with equal or higher amounts of praise. Avoid criticizing in areas that you're not qualified in. For code, that means don't talk about it unless you've personally studied that code in detail. Avoid personal attacks. Avoid trash talking. Avoid starting fights. Avoid continuing old fights. Avoid holding grudges. Avoid rumors and hearsay. Avoid "ranking" people against each other. Never look at anything in terms of "opposing sides." Avoid creating situations where one person wins and the other loses. Remember that everyone is on the same team and as a good community member, the ultimate goal of your criticism is to support others and create situations where everyone can win. This is fairly generic advice and it all isn't even related to GNOME. This is a general guideline for any healthy community. You can read about all this in random books about community building. If you want to be part of open source you just have to be a good community member, there's literally nothing else to open source. That's why I say it's unacceptable to do those negative things. There just isn't any other way this works. These are communities of equals, you aren't the boss and no one else is your boss either, so it's on you to manage your own conduct. I'm trying to be kind to you but you're making it difficult when you lead by saying nasty things about people I know, like they're acting shitty just because they declined to implement a feature that you were personally invested in and they weren't. And you keep insisting that they have to do this or they deserve it or something like that. Please just don't do that, it makes it extremely hard to engage with you when I have to keep going through this wall of "but don't you see this other person sucks" or that type of thing. You're automatically putting everyone else on defense when you do that and it messes up the whole conversation.

traverseda 4y ago
That's how you criticize a person, sure. How do you criticize Adobe for the issues around Pantone support? How do you criticize wizards of the coast for the OGL issues that are going on right now?
- QUrprUd1nCeicw 4y ago
  I don't see how these questions are related. Those are businesses. Volunteer open source projects aren't businesses. There's no barriers for anyone to join the project and start changing it from the inside. And they're specifically set up so you don't have to boycott them when disagreements happen, you just fork the project.
  - traverseda 4y ago
    >There's no barriers for anyone to join the project and start changing it from the inside. There are a bunch of barriers, you don't have to go far to see people asking if pull requests would be welcomed for a particular feature. The gnome foundation may be largely volunteer run, but it is a business and people do get paid to work on it. I don't think it gets a pass just for being open source, any more than the linux kernel or Wikipedia does.
    - QUrprUd1nCeicw 4y ago
      >There are a bunch of barriers, you don't have to go far to see people asking if pull requests would be welcomed for a particular feature. That isn't a barrier and you don't need to do that. You just implement the feature in your own fork. I can tell from this you're not a developer because this is a common confusion. When you ask for a pull request you're not trying to get through a social barrier. You're actually asking someone else to do you a huge favor by taking time out of their day to review your code for free. And then if they merge it you're also asking them to maintain it for free and fix future bugs in it for free. Normally you would have to pay to get other developers to do that. >but it is a business No, this is false and you're getting confused again. Some businesses can contribute by volunteering their employees' time, but that's different from the project itself being a business. The project itself (as in the collection of all the contributors) isn't deciding what those people are paid or what they work on. The project itself doesn't have the customers or answer to them, the business does and that's a separate entity both legally and functionally. Do you see how this is fundamentally different from a business? >I don't think it gets a pass just for being open source, any more than the linux kernel or Wikipedia does. A pass on what, exactly? You're coming back to this combative language again, please stop.