This is a Wikified version of the process document for the ArchReview group, adapted to our current process plans.
An Architecture Review group will be convened of up to 15 people and a chair. The members of the group will be invited to participate by MIT and HP following a defined strategy and with clear criteria: current DSpace committers and representatives from MIT and HP, other senior architects and developers from the DSpace community (who know DSpace well), people with expertise in critical technologies (e.g. database design, Web applications, security) and people with expertise in digital library and archives standards and technologies. Nomination of potential candidates will be solicited from the DSpace community and other allies.
The Architecture Review group will start by agreeing to a set of working principles (ArchReviewWorkingPrinciples) and a set of technical design issues (ArchReviewIssues) drawn from the current DSpace architecture, and will produce a detailed technology roadmap for DSpace development that addresses the issues and suggest improvements to the overall architecture. The group can agree to postpone or not address certain issues, or to set priorities in some other way. In addition to the roadmap, detailed specifications for subsequent development work to implement the roadmap will also be delivered, to the extent possible, so that a major DSpace development project can be defined following the architectural review.
The group will begin its work during the summer of 2006 and will complete the roadmap and other deliverables by the end of 2006. Initial work for each participant may include identifying aspects of the architecture of personal interest and expertise from the draft issues list for subgroup assignment, and/or production of straw man proposals for approaches or solutions to the issues.
The group will convene for an in-person workshop at a location to be determined (probably Cambridge, MA for logistical simplicity, but not necessarily). Travel to this workshop will be funded for all participants, but no other funding is available (e.g. salaries or other compensation for members' time). The workshop could be a single event of 3-5 days during which the first draft of the roadmap would be developed, or it could be two events a month or two apart, of shorter duration. The latter would be easier in some ways but would require more funding and time on the part of the members, so the former may be more practical. One outcome of the in-person workshop(s) will be a process for continuing work during the fall to complete the roadmap and specifications by the December 31 deadline.
Given the number and complexity of issues to address, the group may choose to break into smaller subgroups or to structure themselves in some other way to insure that all the issues are discussed and consensus reached in the amount of time available. The group may choose to continue work, either all together or in subgroups, via telephone conference calls after the workshop in order to complete the roadmap by December 31.