Tentative schedule for architectural review meeting

Schedule is subject to change as developments warrant.

The meeting of the ArchReview group will start at 9am in the Von Hippel Room (room 2137) in Building 13 at MIT on Monday, October 23.
Breakfast will be provided that day.
(Most meals on later days will not be brought in;
instead, we will eat at nearby locations.)

Most of the discussion topics are taken from issues mentioned in the ArchReviewIssues summary. In the discussion, we should keep in mind the
working principles from the first day. For exah main issue, I'd like to make sure we cover at least 4 points:

• How is the issue being dealt with (or not dealt with) by current DSpace users?
• What functional/service/informational changes would be useful for our users (and us)?
• What are our options for making appropriate changes? Pros and cons?
• How can we best ensure that the appropriate options get followed through? (This can include specs, implementation plans, etc.) We can't micromanage or completely tie implementor's hands, but whatever guidance we can give on appropriate architecture and development would be helpful.

Monday, October 23

The first day features largely "big picture" discussions aimed at eliciting
requirements and priorities, and giving people a sense of the main issues
that our users face, their importance, and the implications for specific
architectural and implementation decisions. We won't go deeply into
specific implementation revisions today.

We'll assign times to these issues shortly.

• Brief introductions of members

• Goals of meeting, ground rules, and desired outcomes.
  • Process of meeting described.
  • Deliverables desired for review process.

• Manifesto review and discussion of principles and priorities

• Reviews of usage and functionality
  • Summary of PreReviewSurvey results: What are people reporting they're doing with DSpace, what would they like to be doing (new or better features), where do they see usage going?
  • Review of other feedback from current and potential DSpace users
• Discussion of our own priorities for new or improved DSpace functionality (preferably*after we go over what we've heard from the rest of the community)

• Scalability issues – on this pass, largely looking at what starts to be problematic as the size of the repository, the rate of usage, and/or the rate of growth increases. This should inform us when we turn to more specific issues later in the meeting. Remember that DSpace also needs to be practical at the small scale too; that's where everyone starts and a lot of installations remain.

• Interoperability issues – on this pass, we look at
  • where people are wanting to interoperate with other systems
  • where people have made ad-hoc interoperation
  • what emerging standards and expectations for interoperation we should pay attention to

• Possibly discuss what, if anything, we should consider in terms of documentation and testing support. If it seems worth this group's detailed attention, we may discuss details later in the meeting.

• Issue lookahead and half-bakery visit: Very quick once over of the main issues in our issues list. What are we missing? What's not really important or in scope? What issues seem important to review but not fully baked yet? Who's going to commit effort and responsibility in making sure each of these gets addressed?

Tuesday, October 24

More big picture discussion if needed and the start of specific issues. We start with two that are potentially rather large, and that have implications across the archietcture. I don't think we'll have any problem spending a day on these.

• Data model.
  • See issues in ArchReviewIssues under "Information Architecture / Abstract Data Model. We may want to also include some general discussion of provenance and history insofar as they affect the design of the data model.

• Interfaces and modularity
  • Start with a quick overview of current interfaces (Storage API, Business API, Web interface - ASP and Manajin – various special protocol and batch interfaces)
  • Protocols: what should be supported?
  • What should we consider "core" Dspace and where do addins or apps build from?
  • API structure: can it be rationalized / made to better separate concerns?
  • Plugin or Addin mechanisms: what should be supported here? Can we use this to support customizations that will better survive migration to new core versions?
  • Framework questions: Should we consider adopting or experimenting with new implementation platforms? (E.g. interface standards like JSR170; implementation bases like Cocoon, Spring, Fedora; language shifts (Ajax is so much more Web 2.0, d00d. )
  • User interfaces: How much more development should the JSP-based UI get; does it make sense to shift focus to Manakin or other platforms? And, if we have time to discuss it today, what about a better admin/curatorial UI?

Wednesday, October 25

More Specific issues (both model and implementation issues.) For this
short day, I've picked two items that interact closely with some of the
bigger issues discussed yesterday (making it easier to slosh the schedule
a bit in either direction if need be).

• Asset repository and concere data model: See in ArchReviewIssues
• Administrative/curatorial subsystems: See in ArchReviewIssues

Break Wednesday afternoon.

A couple of members will be leaving at the end of work today, or sometime
before the close of the meeting. If you're leaving early, I'd like to
have a sense of what issues you see as most important to work on and
what you'll be able to contribute. (E.g. if you're interested in, say,
workflow and can work with a small group to co-write a detailed plan to
revise the workflow support process, say. Then we can make sure you are
hooked up with an appropriate task group afterwards.)

Thursday, October 26

Here we look over some more specific issues that might not be as broad as those in previous days, but have still been identified as important to address:

• Workflow: See in ArchReviewIssues. This would also be a good place to talk about provenance and history, since all these things have to do with how content gets managed over time.

• Search and browse: See in ArchReviewIssues
• Authentication and authorization: See in ArchReviewIssues

Friday, October 27

This is a shortened day to step back and make sure we all understand what we've
accomplished, decided on, and still have unresolved; to wrap up loose ends;
and to plan for production and delivery of our architectural recommendations and
a smooth handoff of them to development efforts.

• Review of main priorities and dscisions made.

• Half-bakery review: A chance to revisit half-baked ideas from earlier in the meeting, if folks have had a chance to rethink them and want to bring their ideas and proposals to full group discussion while most of us are still here.

• Action plan for preparing roadmaps and specs.

• Beyond the review: How our plans and recommendations might be implemented, evaluated, and/or revisited in later stages.

The meeting will end at 1pm on Friday, October 27.