[IAEP] Champions Was: future of the Sugar user experience

[David Farning]

Yes, that make a lot of sense.

I think the biggest piece for you personally is to become comfortable
doing the asking:)  It really doesn't take too long to get a feel for
who 'gets' the Sugar culture.

david


On Mon, Jun 8, 2009 at 4:24 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
> On Sun, Jun 7, 2009 at 01:30, David Farning<dfarning at sugarlabs.org> wrote:
>> On Fri, Jun 5, 2009 at 5:17 AM, Tomeu Vizoso<tomeu at sugarlabs.org> wrote:
>>> On Wed, Jun 3, 2009 at 19:23, C. Scott Ananian<cscott at cscott.net> wrote:
>>>> Seems reasonable: "Design review" in addition to "code review" for new
>>>> patches.  Like code review, make a reasonable effort to have an
>>>> experienced designer or someone who knows the design for the
>>>> particular area, but if the patch stalls, any designer or developer's
>>>> review will do.  If you care about coherent design, spent time doing
>>>> design review!
>>>>
>>>> I'd just extend this to allow "initial design review" even absent a
>>>> patch, so that people can get initial review before they sink too much
>>>> time in an implementation.  If you're confident of the basic
>>>> direction, you can skip this step (your work still gets reviewed
>>>> before the patch is committed upstream), but if you're uncertain you
>>>> might want to post screenshots or sketches or a text description of
>>>> what you want to do and have someone say, "sure, that seems mostly
>>>> reasonable" before you start implementation.  The initial review
>>>> doesn't have to be nitpicky, because there are inevitably going to be
>>>> things learned during the actual implementation, but it should serve
>>>> to keep people from wasting too much time on ideas which are far from
>>>> the desired design direction.
>>>
>>> I agree with both of Jameson and Scott, those are very interesting
>>> point of view(s) and see the value of that proposal. To complement
>>> that, we discussed at Paris the convenience of each reasonable-sized
>>> feature to have a champion that makes sure that the development of
>>> this feature keeps moving forward with the participation of all the
>>> needed people.
>>>
>>> As an example, let's say that someone named Greg Smith realizes the
>>> importance of having good tools in Sugar for discovering people to
>>> communicate with. What we currently have doesn't scale for more than a
>>> couple of dozen of people. That person doesn't need to be an engineer
>>> or an expert in HCI, but will need to have excellent communication
>>> skills, enthusiasm and the ability to transmit that enthusiasm and
>>> make other people want to work together.
>>>
>>> In this ideal scenario, the ball would start rolling by asking people
>>> already using Sugar about their opinions on that matter. Would ask to
>>> these and to other people for improvement proposals, will make a list
>>> of people that have shown interest on this issue and would
>>> periodically ping them so they feel in the loop, would see which
>>> engineers would be interested in the implementation, etc
>>>
>>> Other people that I think would make excellent feature champions are
>>> Karlie Robinson, Greg DeKoenigsberg (currently doing that for the 4th
>>> grade math project), Walter Bender (doing that for Turtle Art and
>>> other stuff), Tony Forster, Caroline Meeks (SoaS), Mel Chua, etc.
>>>
>>> Would make sense to formalize the role of feature champion and write
>>> down some guidelines to make these people even more effective?
>>>
>>> Regards,
>>>
>>> Tomeu
>>>
>> You are exactly correct that the important piece of this puzzle is the
>> 'champion.'
>>
>> As sugar Labs grows, it is getting harder and harder for everyone to
>> keep on top of everything.  Less than a year ago it seem like the same
>> six people were attending every meeting, responding to every thread,
>> and working on every aspect of the project.
>
> Right, at the end I think is all about scaling. It's also about having
> people doing what they do best, but is when we fail to scale when
> people overcommit and end up doing things that other people would do
> much better.
>
>> A huge 'wow for me was Josh's new face for the activity portal.  I
>> have lost track of the activity portal development since alsroot
>> became it's champion.
>>
>> I would be hesitant to make the role of champion too formal.  The
>> roles, responsibilities, and even definition of champion change with
>> every feature and project.
>
> Agreed, what I really meant to ask is how we are going to make easier
> for people to realize that they are all able to take ownership of a
> missing piece in Sugar and push it forward until the benefits arrive
> to children. May not be a need to use a formal position for this, but
> I guess we should talk more often about it and give this role more
> visibility?
>
> Regards,
>
> Tomeu
>
>> Instead, champion is an earned position of trust.  A Champion is not
>> the most vocal contributor, the best developer, or even the stake
>> holder with the greatest interest.   A champion is someone who can
>> make good things happen.
>>
>> At meta level the entire purpose of Sugar Labs is attract, engage, and
>> empower champions.
>>
>> Champions produce good results.
>> Champions scale.
>>
>> david
>>
>