5 ms·

Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done a

Acknowledging my bias towards correctness first (or a harness for explicitly experimenting), I think your step 3 ("3. Fix and iterate it") is rarely ever done and that absence puts people off. In the corporate environments I work in, the PR sets the standard for what is acceptable and there's vanishingly little motivation to fix anything that isn't blowing up a high profile client. Basically mini tragedy of the commons. I wouldn't be surprised if an aspect of this is "I don't trust you'll iterate and fix this, and I don't want to, so please make sure this is correct". I would expect a contributor with a long/trust-filled relationship to the maintainer to have much more leeway for not-exactly-perfect contributions.

DannyBee 5y ago
My bias is from watching a lot of smart people experiment well. I think you are not wrong in the limit, but it's a bit more complex than that: 1. You need to set expectations up front of what it means to contribute. 2. You need to be willing to spend time to help ensure people know how to iterate it, etc. Check in with them, etc. We often expect people to just figure out what you want or be completely self-sufficient. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively). But we often suck at training people at things they aren't used to. Training goes a long way. etc Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :) I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not. I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"
- couchand 5y ago
  To bring it back to the article, this really seems like one of those "get it in and run away" cases. Or to be a bit more accurate, run away before getting it in... The author made a number of comments on the PR about how they expected it was almost done while there were still outstanding concerns from maintainers. The author stopped responding to comments when their employer's priorities changed. Someone else volunteered to finish the author's incomplete work, then the author closed the PR, complaining about being tired of seeing it in their PR list. The maintainers spent a fair amount of effort explaining many (basic Rust) things like the extremely unsound API design of dereferencing a user-supplied raw pointer. They were trying to help. This just doesn't seem like an individual the maintainers have any reason to trust.

DannyBee 5y ago

My bias is from watching a lot of smart people experiment well. I think you are not wrong in the limit, but it's a bit more complex than that: 1. You need to set expectations up front of what it means to contribute. 2. You need to be willing to spend time to help ensure people know how to iterate it, etc. Check in with them, etc. We often expect people to just figure out what you want or be completely self-sufficient. Especially with folks who have never interacted with your project, how could they possibly know how to do it well? We often motivate (positively or negatively). But we often suck at training people at things they aren't used to. Training goes a long way. etc Again, this will never work 100% of the time. You will find people who in fact, will just want to get it in and run away. I'm just trying to get that percent to say 5-10%, rather than 80% :) I agree with the aspect you see - people are not always willing to trust. This often turns into "you are all helping me with my software" rather than "we are all working together to produce software". In practice - the process i gave is also one of the only good ways i know to build long term trust and contributor relationships. You trust them to work on their code once added, and to care. They trust you to help them. That is how you start to build good team relationships. They will be good at things you are not, you will be good at things they are not. I'm not sure how you ever build a trust or community relationship if you say "i don't want to trust you to do anything, please drop it on me in a perfect state so i don't have to trust you"

couchand 5y ago
To bring it back to the article, this really seems like one of those "get it in and run away" cases. Or to be a bit more accurate, run away before getting it in... The author made a number of comments on the PR about how they expected it was almost done while there were still outstanding concerns from maintainers. The author stopped responding to comments when their employer's priorities changed. Someone else volunteered to finish the author's incomplete work, then the author closed the PR, complaining about being tired of seeing it in their PR list. The maintainers spent a fair amount of effort explaining many (basic Rust) things like the extremely unsound API design of dereferencing a user-supplied raw pointer. They were trying to help. This just doesn't seem like an individual the maintainers have any reason to trust.