reminder: friday June 29 at 2:30 EDT = 1:30 CDT = 11:30 PDT

The bi-weekly Croquet technical conference calls continue tomorrow,  
friday June 29 at 2:30 EDT = 1:30 CDT = 11:30 PDT

We will be meeting using a QWAQ forums space which means you need an  
account to participate - e-mail me or Andreas if you want need an  
account. Andreas said he made previous tech call participants admins  
for the space, so most people ought to be able to create new accounts  
for people who need to join the discussion.

I missed the previous meeting, so I'm not sure what was discussed  
then - so I may be way off base here but I've included a draft  
agenda. Let me know if there are other items to add to the agenda,  
and I'll talk to you tomorrow.


1.) Development roadmap discussion
- Authentication cross institution - Shibboleth? OpenID?

2.) Current work in-progress updates
- Liz Wendland - headless persistent router
- Mark McCahill - meta directory/worldbase
- Mark McCahill - remote desktop possibilities/VNC - possible  
integration with NCSU's Virtual Computer Lab
- others?




Mark P. McCahill
Architect, Computing Systems
Duke University - Office of Information Technology
334 Blackwell Street, Suite 2107
Durham, North Carolina 27701
USA

[hidden email]
+1 919-724-0708  (mobile)
+1 929 668 2964  (fax)

>  Let me know if there are other items to add to the agenda,
> and I'll talk to you tomorrow.

Perhaps one topic we can include, or at least introduce, is how to
encourage a true open source project along the lines of those talked
about by other OS leaders. In the end, this topic is to answer the
question "when a change or refactoring is suggested or offered, how do
we say "yes, we're already including your fix" or "no, and here's
why". Otherwise the "fix it yourself" motto turns into "fork it
yourself".

Eric Raymond with his early talk on OSS where he talks about fetchmail
is at: http://www.catb.org/~esr/writings/cathedral-bazaar/linux1_d50_96kbs.mp3
, text: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
On studying how OS works he outlined some of these points plus others:
1. Release early. Release often. And listen to your customers. Linus
was keeping his hacker/users constantly stimulated and rewarded --
stimulated by the prospect of having an ego-satisfying piece of the
action, rewarded by the sight of constant (even daily) improvement in
their work.
2. Given a large enough beta-tester and co-developer base, almost
every problem will be characterized quickly and the fix obvious to
someone.
3. If you treat your beta-testers as if they're your most valuable
resource, they will respond by becoming your most valuable resource.
4. I grew my beta list by adding to it everyone who contacted me about
fetchmail.
5. I sent chatty announcements to the beta list whenever I released,
encouraging people to participate.
6. And I listened to my beta-testers, polling them about design
decisions and stroking them whenever they sent in patches and
feedback.
7. The next best thing to having good ideas is recognizing good ideas
from your users. Sometimes the latter is better.
8. A bazaar project coordinator or leader must have good people and
communications skills.
... plus more

Jim Gettys at the  Usenix 2000 Invited Talk mentioned about described
X11 development and its consortium and some mistakes they made. (The
link to the talk seems missing on the site. I can send it as an
attachment.)
I understand he's an adviser to the OLPC project now.
__

There's a "Terse Guide to Smalltalk", a "Terse Guide to Squeak", a
"Terse Guide to Gemstone Smalltalk", and a "Terse Guide to Seaside".

Would we welcome a "Terse Guide to Croquet"?
Something including the likes of "Any FarPointer should be sent to the
future method"
__

I'm still not sure what to do with this quote I once heard: "Every
revolution has its uniform." Is there an image we personally want to
convey that communicates "Were into Croquet Worlds"?

Cheers,
Darius

> Would we welcome a "Terse Guide to Croquet"?
> Something including the likes of "Any FarPointer should be sent to the
> future method"

I meant "A Croquet specific FarRef. Does not allow immediate messages
to pass through automatically. Use only in conjunction with #future or
#send, "

Darius Clarke wrote:
>> Would we welcome a "Terse Guide to Croquet"?
>> Something including the likes of "Any FarPointer should be sent to the
>> future method"
>
> I meant "A Croquet specific FarRef. Does not allow immediate messages
> to pass through automatically. Use only in conjunction with #future or
> #send, "
Never #send unless you know what you are doing, and even then you are
probably wrong...

David A Smith wrote:
You are *definitely* wrong and it'll come back and bite your behind in
the most unexpected moment. Unfortunately, there are some things that
can't be done without it. Once you run into one you'll understand both
why it's needed and why it's so problematic. And you'll *wish* you
didn't need it.

Cheers,
   - Andreas

Programming by slogan will always be wrong.

I remember a slogan we often heard in the Multics project: floating
point always gives wrong answers.

What it really meant was "I'm unwilling to learn numerical analysis
techniques."  But instead of admitting that about oneself, one
disparages a perfectly reasonable design.

Another slogan often heard is: "garbage collection is never needed if
you are a good programmer".  Often coupled with slurs on people who
write code in Lisp or Smalltalk.

Andreas Raab wrote:

BTW, David just reminded me that my comment wasn't clear. "You are
definitely wrong" wasn't referring to David being wrong it was referring
to "unless you know what you do you are probably wrong" (in other words:
I meant to say you aren't "probably" wrong but most definitely so).

Sorry for the confusion,
   - Andreas

Andreas Raab wrote:

I just added minutes for today's Technical Committee meeting:
http://croquetconsortium.org/index.php/TC_June_29%2C_2007
Please correct as necessary.