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

[Caroline Meeks]

Hi Greg,

This was very helpful in letting me understand how your mind works.

I actually have a lot of these planning documents. I did many of them as
part of assignments for school classes.

Greg, you should now have access to:

   - Liquid Planner Gantt Chart
   - Balance Score Card -
   http://spreadsheets.google.com/pub?key=px5yPvIlUlLtsrYpZdVG_EQ&output=html
   - Implementation Plan (walk through of the Gantt and Score Card -
   http://docs.google.com/Doc?docid=dddknwgs_383cb494pc4&hl=en)

Now that I'm in the middle of implementation, these are all out of date and
I am quickly losing this forest view amongst all the Trees.

Perhaps you can help me track and help let me know where I'm slipping vs
plan.

Even more importantly, maybe you can keep track of how the plan turns into
reality and work towards creating generic versions of these plans that can
be reused by other deployments.

Thanks,
Caroline

Dear IAEP,

We are moving this conversation to the main list.  Note that all these
documents are out of date!  I don't have a way to make the Liquid Planner
public, but if you are planning a Sugar on a Stick implementation and you
need to look at it before we figure out the best way to create a replicable
set of planning tools, just ping me and I'll get you access.



On Fri, Jun 19, 2009 at 9:37 AM, Greg Smith <gregsmithpm at gmail.com> wrote:

> Hi Caroline,
>
> Maybe we should do this on one of the lists? Just copy it there when you
> are ready.
>
> Did you win the grant already?
>
> My work at OLPC was more focused on the technical architecture and project
> planning at the country level. Also, my corporate background makes me tend
> to over plan and structure. Just a note to set the right perspective on my
> comments.
>
> The focus is to get the computers online and working on the first day they
> get to class. The time cost of making things "work" is a kills the
> educational ROI if he teacher and/or kids spend too much time debugging or
> even learning how to use the machines.
>
> Main things I think you should have (may already be done):
> - A schedule.
> Includes things like when the computers will be available, when the testing
> of the target image is done, when the USB sticks will be loaded, etc. Start
> with the first day in school date and then work backwards. The key thing to
> identify is which image will you be using so you can lock down final test
> and install dates for that.
>
> - A network diagram and HW list
> Should include the in school network (e.g. LAN wired  or Wireless, BW,
> number of computers, make and model (possibly core OS too) of the
> computers). We ran in to lots of cases where they delivered 100s or 1Ks of
> XOs and then found out there was no network. or the network was too small or
> there were too many XOs in a school to Mesh and it crashed the whole network
> and XOs! Maybe you have a lot of Bandwidth so it wont be a problem but the
> meshing can still lock up even a robust network if there are too many
> computers. Judging from your thread on SoAS on Mac, I think you need a list
> of computers you will run on too. Those should be tested in advance. Also, I
> see mention of servers in your proposal. List those includng HW and
> operating system.
>  - A list of applications (or activities if you prefer).
> Hopefull kids will find a lot of things to do that we don't plan on but you
> should have a baseline set of things that you know work.
>
> - Lesson plans or other "end to end" things they can do
> Related to the applications list. Its important to have some things you can
> do which you know will go well. Meshing and collaboration is an example of
> something that people always thought would work but it only does in a
> limited and well defined set of cases. Get it down to a few detailed work
> flow examples (e.g. everyone boots up, everyone opens write, teacher shares,
> 10 kids join, they create a shared document, they save it, they post it to
> the server, they send out a URL to their parents, everyone cheers :-). Some
> safe ground that you know in advance will work well.
>
> - Servers, authentication and backup
> Write down what the server will be (HW, OS and SW) and what it needs to do
> (e.g. help with network/collaboration, authenication, hosts apps like web
> server or moodle, backup and restore files, firewall and NAT). If the server
> is backing up kids work, make sure you know how and can test that it backs
> up and more importantly restores. Is the server visible to the world or only
> in the school? How do you protect that? Does the server do filtering
> (blocking bad sites)? if not where do you do that? How do you control access
> to the server and network so only kids can get to the content (aka
> authentication).
>
> - Communication plan
> Define how the kids get support. Do they call you and you e-mail the list?
> Also, make a plan to upgrade as needed. How would you patch the code without
> losing their existing work if you have a critical fix that needs to go in?
> Who can visit the school to fix things as needed and when? Also, make a plan
> to communicate the success or challenges of the implementation. A weekly
> report would help but any consistent feedback from the school to the world
> should be in place. Similarly, new, known bugs and work arounds and new
> activities or successes should be communicated back to the users.
>
> - Publishing and sharing strategy
> It would be great for the kids to post and share their work. Could be a
> wiki or a web site with links to their work. Could be only published to
> their parents and teachers and it could be blogger.com or google.
> Regardless, they will publish stuff if they have access to the internet.
> Better to have a place for it picked in advance.
>
> Hope that's not intimidating :-) You do as much as you can in advance but
> there are always surprises so be ready to change the plan after its written.
> Again, this is skewed to my background in designing and deploying mission
> critical networks and servers. If everything absolutely had to work on day
> one and do exactly what was intended you would need another year to plan.
>
> HTHs. I think you have more direct in school technology experience than I
> do. The above doesn't cover the pedagogical aspects at all. Just defines how
> to be sure the computers work.
>
> BTW my favorite overview of how these trials can/should work from a
> learning point of view is here:
> http://dspace.mit.edu/handle/1721.1/41706?show=full
>
> I can flesh out any piece of the above for you but will probably do it by
> asking a lot of questions. It will be very hard to get my time in person but
> I have capacity to read and write a few hours a week if that helps.
>
> Thanks,
>
> Greg S
>
>
>
> On Thu, Jun 18, 2009 at 9:42 PM, Caroline Meeks <cmeeks at sugarlabs.org>wrote:
>
>> Hi Greg,
>>
>> It occurs to me that you've seen more deployments then I have.  Where do I
>> need help?
>>
>>
>> On Thu, Jun 18, 2009 at 4:39 PM, Greg Smith <gregsmithpm at gmail.com>wrote:
>>
>>> Hi Caroline,
>>>
>>> Nice to hear from you again. Thanks for the info on the proposal. Very
>>> well written RFP response.
>>>
>>> One edit on the PDF. The footer shows www.sugaronatick.com . I think it
>>> should be www.sugaronastick.com. It links to Solutions Grove web site
>>> but you may want to fix the text and possibly update the link.
>>>
>>> If I have a few hours a week to write and read e-mail, what could I do to
>>> help?
>>>
>>>  I'm settled in at my new job so I have a little more time but I may
>>> have some crunches comng soon so don't count on me for a lot until I get a
>>> better sense of my schedule.
>>>
>>> My forte is usually keeping track of a list of enhancements then finding
>>> and following up with developers to get them implemented. However, I'm happy
>>> to focus on whatever you need most.
>>>
>>> BTW I saw your e-mail re: problems booting SoAS on a Mac. That boot up
>>> sequence is ugly with lots of strange text prompts and I imagine lots of
>>> ways to make a mistake. We should definitely push to simplify that if at all
>>> possible.
>>>
>>> Thanks,
>>>
>>> Greg S
>>>
>>>   On Wed, Jun 17, 2009 at 11:17 PM, Caroline Meeks <cmeeks at sugarlabs.org
>>> > wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> Here is some background on what we are proposing at the Gardner School
>>>> and where Sugar on a Stick is evolving.
>>>>
>>>> Thanks!
>>>> Caroline
>>>>
>>>>
>>>> On Wed, Jun 17, 2009 at 12:36 PM, David Farning <dfarning at sugarlabs.org
>>>> > wrote:
>>>>
>>>>> On Wed, Jun 17, 2009 at 11:12 AM, Greg Smith<gregsmithpm at gmail.com>
>>>>> wrote:
>>>>> > Hi David,
>>>>> >
>>>>> > No need to do that yet. I'm not sure how much time I will have so I
>>>>> want to
>>>>> > read up a little before I get more involved.
>>>>> >
>>>>> > I know Caroline well and have her e-mail. I'd like to do it all on
>>>>> the
>>>>> > public lists too. Let me see what I can find out from existing
>>>>> Wikis/lists
>>>>> > etc. Then I'll send her an e-mail and copy you with some ideas on
>>>>> what I can
>>>>> > help with. Then I'll try to weigh in on the right lists.
>>>>> >
>>>>> > I have several hot items this week, so I probably need until next
>>>>> week to
>>>>> > get back to you.
>>>>> >
>>>>> > Don't mean to slow you down, just tryng to be extra cautious and
>>>>> under
>>>>> > promise so I can over deliver...
>>>>>
>>>>> No Hurries.  I am giving Sugar Labs 10 years to achieve world
>>>>> domination.
>>>>>
>>>>> Some of my big refrains are 'Slow and steady', 'Each release better
>>>>> then the last', and 'If a feature does not make this release there
>>>>> will always be another one in six months.'
>>>>>
>>>>> Look forward to talking to you soon on the lists.  Every once in a
>>>>> while, I will also ping you with a bit of back story so you are not
>>>>> walking blind into any hot button issues.
>>>>>
>>>>> I'll also follow up your first ml post with a brief introduction:)
>>>>>
>>>>> thanks
>>>>> david
>>>>>
>>>>> > Thanks,
>>>>> >
>>>>> > Greg S
>>>>> > On Wed, Jun 17, 2009 at 10:45 AM, David Farning <
>>>>> dfarning at sugarlabs.org>
>>>>> > wrote:
>>>>> >>
>>>>> >> On Wed, Jun 17, 2009 at 9:18 AM, Greg Smith <gregsmithpm at gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Hi David,
>>>>> >>>
>>>>> >>> I'm falling a little behind as I'm interviewing again for a new
>>>>> position.
>>>>> >>> I'm trying to stay ahead of the curve for a change.
>>>>> >>>
>>>>> >>> I am scanning the Sugar and OLCP Dev lists. I haven't seen anything
>>>>> on
>>>>> >>> these two customers except an occasional e-mail from Bryan. I've
>>>>> worked with
>>>>> >>> Bryan before and I think he is actually managing the community as
>>>>> best as
>>>>> >>> can be done now.
>>>>> >>>
>>>>> >>> So I'd like to think about Gartner School. I don't want to make any
>>>>> >>> commitment until I know how much time I can reserve for them.
>>>>> Canyou point
>>>>> >>> me in the right direction for learning about them? Should I watch
>>>>> the IAEP
>>>>> >>> list or some other list? Is Caroline Meeks involved with that one?
>>>>> >>
>>>>> >> That would be awesome! Caroline is leading the project.  It is our
>>>>> primary
>>>>> >> test case for SoaS.  And I think that Walter will be there most
>>>>> days:)
>>>>> >>
>>>>> >> For the last six months, I have asked him to focus on activity
>>>>> development
>>>>> >> rather than normal Executive Director stuff.  That has help us turn
>>>>> the
>>>>> >> power structure on its head.  Developers have become more respected
>>>>> than
>>>>> >> talkers:)  Starting at the Gartner School, he will be _helping_
>>>>> creating
>>>>> >> teacher training materials.  Hopefully, this will help elevate
>>>>> people
>>>>> >> _working_ on deployments with in the community:)
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> Just trying to get my toes wet slowly until I can come up with a
>>>>> plan I
>>>>> >>> know I can execute.
>>>>> >>
>>>>> >> Working with Caroline would be a great introduction to Sugar Labs.
>>>>> >>
>>>>> >> Should I set up a call with her.  Just to talk....
>>>>> >>
>>>>> >> thanks
>>>>> >> david
>>>>> >>>
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>>
>>>>> >>> Greg S
>>>>> >>> On Wed, Jun 10, 2009 at 3:30 PM, David Farning <
>>>>> dfarning at sugarlabs.org>
>>>>> >>> wrote:
>>>>> >>>>
>>>>> >>>> On Wed, Jun 10, 2009 at 8:13 AM, Greg Smith<gregsmithpm at gmail.com
>>>>> >
>>>>> >>>> wrote:
>>>>> >>>> > Hi David,
>>>>> >>>> >
>>>>> >>>> > That's funny! It also flattering and I'm glad to hear it. I'm
>>>>> over the
>>>>> >>>> > initial surge of learning at my new job now. I think I will have
>>>>> a
>>>>> >>>> > little
>>>>> >>>> > more time so I'll try to watch the sugar and devel lists again
>>>>> and
>>>>> >>>> > chip in
>>>>> >>>> > where I can.
>>>>> >>>> >
>>>>> >>>> > If you have a suggestion of an area where I should focus my time
>>>>> let
>>>>> >>>> > me
>>>>> >>>> > know. I'm not sure how much time I can give but once I glom on
>>>>> to
>>>>> >>>> > something
>>>>> >>>> > I tend to get in to it vigorously.
>>>>> >>>>
>>>>> >>>> If you had the time and interest....  I think that the best way to
>>>>> use
>>>>> >>>> your particular skills would be to act as the voice for a single
>>>>> >>>> deployment.
>>>>> >>>>
>>>>> >>>> Once we have a single voice, I think we can reproduce it for other
>>>>> >>>> communities.
>>>>> >>>>
>>>>> >>>> Personally if I were to try to tackle something like this I would
>>>>> pick
>>>>> >>>> the healthiest deployment I could find.... Nepal or even the
>>>>> Gartner
>>>>> >>>> school in Boston.
>>>>> >>>>
>>>>> >>>> The challenges would be two fold: How to ''translate' the
>>>>> deployments
>>>>> >>>> needs and communicate it to the larger community.  The harder job
>>>>> >>>> would be to communicate to the deployment how to interact with
>>>>> >>>> community and what sort of support the community can provide.
>>>>> >>>>
>>>>> >>>> FWIW, the position is 'open' because it is really hard to fill,
>>>>> _not_
>>>>> >>>> because it is unimportant.
>>>>> >>>>
>>>>> >>>> david
>>>>> >>>>
>>>>> >>>> > Thanks,
>>>>> >>>> >
>>>>> >>>> > Greg S
>>>>> >>>> > On Tue, Jun 9, 2009 at 3:21 PM, David Farning <
>>>>> dfarning at sugarlabs.org>
>>>>> >>>> > wrote:
>>>>> >>>> >>
>>>>> >>>> >> Not sure where the thread actually started.
>>>>> >>>> >>
>>>>> >>>> >> But the internal Sugar Labs term for feature champion is a
>>>>> >>>> >> 'GregSmith."  i.e.  We need a Greg Smith to make sure that
>>>>> happens.
>>>>> >>>> >>
>>>>> >>>> >> I am not sure how things were for you at OLPC.... But your
>>>>> legend
>>>>> >>>> >> lives on in Sugar Labs lore:)  There was even a session at
>>>>> SugarCamp
>>>>> >>>> >> Paris called how to recreate Greg Smith:)
>>>>> >>>> >>
>>>>> >>>> >> david
>>>>> >>>> >>
>>>>> >>>> >> On Tue, Jun 9, 2009 at 1:41 PM, Greg Smith<
>>>>> gregsmithpm at gmail.com>
>>>>> >>>> >> wrote:
>>>>> >>>> >> > Hi David,
>>>>> >>>> >> >
>>>>> >>>> >> > FYI I'm pretty sure this was meant for Greg Dek, not me.
>>>>> >>>> >> >
>>>>> >>>> >> > Nice to see the project doing well and continuing to grow!
>>>>> >>>> >> >
>>>>> >>>> >> > Good luck. I send people your way whenever I see a prospect
>>>>> who may
>>>>> >>>> >> > be
>>>>> >>>> >> > able
>>>>> >>>> >> > to help.
>>>>> >>>> >> >
>>>>> >>>> >> > Thanks,
>>>>> >>>> >> >
>>>>> >>>> >> > Greg S
>>>>> >>>> >> >
>>>>> >>>> >> > On Mon, Jun 8, 2009 at 3:09 PM, David Farning
>>>>>  >>>> >> > <dfarning at sugarlabs.org>
>>>>> >>>> >> > wrote:
>>>>> >>>> >> >>
>>>>> >>>> >> >> 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
>>>>> >>>> >> >> >>
>>>>> >>>> >> >> >
>>>>> >>>> >> >
>>>>> >>>> >> >
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Caroline Meeks
>>>> Solution Grove
>>>> Caroline at SolutionGrove.com
>>>>
>>>> 617-500-3488 - Office
>>>> 505-213-3268 - Fax
>>>>
>>>
>>>
>>
>>
>> --
>> Caroline Meeks
>> Solution Grove
>> Caroline at SolutionGrove.com
>>
>> 617-500-3488 - Office
>> 505-213-3268 - Fax
>>
>
>


-- 
Caroline Meeks
Solution Grove
Caroline at SolutionGrove.com

617-500-3488 - Office
505-213-3268 - Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090620/e18bbafb/attachment-0001.htm