5 ms·

It should be noted that you should contact them about their mistake in the most private way possible, then escalating slowly as the need arises. This follows th

It should be noted that you should contact them about their mistake in the most private way possible, then escalating slowly as the need arises. This follows the "praise in public, punish in private" maxim.

aequitas 6y ago
This makes me think, it is opposite to what mostly is used in open source projects that have bugtrackers. Github is filled with countless 'mistakes' (issues/pr's) people made in the code they published. Should there be some kind of way to make issues private? Before I was into open source I was always afraid to show my code to anyone because of the critique I could expect. But some coworkers helped me get the confidence I needed to go open source (within the company, not public internet). Being completely open about everything and accepting critique publicly really helped me grow as a developer to also be open to others. I wonder if I would have made the same transformation if I was only critiqued in private.
- tsimionescu 6y ago
  Bugs are not critiques. Working in software development, you learn extremely quickly that everyone writes bugs, and there is nothing to be embarrassed about. The openness of issue trackers even helps elevate that. On the other hand, it's not normal and not often practiced to go digging to see whose mistake introduced a bug and call them out in public on it - that would be what shouldn't be done at all.
  - aequitas 6y ago
    > Bugs are not critiques. Not only (technical) bugs are reported, but also design decisions and such. A lot of those things often come down to difference in opinion. I've seen some developers be really adamant about how a bug was actually a feature. > The openness of issue trackers even helps elevate that. I agree partly. For me it helped see things different and make a positive growth. But I can image some staying afraid to enter or be deterred really quick never coming back. >> This follows the "praise in public, punish in private" maxim. So like the previous poster said. I am wondering if Github et al. should not contain a private channel. I have a email on my Github page. And besides spammers I sometimes get questions regarding my projects. I don't know if it is due to people not understanding Github that well[0] or wanting to contact privately[1]. But for some reason they didn't open a public issue[2]. [0] I've met a lot of technical people that just are afraid of Github because it is complex. Electrical engineers, mechanics, embedded engineers. People I figure would understand software development concepts. [1] Asking a stupid question publicly could also count toward making a public mistake depending on how secure someone feels about themselves. [2] There is of course also the discussion if issues should be your projects helpdesk next to being an bug tracker. And raising an 'issue' for something that might just be a question might feel strange for some.
    - kbenson 6y ago
      > I've seen some developers be really adamant about how a bug was actually a feature. And sometimes they are feature, and it's the users that are mistaken on what the project they are using is offering them. It's a fine line, I'm sure, but different projects have different goals, and those goals will align to a specific user's needs differently depending on the user. > So like the previous poster said. I am wondering if Github et al. should not contain a private channel. It might depend quite a bit on the project. In an open source project with many contributors, there isn't really any meaning to "private" other than "limited to a subgroup of the people that care", and those people may have little to nothing with the design and implementation of the items in question. In a project that is mostly driven by one author that controls it and accepts some patches, that might be a lot different, and criticism may be received differently. There's a whole spectrum there, and even if you provide the tools to allow different types of contact, what's to prevent people from using the wrong tool most the time? Rust, PHP, Perl, Bind, Apache etc aren't going to benefit much for a private list for first contact of regular bugs, but people would use it. Meanwhile someone's random personal project is still going to get people making public requests even if they prefer them private. In the end, I think we're all better served by a "public by default" for open source stuff, and for things people feel is actually private (security related items, for example), they'll look up a private contact or personal contact for someone related.
- dustinhayes 6y ago
  In larger projects bugs are rarely caused by a single person. With many people contributing to a problem in the way of code and reviews. The best way forward is for everyone to own the bug and own any potential solutions.
- anticristi 6y ago
  I love critique. It means that someone cares! I contributed to launching a few products. After countless hours of design debates, code writing, code review, the baby was finally ready to see the world ... but nobody cared. Not even a drive-by troll bothered writing "this is completely useless". My Motto: "That product sucks, but wow! It made it on the shelf."
- FireBeyond 6y ago
  I think though there are still some elements, there is also a difference between genuine mistakes (bugs) and "knowing the wrong thing, and choosing to do so".
deleted 6y ago
[deleted]
hammock 6y ago
Gospel of Matthew, chapter 18: If your brother sins against you, go and tell him his fault between you and him alone. If he listens to you, you have won over your brother. If he does not listen, take one or two others along with you, so that every fact may be established on the testimony of two or three witnesses. If he refuses to listen to them, tell the church. If he refuses to listen even to the church, then treat him as you would a Gentile or a tax collector. Amen, I say to you, whatever you bind on earth shall be bound in heaven, and whatever you loose on earth shall be loosed in heaven.
- herodoturtle 6y ago
  If he refuses to listen even to the church, then forgive him anyway.
  - minkzilla 6y ago
    This passage isn’t as much about forgiveness as correction. You are supposed to forgive no matter what (77 times). But this is if someone is doing wrong and needs to be corrected. If no matter what they will not stop their bad behavior then depending on how serious it is they cannot be allowed to keep being a part of the community.
    - jschulenklopper 6y ago
      It’s 7 times 70, not 7 plus 70. Anyway, too many times so that you could keep count.
- contravariant 6y ago
  Wow, guess he really didn't like tax collectors.
  - billjings 6y ago
    Sort of? On the one hand, they were a cultural byword for a morally degraded profession at the time. "Tax collectors and prostitutes" is a phrase that comes up not infrequently in the gospels, and not just out of Jesus' mouth So apparently the practice of tax collecting was a little weird in the Roman Empire. On the other hand, he was known for having dinner with tax collectors and prostitutes. One of his 12 disciples was a tax collector.

aequitas 6y ago

This makes me think, it is opposite to what mostly is used in open source projects that have bugtrackers. Github is filled with countless 'mistakes' (issues/pr's) people made in the code they published. Should there be some kind of way to make issues private? Before I was into open source I was always afraid to show my code to anyone because of the critique I could expect. But some coworkers helped me get the confidence I needed to go open source (within the company, not public internet). Being completely open about everything and accepting critique publicly really helped me grow as a developer to also be open to others. I wonder if I would have made the same transformation if I was only critiqued in private.

tsimionescu 6y ago
Bugs are not critiques. Working in software development, you learn extremely quickly that everyone writes bugs, and there is nothing to be embarrassed about. The openness of issue trackers even helps elevate that. On the other hand, it's not normal and not often practiced to go digging to see whose mistake introduced a bug and call them out in public on it - that would be what shouldn't be done at all.
- aequitas 6y ago
  > Bugs are not critiques. Not only (technical) bugs are reported, but also design decisions and such. A lot of those things often come down to difference in opinion. I've seen some developers be really adamant about how a bug was actually a feature. > The openness of issue trackers even helps elevate that. I agree partly. For me it helped see things different and make a positive growth. But I can image some staying afraid to enter or be deterred really quick never coming back. >> This follows the "praise in public, punish in private" maxim. So like the previous poster said. I am wondering if Github et al. should not contain a private channel. I have a email on my Github page. And besides spammers I sometimes get questions regarding my projects. I don't know if it is due to people not understanding Github that well[0] or wanting to contact privately[1]. But for some reason they didn't open a public issue[2]. [0] I've met a lot of technical people that just are afraid of Github because it is complex. Electrical engineers, mechanics, embedded engineers. People I figure would understand software development concepts. [1] Asking a stupid question publicly could also count toward making a public mistake depending on how secure someone feels about themselves. [2] There is of course also the discussion if issues should be your projects helpdesk next to being an bug tracker. And raising an 'issue' for something that might just be a question might feel strange for some.
  - kbenson 6y ago
    > I've seen some developers be really adamant about how a bug was actually a feature. And sometimes they are feature, and it's the users that are mistaken on what the project they are using is offering them. It's a fine line, I'm sure, but different projects have different goals, and those goals will align to a specific user's needs differently depending on the user. > So like the previous poster said. I am wondering if Github et al. should not contain a private channel. It might depend quite a bit on the project. In an open source project with many contributors, there isn't really any meaning to "private" other than "limited to a subgroup of the people that care", and those people may have little to nothing with the design and implementation of the items in question. In a project that is mostly driven by one author that controls it and accepts some patches, that might be a lot different, and criticism may be received differently. There's a whole spectrum there, and even if you provide the tools to allow different types of contact, what's to prevent people from using the wrong tool most the time? Rust, PHP, Perl, Bind, Apache etc aren't going to benefit much for a private list for first contact of regular bugs, but people would use it. Meanwhile someone's random personal project is still going to get people making public requests even if they prefer them private. In the end, I think we're all better served by a "public by default" for open source stuff, and for things people feel is actually private (security related items, for example), they'll look up a private contact or personal contact for someone related.
dustinhayes 6y ago
In larger projects bugs are rarely caused by a single person. With many people contributing to a problem in the way of code and reviews. The best way forward is for everyone to own the bug and own any potential solutions.
anticristi 6y ago
I love critique. It means that someone cares! I contributed to launching a few products. After countless hours of design debates, code writing, code review, the baby was finally ready to see the world ... but nobody cared. Not even a drive-by troll bothered writing "this is completely useless". My Motto: "That product sucks, but wow! It made it on the shelf."
FireBeyond 6y ago
I think though there are still some elements, there is also a difference between genuine mistakes (bugs) and "knowing the wrong thing, and choosing to do so".

deleted 6y ago

[deleted]

hammock 6y ago

Gospel of Matthew, chapter 18: If your brother sins against you, go and tell him his fault between you and him alone. If he listens to you, you have won over your brother. If he does not listen, take one or two others along with you, so that every fact may be established on the testimony of two or three witnesses. If he refuses to listen to them, tell the church. If he refuses to listen even to the church, then treat him as you would a Gentile or a tax collector. Amen, I say to you, whatever you bind on earth shall be bound in heaven, and whatever you loose on earth shall be loosed in heaven.

herodoturtle 6y ago
If he refuses to listen even to the church, then forgive him anyway.
- minkzilla 6y ago
  This passage isn’t as much about forgiveness as correction. You are supposed to forgive no matter what (77 times). But this is if someone is doing wrong and needs to be corrected. If no matter what they will not stop their bad behavior then depending on how serious it is they cannot be allowed to keep being a part of the community.
  - jschulenklopper 6y ago
    It’s 7 times 70, not 7 plus 70. Anyway, too many times so that you could keep count.
contravariant 6y ago
Wow, guess he really didn't like tax collectors.
- billjings 6y ago
  Sort of? On the one hand, they were a cultural byword for a morally degraded profession at the time. "Tax collectors and prostitutes" is a phrase that comes up not infrequently in the gospels, and not just out of Jesus' mouth So apparently the practice of tax collecting was a little weird in the Roman Empire. On the other hand, he was known for having dinner with tax collectors and prostitutes. One of his 12 disciples was a tax collector.