3 ms·

> 3. Don’t Start Work Without Approval This is not a hard rule. It depends on how much you value your time. If you try to change some behaviour that the proje

> 3. Don’t Start Work Without Approval This is not a hard rule. It depends on how much you value your time. If you try to change some behaviour that the project wants to guarantee to its users, I might reject your contribution based on the idea it embodies, if my idea as the maintainer is different. If you fix a bug, your chances of simply getting through are much higher, and you may even save me time if your change is "good enough" and I don't need to do anything but say "thanks" and merge. I don't really care if you report an issue by filing an issue or by requesting a merge.

Arech 6y ago
And now imagine you're going to fix/add something to a big project with many devs and even more active contributors. Usually the bigger the project the higher the possibility that you may cross over with someone else doing essentially the same. In that case a prior announcement of your intent is a very logical thing to do and the issue tracker looks indeed the most suitable method of synchronization between contributors. So I find the point 3 in the post actually the most important of all (at least for me, I haven't thought about it before)
- rhn_mk1 6y ago
  You highlight an important point: in a big project, where a lot is going on, your thing might be going on without you realizing too. If you start the work without checking past attempts and current claims, you risk wasting your effort. In smaller projects, the chance of making an obsolete contribution is lower due to things moving slower in general. On the flip side, there are people who announce their intention and never follow up on the promise, while potential new contributors may think the problem is getting solved. As the maintainer, I'd rather have them announce nothing. Then there are ideas that are not easily expressible in worrds. Sometimes you just have to show it for others to be able to meaningfully consider the topic.

Arech 6y ago

And now imagine you're going to fix/add something to a big project with many devs and even more active contributors. Usually the bigger the project the higher the possibility that you may cross over with someone else doing essentially the same. In that case a prior announcement of your intent is a very logical thing to do and the issue tracker looks indeed the most suitable method of synchronization between contributors. So I find the point 3 in the post actually the most important of all (at least for me, I haven't thought about it before)

rhn_mk1 6y ago
You highlight an important point: in a big project, where a lot is going on, your thing might be going on without you realizing too. If you start the work without checking past attempts and current claims, you risk wasting your effort. In smaller projects, the chance of making an obsolete contribution is lower due to things moving slower in general. On the flip side, there are people who announce their intention and never follow up on the promise, while potential new contributors may think the problem is getting solved. As the maintainer, I'd rather have them announce nothing. Then there are ideas that are not easily expressible in worrds. Sometimes you just have to show it for others to be able to meaningfully consider the topic.