Huh? Says I posted this 2 hours ago, but I'm pretty sure I posted it yesterday
First Timers Only
11–20 of 71 posts
Re: First Timers Only
#12There are a lot of ways to contribute that don't involve making pull requests. Identifying and raising issues is a good place to start for someone who is not familiar with the codebase.
Re: First Timers Only
#13This titles man are worst than FB. Why not just "Click here!"?. Or could just copy and paste the title: "A suggestion to Open Source project maintainers"
Re: First Timers Only
#14Huh? Says I posted this 2 hours ago, but I'm pretty sure I posted it yesterday
I believe if dang (and perhaps others) finds a submission that would probably be interesting to a lot of HNers but didn't get much/any traction when initially posted it is "resubmitted" to give it another chance.
Re: First Timers Only
#15Earlier quoted context omitted.
What is the point?
The point is that the tradeoff between making things at optimal productivity and using thing-making as an educational opportunity exists. The OP's initiative may come at an excellent cost-benefit price, but it's questionable whether they even considered the tradeoff. And if they have, it's still important to discuss it if it comes to an internet forum.
It was pointed out in the article and he did consider it.
" Now, could I have finished it quicker and moved on my way if I’d just done it myself? Of course. But that’s not what it’s all about as an open source contributor. It’s fun delivering good software that helps other people, but also realize that there are tons of people out there who just don’t know where to get started.
Some of you may be asking yourself, “what if I (and other lib users) don’t want to wait days for the feature?” From my experience, people are eager to try it out. At least one PR (sometimes several) is submitted, iterated on, and merged within a matter of a few hours. "
Re: First Timers Only
#16similar : Mozilla "Mentor Bugs If you are looking for a bug with guidance, we maintain a set of bugs that are marked with an assigned mentor (see "Whiteboard" field). The mentor will help you get the necessary information to understand the issue, point out relevant parts of the code to look at, etc. You can browse these bugs on Bugs Ahoy!, but here's a list of unassigned mentor bugs to get you started:" https://wiki.…
We also try to have good starter bugs on Servo (and its myriad dependencies):
http://servo.github.io/servo-starters/
One of the biggest challenges we have is keeping some around and available! The good ones almost always have an opened PR within 24 hours:
https://twitter.com/ServoDev/status/665930502503723008
There are a bunch of other benefits to these bugs, including:
- There's a lively stream of people setting up the dev environment for the first time, both keeping our instructions up to date and making sure we handle scenarios like slow internet connections, really old versions of Ubuntu or Linux graphics drivers, etc.
- Reviewing these bugs is also a good way to help grow contributors from committers into reviewers/maintainers.
Most of our challenges with these kinds of bugs are related to GitHub. e.g., you can't "assign" an issue to somebody outside of the project organization, so somebody has to manually label it "Assigned" for our filters to work. Also, you don't get notifications when somebody pushes a new commit to their work branch or rebases, so there's a lot of manual watching of these PRs during the review cycle that sometimes gets dropped (though our myriad GH bots could probably fix this!).
Even with the challenges, we love having this kind of bug as a way to bring in more contributors and keep development on the project accessible, and like the author, I'd highly recommend it to other projects.
Re: First Timers Only
#17Earlier quoted context omitted.
The point is that the tradeoff between making things at optimal productivity and using thing-making as an educational opportunity exists. The OP's initiative may come at an excellent cost-benefit price, but it's questionable whether they even considered the tradeoff. And if they have, it's still important to discuss it if it comes to an internet forum.
He already had the implementation ready, but choose to not push it to github in order to encourrage participation. Clearly, productivity was not a priority.
Today's productivity wasn't a priority for the author, but tomorrow's productivity is the goal.
edit: A proverb: If you want to go fast, go alone. If you want to go far, go together.
Re: First Timers Only
#18As a bit of a nitpick, I find it slightly ironic that this article uses TDD and PR as unexplained abbreviations.
Re: First Timers Only
#19As a bit of a nitpick, I find it slightly ironic that this article uses TDD and PR as unexplained abbreviations.
TDD is acceptable as it is the top search result for TDD. PR on the other hand ...
Acronyms and abbreviations with well defined / well known alternative meanings really bug me.
Actually Acronyms and abbreviations bug me full stop.
Re: First Timers Only
#20As a bit of a nitpick, I find it slightly ironic that this article uses TDD and PR as unexplained abbreviations.
TDD is acceptable as it is the top search result for TDD. PR on the other hand ... Acronyms and abbreviations with well defined / well known alternative meanings really bug me. Actually Acronyms and abbreviations bug me full stop.
Well, I googled both, which kinda bugs the flow of reading the article. Abbreviations bug me too.