11–20 of 188 posts
Just stopping by to point out that there is a typo in the first sentence of the article, I think: in "I maintain over many", the "over" should not be there. Now I will read the article. :)
Just stopping by to point out that there is a typo in the first sentence of the article, I think: in "I maintain over many", the "over" should not be there. Now I will read the article. :)
Also "the bus factor is high". Should be "low", as it is 1 for most projects.
Real world examples of these design docs can be found at https://github.com/golang/proposal
Earlier quoted context omitted.
Why not send requests out of the blue? This happens to me all the time and I don't mind. It means someone cares enough to try to fix their problems instead of dumping it on me.
The problem is on the other side. If you don't want the push, the sender just wasted a some work.
Just stopping by to point out that there is a typo in the first sentence of the article, I think: in "I maintain over many", the "over" should not be there. Now I will read the article. :)
You should report this to the blog author; not to HN readers.
Earlier quoted context omitted.
Also "the bus factor is high". Should be "low", as it is 1 for most projects.
I'm not sure if you're just being pedantic, but "the bus factor is high" in this instance means there is a high level of risk to the health of the OSS projects he maintains if he were to get hit by a bus.
Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea , much less the implementation, and save you time. The mere creation of a fork isn’t a sufficient signal, either; the project…
Why not send requests out of the blue? This happens to me all the time and I don't mind. It means someone cares enough to try to fix their problems instead of dumping it on me.
Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea , much less the implementation, and save you time. The mere creation of a fork isn’t a sufficient signal, either; the project…
I see a problem that I can fix, I do that, and then send it back to the original maintainer, making sure that I'm not breaking tests if they exist, and providing a good description of the change. Then it's up to the maintainer to either merge it, or throw it away.
Of course, I don't have any problem with getting my PRs closed, I'm not the one who would end up maintaining the code.
Earlier quoted context omitted.
Why not send requests out of the blue? This happens to me all the time and I don't mind. It means someone cares enough to try to fix their problems instead of dumping it on me.
The problem is on the other side. If you don't want the push, the sender just wasted a some work.
Also, don’t send requests out of the blue. The original maintainer has to know that you’re working on something. One reason is that your changes might collide spectacularly with other planned changes you weren’t aware of. Another reason is that the maintainer might say “no” to the entire idea , much less the implementation, and save you time. The mere creation of a fork isn’t a sufficient signal, either; the project…
Padding resumes is a bit cynical there are many good reasons to make a fork for oneself. Like ensuring you have code you depend on in the event the project is deleted