Should we provide installation support?

[gravitystorm]

Currently we don't provide any support for installation problems (e.g. #1688 #1559 among others).

I think we should try to support basic installation problems. Sometimes these will be new or potential developers, and if they can't get the test suite passing it seems less likely that they'll submit a pull request. Other times they have no immediate intention of making a PR, but the more people using the codebase for their own purposes, the more likely they are to contribute changes back to us in future.

It's worth being clear that I only mean basic installation support, namely a) getting the tests to pass and b) getting iD and potlatch2 set up. I would specifically exclude any support for configuring postgresql, configuring alternative tiles and so on. What does everyone else think?

If we decide that we prefer to continue as-is, then I would make some further suggestions. Currently people ask here for support and then are told they are in the wrong place, but there's nothing available up-front to guide them. We can add a warning about there being no support to CONTRIBUTING.md or create an issue template noting that. And we should have a standard list of other places to ask, rather than leaving new users to figure out whether help.osm.org, mailing lists, irc etc is the right place. There are also problems with these channels that each one of them has fewer people available to help than could be found here, so we should indicate which channels have the highest likelihood of actually getting support.

[simonpoole]

IMHO the rails port is by far the easiest to setup with the best documented installation piece of software that we currently have in OSM as long as people stay on the recommended platform. If people do run in to issues they can ask on help.openstreetmap.org which is likely more suitable for "support" than the repo.

[tomhughes]

My problem is that I don't see how we can - if it's reasonably easy to see what the problem is likely to be then I will normally say when I close the bug but otherwise the only way I'm going to be able to help is to sit in front of their computer and start debugging which isn't really practical ;-)

I suspect the problem is that all too often people who are "users" and don't really have the necessary skills or experience are, for whatever reason, trying to set it up.

[tomhughes]

To take the example of #1688 for that assertion to fire basically means that the server couldn't find the way that the test requested, which means that the database somehow doesn't contain the right data, which means we need to start investigating what data is in the test database and why it didn't get added correctly during the test setup.

None of that is something you can sensibly talk somebody through doing on a bug ticket, especially if they're not used to the postgres console, SQL, the rails command line, etc which are the tools you would need to use for that investigation.

[zerebubuth]

Another approach might be to tag such issues as support-wanted (or better name) rather than close, so that they can be picked up by whichever people are interested in helping with support.

It seems to me that if we can get to the root of some of these issues, then they might lead to additional tests that could yield more meaningful error messages. I agree with @gravitystorm; the harder it is to get a working installation, the harder it is to contribute. I also understand that support shouldn't fall entirely on @tomhughes's shoulders - we need some way of marking these as needing triage from someone else.

[tomhughes]

Well if we had people queueing up to deal with such issues then sure but I fear it would just people false hope and that those issues would languish unanswered for evermore.

We could certainly do with defining a sensible set of labels for our issues though, and then deleting all the existing ones and doing some triage to label things properly.

[zerebubuth]

Well if we had people queueing up to deal with such issues then sure

If @gravitystorm and I are willing to give it a go, shall we do a trial run for a few months to see if it's sustainable?

I fear it would just people false hope and that those issues would languish unanswered for evermore.

Yes, I agree we shouldn't let these issues (or any issues) remain unanswered indefinitely. Perhaps if we run a trial and see what the average response time is? It might be helpful to categorise things (such as support-wanted) so that it's clear what the next (or first) step should be, and who can do it. And I'm sure there must be Github-based tools for doing issue triage, perhaps we could look into them also.

[mmd-osm]

To take the example of #1688 for that assertion to fire basically means that the server couldn't find the way that the test requested, which means that the database somehow doesn't contain the right data, which means we need to start investigating what data is in the test database and why it didn't get added correctly during the test setup.

That's just a silly timezone issue, with actual requirements being undocumented AFAIK.

Please add some comment in INSTALL.md that the server is supposed to run in UTC+0 timezone. Or maybe fix the testcase?

[tomhughes]

@mmd-osm well that's just a bug in the tests that should be fixed.

[gravitystorm]

Thanks to everyone for chipping in. I'd like to take up @zerebubuth's idea and run a trial for a few months. Let's tag any installation support requests with a 'support' label. We'll only provide support for basic setup ( namely a) getting the tests to pass and b) getting iD and potlatch2 set up).

We'll make sure that none of the support issues stay open for more than a fortnight. Nobody needs to feel obliged to provide support if they don't want to!

If it's successful (as determined by a future discussion) then we can formalise it in the documentation somewhere. If it's not successful then we can stop doing it.