4 ms·

> 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 op

> 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.

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.