Compiled by Bob Sproull. Special thanks to Tony Hoare for many good comments.

Observations about the conference:

• There was a lot of energy and discussion; almost everyone chimed in. The spirit was largely one of brainstorming rather than criticizing or limiting or intimidating.
  
  
• The overall format worked well. The general idea was morning sessions, afternoon "free," and evening sessions. In practice, the afternoons were devoted to more working sessions by the various groups. People stayed engaged, and worked hard.
  
  
• Bruce Sterling's keynote was a good catalyst. He was provocative, annoying, amusing, and completely different from the rest of us.
  
  
• The topics, and the voting, seemed to be driven toward problems whose solution would have high social value. There was an implicit bias toward perceived "fundability" rather than toward exploiting specific technical opportunities. There was less technical discussion than the organizing committee anticipated.
  
  
• The plan for the conference required late-night meetings of the organizing committee to tally votes and plan the next day's sessions. This worked, in large part because people were willing to let each day's structure be fluid, and because a moderator/leader stepped forward the next day to try to make their session work.
  
  
• As the conference adjourned, there was little written material completed about each of the challenge areas. (This is a problem with any such effort, but it seemed particularly acute in this case.) Interim presentations were saved (in digital form). As a result, it's going to be tough to prepare a written report of the whole conference. (Note that this is one respect in which this conference departed from the Gordon Conference pattern; they do not require written reports.)
  
  
• The conference was intended to focus on "systems" research, but that focus was not reflected in the conference title (CRA Conference on "Grand Research Challenges" in Computer Science and Engineering).
  
  

Opportunities for improvement:

• Make a clearer statement of what is wanted in the way of a "grand challenge" -- perhaps even present some examples in our or other fields. While societal needs might form a background for some discussion, the agenda for a conference on grand challenges in computer systems should not be to "solve society problems." The themes discussed at the conference tended toward society problems or "boiling the ocean" technical problems rather than specific technical challenges. When people return home from the conference, they're going to work on "technical problems" -- which ones? In other words, the challenges that will have an effect on the community are those that are scientifically compelling--so much so that the participants will want to pursue them on their own account, even if no additional funding is available.
  
  
• Don't worry about "fundability" of challenges: focus on their scientific and technical merits. (Actually, of course, people will silently take a view on fundability anyway.)
  
  
• Have a clear view of where the conference effort fits inside a larger effort to "sell" a grand challenge agenda. This conference focused on "systems," which does not embrace all of computer science and engineering. How will the rest of the community be consulted and engaged?
  
  
• Seek ways to minimize "tape plays," in which each attendee wants to recite his/her research passion and try to recruit joiners. The position papers, if they are widely read, may have some of this effect, but many attendees still sought opportunities to "play their tape." Stronger moderators, or better preparation of the initial topic sessions, might mitigate this.
  
  
• The voting procedures tended to inflate the prose produced by the individual panels, in the hope of attracting the votes of the supporters of themes that have just been voted down. Voting might better address only 'relative emphasis' or 'postponement of consideration.' The supporters of a postponed theme will be invited to work it up later. This would inhibit wooing by widening a topic or appropriating the buzzwords of others.
  
  
• More "young turks" should be invited.
  
  
• Invite scientists from other countries. Tony Hoare was able to attend the conference, and was a great addition. All of the research, not excepting "national" challenge topics, is undertaken by an international research community.
  
  
• More "wacky ideas" should be discussed. Perhaps even solicit a long list; more room for fun during the conference.
  
  
• Give some thought to the "life cycle" of a grand challenge. A new set of grand challenges produced on a regular schedule makes no sense. Rather, challenges gestate over a longer time, and gather technical and perhaps financial support. Conferences may play a role at several different stages in the evolution of a challenge.
  
  
• More IT support is needed. Facilities for printing are essential (working groups need them). If two LCD projectors are available, one can be used for a presentation while the next speaker is readying a presentation on the other. (Internet access was not generally available. This was probably a good thing, because it limited the amount of time people spent catching up on email.) There need to be good ways to transfer file snippets from one person's machine to another (e.g., USB memory "sticks," which don't depend on exotic device drivers).