Subject: working procedures

From: Jack Dongarra <[email-masked]>
Date: Tue, 24 Nov 92 16:45:35 -0500

Chuck Koelbel has passed on some notes from the HPF experence.
I think we will find them useful in carring out our meetings.
Jack

HPFF Working Procedures

HPFF never had an explicit vote on adopting any operating procedures.  We 
did, however, informally adopt the following rules.

General Organization

Most of the technical details were hammered out in subgroups, which made 
the base proposals. The main group would discuss these proposals and 
(usually) adopt them. In practice, lots of the technical discussions were 
done on email lists. Keeping those lists public was a big part of the 
openness of the forum.

For a while, each subgroup brought its own proposal as handouts. 
Eventually, we ended up with a unified draft thanks to Dave Loveman. The 
intent (which we never lived up to) was that all proposals discussed at a 
meeting would be in that draft. Despite always having a loose proposal or 
two, the draft was extremely useful - among other things, it made editing a 
final report possible. 

Main Group / Plenary Session Matters

For running discussions, we used loosely-enforced Robert's Rules of 
Order.  Basically, we didn't stand on formalities unless the discussion 
was becoming unruly.  Some of the more often-invoked rules:
	1. Moving and voting on amendments before the main proposal.  Basically, 
	this kept the discussions focussed.
	2. Motions coming out of committee (subgroup) are automatically 
	seconded; others need a second from the floor.
	3. Triply-nested amendments are not allowed.  This keeps the confusion 
	down.
Generally, whoever was making the presentation ran the discussion, 
recognized comments from the floor, etc.  Ken usually came in after the 
meat of the discussion to run the votes.  Peer pressure was fairly 
effective at keeping people from filibustering (I think once there was a 
call to limit discussion).  More common was lots of people wanting to 
make comments - this was handled by the presenters, usually by saying "OK, 
let's go clockwise around the table".

Organizations were limited to 2 attendees each (not enforced, but no 
major problems). We passed around an attendence sheet at each meeting to 
keep track of who was there; because of various planning problems, I 
recommend using a pre-registration scheme ("send email to xxx@yyy if you 
plan to attend").  Organizations were asked to commit to having the same 
attendee at every meeting, and this was generally followed.  It's very 
important to have this kind of continuity in attendees, else we would 
have spent too much time in remedial education.

Each organization (school, company, lab) got one vote - note this was on an 
organization basis, not a person. We didn't have trouble with cheating on 
this rule - just make sure the representatives from an organization have 
agreed on who is voting. An organization was eligible to vote if it had 
attended 2 of the last 3 meetings, counting the current meeting (i.e. you 
could attend every other meeting and still vote; you could not vote at your 
first meeting). Obviously, we couldn't enforce this rule at the first 
two meetings. 

Accepting a section of the HPF language spec was a multi-step process.
	1. Someone wrote a draft specification; often there were a couple 
	drafts.  Details of these were hashed out in the subgroup.
	2. First Reading: The subgroup leader (or occasionally the draft author) 
	presented the subgroup-approved draft to the main group.  When there was 
	controversy, it was usually pointed out.  The main group discussed, 
	suggested changes (sometimes), and held a series of "straw votes" on the 
	proposal.  All attendees were eligible to vote in straw votes, which 
	were not binding on the subgroups.
	3. More subgroup discussion, both electronic and in person at the next 
	meeting, producing a revised proposal.
	4. Second Reading: The subgroup leader presented the revised proposal to 
	the main group.  Sections that were substantially the same as the 
	original (or an alternative presented at the first reading) were amended 
	by motion and eventually voted on.  Eligibility for votes was as 
	explained above.  Major additions (for example, when PURE functions were 
	added to FORALL between meetings) were treated as first readings at this 
	point.  Often most of the proposal was accepted, and a few sections were 
	sent back to subgroup for more work; these came back as second readings 
	at the next meeting.
	5. Once a section was accepted at second reading, it was "frozen" until 
	the end of the HPFF process.  Revisions were only allowed for clarity or 
	when new information surfaced (like discovering that the draft was 
	self-contradictory).  This limitation was enforced as strictly as we 
	could, to avoid backtracking.
	6. At the end of the process (December), we promised to allow 
	reconsideration of any feature.
See also the discussion of the Journal of Development below.

Subgroup Matters

Subgroups met independently of the main body, usually the afternoon and 
evening of the day before.  The leader of the subgroup ran these meetings 
using whatever style he or she was comfortable with.  Most of us took 
votes from whoever showed up, and ran a pseud-democratic style.  Also, 
there was a mailing list for each subgroup where most of the discussions 
went on.

Each subgroup was devoted to one topic from the following list:
	Data distribution
	FORALL and other parallel statements
	Fortran 90, storage & sequence association, and the HPF subset
	Intrinsic functions
	Parallel I/O
	EXTRINSIC (nee LOCAL, nee FOREIGN) functions
The groups met in parallel, which caused a little friction but was 
logstically unavoidable.  When a subject straddled two groups (like 
intrinsic functions for enquiring about distributions), the subgroup 
leaders would talk to each other and decide who would handle it - this 
often led to minor anti-turf battles (also known as "after you" 
deadlock).  Both groups would act as sanity checks on the results.

When it came time to write the draft, each subgroup became a chapter.  
The subgroup leader was the editor (and usually major author) of the 
chapter, and was responsible for making sure the chapter reflected the 
decisions made in the subgroup and in committee.  

Logistical Matters

Meetings were 2.5 days, starting Wednesday afternoon, in Dallas (there 
were exceptions to this for logistical reasons, but we would have 
prefered to keep them all on this schedule).  A typical schedule was

	Wednesday
	  1:30-6:00  Subgroup meetings, about 3 going on in parallel (reserve 4 
		"breakout" rooms with the hotel, fo 10-20 people each)
	  6:00-7:30  Unofficial dinner break (usually the subgroup leaders ate 
		together & planned the meeting agenda)
	  7:30-10:30 More subgroup meetings (subgroup leaders usually ended up 
		staying up late to revise drafts)
	
	Thursday
	  9:00-12:00 Full group meeting (coffee breaks at natural breaks)
	  12:00-1:30 Lunch (provided)
	  1:30-6:00  Full group meeting (and coffee breaks)
	  6:00-8:00  Dinner (attendees pay, but hotel provided transport to area 
		restaurant)
	  8:00-10:00 (Sometimes) Full group meeting (when no full meeting, 
		subgroups usually met instead)
	
	Friday
	  9:00-12:00 Full group meeting (and coffee breaks)
	  12:00-1:30 (Sometimes) Lunch (provided if we thought the meeting would 
		last long)
	  1:30-3:00  (Sometimes) Full group meeting

We tried to finish as early as possible on Friday, to allow people to 
catch flights.

Since we scheduled all the meetings early on, we set up a contract with 
the hotel.  I didn't handle the details, but I think this saved us a 
little money and a lot of aggravation (talk to Theresa Chatman if you 
need more info).  At any rate, this is a great thing for someone on your 
staff to set up.

We financed the meetings primarily from a per-meeting fee of $95 ($75 if 
we didn't have lunch the second day) per attendee.  Ken offered to foot 
the bill for academics to attend, based on the expectation of NSF funds.  
We're still waiting on those funds; highly recommend that you don't make 
such offers without first getting the cash.

Documentation

The Draft: The earlier you have one the better. David Loveman served as our 
general editor, collecting the chapters and trying to smooth format 
details. I contributed the introduction and credits, mainly cribbed from 
meeting notes and other announcements. Guy Steele contributed a set of 
macros for BNF syntax and reproducing code segments. We tried to find some 
formatting from an ANSI standard, but no dice. Toward the end of the 
process, version control became a problem. We (tried to) set up the 
following framework: 
	1. David had the "official" version of the draft.  He set deadlines for 
	receiving the chapters, and edited for formatting.
	2. David sent me the whole document when all the chapters were done.  
	I LaTeXed it to check for system dependences (never a problem)
	3. I sent the document to the "core" mail group (see below), put it out 
	for anonymous FTP, and announced it on the net.
	4. Any further changes were supposed to be made to David's edited 
	copy, not the original version (this to make the next round of edits 
	easier).
The system worked pretty well, until the final draft when the wrong 
version of Chapter 6 got distributed...

Each subgroup wrote one chapter, generally written and/or edited by the 
subgroup leader. While the meetings were going on, the draft contained all 
proposals still under consideration (Guy provided a "\alternative" macro 
that marked sections as being alternatives to each other). Also, the author 
of each section was identified in a footnote at the beginning of the 
section, along with the date (and occasionally other version information). 
In the current draft, we've moved summaries of some discarded proposals to 
the "Journal of Development" (primarily the ones dropped for lack of time). 
All proposals exist in the archives; we may put together a "rationale" 
document to explain some of the more controversial decisions. We're also 
planning to move the authorship information from footnotes to the credits 
chapter in the December draft. It's too early to know how this organization 
will work for the reader, but the modularity has helped in writing the 
document.

Other lessons from the draft:
	1. Make sure the chapter authors realize they are writing a draft 
	chapter, not a stand-alone document.
	2. Make sure the person in charge of the credits chapter has plenty of 
	time to work on it (I spent 50% of my time for a week appeasing various 
	corporate egos, wording things right, and checking spelling of names).
	3. Proofread the document before sending it out - both spell checking 
	and careful chapter reading.

Mailing lists: Every subgroup had its own mailing list.  Those lists are 
where most of the technical action happened; they were very high-volume 
(final total was something like 1.5Mb of archived messages).  On top of that, 
there was a list for everybody in the world interested in HPF, and another 
for the "core" group. The "everybody" list was used for the meeting minutes 
and a few miscellaneous announcements. The core group list was primarily 
for the meeting attendees, but a few others were also on it for political 
and/or practical reasons (for example, Gil Weigand and Theresa Chatman were 
both on the list); it got meeting details, and copies of the various 
proposals before the meetings. All lists were kept at cs.rice.edu (there 
were a couple smaller lists other places, including a European list at GMD 
and several local lists for particular campuses). People could add or 
delete themselves to/from any of the lists by mailing to another mail alias 
at Rice. Automating this was a huge win (although I got 2 or 3 requests 
sent directly to me every week).

FTP: We made everything we could available by anonymous FTP at Rice; 
eventually other sites picked up some of it as well. This included the 
various drafts of the language spec; any other handouts from the meetings; 
supporting (sometimes critical) commentary; papers on Fortran D, Vienna 
Fortran, ADAPT, and other systems; archived email traffic; and the minutes 
of the meetings. Generally, I put up a couple versions of any document 
(particularly text formatting stuff) - TeX or LaTeX, Postscript, and 
compressed versions of large files.  This was important, since I've found 
out some fascinating things about portability (or lack thereof) of 
different formats.  (Hints: keep all lines 80 characters or less; no 
fancy macros in TeX; at most one "." in a file name (filename.tex.Z 
doesn't translate well to IBM!); never include ANY pathname.)

Minutes: Extremely popular, but lots of work. I'm convinced that making 
them available was a key to HPFF's success. Make them as detailed as 
possible, particularly including counts of the votes taken, major topics 
discussed, and lists of people (humor helps occasionally, too). "Executive 
Summary" sections with the major issues at the front seemed to be popular. 
I also used the minutes to announce additions to the FTP archives.

Advertizing:
Announcements of major news (new drafts, etc.) went everywhere I could 
think of.  This includes the "world" mailing list; newsgroups 
comp.lang.fortran, comp.lang.misc, and comp.parallel; (indirectly) 
na-net, scinet, and hpcwire.  Meeting minutes went to the world and core 
mailing lists and the newsgroups.  I've been writing short "What is HPF" 
articles constantly, and I think the same is true of others.  Ken, Dave 
Loveman, Guy, and I have all given large numbers of talks on HPF; again, 
the same is probably true of others.  This includes invited talks at 
conferences and visits to various companies.