<div class="gmail_quote">On 9 August 2010 09:09, Christoph Derndorfer <span dir="ltr">&lt;<a href="mailto:christoph.derndorfer@gmail.com">christoph.derndorfer@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney <span dir="ltr">&lt;<a href="mailto:ed@laptop.org" target="_blank">ed@laptop.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">


Instructions:<br>
<br>
1. Report bugs at <a href="http://dev.laptop.org/newticket" target="_blank">http://dev.laptop.org/newticket</a> - if necessary, register first at <a href="http://dev.laptop.org/register" target="_blank">http://dev.laptop.org/register</a> (as mavrothal kindly points out)<br>



2. If you have interesting experiences or user information to contribute, please do so at <a href="http://wiki.laptop.org" target="_blank">http://wiki.laptop.org</a><br>
3. If you&#39;re unwilling to perform steps 1 and/or 2 as appropriate, please don&#39;t expect the bug to be fixed, or for anyone else to even know about it.<br></blockquote><div><br>I know I&#39;m repeating myself here but I find the attitude expressed in these instructions and particularly point 3 troublesome and a continued source of frustration for me as well as other people I&#39;ve talked to. Even more so I think it&#39;s a very clear symptom of the much-discussed disconnect between developers and end-users in the OLPC and Sugar Labs context.<br>


<br>The core here is that software developers seem very reluctant to step out of their own comfort zone when it comes to processes and tools (a.k.a. point 3 a.k.a. &quot;my way or the highway&quot;) yet consistently expect teachers and other XO and Sugar users to do exactly that.<br>
</div></div></blockquote><div><br></div><div>I&#39;m not sure of the wider context here, but in general I think it&#39;s entirely appropriate to expect that people asking for help do so via the correct channels. It&#39;s also appropriate for OLPC &amp; Sugar to set realistic expectations. Placing the burden on the user may be the only way to understand what&#39;s going wrong with the software. That said, the OLPC/Sugar communities should be very good at guiding new contributors to those channels.</div>
<div><br></div><div>Perhaps OLPC/Sugar could create a super simple web form for problem submissions. They would then be triaged (by support gang?) and sent to the correct ticker. That way, new contributions only have a single channel for everything.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>This leads to the current situation in which crucial information and feedback from these users does not make it back to developers and the broader community. Therefore rather than working on things that users need or need to work reliably (e.g. the Journal) resources are spent elsewhere.<br>
</div></div></blockquote><div><br></div><div>This is not the only reasons why the development of pieces of Sugar moves very slowly.</div><div><br></div><div>The datastore is a complex piece of software engineering. I have no idea how it works and don&#39;t think I&#39;ll ever able to understand it without someone next to me explaining its operation. The real problem for me, even if I wanted to help with the Journal, is that there is nearly no code documentation through Sugar&#39;s core. I find it very difficult to justify spending a few hours learning how a module operates when I want to fix a bug. Yet, this is the situation I face every time.</div>
<div><br></div><div>An associated problem for me is that I don&#39;t know if my code will break things. AFAIK , there are no unit tests in Sugar&#39;s code base. Sugar is actually quite hard to test. Secondly, many of the functions &amp; methods are not designed with (unit) testing in mind, meaning it&#39;s hard to retrospectively create tests for methods. Testing side effects is annoying.</div>
<div><br></div><div>Even if unit testing was integrated into Sugar&#39;s development, it&#39;s really tough to set up development &amp; test environments. sugar-jhbuild has never built correctly for me.  Looking through compiler errors trying to identify what&#39;s wrong makes me feel like an idiot. </div>
<div><br></div><div>The reason I don&#39;t look into the hard problems is not that I don&#39;t know they exist. It&#39;s that they&#39;re hard to even start looking into. </div><div><br></div><div>Tim</div></div>