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<[email protected]> wrote: > On Sun, Jun 7, 2009 at 01:30, David Farning<[email protected]> wrote: >> On Fri, Jun 5, 2009 at 5:17 AM, Tomeu Vizoso<[email protected]> wrote: >>> On Wed, Jun 3, 2009 at 19:23, C. Scott Ananian<[email protected]> 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 >> > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
