[interfacekit] Handling code reviews & other administrivia

First off, I'd like to welcome a new member to the team:  Jeremy Rand. 
He's got a great attitude and I think he'll be a good addition.

Second, I want to throw some thoughts out about dealing with code
reviews.  My thinking thus far:  each step of the process for a module
should be given a once-over as soon as it's completed, to ensure we
don't have people going off into the weeds ("an ounce of prevention is
worth a pound of cure" kind of thing).  A subproject member other than
the implementor should go over the completed implementation with a fine
tooth comb and forward any issues revealed in the review to both the
implementor and the tech lead; the three can then figure out how to
resolve them (bringing the rest of the subproject or even the entire
team into the discussion if necessary).  Once the issues are resolved,
the module is ready for final code approval, which consists of making
sure all process steps have been satisfactorily completed for the module
and all unit tests pass.

Ideally, once we've got our team fleshed out and all the subprojects
chugging along, I think the various tech leads should be responsible for
the "once-overs" and final code approval on their subprojects.  For the
time being, since only a portion of us are really active (my condolences
to those being hammered by real life =P) and to ensure we get everything
off on the right foot, I'll do final code approval.  I've been working
the last couple of nights on some tools so that we can see "at a glance"
what our progess is, right down to individual functions; I'm hoping to
have something to show everybody by the weekend.

Third, I couldn't think of a way to automate making sure all our widgets
draw correctly, etc. (thereby becoming unit test-able), but if somebody
can, it sure would be nice if we could do that.  Otherwise, at some
point we'll want to recruit some QA-type folks to verify our stuff
visually.  Come to think of it, even if we did automate it, we'd still
want some people to compile everything they can get their hands on
against our stuff -- we should be able to flush out a ton of bugs doing
that. =)  That's a ways down the road, though ...

Fourth, I'm going to move BView into the Integration subproject, which
will entail some revision of the schedule.  I've been considering doing
it since I first laid out the schedule and I've finally gotten off the
fench about it.  BView has got its dirty little fingers all inside
BWindow, and leaving it in the Interface subproject creates a nasty
dependency between the two subprojects, and I would really like to
minimize that as much as possible.  Ideally, subprojects would only be
dealing with the public interfaces presented by the other subprojects;
the Integration group is meant to deal with the places where this breaks
down.

Fifth, an idea so the interface group can get productive as soon as
possible.  I suggest that for development purposes, all interface group
modules be placed in the OpenBeOS namespace.  Although most of the
narsty guts of our work is in app_server and integration, interface has
by far the largest number of modules to implement.  It would be nice if
they could simply work off of the existing BeAPI and get right to it. 
My hope is that it will be relatively simple to modify the
projects/makefiles of existing apps to use the OpenBeOS:: stuff for
testing.  The key thing would be making it as simple as possible to turn
off the namespace when it comes time.  I'm thinking something like this
in our source:

#ifdef USE_OPENBEOS_NAMESPACE
namespace OpenBeOS {
#endif

// All your implementation are belong to us ... ;P

#ifdef USE_OPENBEOS_NAMESPACE
}  // ns OpenBeOS
using namespace OpenBeOS;
#endif

coupled with some creative manipulation of include/lib paths, etc. and
we'll be off.  Thoughts?

Finally, a cryptic request:  if at all possible, keep track of your time
spent working, be it on admin, docs, testing, R&D or coding.  It's not a
requirement, by any stretch, so if it's just too big a pain, please
don't burden yourself with it.  All I can really say is that it *MAY*
eventually prove beneficial to be able to show your contribution in
terms of time spent -- however, there is *NO* guarantee of that.  Again,
it is *entirely* each person's choice; I'm still on the fence myself as
to whether or not to bother with it.

*Whew!*  I think that about wraps it up ... =P

e

Other related posts: