Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2018-06-19 Thread James Cameron
On Sun, Aug 08, 2010 at 06:02:58PM -0500, Mikus Grinbergs wrote:
> In my opinion, developers of a product ought to be interested in
> learning about shortcomings perceived in that product by users.

Certainly interested.  But not willing to prance about looking for
problems when some very neatly defined problems are already logged
waiting for fixing.  Also not willing to go and interview every user;
this does not scale.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2018-06-19 Thread Tim McNamara
On 9 August 2010 11:02, Mikus Grinbergs  wrote:

> > in general I think it's entirely appropriate to expect
> > that people asking for help do so via the correct channels
>
> I believe that "asking for help" should not be the only supported
> motivation for contacting developers.
>

Not at all, but it's a significant one.


> In my opinion, developers of a product ought to be interested in
> learning about shortcomings perceived in that product by users.
>

Looking into the original case - we had people on a public forum[1]
expressing frustration that yum fails to work among other things.

I hope this doesn't come across the wrong way - but are G1G1 laptop owners
considered the target market? If a user installs Skype on an XO-1, only to
find that it kills the sound, then I think it's okay for OLPC to abstain
from taking responsibility. Fora such as olpcnews.com attracts very
motivated individuals who experiment. That's great, but once they leave the
realm of the product, peer support takes over.

In practice, it seems that genuine issues from these comments do find their
way to the surface, albeit in roundabout way. OLPC & Sugar Labs are now
aware that yum doesn't seem to work.


> Are "the correct channels" any different than blinders ?
>
> mikus
>

I'm not sure I understand what you mean by blinders. Do you mean blinkers?
[edit: Wikipedia says yes]

In many ways that's true, but the metaphor doesn't transfer exactly. Each
channel (Trac, wiki, mailing list, local user group) deals with a different
type of problem. They e  simply to block unintended knowledge. However, it's
likely that some people will be put off - which means that they become
fairly blunt filters.

Where the metaphor does fit is using a system to create focus. It's
important to recognise that OLPC & Sugar Labs have very constrained
development resources. Therefore, systems that reduce load on developers
increases time on development.

Tim

[1] http://www.olpcnews.com/forum/index.php?topic=4867
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2010-08-09 Thread Martin Langhoff
On Mon, Aug 9, 2010 at 12:46 AM, Neil Graham l...@screamingduck.com wrote:
 Perhaps what is needed is a KDE to olpc's gnome in order to lift the
 game of both.

We do a ton of things in relationship with our 'community' (or perhaps
our different 'communities'). For example, we engage in this thread
with you.

As with most projects, it's up to you to help, participate positively, or not.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2010-08-09 Thread Martin Langhoff
On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer
christoph.derndor...@gmail.com wrote:
 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.

Not really. There is a lot of glue people that can help bridge the
gap between teachers / nontechie deployers and developers.

I am one of them. I am sure you are one too. Deployments need to have
a (small) technical team that also fits this role.

Such bridge people are needed to boil down end users' reports into
something that looks like a usable bugreport.

Being a bridge person, a translator between the two worlds is
sometimes frustrating (can't these people talk to eachother
directly?) but the barriers are real. Rejoice in being able to do it
(at least I do).

And sure -- we need to get more hands (ears/eyes) into this role. It
is essential social glue.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2010-08-09 Thread Martin Langhoff
On Mon, Aug 9, 2010 at 4:17 PM, Neil Graham l...@screamingduck.com wrote:
 And yet, Developers on this list [olpc-devel] have complained when
 people have done that, because this is not the place for it.  Of course,
 there isn't any other place for it.

Don't take every complaint seriously ;-)

 I really don't want to get combative here.   This may come off as You
 guys all suck but what I want is for things to improve.

We all do. But we are damned swamped with things, and we do a ton with
the community. You might not see it right now but we do.

...

 but a friend of mine who attended PyCon came back and said he was amazed
 with just how many people he met who felt burned by OLPC.

Having been an external volunteer first, I can attest that it is hard
to contribute to OLPC. A lot of that is because OLPC has chosen to do
hard things. OLPC requires a lot of time investment. All the other
open proects I know that have similarly hard goals are known to burn
people out.

Don't know if there's a fix for that overall problem :-/

Are there specific issues you are hoping for support with, what are they?

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2010-08-08 Thread Christoph Derndorfer
On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@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.

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.

But that's all just basically a recap of the IRC discussion on #sugar
earlier in the week and many hours of discussions with Bernie and others in
Paraguay over the past 2 weeks.

Now at this point I'd normally stop but seeing that I've been increasingly
frustrated about this and have subsequently complained a lot about it I'll
get off my ass and try something to improve the situation a bit.

Over the next 6 weeks (can't make promises beyond that since university and
my job will then start again) I plan to:

(a) Contact people at deployments asking for their input as to whether they
see a need for a closer feedback-loop between deployments and development
(because maybe I'm seeing issues when in fact there are none). For this I'll
rely on the people I know plus the contacts listed at
http://wiki.sugarlabs.org/go/Deployment_Team/Places for starters but please
send along any suggestions on who else to get in touch with.
(b) If it turns out to be a need then ask for input as to how these needs
could be best communicated so we can figure out an appropriate process.
(c) Try to schedule some sort of meeting with several deployments, possibly
as a continuation of the Sugar Labs deployment meetings on IRC or via a
Skype call or something. In my mind the focus here should be input into what
deployments would like to see development focus (more) on.
(d) Compile all the resulting input into a readable format and distribute it
where seen appropriate.

Things I most likely won't do as part of these efforts include (but aren't
necessarily limited to) setting up new mailman-lists, creating a new
category on w.l.o or w.s.o and following wiki talk-pages, asking for a trac
instance, learning to use git send-email, switching to Mutt, booting into
Ubuntu instead of Windows 7, etc. ;-)

As always, let me know what you think.

Cheers,
Christoph

-- 
Christoph Derndorfer
co-editor, olpcnews
url: www.olpcnews.com
e-mail: christ...@olpcnews.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2010-08-08 Thread Walter Bender
On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer
christoph.derndor...@gmail.com wrote:
 On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@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.

What was the context for Ed's post? And who was his intended audience?
Certainly not the end user. In .uy we have discussed various
mechanisms for bug reporting by children and teachers. The current
plan of record is to use some sort of web form where the bugs are
aggregated by a technical liaison. The liaison might then be trained
in filing the occasional ticket on Trac. As with any software (and
hardware) project, different people in the support hierarchy utilize
different tools.

-walter

 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.

 But that's all just basically a recap of the IRC discussion on #sugar
 earlier in the week and many hours of discussions with Bernie and others in
 Paraguay over the past 2 weeks.

 Now at this point I'd normally stop but seeing that I've been increasingly
 frustrated about this and have subsequently complained a lot about it I'll
 get off my ass and try something to improve the situation a bit.

 Over the next 6 weeks (can't make promises beyond that since university and
 my job will then start again) I plan to:

 (a) Contact people at deployments asking for their input as to whether they
 see a need for a closer feedback-loop between deployments and development
 (because maybe I'm seeing issues when in fact there are none). For this I'll
 rely on the people I know plus the contacts listed at
 http://wiki.sugarlabs.org/go/Deployment_Team/Places for starters but please
 send along any suggestions on who else to get in touch with.
 (b) If it turns out to be a need then ask for input as to how these needs
 could be best communicated so we can figure out an appropriate process.
 (c) Try to schedule some sort of meeting with several deployments, possibly
 as a continuation of the Sugar Labs deployment meetings on IRC or via a
 Skype call or something. In my mind the focus here should be input into what
 deployments would like to see development focus (more) on.
 (d) Compile all the resulting input into a readable format and distribute it
 where seen appropriate.

 Things I most likely won't do as part of these efforts include (but aren't
 necessarily limited to) setting up new mailman-lists, creating a new
 category on w.l.o or w.s.o and following wiki talk-pages, asking for a trac
 instance, learning to use git send-email, switching to Mutt, booting into
 Ubuntu instead of Windows 7, etc. ;-)

 As always, let me know what you think.

 Cheers,
 Christoph

 --
 Christoph Derndorfer
 co-editor, olpcnews
 url: www.olpcnews.com
 e-mail: christ...@olpcnews.com

 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel





-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2010-08-08 Thread Tim McNamara
On 9 August 2010 09:09, Christoph Derndorfer christoph.derndor...@gmail.com
 wrote:

 On Sun, Aug 8, 2010 at 3:56 PM, Ed McNierney e...@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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2010-08-08 Thread Mikus Grinbergs
 in general I think it's entirely appropriate to expect
 that people asking for help do so via the correct channels

I believe that asking for help should not be the only supported
motivation for contacting developers.

In my opinion, developers of a product ought to be interested in
learning about shortcomings perceived in that product by users.

Are the correct channels any different than blinders ?

mikus

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2010-08-08 Thread Tim McNamara
On 9 August 2010 11:02, Mikus Grinbergs mi...@bga.com wrote:

  in general I think it's entirely appropriate to expect
  that people asking for help do so via the correct channels

 I believe that asking for help should not be the only supported
 motivation for contacting developers.


Not at all, but it's a significant one.


 In my opinion, developers of a product ought to be interested in
 learning about shortcomings perceived in that product by users.


Looking into the original case - we had people on a public forum[1]
expressing frustration that yum fails to work among other things.

I hope this doesn't come across the wrong way - but are G1G1 laptop owners
considered the target market? If a user installs Skype on an XO-1, only to
find that it kills the sound, then I think it's okay for OLPC to abstain
from taking responsibility. Fora such as olpcnews.com attracts very
motivated individuals who experiment. That's great, but once they leave the
realm of the product, peer support takes over.

In practice, it seems that genuine issues from these comments do find their
way to the surface, albeit in roundabout way. OLPC  Sugar Labs are now
aware that yum doesn't seem to work.


 Are the correct channels any different than blinders ?

 mikus


I'm not sure I understand what you mean by blinders. Do you mean blinkers?
[edit: Wikipedia says yes]

In many ways that's true, but the metaphor doesn't transfer exactly. Each
channel (Trac, wiki, mailing list, local user group) deals with a different
type of problem. They e  simply to block unintended knowledge. However, it's
likely that some people will be put off - which means that they become
fairly blunt filters.

Where the metaphor does fit is using a system to create focus. It's
important to recognise that OLPC  Sugar Labs have very constrained
development resources. Therefore, systems that reduce load on developers
increases time on development.

Tim

[1] http://www.olpcnews.com/forum/index.php?topic=4867
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable

2010-08-08 Thread James Cameron
On Sun, Aug 08, 2010 at 06:02:58PM -0500, Mikus Grinbergs wrote:
 In my opinion, developers of a product ought to be interested in
 learning about shortcomings perceived in that product by users.

Certainly interested.  But not willing to prance about looking for
problems when some very neatly defined problems are already logged
waiting for fixing.  Also not willing to go and interview every user;
this does not scale.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel