beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Marvin" <>
Subject RE: Review sets for non-bea committers
Date Wed, 28 Jul 2004 16:52:48 GMT
I'd definitely agree that we need to work through this and find ways for folks new to the code
base to come up to speed on the overall structure and how to find/understand the various subsystems
they are interested in.
I'd observe, though, that this is not a point-in-time problem (i.e. let's get existing non-BEA
committers up to speed).  The right way to handle it is to provide sufficient info such that
_anyone_ interested in diving into the source has a roadmap of sorts to begin to understand
the code base.   This will be the best way to build a community and add more contributors
over time.
Given that there is already a significant amount of code there, it seems like a top-down approach
is best.  We probably need some high-level description of the structure of the source tree
and what's in different locations, and then folks working closer in various subsystems (pageflows,
controls, ...) can fill in the gaps, hopefully w/ some combination of useful javadocs + design/overview
documents where useful/appropriate.
It's probably also best driven w/ an eye towards what needs to be done next... i.e. rather
than trying to capture documentation on everything, preparing information on areas of the
code base that have missing functionality or enhancement work remaining probably has the best
ROI on effort.
-- Kyle

	-----Original Message----- 
	From: Karr, David [] 
	Sent: Wed 7/28/2004 8:19 AM 
	Subject: Review sets for non-bea committers

	So now that we have source code in the repository, we have a set of
	committers who have worked closely with the existing source code, and a
	set of committers who have never seen it.  This is likely the same
	alignment as the BEA committers and the non-BEA committers. 
	There are over 5000 files in the trunk.  It would be prudent to engineer
	some sort of "knowledge transfer", "design review", or something
	similar, to get people familiar with the code base who up til now
	haven't been deeply involved in its development.  This could be done at
	several levels of sophistication, starting at simply a road map of what
	high-level modules are present, or a list of "code review sets",
	consisting of lists of files that should be reviewed by people
	interested in getting involved in particular parts of the system.

View raw message