6 folks: * Mark Diggory * Stuart Lewis * Richard Rodgers * Sarah Shreeves * Maureen Walsh * Myself
To be fair, the Survey specifically listed many features which we knew that DSpace didn’t support/meet. That was one of the goals of the survey. So the “All Features” pie chart is NOT a surprise. Very High = above 7.5 (on scale of 1 to 10) Moderately High = between 5 and 7.5 (on scale of 1 to 10)
These 4 features represent the 21% of the very highly ranked, unmet needs. “Relationships between objects” is more of a structural/architectural limitation, while the others refer to End User or Admin UI needs.
These charts obviously ONLY cover features which we listed in the Survey. The results of the survey pointed out that all the listed features were at least “moderately important”, so this shows the rough gaps in each category of features.
These goals are “non-functional” in that they cannot easily “map” to a single feature or use case. They are goals of the product itself, and therefore are harder to measure (more subjective in nature), but important to keep in mind in creating a sustainable community product.
Based on the Non-Functional Goals, and the “gaps” shown in the survey analysis, our group felt that the following type of project is likely needed.
Organic Development model: * It’s a great way to get new features in, & being responsive to immediate needs (bottom – up, rather than top-down) * However, not the greatest at prioritizing needs or larger scale changes Product Decisions (what Debra will cover): * This is where a Governance Model will help. Need a better model to make product-wide decisions. Process to achieve Product goals (what Lieven will cover): * Need community use case gathering, etc.
Three major bodies responsible for different parts of governance and how they all fit together. Will walk thru the three individual groups
DSpace Steering Group The DSpace Steering Group provides leadership and sets strategic direction for DSpace software. They oversee project operations and recommend annual budget allocations. Primary Responsibilities: Provide leadership and strategic guidance for DSpace software Recommend annual budget allocations Present key decisions to the Leadership Group Raise funding and other resources on behalf of DSpace Meeting Frequency: Monthly phone meetings Group Participants (6-15 individuals): Steering Group is nominated and elected by the DSpace Leadership Group Participants have a set term limit (2 years) Any DSpace Member or Registered Service Provider may be elected to the Steering Group Ex-officio participants: Chair of DSpace Product Planning Group (i.e. DSpace Product Manager, once hired) Chair of DSpace Technology Advisory Group (i.e. DSpace Technical Lead) Chair of DSpace Community Advisory Team DSpace Leadership Group The DSpace Leadership Group approves the overall priorities and strategic direction of the project. Primary Responsibilities: Approves priorities and strategic direction (as presented by Steering Group) Approves annual budget allocation decisions Approves strategic product roadmap decisions Approves strategic community direction decisions Nominates and elects Steering Group members Votes on key decisions presented by the Steering Group Meeting Frequency: Annually at DuraSpace Summit (March). Up to 3 other phone calls per year, based on whether there are key decisions or proposals to review. Group Participants: The Leadership Group is a subset of the overall DSpace Members, selected based on their level of contribution to DSpace. Any institutional member that contributes at least $10K annually to DSpace is guaranteed one seat on the Leadership Group Any institutional member that contributes at least 0.5 FTE in-kind developers to DSpace is guaranteed one seat on the Leadership Group 4 participants are elected from all institutions that contribute at least $5K annually to DSpace. 2 participants are elected from all institutions that contribute at least $2.5K annually to DSpace 1 participant is elected from all institutions that contribute at a discounted Bronze level ($250 discounted membership for economies in transition and developing economies, as decided by the United Nation&apos;s World Economic Situation and Prospects report) Nominations for elections are made by DuraSpace DSpace Project Members Primary Responsibilities: Members are not directly involved with decisions regarding the DSpace platform. However, they may provide their feedback via member-directed surveys or similar Any Member may be nominated and elected to the DSpace Steering Group. However only the Leadership Group can vote on nominations As Members are providing funding to DSpace, their use cases and feature requests may be prioritized over non-Member institutions Meeting Frequency: This group does not have official meetings. However, they are invited to attend the DuraSpace Summit (March). Group Participants: Any institution which has chosen to become a Member of DuraSpace and has targeted at least a portion of their membership dues towards DSpace.
DSpace Committers DSpace Committers have primary control over the code and is also the primary support team for DSpace. They are a meritocracy (members are added from the community based on merit). Primary Responsibilities: Maintain the codebase; Committers are the only individuals who can actively change/commit to the codebase Review all code contributions/changes to ensure stability, etc (see Code Contribution Guidelines) Merge/accept community code contributions Help to resolve bugs or security issues within codebase Help to provide ongoing support to community developers and users (via IRC, mailing lists, etc.) Perform and manage new releases based on the Technical Roadmap (from the Technology Advisory Group) Meeting Frequency: Weekly Group Participants (no limit on number of participants): Chair: DSpace Technical Lead The Committers group is a meritocracy. Members are added from the pool of volunteer contributors based on merit. Anyone may be nominated for Committership. Only existing Committers may vote to add a nominated person to the Committers group. For more information see Committer Nominations.
Standing Working Groups DSpace Product Planning Group The DSpace Product Planning Group develops and maintains the DSpace Product Plan in conjunction with the DSpace Community Advisory Team (DCAT) and the Technology Advisory Group. Primary Responsibilities: Once per year: Create / Refresh the DSpace Product Plan / Product Roadmap and present to Steering Group for approval Every three years: Refresh High Level Vision for DSpace (in conjunction with DCAT and Technology Advisory Group) Meeting Frequency: Monthly? (Perhaps a few times a month during detailed planning phases) Group Participants (4-8 individuals) Chair: DSpace Product Manager (once hired) Interim Chair: DSpace Tech Lead? Ex-officio: Chair of DSpace Technology Advisory Group (DSpace Tech Lead) Chair of DSpace Community Advisory Team Participants are selected from and by the DSpace Community Advisory Team and DSpace Technology Advisory Group Ideally, participants should be from various backgrounds in order to ensure diverse representation (larger vs small institutions, from various countries around the world). (New Role for this Group) DSpace Community Advisory Team (DCAT) The DSpace Community Advisory Team represents the interests of repository managers and administrators across the globe, and indirectly, DSpace end users. DCAT plays a user advisory role with Committers, Steering Group and Technology Advisory Group. They help to gather and maintain a list of product use cases from the user community, which help to inform the Product Plan. The DCAT chair is an elected member of the community. Primary Responsibilities: Advisory role to Committers, Steering Committee and Technology Advisory Group on any topics related to repository management and use cases Survey the DSpace community to solicit comments and suggestions on recent developments in the software Champion particular feature requests or bug reports Gather use cases to help inform the Product Plan Share knowledge and best practices on user mailing lists Meeting Frequency: Monthly Group Participants (no limit on number of participants): DCAT members are primarily individuals who function as DSpace repository managers at their institution All members have an interest in advancing the development of the DSpace software and expanding the user community DCAT aims to have representatives across the globe in order to provide broad support to the DSpace user community Anyone in the community may choose to join DCAT More details coming soon. Official charge is being drafted by the existing DCAT group. DSpace Technology Advisory Group The DSpace Technology Advisory Group advises all groups on DSpace technology and architectural decisions. They help to research and/or prototype various implementation options, and recommend the &quot;best of class&quot; for implementation. Primary Responsibilities: Once per year: Refresh the Implementation Plan / Technical Roadmap for upcoming release(s) based on Product Plan Work with the Committers group to schedule & plan upcoming releases based on Technical Roadmap Advise on technical implementation/architecture options based on prioritized use cases (from DCAT) and/or the proposed product plan (from Product Planning Group). Help lead or organize the analysis, researching and/or prototyping of specific technical implementation options (in order to provide input/advice to Product Planning Group and Steering Group on available paths forward). In some cases, participants may help lead or organize implementation teams (of Committers and/or donated developers) to add specific features into DSpace Meeting Frequency: Monthly? (Perhaps a few times a month during detailed analysis phases) Group Participants (4-8 individuals): Chair: DSpace Technical Lead Participants are selected from the Committers group by the Technical Lead and the Committers. Community Contributors (non-Committers) may be selected to this group by a vote of the Committers. `
Planning Process Overview High Level Vision Every three (3?) years, the DSpace Steering Group will revisit and refresh the High Level Vision for DSpace as a product. Participants: DSpace Steering Group (lead) An ad-hoc &quot;Vision Group&quot;, whose role is to help refresh the Vision. This group would be made up of members of the Product Planning Group, DCAT and the Technology Advisory Group. Community Survey / Use Cases Every three (3?) years, after the High Level Vision is refreshed, a new Community Survey will be performed to help validate the Vision and ensure it is in line with the needs of the Community. In conjunction with the survey, DSpace Use Cases will be refreshed based on the survey results/feedback. NOTE: Use Case gathering is obviously an ongoing activity, and as such may be scheduled as a yearly activity to help inform the Product Plan. Participants: DSpace Community Advisory Team (lead) Support/Feedback from Product Planning Group Support/Feedback from ad-hoc &quot;Vision Group&quot; (every three years) Product Plan On a yearly basis, the DSpace Product Plan will be updated. This is a high-level Plan based on both the most recent Product Vision, and based on the latest Survey and gathered Use Cases. This Product Plan will be approved by the Steering Group. Participants: Product Planning Group (lead) Support/Feedback from Technology Advisory Group and DCAT Approval by DSpace Steering Group Implementation Options On a yearly basis, the Technology Advisory Group will work with the Product Planning Group to determine implementation options which meet the Product Plan&apos;s yearly goals. These implementation options may involve decisions such as which third-party tool or technology to recommend utilizing in order to meet a particular use case/need. Participants: Technology Advisory Group (lead) Support/Feedback from Product Planning Group, Committers and DCAT Technical Roadmap On a yearly basis, based on the Product Plan and recommended Implementation Options, a Technical Roadmap will be created by the Committers team. This Roadmap will correspond to scheduling which major features should be in each major release of the software platform. NOTE: The Technical Roadmap will also include features / improvements which are contributed by the community. So, it is a combination of known community contributions and planned development (based on the Product Plan). Participants: Committers Team (lead) Support/Feedback from Technology Advisory Group, Product Planning Group and DCAT
Future of DSpace - Steering Group panel at OR14
Licensed under Creative Commons Attribution-ShareAlike 4.0 International License
The Future of DSpace
Jonathan Markow, DuraSpace
Tim Donohue, DuraSpace
Lieven Droogmans, @mire
Debra Hanken Kurtz, Texas Digital Library
DSpace Steering Committee
• Debra Hanken Kurtz Texas Digital Library (TDL) -Chair
• Richard Jizba Creighton University
• David Lewis Indiana University Purdue University
• Stuart Lewis University of Edinburgh
• Lieven Droogmans @mire
• Ingrid Parent University of British Columbia (UBC)
• Eloy Rodrigues University of Minho
• Steve Gass MIT
• …Plus two at-large Member Representatives
Many Other Active Groups
• Dspace Committers
• Distributed Contributors
• DSpace Community Advisory Team
• Vision Group
• DSpace Ambassadors
• DSpace Sponsors – now Members!
1.Focus on IR fundamentals, modern
2.Be lean & flexible
3.Include “core IR” functionality which
can be extended
4.Be designed to integrate well
5.Support low-cost, hosted
Draft Product Plan(ning)
• Team: 6 Committers & DCAT
• Analysis: DSpace Vision Survey
“features importance ranking”
– Feature categorization
– Rough draft of use cases
– Where do we stand on popular features?
• “Non-Functional” platform goals
Survey Feature Gaps
By Average Ranking
(34 total) Very Highly Ranked
>7.5 avg out of 10
NOTE: Survey purposefully listed features
& needs which we knew were not yet met.
5.0-7.5 avg out of 10
Highly Ranked Gaps…
• 4 most highly ranked, unmet needs:
– Batch upload via UI
– Relationships between objects*
– Configuration via Admin UI
– Template driven UI for easy branding
Very Highly Ranked
End User UI
• DSpace should strive to:
– Be Easy to Install
– Be Easy to Upgrade
– Be Scalable and have Good Performance
– Be Attractive to New Developers
– Be Attractive to New Repo Mgrs
– Avoid maintaining duplicative codebases
Group felt these are important in maintaining
a sustainable community product
Likely Project Scope
• Need *single* UI and to decrease
duplicative code / functions
– Current maintenance effort is high
– Ongoing development effort is double
• Refactoring or rebuilding of codebase
– Codebase & architecture is aging, needs
cleanup / enhancement
– Again, decrease duplicative code
• Our “organic” development model is
not good for significant work
• Organized/funded project needed
– Hire a Product Manager
– Full time Tech Lead
• Model to make Product decisions
• Process to achieve our Product goals
Product Planning Process
Develop high level
High level vision
High Level Vision
Develop high level
High level vision
• Set vision for DSpace:
– Conducted recently.
– High Level.
• Updated every few years
High level vision
– Help validate the Vision and ensure it is in line with the needs
of the Community.
• Use Cases will be refreshed based on the survey feedback.
High level vision
• High-level plan based on:
– most recent Product Vision
– latest Survey and Use Cases.
• Approved by the Steering Group
• Updated every year/release
• Determine implementation options
• Meet the Product Plan's yearly goals. Decisions such as which third-
party tool or technology to recommend in order to meet a
particular use case/need.Approved by the Steering
• Updated every year/release
High level vision
High level vision
• Executable plan:
– Based on Product Plan and recommended Impl. Options
– Scheduling major features for major releases.
– NOTE: will include features/improvements contributed by the
community. Combination of known community contributions
and planned development.
• Updated every year/release