Warning: This page has not been updated in over over a year and may be outdated or deprecated.
community:planning
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
community:planning [2020/10/12 15:20] – [Project Administration/Management: Required Roles] demiankatz | community:planning [2021/03/10 16:46] (current) – demiankatz | ||
---|---|---|---|
Line 5: | Line 5: | ||
===== Roles and Responsibilities ===== | ===== Roles and Responsibilities ===== | ||
- | This section lists roles and responsibilities that members | + | The contents |
- | + | ||
- | ==== Open Library Foundation: Required Roles ==== | + | |
- | + | ||
- | 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, | + | |
- | * Treasurer - this person manages or is deeply familiar with the finances of the project. | + | |
- | * 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. | + | |
- | ==== Project Administration/ | + | |
- | + | ||
- | * Project Server Administrator - patch/ | + | |
- | * 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; | + | |
- | * GitHub Administrator - use escalated privileges to manage GitHub resources (vufind-org community, releases, etc.) * Jenkins Administrator - use escalated privileges to manage Jenkins application; | + | |
- | * JIRA Administrator - use escalated privileges to manage JIRA application. | + | |
- | * SourceForge Administrator - use escalated privileges to manage SourceForge resources (news feed, mailing lists, downloads). | + | |
- | * Release Manager - someone needs to be responsible for scheduling releases, ensuring that outstanding tasks are completed on schedule, and working through | + | |
- | * Committers / Code Reviewers - some members of the community need to be able to commit to the main vufind-org repositories and to review/ | + | |
- | * Community Call Host - someone needs to plan for monthly Community Calls (set agendas) and moderate/ | + | |
- | * Documentation Experts - some members of the community need to maintain the project' | + | |
- | * Newsletter Editor - someone needs to 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 - some members of the community need to be willing to present on behalf of VuFind at conferences, | + | |
- | * Technical Support Experts - some members of the community need to monitor incoming communication channels (mailing lists, Slack, JIRA tickets, etc.) and assist users who are encountering problems. | + | |
===== Expenses ===== | ===== Expenses ===== | ||
Line 46: | Line 18: | ||
* Emergency fund (to hire temporary staff to aid in a leadership transition) | * Emergency fund (to hire temporary staff to aid in a leadership transition) | ||
+ | * Grants/ | ||
* Server fees (if we switch from institution-supported project resources to cloud-hosted services) | * 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) | ||
+ | |||
+ | ===== Support ===== | ||
+ | |||
+ | The project needs a formal mechanism for receiving support. Some questions to discuss: | ||
+ | |||
+ | * Do we need to define specific levels/ | ||
+ | * What are the benefits of support? | ||
+ | * A listing on the website? | ||
+ | * Increased/ | ||
+ | * Privileged access to certain project roles? | ||
+ | * Weighted input into decision-making/ | ||
+ | * 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/ | ||
+ | * Options beyond membership model: | ||
+ | * Grant-seeking: | ||
+ | * Service-provision: | ||
+ | * 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. | ||
---- struct data ---- | ---- struct data ---- | ||
+ | properties.Page Owner : | ||
---- | ---- | ||
community/planning.1602516003.txt.gz · Last modified: 2020/10/12 15:20 by demiankatz