[Opensource] Discussion: Walkthrough Committee

[Michael Rimov]

Hey All,

Just a thought here....

As Lirian and others have voiced, the Expresso code base could use 
additional cleanup.  To be honest, I only see the possibility of this 
happening by doing a series of code walk-throughs.  I, personally, believe 
this is beneficial from a security standpoint as well since the OpenBSD has 
proven time and time again that such practices significantly increase the 
security of the software.

So, if we did something like this, what would it look like?  How would 
meetings happen?  How often, how much, etc?

I suggest that something along the lines of a minimum of a 3 people meeting 
that took place once a month and would entail a walk-though of probably 
only one class at a time.  Depending on the size of the class the group 
could decide to tackle more than one class as well.

Pre-meeting tasks:
-Have somebody with Jalopy reformat the code for the class we're going to 
look at.  This would provide a standard format that we could all agree on.

-Somebody goes through the class and walks through the javadocs on the 
class and adds what they do understand.  Leave '????' for javadocs on 
undocumented classes/functions that don't make sense at a casual glance.

Meeting Tasks:  Generalized walkthrough the code.  If nobody understands 
the code being looked at, the goal of the walkthrough is to just understand 
it at first and javadoc it.  Look for code cleanup.  Look for updating unit 
tests, etc.

Quorum:  As I said, I think 3 people groups are probably a good idea.  For 
a distributed project and all our wild schedules, I don't really see being 
able to corral more folks at once than that.  That doesn't mean only 3 
people have to sign up for walkthroughs!  Depending on skill level with the 
code, folks could 'tag along', others could form their own group... or 
having additional people would help provide a 'pool' of people that could 
meet at a particular time, thus helping to ensure the meetings happen :)
	Each group would have to have a committer on board.  [Major Contributor 
and higher], and that person makes changes as suggested.  Anything that 
isn't a 'quick fix' should be added to the Expresso task list for 
fixing/refactoring for for the next release.

How do we prioritize the classes to walk through?  There was an interesting 
Dr. Dobbs article about somebody tracking down the classes that most likely 
need walkthrough's simply by running standard code metrics against various 
classes and computing a 'complexity' number.  Higher complixity classes 
should be walked through first.  This should help yield the highest number 
of bug fixes.

How do we meet?  That depends... we could MSN or AIM... there's a few UNIX 
folks out there that could donate the use of an IRC server.  Or if somebody 
wanted to donate a 'conference call' system for use, that would be great 
too.  This would be something to hash out.

Anyway, I think things like this could greatly assist the Expresso code 
base.  By only taking once class a month, we being a slow but steady effort 
to clean things up, and by prioritizing our walkthroughs we could get the 
worst offenders first.  Best of all, participants would get thorough 
knowledge of one class at a time, and since.

Reporting:  Probably it would be best if the findings of the walkthrough 
were posted to the list.  We could agree on a general template so that 
folks would only have to fill in the blanks.

Implementation Timeline:  I would like to start this probably after the 
release of 5.1 [or at least begin it well into the 'ea' schedule].

So, the question is, what do you guys think of this, if we did this, who 
would volunteer, and finally what could be done to make this more efficient?

Feedback appreciated!
							-Mike