21–30 of 37 posts
I've been on the project for a couple months, and I find folks to be very friendly and quick to respond on Github/IRC/etc. Plus it's part of the bigger Apache CouchDB ecosystem, so it's a good crowd to run with!
Regarding discovering them algorithmically tends to be quite an interesting idea actually, should think more on this.
I'm terrible at open source because I usually fix things that don't need to be fixed (aka refactor). Then people yell at me to go away.
-Actually makes the code cleaner.
-Reduces redundancies.
-Above all, actually results in there being less code than there was before.
If you can achieve clean code + negative lines of code after a refactor, with identical functionality, they'd be fools to not merge it.
It's possible the refactors you submitted didn't meet these requirements. Or the project owners simply were too possessive of the code they wrote with their own fingers.
What about contributing to writing docs instead? yes i'm serious. When it comes to writing documentation for opensource projects, suddenly,there is no developper available. Yet documentation is central to any opensource project. Maybe I should launch a "Please write help us write docs" plateform.
Maybe OSS contributions should actually start with writing the docs, sort of like how interns start with fetching the coffee ;) Of course, you can do more if you like but writing docs is a great starting point to learn more about the underlying code anyway!
Earlier quoted context omitted.
That strikes me as a bit of an odd stance to take. While refactoring is certainly a portion of the work done to most any project, I wouldn't think that refactoring would be attractive as a first commit for someone who may be viewed as an outsider to a project. Even if you overlook that getting code that matches a projects style guides might be rarer than it should be refactoring (at least in most cases that I need to…
What does make a good first commit? I ask because I'm just starting to try to work on open source. The first commit I made on the one project I've already started getting involved with was adding more content (especially where there was a "TODO: more of this" comment), and correcting spellings. I wouldn't know how to start on something less content-based, though.
Answering questions on Stack Overflow / mailing lists / issue trackers can be a good way to build up trust in your abilities and a working relationship with other contributors.
Often projects label things that are "good for a first commit" and you should check out those.
All that said, most projects are eager to include new people, and personally I enjoy helping new contributors feel comfortable and get their commits accepted.
I'm a volunteer with OpenHatch, which egor83 mentions below -- a non-profit to help people get involved in open source. At our Open Source Comes to Campus events, we aim to find great projects to connect newcomers with. (More info on the event series here -- http://campus.openhatch.org/ )
Your question struck a chord with me, since I think your curriculum and the curriculum we use for our weekend-long events would have some overlap: https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Curri...
But the hard part is helping find great open source projects to contribute to.
To help with that, we wrote a guide for projects: http://opensource-events.com/
and are trying to reach out to project maintainers to help projects become "OpenHatch affiliated"; https://openhatch.org/wiki/OpenHatch_affiliated_projects -- maybe one great next step is to take this list of goals for projects, and work together in reaching out to projects to become OpenHatch Affiliated. Then you can have your students join the collection of people reaching out to those projects.
We find that having a specific person in the project care about the newcomer experience matters more than what we could find algorithmically. We still have the automated tool here: https://openhatch.org/search/ , in case you're interested.
Semi-sorry that this is a long comment, but I wanted to fill you in on a bunch of things, and I'm about to go to bed, so this has a higher chance than usual of being rambly.
OpenHatch-y people who care about outreach like this convene on the "Events" mailing list " rel="nofollow">http://lists.openhatch.org/mailman/listinfo/events/> and I hope you'll join us there and say hi! And/or reply with your thoughts here.
I'd love to collaborate on this, as it's something that we're always interested in improving for our students, too. I'm based in SF, in case you want to meet up for coffee etc.
P.S. The OpenHatch web app is itself is an open source project, in Django & Javascript, and we are always welcoming contributors. (-: Also, oppia is the project that we're furthest-along with in terms of OpenHatch affiliation.
Most of the contributers are students including me and we have a very welcoming environment.
Just drop I'm #elementary-Dev introduce yourself and join the effort.
Earlier quoted context omitted.
That strikes me as a bit of an odd stance to take. While refactoring is certainly a portion of the work done to most any project, I wouldn't think that refactoring would be attractive as a first commit for someone who may be viewed as an outsider to a project. Even if you overlook that getting code that matches a projects style guides might be rarer than it should be refactoring (at least in most cases that I need to…
What does make a good first commit? I ask because I'm just starting to try to work on open source. The first commit I made on the one project I've already started getting involved with was adding more content (especially where there was a "TODO: more of this" comment), and correcting spellings. I wouldn't know how to start on something less content-based, though.
Tests are a way to delegate trust. Instead of trusting the developer, you trust the code. It's a huge huge relief. If you can remove that burden from the shoulders of the maintainers, I guarantee you will be welcomed with open arms.
The side-effect is that you don't need to _add_ content/functionality, so the maintainers don't have to think about your new shiny feature. And if you fix something that was supposed to work in their own view of the project, then you start being noticed.