benilov

It's possible to start agile projects without requirements but with loads of user research and prototyping instead.

DbFit (http://dbfit.github.io/dbfit/) provides a more heavy-weight, but much more scalable alternative to raw SQL for testing CTEs.

There is monopolistic/market manipulating behaviour going on - it's basically an oligopoly, and the barrier to entry into the mobile telecoms market (ie building your network) is only growing.

The UK is adopting a similar approach: http://digital.cabinetoffice.gov.uk/2013/01/17/identity-beyo...

Well ok, the GOV.UK is the 80+% solution for publishing; transactions is another matter, although hopefully when the Digital by Default Service Standard starts kicking in (specifically the open source provision: https://www.gov.uk/service-manual/digital-by-default#criteri...) then a lot of code around transactions should start appearing.

Well, the GOV.UK code (https://www.github.com/alphagov) is your 80% (or more likely higher) solution. It's based around many micro-services that integrate over HTTP, so it's extremely extensible.

However, even with the software being perfect, you still have very high barriers of entry to overcome: 1) the local authority is likely to be locked into a 5- or 10-year contract with its current supplier 2) the choice of supplier is rarely (if ever) based on technical excellence/licensing strategy. Usually the people commissioning the IT don't tend to have a very deep understanding of technology, licensing, etc

Grassroots sounds nice, but the hard work isn't writing the code - it's convincing those within government that user-centered services and open source are the way to go. I believe that this can only be achieved given a strong mandate, from within government itself.

What's a 'tittle'?

> Holding someone else to your own arbitrary standards of acceptability is exactly what I'm referring to when I say these sort of complaints usually ignore the possibility that someone else's life is different than one's own.

I agree with the spirit with what you're saying, this is indeed all opinion.

I see it like this; if you're walking along and say "hi" to your neighbour, he doesn't have to say "hi" back, but it's nice, 'sall :)

> I even considered not submitting this comment, for fear of anyone misunderstanding or taking this the wrong way, and the inevitable "open source is a responsibility" responses.

I'm glad that you did, thank you for taking the time to respond.

> The thing is, you're actually implying more than you're saying. What you really mean is, "You could always have the courtesy to acknowledge the bug or PR I’ve submitted as soon as I submit it."

While I've definitely been guilty of impatience in the past, now I try to measure the response against some kind of "OSS time", which is a lot more forgiving. I appreciate that people are likely to be busy, or away with their kids in Hawaii for the past two weeks.

Having said that...

> The maintainer may just be really busy this month. Or maybe they've been really busy for 6 months.

I think one month is a bit long to have to wait for a response. 6 months: most certainly too long. In those cases, the "pull request hack" [1] may be the way forward.

[1] http://felixge.de/2013/03/11/the-pull-request-hack.html

I've taken over the maintenance for a project a few months ago and have tried to stick as closely as I can to what I wrote about.

I've also used the pull request hack, it's a really good idea!

I definitely didn't want to imply that "you should merge any ol' crap".

I was commenting more on how maintainers communicate (or don't communicate) their feedback. I see no problem with saying "please add tests", or "don't break the existing tests". Some of that can be managed automatically with the likes of Travis, other stuff like "I only accept code that's coffeescript" can be mentioned in the CONTRIBUTING file, and your reply to the PR can just point to the rules. I don't have a problem with any of those cases; it's stony silence that gets me.