Posible project

[Josef Assad]

On Fri, 10 Aug 2007 20:59:32 +0100
Robert Fitzsimons <robfitz at 273k.net> wrote:

> To give a weakness.  Even though I'm a native English speaker my
> written English (grammar/spelling) can be very bad sometimes.

My C is probably orders of magnitude worse than your English! :)

> I think the role of the prjmgr's for LDP is to help get the each
> project off the ground, with a small group of developers if
> needed/possible. Act as a communications channel between the
> developers and manufacture. Then periodically touch base with the
> developers and keep the hardware manufacture and general community
> informed of the progress.  If problems occur with time or other
> resources they should try and resolve them by changing/adding
> developers, contacting the manufacture, etc.

Cool. I acknowledge that the developers are the real stars in this
game, so I'm glad to hear how you see us managers making your lives
easier.

> > The next step should be to define the scope of effort and determine 
> > whether additional resources are required.  Since Greg has an idea
> > of the type of driver required, perhaps he could provide a
> > reasonable effort of the time/effort required to write same.
> 
> This is a very difficult task for me and imagine the same for Greg.
> On code that I'm familiar with it might only be minutes or hours to
> make a change but for someone unfamiliar withe code it could take
> days, weeks or even months.

Which is where it might make sense to let you give estimates once
you're ramped up. Hear ya, and entirely in agreement.

> To give an up in the air guess.  I would have to say a month, but I'm
> almost always wrong (short and long) with these types of guesses.
> Also we don't have a true understanding of the requirements.

Yes, Red River lists quite a few devices. We still need a handle on
what the precise expectations are.

> > I think our detailed correspondence regarding the project would
> > best be done off-list
> 
> Actually we should try and conduct everything in the open if possible,
> protecting the contact details of manufacture staff would be very
> reasonable, etc.  Also if the full datasheets can't be made available
> to the public, we should at least try for custom versions which
> include just the information needed to write and maintain the drivers.

I do agree that as much as possible needs to be in the open. I had an
experience in late 2006 with a project where both the vendor and the
client were jumping into an open source community driven project for
the first time. We had two channels of communication: a closed one and
the community mailing lists. I had recommended as a guideline back then
that the criterion for what discussion goes where was simply this: if
it is boring project administrative, it goes to the private. All else
goes to the public list. It's worked well. Again, this is one of these
areas where the project manager will be useful: building the
understanding on the OEM side of the value of keeping communication in
the open, and - in the cases where there is information to be protected
- acting as the gatekeeper between making use of this data and keeping
it from general circulation in a manner not acceptable to the OEM.

> Robert

J

> _______________________________________________
> prjmgr mailing list
> prjmgr at linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/prjmgr
> 


-- 
The Banjo Players Must Die!
http://www.archive.org/details/JosefAssad_TheBanjoPlayersMustDie

e-mail: josef.assad at gmail.com
url: http://www.DonAssad.com
skype ID: josef.assad