|
The Thinking Behind theAgenda . . .
The agenda is attended to facilitate the execution of a productive workshop. We welcome any suggestion on how to make the workshop more productive. In order to understand what we have so far, here is an explanation of our thinking of how this agenda might accomplish our goals.
We will start with an explanation of the goals of the workshop. How did we get here, what have we promised to do in the project, what do we expect to accomplish during the workshop, and how will we accomplish it? Edgar will then address what the current limitations are. We are already doing a lot of remote operation and control. Why is it not good enough? What can we not do today that we would like to be able to do? He will present a test case that should help us understand where the current holes are. Bryan will then present a straw man architecture diagram. This is intended to show all the pieces that we currently think are necessary to have a successful collaboratory and to provide a framework and common vocabulary for later discussions.
The next session could easily degenerate into a free for all if we are not careful. The idea here is that we want to get all the issues out on the table before we start to make decisions on a block diagram. Everyone will get a chance to make their specific desires known. We are not going to try to solve anything during this session, just make some opinions known. The list of topics and speakers is just what came to mind. We expect modifications to this list. The part before lunch is generally about remote operation, the part after lunch is about collaboration. Lunch will be catered.
The remainder of the day will be used to determine the components of the architecture and the functional requirements of each component. That is, what are the boxes and what do they do? We want to get as specific as possible on the functional requirements of each box. The actual implementation will be determined later but we need to know now what the boxes do and how do they talk to each other.
We will have diner together somewhere in town. We expect discussions to continue after diner, perhaps as a large group but more likely as spontaneously formed topical breakout groups.
The second day will be used to decide how we will implement our architecture. What are the specific tasks that can be defined, who will volunteer to perform each task, when will the task be completed and what are the dependencies among the tasks? We must leave the work with an understanding of what each person is supposed to do. What is his/her contribution to the overall project? Finally, we need to decide on a plan for how we are to commnicate with each other to coordinate the work on the tasks. We are a large distributed team. Our collaboration on the project itself will be a significant test of our tools and our ability to collaborate scientifically.
Unresolved questions:
When should the workshop end? Some people think it should be two full days or else we will spend more time travelling than working. Others want to be able to return home on the second day. Probably we will extend the meeting into the middle of the afternoon. This will still allow anyone to get home that same day, even on the west coast. We may also schedule optional working group meetings after the close of the workshop itself.
Should we have breakout groups? At first we thought we should spend the afternoon of the first day in smaller breakout groups that would report back to the everyone at the end of the day. Then we decided we should stay as one group since it looked like we might not get far enough along to make breakouts reasonable. Maybe we could have some kind of breakouts on the second day. Probably the breakouts will happen spontaneously.
Who should attend the workshop? Initially we thought it would just be the people who were involved at the time of the original proposal. However, it has expanded beyond that, both from the DOE side and from industry also. That's probably better. Is there a size that's too big? Probably not. We need to get everyone's buy-in to the project specifics and to be sure that all interests and capabilities are represented. |
|
