4 ms·
1 per day for projects I am unfamiliar with seems aggressive. I wonder if I would even be able to add any value with such a shallow understanding of the projec
by samspot 14y ago
1 per day for projects I am unfamiliar with seems aggressive. I wonder if I would even be able to add any value with such a shallow understanding of the projects. I think 1/week is probably more reasonable if you are trying to get people who don't contribute to get involved.
- otherdave 14y agoI thought the same thing, but I've had success in the past making pull requests for documentation or other "little" things like that so you could still find ways to provide value without having to do too much. It taught me to love Github even more - with the file editing in the browser I could clone, make my change and submit my pull request all without ever cloning the repo locally.
- chopsueyar 14y agoIf you do it for Chanuka, you only need 8 pull requests.
- pavel_lishin 14y agoTechnically, it should be a single pull request that applies to eight different repos.
- justinlilly 14y agoThe first night, you do one pull request. The second night, you do one, two pull requests. The third night, you do one, two, three pull requests. ... 36 pull requests (plus the shamash each night. Maybe that's a patch to your dotfiles to get the juices flowing )
- sophacles 14y agoWhen I get involved with projects, I have a lot of potential up front to contribute, and try to do so. Some problems are best handled by those unfamiliar with the project. Examples: * Documentation fixes - clarifications of parts you find confusing, inconsistencies with current behavior, etc. * Convention fixes - are most binary checks names IsFoo() but one is named Foo_exists() ? do a quick refactor patch for it. Is one Exception named oddly, or have an unclear message? Patch is quick. * Examples - does an example highlighting something you're confused about exist? Once you figure it out, whip up an example and contribute. Others are also confused about it - I promise. * Code commenting - Do the comments contradict the code? Is there something in the code that confuses you? Once you figure it out, fix it and submit. These are all things that are actually EASIER for newcomers to a project to do - once the quirk has been internalized by a dev, they frequently don't notice it anymore. Particularly with documentation and commenting stuff. It is harder to do this with giant/super popular projects, but medium and smaller projects can always use this sort of support. For example - I decided to checkout Marionette a couple weeks ago. I was reading the docs and browsing the code to see how something was implemented, and noticed the docs and the code were not in sync. I created and submitted a patch within hours of first learning of the project. This was also a work day, so most of those hours were not spent on anything at all related. The patch was accepted - not a big deal thing, but it was nice to contribute, and it may save someone else half an hour of figuring out what was happening. The dev who merged it actually commented that he didn't realize the docs were out of date - because he knows the code. Point being, little contributions like this abound. As a project owner, I don't care when contributions are major deals or little tweaks or documentation helpers. I'm just happy when someone contributes, it makes me feel that my project is worth the effort. Which I think may be the point of the idea anyway.
- andrewnez 14y agoWould it be ok if we used some of these tips as part of the introduction process on the site to help guide people who are new to contributing to open source?
- bronson 14y agoOne more: tests! Contribute a few more tests to a project's test suite. Especially for the features that you rely on.