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

David Farning dfarning at sugarlabs.org
Sat Jun 6 19:30:33 EDT 2009


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.

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.

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


More information about the IAEP mailing list