Date: Thu, 28 Mar 2024 20:24:59 +0000 (UTC) Message-ID: <914189643.15.1711657499057@71c57bd6c662> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_14_712735838.1711657499056" ------=_Part_14_712735838.1711657499056 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
You need help or advice to set up a Samvera Interest Group or a Working = Group? You've come to the right place!
If this page doesn't answer your questions and you still need help, then= you might want to
...but please read the relevant bits of this page first!
Interest groups, as comp= ared to working groups, are for discussion rather than developing specific = deliverables. It is expected that working groups will be formed out o= f interest groups as requirements emerge from the conversations.
Working groups are the main working vehicle within =
the Samvera Community and may stand alone or be born out of existing Workin=
g Groups or Interest Groups. They are created to perform specific tas=
ks in a defined realm and timescale, thereby allowing collaborative work to=
flourish in a structured environment.
Interest groups can be f= ormed at will. A lightweight statement of the topic, the scope and objectiv= es of discussion of the interest group should be documented in the wiki using the standard template, an= d at least one channel for communication noted. Interest groups do no= t need to be approved, but should not be formed without some level of need = within the community.
At least three organizations m= ust be represented in an interest group. Anyone may be part of an int= erest group with or without a Contributor License Agreement, as there are n= o deliverables from the group.
All of the discussions of the interest group should=
be transparent and public and the channels used for communication must be =
published, but there may be situations where either the discussion takes pl=
ace offline or is not suitable for public dissemination.
<=
/span>
Working groups should be able = to be convened with a minimum of effort, while allowing participants to und= erstand what they are signing up for. The group should emerge naturally fro= m discussions and needs within the community, while not penalizing individu= als or organizations that were not part of those initial discussions.  = ;Using existing channels, such as interest groups, participants in discussi= ons that show promise of inter-institutional convergence and the possibilit= y of joint development work should document the shared needs and requiremen= ts. This documentation should be more persistent and visible than an = email thread, but need not be overly formal. The preferred method is = a maintained page within the Samvera wiki using the template provided there, otherwise a publicly share= d document linked from the wiki is sufficient.
The documentation process shou= ld result in a common understanding of:
The overall domain into which the discussion falls
The shared needs and requirements within that domain
Use cases that demonstrate these needs and requirements
=A path towards one or more products that would meet the requiremen= ts
The organizations willing to commit resources towards realizing th= e product(s)
The timeframe in which the product(s) are needed and should be pos= sible
This document, henceforth the = charter, provides the definition of the working group and its deliverables.= It is not a contract and may be changed with the consensus of the me= mbers of the working group at any time, however significant changes such as= a 6 month or more delay in timeframes, the abandonment of a deliverable, o= r the change in the overall scope of the work should be announced to the Sa= mvera Community via the regular channels.
Once the draft charter is acce= ptable to the participants in the discussion, there is a Call for Participa= tion (CfP) issued. This is simply an email to the appropriate lists w= ith at least [CfP] in the subject heading that announces the document and s= eeks the engagement of the additional participants. Organizations must resp= ond publicly that they are willing to take part and commit development reso= urces towards the working group's goals. At least three Partners must= respond positively, and no more than three Partners may respond negatively= , for the working group to be approved. If fewer than three Partners = are willing to contribute, then the working group's topic is likely too spe= cific and the work should be done outside of the Working Group process. &nb= sp;If more than three Partners object to the work being done, then there is= a significant issue that should be resolved before committing resources.= span>
At least two calendar weeks mu= st pass between the CfP and the working group being approved. If ther= e are only one or two Partners interested after four calendar weeks, then t= he CfP is ended and the charter should be discussed and modified before re-= announcing.
Once the working group is appr= oved, the link to the charter will be added to the Hydra Wiki page that lis= ts active working groups.
All members of a working group= producing code must be licensed Samvera contributors covered by the approp= riate CLAs, otherwise members must agree that textual materials may be rele= ased under a Creative Commons Attribution 4.0 International License. = This is to ensure that the deliverables of the group are unencumbered by in= tellectual property restrictions. Participants meeting these requirem= ents may join at any time, without any prior approval process: the gateway = is activity, not reputation.
All discussion within the work= ing group must be transparent. This means that meetings must have not= es taken about the attendance and any decisions or action items, general di= scussions take place on mailing lists maintained by the community, IRC logs= should be posted and so forth. Any meetings, face-to-face or telecon= ference, at which decisions are made must be announced in advance and open = to any working group participant, otherwise any opinions expressed at the m= eeting must also be discussed on a mailing list. Meeting times should= be published far enough in advance to allow members to schedule their part= icipation, and preferably use a consistent schedule. The Partner institutio= ns are responsible for ensuring the transparency of the discussion, but eve= ry participant is encouraged to take an active role in this regard.<= /p>
Working groups must remain act= ive. Any working group that does not respond to comments, questions or conc= erns either from participants or the community will be removed from the lis= t of active working groups in the wiki.
Working groups must strive to = meet their timelines and produce the deliverables designated in their chart= er.
The working group must always = have at least one participant designated as Facilitator. Facilitators= are responsible for promoting continued activity within the group. T= he Partner institutions are responsible for ensuring there is active facili= tation, however the Facilitator is not required to be from a Partner.  = ;Facilitators have no additional powers or rights than any other participan= t.
Working groups may self-= organize in the most convenient manner to accomplish their tasks, including= creation and assignment of additional roles and responsibilities as approp= riate. Sub groups may be formed and disbanded at will, consisting onl= y of members of the Working Group. They do not need to separately meet the = requirements of the Working Group, such as having their own Facilitator or = Partner members.
A list of existing Samve= ra interest groups and working groups is maintained here: Interest Group (IG) and= Working Group (WG) Hub