Leadership supports no longer providing dates for the release timeline. What pages need to be updated?

DSpace Release 7.0 Status

Dates have been changed more than 40 times; great number of institutions counting on release of DSpace 7 for their projects where the timeline is important; no precise dates but turn into a positive message

Focus on a stable and high quality release

DSpace 7 page on web site

Status page on wiki, who updates? Bram to update, this group to review by 10/11/19

Section on release schedule/timeline

Try to include positive messages

Tim's slides from OR had lots of information about the impact and importance of this release, perhaps use some of this info in pivot message (particularly the infographics on quantity / quality of code)

Develop a communication package to the larger community about this pivot

Google doc by 10/11/19, Carol

DSpace 6 is a very good stable version to work with

Community is supporting last 3 versions, plenty of time and support to work with past versions

Older versions will continue to be supported

There will be migration procedures to help 

DSpace 6 compatible with Java 11?

Susanna developed and presente the "Adopt a feature" idea at the North American DSUG meeting last week: when estimates are ready it might be easier to find developers will that volunteer to have it done or  institutions that pay to "sponsor" a feature

Feedback from DSUG was positive (easier to raise money for a specific feature than for a generic contribution to the community, as the decision makers can see where the money goes)

Parts of budgets have not yet been spent in 2019

Step 1, LYRASIS management question, Carol to ask

Bram has had similar convos with Atmire clients, if all of funds are not earmarked in last 3 months, working with existing contracts may be easier. Susanna says it's the same situation for 4Science's clients.

End of year may be too soon to begin a new fundraising campaign, but it does not need to be concluded by end of 2019, need an agreement by end of 2019, does not need to be concluded/paid

Adding features to DSpace 7 requires code review, cannot promise that any feature will be implemented exactly as imagined, really selling R & D time, monthly updates/accountability to sponsor may be required, very hard as a deliverable, will depend on how complex the feature is, features are interdependent 

But the idea of "adopting" is a contribution-type idea to the community effort, it should not be related to any "purchase" or "delivery" concept, "Adopt" is not control over feature

Community makes features available ultimately

Off topic but related:

Minor releases are less attractive as fundraising benefits/incentives

Minor release of say DSpace 5, would LYRASIS be able to give an RSP recognition for coordinating a minor release?

Finding more active committers after release of DSpace 7