Hacker News Reader

Comment by shurcooL | Hacker News Reader

I just want to say this kind of future really gets me excited! I love it when a product/service I use is open enough that if I ever spot a typo, it's easier and faster for me to fix it in the source and submit a PR (and enjoy a more perfect product) than to ignore it.

That's the kind of future I want to live in. I'm very thankful to Balanced, Gittip for being some of the ones paving the way there.

View on HN

Here's a few counter-examples of easily fixable bugs in closed systems that really bug me.

GitHub has a few tiny bugs that could probably be fixed with a few lines of code within a day (best case scenario), but they haven't for months now since I've reported these issues. http://shurcool.github.io/bettertogether/

The latest version of Chrome for iOS has a shadow not appearing properly when you open a new tab in the background. Once you switch to it, it's fine.

Chrome [1] for OS X has a small area around the close tab button where the hover animation occurs (button highlights red), yet clicking the mouse does nothing. You have to move the cursor a few pixels closer to the center before clicking will have an effect. This discrepancy between hover and clicking action is annoying because I often (several times per day) run into it. OS X dock has a similar issue.

I'm very picky when it comes to the smallest details... I'd rather fix them and move on than keep running into them every day.

[1] I know this one is open source, but because it's a huge project, I never got around to compile it, etc.

pull requests welcome and much appreciated ;-) https://github.com/balanced/balanced.github.com/issues https://github.com/balanced/balanced-dashboard/issues

you just reminded me of a mobile display issue on the blog: https://github.com/balanced/balanced.github.com/issues/32

The Chrome example brings up a good point: it's a lot easier to fix niggling details on small projects than big ones. We could probably stand to see some innovation in architecting open products to be easy to install only part of into a development environment. The GitHub editing interface helps here, though project culture is another barrier. I fixed a typo on AngularJS and started to discover a heavier project structure than I'm used to:

https://github.com/angular/angular.js/pull/2374

Maintaining a culture of innovation at scale is a challenge for both open and closed companies.

I absolutely agree. I think we need to try to innovate how large scale complex software can be written.

One of the approaches I'm currently investigating and have high hopes for composition, pure functions, and explicit two-way dependency tracking. I'm trying to put this to the test in my work. The idea is that I hope even huge software can be decomposed into smaller independent (meaning all the dependencies are explicit) chunks with pre- and post-conditions. So fixing many bugs could boil down to navigating to the code responsible and fixing it there. It's too early for me to say how it'll work in reality, but I will find out with time.

I have done this with blog posts by Balanced, actually. Especially with 'edit this file on GitHub,' it's so simple.

In my experience, the only nicer UI for fixing typos is Medium.

Here are some examples of where I was able to do just that. It's tiny things, but it feels great to make something better.

https://github.com/liveprogramming/2013/pull/1/files

https://github.com/liveprogramming/2013/pull/2/files

https://github.com/skx/bookmarks.public/pull/1/files

https://github.com/gittip/www.gittip.com/pull/625/files

https://github.com/mojombo/semver.org/pull/55/files

Much of the frontend for the blog was done by github.com/joonas (not a Balanced employee): https://github.com/balanced/balanced.github.com/pull/3

We're working on the same approach at FastCompany--we've already started loading all our Labs posts into github, and soon we'll allow readers to fork articles to correct them, argue with them, edit or create their own versions. Github obviously wasn't meant for dealing with rich text articles, so it's taking some hacking, but we agree that it's a positive experiment. --chris dannen, tech editor, fastcompany

"ever a spot" -> "ever spot"

<:)

HN comments should have pull requests.

They totally should. Everything should. There's no reason to make them not available.

#winning

Thanks! Fixed.

Reply on news.ycombinator.com