Many open source projects (definitely those at Mozilla) even have specially-labeled bugs in their database that are good for beginners. For example, in Servo we mark those issues "E-easy" and provide support for them on our IRC channel:
I know the Firefox team is even better than we are, with a split into Mentored bugs (with an identified owner you can contact for help!), Easy bugs, and Good Student Projects:
Those bugs will definitely get you started working with a larger Rust codebase. You might want to at least scan the Rust tutorials on http://www.rust-lang.org/ , though, as just reading Servo code is probably not a good way to initially learn the language. Servo has a lot of foreign function interface code and many parts of the architecture are optimized for performance, making some of the data structures and task communication patterns fairly advanced.
Rust itself also has its own E-easy bugs, many of which are in libraries that do not suffer from the same kind of heavy optimization that we've done in Servo:
This is a great writeup for would be contributors.
I recently ran a questionnaire for potential and new open source contributors, pretty unanimously the responses were split between
People who havent contributed: had maybe tried, were nervous about getting started, lacked good guidance from the project and in general
People who had: Found life a lot easier once they got over the initial hump, were extremely grateful of the help they got, were hugely positive about the impact OS had on them
I was originally planning to do a project to help first time contributors (goodfirstpatch.com), however realistically I dont have any time right now. I found openhatch.org to be a good place for people to get introduced, there was definitely improvements it can make but it was a real help for an open source workshop I ran.
Yeah openhatch is good. There was a bit of talk on it on the episode on Twisted (because Jessica is also involved in that) on the FLOSS weekly podcast, check out that episode if you're interested.
I wanted to contribute to my first OS project. I am an hobbist programmer, but I do have some good skills in python/flask. As I said I was still learning and once I pointed the project coordinator to my half-assed github, he did not answer me back anymore.
Point is: I can work on documentation and bugs, but if you behave like an asshole, how can I even do that? People are not contributing much to OS because many programmers reject the idea of mentoring. But think about it: it gives you more 1 hr of mentoring and then 10 hours of work of an hobbist programmer or 1 hr more of programming?
Could you find a project with some form of mentoring happening on a forum or mailing list? Some projects have sort of 'funnels' where people get small tasks to do then progress to larger chunks of stuff.
Somewhat of a Hanlon's razor, a lot of open source projects arent maintained, they are thrown over the wall, similiarly a lot of project maintainers are very busy and unless they get a pull request then they are quite likely to ignore it, as projects gets popular it easily gets the point where maintainers have 'no' time to code, and spend their time guiding contributions.
Ultimately if a maintainer isnt showing interest in taking your contributions then it just isnt a project you want to carry on attempting to, it takes some a little time and maybe experience to find a suitable project.
Certainly dont make sweeping statements about nobody contributing to open source because programmers dont like helping each other, there may be exceptions but the people contributing to OS is growing faster than ever
but sometimes the net cost to the senior/mentor person is actually negative, if the other party, the newb is sufficiently junior or incompetent. there are plenty of cases where somebody delivers one "fix" or "improvement" which then itself introduces other problems. save 2 hours, cause other people an additional >2 hours of work afterward, sometimes multiple of that. (time to add a bug? a few seconds. time to discover/home-in/fix/test that bug later? hours/days/weeks.) that's... not good. and experienced folks try to minimize it. the nice thing about the Internet is how we can all talk and learn and collaborate together more easily now than ever before. the bad thing about the Internet is folks who are still but wee infants, skill-wise, who, say 20 years ago would have had a long gestational period working in private and relative isolation, on their boxes before they emerged into the larger ecosystem (at a job or university, etc.) are instead often almost immediately jumping into forums, channels and repos and trying to "contribute" while they're still in that gestational stage. It's like there's now an army of cute fuzzy wittle lion cubbies who now try to tag along with the adult lions when the latter slink off to hunt for prey -- it impairs both parties and does not actually "help" either.
Let's not get offensive, OK? I have been programming in University, learning on my own, both R and Python (and SQL, Javascript, HTML, CSS). I played in Python for 3 years. I am not a noob, I know what I am doing. My "problem" is a half assed github. And you know why is that? Not because of my bad programming, but because of lack of motivation. Really, we are not all ninjas here coming home from a 9-5 and then coding on side projects till 1am. Many people lack that kind of motivation and that is why we need people willing to mentor or at least being friendly.
Finally, if a push from a total stranger can mess up your code base, I wonder if you know what you are doing. We do test driven development for a reason.
P.s. I am giving you an up 1 so I make sure you read this.
I spoke in the general case based on decades of first-hand observations in RL. There are obviously always exceptions to any general pattern or effect.
Also, not all projects have automated tests. Not all those with automated tests have 100% perfect coverage of everything that could possibly break. If anything I'd argue that the rise of unit test culture and TDD culture has actually increased the incidence of allowed sloppiness in some cases by folks having the mindset of, "I can deliver any diff I want. If no existing test failed, or the project has no tests, I did nothing wrong." This mindset too I've seen evidence of repeatedly.
And there's nothing wrong with a person being new to programming. I can only reiterate the core point of my original comment to which you replied.
Yesterday I made my first pull request to an open source project.
Previously I'd always felt like I wouldn't know where to start or wouldn't be able to contribute in a meaningful way. In the end, I decided to just get over myself and do it.
I think everyone should try to aid open source projects in some way, especially when they use open source on a daily basis.
I would love to see a few more people contribute to open source. I read article after article about people who want to make a switch from their Apple or Microsoft Desktop, but then say open source / floss desktops are not ready or not productive enough.
There is a huge disconnect in that these people don't feel empowered to jump in, fix those defects and make it the desktop they have always wanted. I think blogs like this will help point them in the right direction.
I tried to work this year on contributing to open source, while looking for projects I ran into the KDE summer of code. I emailed the guy who was in charge of the project I wanted to work in. I messaged him in IRC. I never got any kind of reply.
And that sucks. I don't even use KDE I just wanted to help, to not even get a "hey sorry we're full" or something, that sucks.
So what step is before this one? I'd love to contribute to an open source project, but I still don't think I have enough programming skill in Python. I've been following several MOOCs and been through codeacademy and LPTHW, and I still can't program any projects(small or big), or even contribute to any.
One way to contribute is by testing documentation - try following a project's instructions to set up a local dev environment, and then report anything confusing or outdated in the documentation. You can also write a blog post explaining your experience of trying to contribute to a project - being a thoughtful beginner can help you point out problems that a more experienced contributor might automatically compensate for and not even notice. I wrote this kind of post for OpenStreetMap once, and experienced contributors appreciated it: http://www.openstreetmap.org/user/brittag/diary/19741
Like the article says, you can also answer support questions, report bugs, help manage bug reports (verifying reports, marking duplicates), write publicity blog posts, etc. These tasks are important and often understaffed on projects, and they help you become more familiar with a software project and more prepared to become a productive contributor to code.
I do non-code software work like that, and I've been happy to find a project that invited my kind of help: OpenHatch (http://openhatch.org/), conveniently relevant because it's about helping people who want to contribute to open source projects.
It's tremendously easy to contribute to open source. The problem is, everyone wants to get their name in the Linux kernel. It's just not happening. The technical bar is too high. Pick something less visible. There are literally thousands of projects that have bugs and are not even being maintained. Stop being a trendwhore.
"Trendwhore", seriously? Anyway, this article isn't talking about people aspiring to make major contributions to high-profile highly-complex projects, it's talking about people who want to contribute to projects in general, and saying that small less-technical contributions are great to start with.
And it's not that easy to find a project, especially not for inexperienced developers. You don't want to pick an unmaintained project - you need somebody around to help you when you get stuck, ideally at least a few people so that you don't burn them out on answering questions. Hopefully you manage to find a project that has reasonably friendly people, some way to talk to them, a language you're familiar with, relatively easy tasks to get started with, and is interesting to you in some way - not really a simple Github search.
Many open source projects (definitely those at Mozilla) even have specially-labeled bugs in their database that are good for beginners. For example, in Servo we mark those issues "E-easy" and provide support for them on our IRC channel:
https://github.com/mozilla/servo/issues?labels=E-easy&page=1...
I know the Firefox team is even better than we are, with a split into Mentored bugs (with an identified owner you can contact for help!), Easy bugs, and Good Student Projects:
https://developer.mozilla.org/en-US/docs/Introduction#Find_a...