jglovier

Looks like you can export any board as JSON by going to Board Menu > More > Print and Export (from http://help.trello.com/article/747-exporting-data-from-trell...).

There's also a Chrome extension to export a board to a spreadsheet: https://chrome.google.com/webstore/detail/export-for-trello/....

Great feedback. Thanks for sharing.

Also, FTR there is no intent to boast here, merely sharing an idea and trying to elicit discussion about a problem which I admittedly do not fully understand.

I had hoped that starting with an admission of plausible fallacy would deter such judgements, but I guess you never can underestimate the power of HN to bring out the moral superiority of others.

Git has a very scalable solution for a large volume of changes and establishing change set as current (via SHA). What is different about the DNS registry than any other codebase that Git could not handle?

Thanks! The demo has a relatively small data set, but keeping it fast as production data grows is one of the challenges we're working on right now.

Thanks for the heads up!!

HospitalRun (http://hospitalrun.io/)

HospitalRun is an offline first, Ember based, Hospital Information System for charitable hospitals in developing countries.

> What do you hope to build this month? We are focused on ongoing work toward reaching the 1.0. For a list of outstanding issues, see this GitHub milestone on the frontend app: https://github.com/hospitalrun/hospitalrun-frontend/mileston...

We're in need of folks with the following skills: Ember JS experience for general app development; internationalization and localization; New Relic instrumentation experience; automating deployments from GitHub; HL7 experience; product and UI design for lots of CSS and UI cleanup (https://github.com/hospitalRun/design); design systems experience for working on a styleguide and pattern library; docs writing for app documentation; web and marketing design for the hospitalrun.io site (http://github.com/hospitalRun/hospitalrun.github.io)

To contribute, check out our CONTRIBUTING.md file on GitHub (https://github.com/hospitalrun/hospitalrun-frontend/blob/mas...) and join our Slack team.

HospitalRun is open source under the GNU general public license.

Very unlikely. We hope that Projects will be the best place for people to coordinate work on a GitHub repository, but that doesn't really limit Trello's value much. They'll continue to offer lots of value as a great way to coordinate work for many contexts outside GitHub repositories.

This all applies to github.com the website, and will ship separately in upcoming Enterprise releases per our normal Enterprise release schedule.

Great idea. Thanks!

>projects. replaces trello, waffle.io, zenhub and many other similar services.

This is really not about replacing those services, it's more about building a better foundation for integrators like Waffle and ZenHub to build on.

Yes. Several of the CURE International (https://cure.org/) charitable hospitals (including a few in sub-saharan Africa) are already running it.

HospitalRun (http://hospitalrun.io/)

HospitalRun is an offline first, Ember based, Hospital Information System for charitable hospitals in developing countries.

> What do you hope to build this month? We are focused on ongoing work toward reaching the 1.0. For a list of outstanding issues, see this GitHub milestone on the frontend app: https://github.com/HospitalRun/hospitalrun-frontend/mileston...

We're in need of folks with the following skills: Ember JS experience for general app development; internationalization and localization; New Relic instrumentation experience; automating deployments from GitHub; HL7 experience; product and UI design for lots of CSS and UI cleanup (https://github.com/hospitalRun/design); design systems experience for working on a styleguide and pattern library; docs writing for app documentation; web and marketing design for the hospitalrun.io site (http://github.com/hospitalRun/hospitalrun.github.io)

To contribute, check out our CONTRIBUTING.md file on GitHub (https://github.com/hospitalrun/hospitalrun-frontend/blob/mas...) and join our Slack team.

HospitalRun is open source under the GNU general public license.

NOTE: We are hosting a two day hackathon at GitHub HQ in San Francisco on September 23 & 24th. Apply here if you are interested to join us: https://docs.google.com/forms/d/e/1FAIpQLScY8IzsHNXuSnwJamdO...

Sorry to hear this change is frustrating for your team. If the new model doesn't work for you, can stay on the old structure. We're not automatically migrating anyone, so you can stay on the old plan. If we ever do decide to phase out the legacy structure completely, you'll still have 12 months from that point before you have to move over. (We've updated the blog post to reflect that clarification, too)

Nope. We'd been working on our response ever since Dear GitHub was published. It just took a little time because we wanted to think long and hard about our response - beyond just the words we used to respond – and actually consider how we are interacting with the community, and where we can make demonstrable improvements. It is just coincidence that the ESLint thread happened this week, and our response came out today.

Not saying your conclusion is necessarily accurate (though I don't disagree), but anecdotally my own experience was similar. I interviewed for a design position with Automattic 3 or 4 years ago and made it to the contract stage, and ultimately had to decline because the $25 contract gig was just so off-putting. Not to mention the super-intimidating terms and intellectual property agreement that came with the trial gig.

Yeah, that's a fair criticism. Still a lot of work left to do on that effort.

>Mobile first is a basic requirement in developing countries.

When you say "mobile first is a basic requirement" you're thinking about a specific context of software intended for the general population of people in those countries.

However, with projects like HospitalRun, the general population is not the audience, Hospital staff and administrators are, and even in developing countries they still primarily use laptops and tablets at the Hospital.

>What surprised me most is that the UI does not seem to be mobile responsive, and does not work well on smartphones. I would have guessed that in developing countries mobile use would be hugely important?

The UI is still a massive WIP, but I am working on making it fully responsive down to tablet size. Our goal is to accommodate viewports down to tablet because in hospitals where the software will be run (and is already running in a few CURE hospitals) medical and administrative staff will be using it from laptops and tablets.

Viewports lower than 600px are not currently a consideration, however, as we don't currently have a legitimate use case for the software on phones.

Responsive work is on the roadmap and coming soon. However, the current intent is for the project to be fully usable on tablets, but not necessarily on phones. The hospital staff in our use cases will all be using the software from either a laptop or tablet.

Because design patterns, basically. I designed this page and have never seen codio.com before so I'd say it's just a reflection of common design paradigms for marketing pages.

Will the ycombinator.com banner ad finally be replaced with an HN symbol that links directly to the index? :-p

Also, a while back I made a little Hacker News logo concept. (https://news.ycombinator.com/item?id=4731140) If you're thinking responsive redesign work, just hollar. ;-)