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

Sun Aug 8 17:52:02 EDT 2010

Christoph -

(you're talking about OLPC and SugarLabs, of course, but I'm only responding from an OLPC perspective)

There's a difference between "approachable" and "findable".  Every member of the OLPC technical staff is on the devel at laptop.org mailing list, and we all see bugs filed in trac.  I expect all of us to pay attention to both those channels.  I think we're all pretty approachable, and we try to be as findable as possible.  We do not all read OLPCNews, nor do I expect OLPC's technical staff to cruise OLPCNews' forums in search of bug reports.  I do not count "proactively search for places people mention the word OLPC online" as being "findable".

I answered a specific question about how "the olpcnews.com/forum/ kind of people" should report problems.  It is in fact the same information mavrothal pointed out in the forum.  Maybe that's not a good answer, but other than mavrothal and I, I haven't seen another answer to that question.

As to your main topics, I would *love* it if we could all agree on a standard nomenclature for what we call "deployments", because they're not all the same.  OLPC has, I think, I pretty darn good feedback loop with the entities we consider "deployments".  But a lot of people use that term to mean a lot of different things - every time more than two XO laptops are in one place (or perhaps when there are two SoaS machines), it's a "deployment" to someone.  There's nothing wrong with that, but when you then say there's a problem with getting input from deployments, it's hard to understand exactly what you mean.  Particularly with volunteer-led or -driven deployments, it can be hard for anyone at OLPC to know what's going on.  In your discussions with various teams, it would be great if you could emphasize the value of having a stable, findable, long-term technical contact that someone at OLPC knows about.  That's a big help to us in any situation.

More help is always welcome, although while you're doing all those things, please consider registering on trac and try filing one ticket.  It's really not hard, and if the problem at hand is an apparent software/hardware bug, that's the best way to communicate it.

	- Ed

P.S. I just saw Walter's reply, and things in Uruguay do indeed seem to work well.  Those sorts of processes are what's needed in large deployments.

On Aug 8, 2010, at 5:09 PM, Christoph Derndorfer 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.
> 
> 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: christoph at olpcnews.com
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel

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