11–20 of 98 posts
Horrible GitHub workflow: corporate logos, octop^Hcat, CoC shoved in your face on every commit.
I'm currently forced to contribute to a GitHub project, it is the most annoying, bureaucratic and brainwashing workflow I've ever experienced.
I dislike the idea of using 'origin' for my own remote name. I keep 'origin' as the canonical remote and my local master branch tracks origin/master. I use people's usernames for their remotes (including for my own). If I'm pushing a feature branch to my own remote: git push -u myusername mybranchname If I need to checkout someone's PR, it's: git remote add theirusername git@github.com:theirusername/repo.git git fetc…
I grew so tired of that that I just wrote a little wrapper script, that just does the right thing (tm). So it's
$ shit push
Of these, 1: Chose the project you want to contribute to (and 1.5: Choose the issue to work on) and 9: Follow up are the hard ones. Both are primarily social problems. For 1, it's mostly about knowing yourself. What projects interest you, and where can you contribute? For 9, it's convincing the owners that your contribution is a net positive. Start with 2: Check out how to contribute, and proactively reach out so you…
So I keep coming back to what has been said elsewhere: the best way seems to be to find a bug in something you use, realize it's open source and go from there. That's unfortunately not a great way to mobilize the masses of people that could contribute, but don't have a particular project in mind (think GSoC).
Not just spaces vs tabs or block styles, but idioms and other idiosyncrasies, too. Why? Imagine reading a source repo where every second block uses different bracket styles, mixing spaces with tabs and so on. It's going to look like a kludgy mess, and will be distracting to read.
There is no correct style for most languages (perhaps `go fmt` might be an exception), only opinions.
And if a change is rejected, it's usually because there was not enough discussion beforehand about how to solve the problem, the change itself did not undergo enough discussion/iterations, or the change is not really a solution to a problem. (It's not the maintainers saying "Go away and never come back" -- more like, "Thank you for your effort! Please approach this differently.")
Step 1: stumble upon a terrible bug (or that really obvious missing feature that _should_ be there) in your favorite library / framework / app. Step 2: rant about it on HN / Github issues / whatever. Step 3 (optional): try to reach developers on GitHub and get the obligatory "pull requests are welcome" response. Step 4: In frustration, clone the repository, fix the damn bug and submit your pull request. Steps 5..41:…
https://xkcd.com/386/ Disclaimer: I am an akka and akka-http community contributor. I don't know how this works for other projects. But I don't think the process is as painful as you describe in the akka world. My experiences are quite to the contrary. The community here is warm and welcoming. But, please look at this from the other side. Would you use the software in your mission critical application if the project…
Akka community is excellent.
I disagree with this premise. The way people usually contribute to an open source project on GitHub is creating an issue or adding to a discussion. IMHO this is more valuable than actually writing code because it helps other developers gauge the relative demand for a feature/bugfix and sometimes you find out that other people have already solved the problem in their own forks.