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?
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)
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.
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)
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.
>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.
There's also a Chrome extension to export a board to a spreadsheet: https://chrome.google.com/webstore/detail/export-for-trello/....