[Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)

[Tim McNamara]

On 9 August 2010 09:09, Christoph Derndorfer <christoph.derndorfer at gmail.com
> wrote:

> On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney <ed at laptop.org> wrote:
>
>> Instructions:
>>
>> 1. Report bugs at http://dev.laptop.org/newticket - if necessary,
>> register first at http://dev.laptop.org/register (as mavrothal kindly
>> points out)
>> 2. If you have interesting experiences or user information to contribute,
>> please do so at http://wiki.laptop.org
>> 3. If you're unwilling to perform steps 1 and/or 2 as appropriate, please
>> don't expect the bug to be fixed, or for anyone else to even know about it.
>>
>
> I know I'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've talked to. Even more so I
> think it's a very clear symptom of the much-discussed disconnect between
> developers and end-users in the OLPC and Sugar Labs context.
>
> 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. "my way or the highway") yet consistently expect teachers and other
> XO and Sugar users to do exactly that.
>

I'm not sure of the wider context here, but in general I think it's entirely
appropriate to expect that people asking for help do so via the correct
channels. It's also appropriate for OLPC & Sugar to set realistic
expectations. Placing the burden on the user may be the only way to
understand what's going wrong with the software. That said, the
OLPC/Sugar communities should be very good at guiding new contributors to
those channels.

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.


> 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.
>

This is not the only reasons why the development of pieces of Sugar moves
very slowly.

The datastore is a complex piece of software engineering. I have no idea how
it works and don't think I'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'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.

An associated problem for me is that I don't know if my code will break
things. AFAIK , there are no unit tests in Sugar's code base. Sugar is
actually quite hard to test. Secondly, many of the functions & methods are
not designed with (unit) testing in mind, meaning it's hard
to retrospectively create tests for methods. Testing side effects is
annoying.

Even if unit testing was integrated into Sugar's development, it's really
tough to set up development & test environments. sugar-jhbuild has never
built correctly for me.  Looking through compiler errors trying to identify
what's wrong makes me feel like an idiot.

The reason I don't look into the hard problems is not that I don't know they
exist. It's that they're hard to even start looking into.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100809/c4dd7210/attachment.html>