This page captures planning efforts to formalize the VuFind Community, as discussed during the 2020 VuFind Summit.

This section lists roles and responsibilities that members of the VuFind Community will need to fulfill in order to keep the project functional.

It is certainly possible for one person to fulfill many roles, and for some roles to be shared by multiple people; this list is simply intended to highlight all key activities that need to be accounted for.

In order to form an SMLLC and join the OLF, the project needs to designate individuals to serve in these three roles:

• Primary Manager - for the OLF's purposes, this is the primary point of contact within the Project for OLF Communications + Collaboration. This person executes contracts/agreements with the OLF on behalf of the project.
• Treasurer - this person manages or is deeply familiar with the finances of the project. If Project chooses Full Project status and does banking with the OLF, this person is designated to approve expenditures of the project, can wield a credit card and bank account ownership on behalf of the project, and is available to coordinate with the OLF Treasurer on reporting and annual bookkeeping.
• Secretary - this person manages the minutes of the project including any resolutions required to document business with the OLF. This person also manages and maintains all contracts brokered and executed through the SMLLC on behalf of the project, and supports the activities of the Primary Manager and the Treasurer.

• Internationalization Manager - as part of the release cycle, coordinate the activity of volunteer translators to keep VuFind's language files up to date with newly-added strings.
• Project Server Administrator - patch/maintain/monitor the operating system and software on server(s) hosting tools used by the VuFind community. This currently includes:
  • Dokuwiki
  • Jenkins
  • JIRA
  • VuFind demo instance
  • VuFind website (reverse proxy on top of GitHub pages)
• Project Software Administrator(s) - manage key software applications for the project. These include:
  • Dokuwiki Administrator - use escalated privileges to manage Dokuwiki application; receive/monitor notices of page changes to prevent/revert malicious updates.
  • GitHub Administrator - use escalated privileges to manage GitHub resources (vufind-org community, releases, etc.)
  • Jenkins Administrator - use escalated privileges to manage Jenkins application; update plugins/configurations as needed.
  • JIRA Administrator - use escalated privileges to manage JIRA application, including license renewals through Atlassian.
  • SourceForge Administrator - use escalated privileges to manage SourceForge resources (news feed, mailing lists, downloads).
• Release Manager - schedule releases, ensure that outstanding tasks are completed on schedule, and work through the release checklist whenever a new version is released.

• Committers / Code Reviewers - commit to the main vufind-org repositories and review/merge pull requests. There should be a qualification process to gain these privileges, and a mechanism for ensuring that reviews are completed by the most appropriate individual(s) in a timely fashion.
• Documentation Experts - maintain the project's documentation (wiki, introductory book, videos, etc.) to ensure it remains accurate and logically organized.
• Technical Support Experts - monitor incoming communication channels (mailing lists, Slack, JIRA tickets, etc.) and assist users who are encountering problems.

• Community Call Host - plan monthly Community Calls (set agendas) and moderate/host the events. This also includes ensuring that a viable communication platform is available for the calls.
• Newsletter Editor - monitor ongoing development (pull requests, JIRA tickets, Community Calls, etc.) in order to maintain the activity lists for the monthly newsletter; an executive summary also needs to be written each month to highlight key developments.
• Project Advocates - present on behalf of VuFind at conferences, provide references to potentially interested institutions, and otherwise increase the visibility of the software through active communication.
• Summit Planners - take responsibility for planning annual conferences: developing calls for papers, scheduling, communication platform selection, event hosting, post-event surveying, etc.
• Video Editor - edit tutorial videos, Summit outputs, etc.; polish/correct machine-generated transcripts.

The list of roles above does not explicitly account for decision-making within the project. How do we set priorities, make architectural decisions, etc.? Does the project need a “lead architect” role, or some kind of technical steering committee? This is an important gap that will need to be filled, but depending on the mechanism decided upon, the role(s) involved might vary.

OSS Watch's Governance Models document provides some helpful food for thought.

How do we determine assignment of roles to individuals? Is there a fixed term for serving in each role? What happens if someone is suddenly unable to fulfill their obligations? How do we keep things running in an emergency?

This section lists known and potential expenses that the project will need to meet in order to survive.

• Annual OLF membership fees.

• Emergency fund (to hire temporary staff to aid in a leadership transition)
• Grants/bounties (to encourage development of key features, or expand project participation)
• Server fees (if we switch from institution-supported project resources to cloud-hosted services)
• Training costs (to hire trainers and cover other expenses for ongoing training programs)

The project needs a formal mechanism for receiving support. Some questions to discuss:

• Do we need to define specific levels/tiers of financial support? Do we need different criteria/options for institutions vs. vendors vs. individuals?
• What are the benefits of support?
  • A listing on the website?
  • Increased/discounted access to events?
  • Privileged access to certain project roles?
  • Weighted input into decision-making/prioritization?
• Do we need a formal mechanism for recognizing non-financial support (e.g. commitment to assign institutional resources to a particular role for a particular amount of time)?
• How can we recognize regional differences (currencies/economic status/language/etc.)?
• Options beyond membership model:
  • Grant-seeking: this would require a new project role for grant-writing and management; potentially very time-consuming, and with only intermittent/uncertain benefits (but possibility of large windfalls)
  • Service-provision: can the community run training courses or provide services like hosting? This incurs additional expenses and responsibilities. Do we need a formal, well-defined partnership model for these types of services?
  • Sale of content (e.g. books) – how would we structure this, and how would we differentiate it from free offerings in a fair/useful way? Perhaps a “pay what you wish” model would be a viable option, but this would require infrastructure to set up.
  • Donation solicitations – many projects ask for donations on their download screen; would this be appropriate for us? Again, administration is a cost.