Re: Fight Back For Guile!

[Evan Prodromou]

>>>>> "TN" == Thien-Thi Nguyen <address@hidden> writes:

    Me> So I propose that interested parties who feel like making
    Me> this happen should unite under a common banner ("GLUG" would
    Me> be a good one -- ttn?) and get ready to make a submission.

    TN> that's fine by me.  dunno if i have the fortitude to compete,
    TN> personally, but i'm glad to add @glug.org forwarding
    TN> aliases...

Aw, c'mon! Of _course_ you have the fortitude! You're my Guile
Advocate Hero! B-)

    Me> One way to get ready might be to try a couple of practice
    Me> problems (like maybe some of the [h] problems from PAIP...?)
    Me> and get the process straight before the actual contest, so
    Me> that we work like a well-oiled machine right out of the box.

    TN> sounds good.  coordinating people from around the world is
    TN> challenging; what's your specific strategy for this?

Well, I didn't have one before, but let's see if I can try and
enumerate something off the top of my head. I'm estimating here for a
team of <20 people, which I think is probably pretty reasonable.

Also note that it's pretty detailed and strict; obviously, this is all
flexible, and mostly wouldn't need to be too rigid. Despite the fact
that there's a fairly busy schedule for 3 days, I think that there's
plenty of time in there for extra things like, say, work, sleep,
school, etc. B-)

---8<---

COLLABORATION TOOLS
-------------------

We can use the old standards of Free Software collaboration, namely:

        * IRC for "meetings" and quick chats about code, design,
          strategy

        * A mailing list for more elaborate discussion

        * CVS for code sharing and version control

        * Bugzilla for problem tracking

PROCESS
-------

I think we can solve a non-trivial problem in 3 days this way:

        * Hour 0-2: Meet in IRC and brainstorm immediately after the
          announcement of the problem, to get lots of ideas on the
          table

        * Hour 2-10: Break for 8 hours to let people stew, do
          prototype code, research, IRC chat informally, and make
          design proposals on the mailing list.

        * Hour 10-12: Reconvene in IRC and choose a design. Hopefully
          by this point there have been several options suggested and
          one comes out as the clear leader.

          Decompose problem into several sub-problems (I/O, parsing,
          UI, etc.) and assign "teams" to each sub-problem. ("Team"
          may be one person, really).

          (One special QA "team" will not work on code, but will
          develop plan for testing system for correctness and
          robustness. This would include test scripts, etc.)

        * Hour 12-18: Individual teams do a similar design process,
          one level lower. At the end of this time, the sub-systems
          should have defined interfaces with stubbed functions
          ("(define (read-object (prt) #f))") checked into CVS.

        * Hour 24-25, 36-37: Organized status meetings each 12 hours
          during the next day and a half. Try to do some kind of
          smoke-test build at each 12-hour point. 

          Try to balance out people on teams if stuff gets done early,
          deal with problems, etc.

          (Obviously, discussion on mailing list, IRC should
          continue.)

        * Hour 48-49: Freeze code at hour 48, and reconvene on IRC. Do
          "candidate build." Begin QA process.

        * Hour 49-60: QA runs tests and logs bugs. Others fix bugs,
          document, etc. Some refactoring/redesign may be appropriate
          here.

        * Hour 60-61: Reconvene on IRC, do status to see where project
          is, final wrap-up.

        * Hour 61-70: More QA & bug-fixing.

        * Hour 70: submit finished program.

ROLES
-----

Based on this process, I see the following roles for people in the
process. Note that "roles" doesn't mean "titles", just "cluster of
jobs that somebody has to do, and probably will get done better if
there's one person responsible."

        * SECRETARY: Organizes the meetings, sets up the mailing list,
          IRC channel, CVS repository, Bugzilla database, etc.

        * LEAD PROGRAMMER: Organize design discussion, formulate
          design description. "Last word" on design issues.

        * TEAM LEAD: Act as lead programmer for the smaller teams.

        * QA LEAD: Act as lead for smaller QA team, develop test
          stuff, run tests, route bugs.

        * BUILD MASTER: Do "milestone builds", final package for
          submission, and submit.

        * HACKER: Fill in everywhere.

---8<---

Wow! As I read that over, I can see that it's pretty insanely
organized. But it's a start, eh?

~ESP

-- 
Evan Prodromou
address@hidden