On 11/12/13 21:42, Robert Collins wrote: > On 12 December 2013 01:17, Jaromir Coufal <jcou...@redhat.com> wrote: >> On 2013/10/12 23:09, Robert Collins wrote:
[snip] >>> Thats speculation. We don't know if they will or will not because we >>> haven't given them a working system to test. >> >> Some part of that is speculation, some part of that is feedback from people >> who are doing deployments (of course its just very limited audience). >> Anyway, it is not just pure theory. > > Sure. Let be me more precise. There is a hypothesis that lack of > direct control will be a significant adoption blocker for a primary > group of users. I'm sorry for butting in, but I think I can see where your disagreement comes from and maybe explaining it will help resolving it. It's not a hypothesis, but a well documented and researched fact, that transparency has a huge impact on the ease of use of any information artifact. In particular, the easier you can see what is actually happening and how your actions affect the outcome, the faster you can learn to use it and the more efficient you are in using it and resolving any problems with it. It's no surprise that "closeness of mapping" and "hidden dependencies" are two important congnitive dimensions that are often measured when assesing the usability of an artifact. Humans simply find it nice when they can tell what is happening, even if theoretically they don't need that knowledge when everything works correctly. This doesn't come from any direct requirements of Tuskar itself, and I am sure that all the workarounds that Robert gave will work somehow in every real-world problem that arises. But the whole will not necessarily be easy or pleasant to learn and use. I am aware, that the requirment to be able to see what is happening is a fundamental problem, because it destroys one of the most important rules in system engineering -- separation of concerns. The parts in the upper layers should simply not care how the parts in the lower layers do their jobs, as long as they work properly. I know that it is a kind of a tradition in Open Source software to create software with the assumption, that it's enough for it to do its job, and if every use case can be somehow done, directly or indirectly, then it's good enough. We have a lot of working tools designed with this principle in mind, such as CSS, autotools or our favorite git. They do their job, and they do it well (except when they break horribly). But I think we can put a little bit more effort into also ensuring that the common use cases are not just doable, but also easy to implement and maintain. And that means that we will sometimes have a requirement that comes from how people think, and not from any particular technical need. I know that it sounds like speculation, or theory, but I think we need to tust in Jarda's experience with usability and his judgement about what works better -- unless of course we are willing to learn all that ourselves, which may take quite some time. What is the point of having an expert, if we know better, after all? -- Radomir Dopieralski _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev