[OLPC-devel] OLPC development project organization. Status calls? Other techniques?

[Jim Gettys]

On Wed, 2006-05-31 at 17:00 -0500, Darryl Palmer wrote:
> On 5/31/06, Jim Gettys <jg at laptop.org> wrote: 
>         1) would a weekly/biweekly phone call help with coordination
>         and
>         communications?  If weekly, we might alternate times to favor
>         far east 
>         vs. US and Europe on alternate weeks.
>  
> That would be great but we will need a moderator for it that isn't
> afraid to cut people off and keep the meeting moving.  We should also
> try to record it and have it up on a website for people to listen to
> it if they can't attend.  We may need to designated a meeting
> secretary to write summary notes.

I think I know how to run phone meetings: I have more experience than I
care to think about...  I'm not a good note taker, however, so a
volunteer secretary would be greatly appreciated.
> 
>         2) would people prefer to post status to the list? in addition
>         to a
>         phone call?  instead of a phone call?
>  
> I think there should either be a website where the status of the
> projects are at or 1 person should make 1 large mail with the status
> of all the projects.  I would hate people to get hit by 20 or so
> emails on the status of sub-projects each week.

Good point: we have to worry about scaling, and mail messages go as the
number of people.

> 
>         3) we could put tasks needing doing into a tracking system
>         (e.g.
>         bugzilla) and track tasks that way?  Or are there better tools
>         for this 
>         purpose we should install and use?
>  
> If I am working on a project, I want to know about my project in
> detail but I don't care that much about other projects as long as they
> are on schedule.  So I would want something like an "OLPC" wide
> feature list and release schedule where someone can drill-down to get
> to the little things, for example, whether the "Sugar" icons need to
> be modified to be international friendly.

Yup.

> 
>         4) What should our preferred SCM be?
>  
> As long as what we pick helps me more then hinders me, I don't care.
>  
>         5) Ivan is recommending we not use gforge having talked to
>         some people
>         who have been using it; this begs project hosting tools.  In
>         my 
>         experience, account management quickly becomes a scaling
>         issue.  It is
>         important that project leaders be able to add members to
>         projects
>         immediately without requiring central approval or manual
>         account
>         creation. I know there are tools developed by a number of
>         other 
>         projects: e.g. handhelds.org has time tested and recently
>         improved
>         tools. There may be others.  Time is of the essence if we want
>         to go
>         this route. If you know of such tools, please let me know so
>         we can make 
>         a rational judgment of what to do in this area.
>  
> In most Open Source projects it is usually the Lead
> Architect/Designer/Programmer that is the Project Leader, we may just
> have to revert to having a specialized Project Leader for the larger
> sub-projects.
> 
>  
> One of the things that I want to make sure of is that everyone that is
> working on the core project has confidence.
>  
> 1) Confidence in knowing what they are doing is correct.
> We have a specific list of features/requirements/tasks with
> priorities, and/or a "customer" representative to ask questions to and
> get feedback on.

Are you suggesting something like a list of people to ask specific types
of questions of? 
>  
> 2) Confidence in knowing a defect will be found.
> While I expect all the developers to have a personal process for
> software quality, we should have a build system to make sure that
> everything still compiles at least.  If we have some automated tests
> running also it would be neater.

Chris' crew have been setting up automated builds for the Fedora
distribution.  I think this is almost on-line.

>  
> 3) Confidence in knowing when you are done with a task.
> It maybe that we have enough resources to continue development down to
> when we freeze the code, but it would be nice to know when something
> is good enough to ship.  If it is up to each developer to do this, or
> if we have someone review the running program or app to do this, I
> don't know.
>  

Yup; this goes back to having a task list, and milestones of some sort.

Part of what I have found phone conversations good for is getting a
feeling for how confident people are in how things are going.
Tones of voice don't get through email well. :-(.
                              - Jim


> 
-- 
Jim Gettys
One Laptop Per Child