Process for Establishing a New Hyperledger Special Interest Group (SIG)

A Hyperledger Special Interest Group (SIG) is a community focused on a particular industry sector or activity with a shared interest in advancing a common understanding of how blockchain technology in general, and Hyperledger technology in particular, may be applicable. Members of a SIG include both technical participants (ideally including some from Hyperledger software projects) and business-level practitioners from relevant organizations. Together they share and discuss common software product needs, lessons learned from the real world, information about related or relevant code or standards from elsewhere, and other information they see fit. They also are expected to produce work products relevant to their sector of interest.  

SIGs differ from Hyperledger Working Groups (WG) in that WGs are focused on the development of the Hyperledger software projects and are not tied to a specific sector. The work products of the SIGs can be diverse based on each SIG's charter and focus, and are driven by the chairs and members of the SIGs. For example, SIGs might produce papers, case studies, solution briefs, presentations, blog posts for the Hyperledger blog, recommendations to Hyperledger Working Groups or new ideas or wish-list requirements to software projects, or other such content that can help others better understand their needs. SIG research and discussions might  also lead to software development activities, which would be expected to flow into a Hyperledger Lab, or even possibly to proposals for new Hyperledger projects. SIGs don’t oversee the creation or development of software or code. SIGs do not oversee the creation or development of software or code and all related work to SIGs that occur in WGs, Labs, or Hyperledger Projects will fall under the domain of the Technical Steering Committee (TSC) and the processes established by and governed by the TSC.

Each SIG will have an assigned Hyperledger Staff point of contact from the Hyperledger Ecosystem team who will work closely with the SIG Chair to ensure that the SIG and its participants are working together towards the SIG’s chartered goals as established when the proposed SIG is approved. Hyperledger SIGs are supported by Hyperledger staff and they self report on a quarterly basis by posting on the public wiki. Monthly reports on SIG activity are prepared by Hyperledger staff for the Governing Board.

Initiating a new SIG

1. Any community member may propose a new SIG considering the following parameters:
1. The proposed SIG should be sufficiently differentiated from all other SIGs. If a proposed SIG is similar to an existing SIG, we encourage the proposer to reach out to the existing SIG and determine whether or not there is enough overlap in the mission and scope that the proposed SIG could make sense as a part of an existing SIG.
2. If the proposer(s) determines that the proposed SIG is differentiated enough they will need to provide a justification in the proposal for why it should be a new SIG and not part of an existing one.
3. If a proposed SIG plans to be more technical in nature than what normally falls under the scope of a SIG, Hyperledger staff may propose they instead follow the WG process and connect the proposer(s) to the Hyperledger Community Architects for support in that process.
2. In order to initiate a new SIG proposal, a community member will need to:
1. Reach out to Hyperledger Ecosystem team (membership@hyperledger.org) to let us know your interest in starting a group. 
2. Visit the SIG Proposals page to review previous proposals and the Proposal Template that can be copied to create a new SIG proposal. Typically the community member proposing the group lays out an initial high-level mission and goals for the group and invites others to join the group. In order to be approved officially by a Hyperledger staff, a group must have at least 15 interested parties and meet the criteria in #1 above. The Hyperledger Ecosystem team can also assist in bringing on new interested parties. 
3. After initial discussion with Hyperledger Ecosystem team, the proposal will be added to: “Proposals in Process” until final approval or rejection as a SIG. The proposal can continue to be worked on while the proposer is working to reach the minimum of 15 interested parties. Hyperledger staff can help with finding interested parties by reaching out to community members or contacts that have indicated an interest in the topic or are involved in similar activities.
3. During the approval process the initial SIG community proposers/members should identify the overall goals of the group in order to attract interested parties, and then once the group is officially approved, the group should work to layout the remaining elements of the charter using the SIG Charter Template (i.e. work products, meeting time and cadence, etc.).

Note: Keep in mind that your initial idea will evolve as new people join your group and add their own thoughts and ideas about what the group should focus on. It is a sign of a healthy community effort when multiple people are able to collaborate together and share ideas, thoughts and suggestions in a collaborative way. Revising and updating your initial idea based on group input will be one of the first tasks when the group official launches.

After Approval of SIG

When a new SIG gets approved, Hyperledger staff will ensure the following items are completed:

• A Hyperledger staff member is identified as the point of contact for the SIG. This staff lead will be the main point of contact for the SIG's chair and will oversee the specific SIG.
• Schedule a SIG Chair on-boarding session
• Set up real-time chat channel for the SIG. Channel should be named #{SIG-name}-SIG.
• Set up the mailing lists for the SIG.
• Set up a wiki space for the SIG. Hyperledger will create a space at https://wiki.hyperledger.org/groups/{SIG-name}. See other SIG pages for reference here: https://wiki.hyperledger.org/#Hyperledger-SpecialInterestGroups. The SIG Proposal will be moved into the new SIG space.
• Share the schedule for the SIG's quarterly updates. This should be captured on the calendar for the SIG at https://lists.hyperledger.org.
• Send Welcome Email Template to interim chair
• Work with the SIG's chair to ensure that the community calendar is updated (Hyperledger Community calendar) to include the date/time of the meeting. 
• Send out a calendar invite to the mailing list once a regular meeting cadence is established

When a new SIG is approved, the SIG interim chair will ensure the following is completed:

• The new SIG’s first order of business will be to finalize the Charter and select an interim Chair. Please refer to the charter template below. The chair will copy the SIG Charter Template into the new SIG wiki and incorporate relevant portions from the proposal into Sections 1-4. The chair will also work with the community to finalize these portions and the Charter fully. https://wiki.hyperledger.org/pages/viewpage.action?pageId=16320421
• Establish a regular meeting day/time/cadence with input from the community, taking into consideration time zones and also consulting with Hyperledger staff that days/times don’t overlap significantly with other community calls.
• Set up the SIG Wiki space and pages with content to make it easy for members and the public to join and participate.
• Establish an agenda for the first meeting which can include:
• Introductions of all interested parties
• Discussion to finalize Charter elements and future work products
• Presentation on project from a community member
• Begin carrying out regular SIG Chair responsibilities which include:
• Facilitating the group and helping ensure that the mission statement and goals are observed and met
• Scheduling and facilitating regular meetings open to all SIG membership
• Developing and distributing meeting agendas at least one business day before the scheduled meeting
• Ensuring that all group members have the opportunity to participate in decisions and provide input even when not attending a meeting. SIG communities are global and a chair should make efforts to ensure all are included in the community’s activities. This can be done by ensuring meeting notes are shared after calls and any major decisions are shared on the mailing list.
• Ensure recordings/minutes are taken during meetings which captures the discussion and includes a list of meeting participants, shared post meeting, and are added to the SIG wiki page
• Manage the SIG wiki page
• Generate Quarterly Updates to present to Hyperledger staff in a timely manner and communicate regularly on any concerns or questions related to the SIG
• Serving as a proxy and ambassador for SIG membership (as appropriate)
• Enforcing adherence to the Hyperledger Code of Conduct and communicating the Linux Foundation Antitrust Policy at the beginning of every meeting.

When a SIG starts producing deliverables

Each SIG is unique and will be focused on producing a set of work products that are relevant for their sector. The following list is what we have seen most SIGs work on and serves to help new communities get a sense of what SIGs often produce and hopefully provide inspiration as your group defines its work products. Hyperledger staff can also assist the SIG community in accessing broader community resources to support the SIG with the work it is wanting to produce.

• Published documents: SIGs often decide to produce written work that relate to their discussions, backgrounds, and research. Written work could involve short pieces that are published on the Hyperledger blog to longer form pieces that are polished and promoted in the publications section of the Hyperledger site. Hyperledger staff can help the SIG with reviewing the content, ensuring it is relevant and within SIG scope, meets the standard of Hyperledger publications, and facilitate publishing and promotion these documents.
• Presentations: Many SIGs use time at their regular meetings to have presentations to their group members from others in the community, outside experts, researchers, WG representatives, and Hyperledger project representatives. The Chair and SIG community members work together to identify speakers but if needed, Hyperledger staff can also help identify speakers from the broader Hyperledger community.
• Written documentation & research: Some SIGs build databases of use cases in their industry, best practices, taxonomy, existing implementations, etc. SIGs can create requirements that technical communities can draw upon to inform their software development. They can also produce content in the form of blogs, solution briefs, or white papers (some may require review by the TSC if there are technical elements) relevant to their sector topic.
• Hyperledger Labs projects: Some SIGs may be interested in producing code and in these instances the Hyperledger staff point of contact will help them through the process of creating a Hyperledger Lab so that the group’s coding effort can happen within the technical community at Hyperledger. We have seen so far that the Healthcare SIG has been interested in working on code related to a use case they were exploring and more recently the Telecom SIG has also started a Labs project based on a use case that is relevant for them. If you would like lessons learned on how they’ve gone about this, please feel free to reach out to those SIG Chairs and/or mailing lists.
• Talks and demos at events: Helping SIG members present about the work of the group is a great way to recognize the work of group members and help bring new people into the group. Hyperledger staff can help connect group members with talk and demo opportunities at events and providing travel support as needed for the group chair or key group members to attend events.

Terminating a SIG

As with any community, there will be a natural lifecycle to each SIG and some may close down at some point. As more SIGs mature with some potentially reaching the end of their lifecycle, the criteria to terminate a group may evolve and this wiki page may be updated. There will be some natural indicators coming from the group itself -- for example, in their quarterly reports groups may talk about how they feel that they have met the goals they set for themselves at the time that they started or that they feel like there are no more useful actions or discussions for the group members to take. Several months of inactivity, significant loss of membership, along with lack of chair leadership may also lead to a SIG closing down. A SIG may always be restarted however, if new parties join and would like to resume a SIG under the same title. The process would be the same as for starting a new SIG.

In certain, rare cases where there is a sudden departure or inactive leadership of a SIG, a Hyperledger staff point of contact may temporarily assist with the basic operations of SIG activities to keep the community active and rebuild membership. However, this is a temporary situation and eventually the community will hold an election for a new chair or a chair will be identified to take over SIG chair duties if no one presents themselves as a candidate. If chair leadership cannot be established, this may also be a reason to terminate a SIG.

Considering the above factors, the decision to close a group will be made by Hyperledger staff. When a group is closed Hyperledger will archive the wiki, mailing list and other artifacts so that others can still learn and make use of the work the group did while active.