Meeting Information

Date and Time: September 25 2024, 11 AM-12 PM (EDT)

Meeting link: See calendar invitation

Attendees

• Maureen Walsh (Chair)
• Pascal Becker
  
• Scott Hanrath 
  
• Erica Johns
  
• Kristi Park
  

Note taker. Rotates each meeting

Agenda

Notes

The MoU passed the Leadership Group. It is send to Lyrasis. Lyrasis gave feedback about it, but other people at Lyrasis have to review it now.

The working group will continue with drafting DSpace bylaws now and then to the operating manual.

There were again issues with the voting process for the Leadership Group: the institution of a LG member was not contacted correctly in time, so they did not responded. Governance is currently not included in the voting process and that should change. We should include this in the bylaws.

It was suggested to have bylaws for the DSpace Governance and one operation manuals for each of the following groups: Leadership, Steering, DCat, Committers.

In the notes from our meeting on 2024-03-27 DSpace Governance Working Group Meeting, we have links to several other bylaws of comparable communities. Kristi Park will start a skeleton bylaws document, basically containing headings, that the working group will then pick up to work on. The bylaws and the MoU will overlap in some parts, as the bylaws will define how DSpace sees itself and the MoU agrees with the organizational home on these fundamentals. That means we can build up on some of the definitions we put into the MoU. The MoU is not public, the bylaws will be.

The bylaws will define what we do, the operation manuals will explain how to do it. For example the bylaws should state the fiscal year (July to June) and the governance year (November to October). It should also contain that there are votes for the Steering and Leadership Group. The operation manuals should then show out how the voting process works. The operating manuals are subject to the bylaws, but the bylaws are not subject to the operating manuals. The operating manuals refer to the bylaws. The bylaws should state that there are/will be operating manuals and who and how they will be changed/decided on. Another wording for operating manual is rules and procedures. Both wordings are being used.

We use a folder on google drive for working on the bylaws.

The general plan is to have a first version of bylaws for the Leadership Group meeting of February 2024.

At the end of the meeting, a questions and interesting discussion popped up. For most of the members of Leadership Group one of the reasons to join is to represent the money their institution is putting into DSpace. Many of them wants to push features their institutions needs. The problem is, that the DSpace community does not employ a staff of developers that can take the necessary development work. If you want to push a feature, you have to build it yourself and bring it into DSpace or you have to come up with funds. Once you have either the code or the funds to hire someone, Steering and Leadership Groups are very helpful to push things through. Three examples: 1. between DSpace 7.0 and 7.2 or 7.3 there was a voting going on about features that were existing in DSpace 6 but not yet in DSpace 7 at that time. This voting was used to determine the priority certain features get. The features were then build by service providers who were paid from the DSpace community out of funds gathered to finish the work on DSpace 7 and from DSpace membership fees. At that time we hade money to hire developers (or actually service providers) and were able to make decisions in steering and leadership. 2. For DSpace 7.6 we had three features that were not reviewed while being finished. Steering gave priority to these, which helped Tim to push getting these reviewed. But these features were build and done and just awaiting the review. 3. The whole DSpace development fund came from a couple of institutions that gathered money to get ORCID implemented fully into DSpace. The money was used to hire 4Science and was "routed" via the DSpace community. Here we had a group of instiutions that hade money, had to push very hard to get Lyrasis to find a way to accept this money and then Steering to use this money to get ORCID as part of the labor work into DSpace 7. This is probably not clear to a lot of members in Leadership. LG has not much influence on the features coming into DSpace, as we do not have a staff of developers and have to rely on volunteers. The only person with technical abilities hired by the community is Tim, who is desperately needed to organize the development process and cannot develop much himself. If we got (with Scoss funding) a junior developer, they could have helped out with reviews. We would need to employ at least 3 or 4 developers (including Tim) to have enough capacities to lead the development, to do reviews and have some capacities left to implement features LG wants to get into DSpace. We should right a peace for the DSpace newsletter, the website and maybe an addendum to the operating manuals on this.

Action Items

• Kristi Park Starting a skeleton bylaws document (basically headings)
• Maureen Walsh Suggesting new dates for WG meetings
• All members: add ideas to the bylaw skeleton and brainstorming document