Working Group-Level Processes - ARCHIVED

Working Group Onboarding

Deprecated content

This might be obsolete content following 2019 after the consolidation the concept of projects and working groups under the unified notion of projects. For the latest information on the infrastructure provided to projects see the Open Developer Platform documentation.

Soon after a new Working Group is approved, Foundation staff will create the following infrastructure for the group.  Although that infrastructure will have been created and minimally configured, further configuration and content creation will be required, and the Chair of each new Working Group is expected to coordinate the completion of those tasks as soon after approval as possible.

Initial Infrastructure

As part of onboarding a new Working Group, the Foundation creates the following infrastructure components:

Wiki Pages (Atlassian Cloud Confluence)

A dedicated sub-tree of wiki pages will be created within the hosting Program's wiki "space" (site), and the Working Group chair granted full read/write access to them.  If the Working Group Chair doesn't have an account on the Foundation's Confluence instance yet they will receive an invitation via email.

We use a basic template for this space, with the following structure:

• Working Group page
  • Minutes of the Working Group
  • Tasks of the Working Group

If you’re new to Confluence, it's worth reviewing their Getting Started guide.

Email Distribution List (Google Groups)

Each new Working Group will have a working group created, and the Working Group Chair will be configured as the manager of the list (to support ongoing list management - the Chair, or Working Group participants they nominate, are expected to manage all list subscriptions going forward).  The Foundation will, to the best of our ability, subscribe the appropriate Working Group participants to the list at creation time.

The list will have a name of the form <program name>-<working group name>@finos.org.

If you're new to Google Groups, it's worth reviewing the Google Groups Help Center.

Google Groups can only be administered via the Foundation's Google Groups admin console, using a Google Account.

If no one in your PMC has access to the Google Groups admin console, the /wiki/spaces/FINOS/pages/77955298 can maintain your Program's lists.

Post-Approval Tasks for the Working Group Chair

Despite the Foundation initially creating and configuring this infrastructure, there are still a number of tasks that the new Working Group's participants will be required to complete soon after approval, coordinated by the Working Group Chair.  These tasks are captured as Confluence tasks in the "Tasks of the Working Group" page mentioned above, and the Chair should review their Confluence task list to see the specifics.

Meetings and Decision Making

Deprecated content

This content might be obsolete as the page was archived following deprecation of the concept of FINOS Programs in early 2020. For the latest on FINOS Corporate Governance please refer to the FINOS website while for the Community Governance check the FINOS Community Github Repository and specifically see here more information on FINOS Meetings Procedures.

Regular meetings are a key feature of most FINOS programs and working groups. Here is the typical process: 

1. Schedule the meetings

Find a day and time that works for all or most participants. FINOS recommends that working groups and PMCs meet at least monthly.

Once you have a meeting time, contact the Foundation to schedule a recurring Webex meeting. (We don't recommend using other conference solutions as firewall restrictions may prevent members from joining.)

2.  Prepare and circulate an agenda

Before each meeting, create an agenda (using the Meeting Minutes page template) listing the topics to be discussed and decisions to be made at the meeting, and circulate the agenda on the group's mailing list.

See this sample agenda for an example.

3. Keep minutes

The minutes of each meeting should capture all of the following:

1. Roll call - everyone who attended the meeting
2. For each agenda item:
   1. A brief summary of the matter discussed (one sentence is often enough)
   2. Any significant positions/proposals put forward (one sentence each is often enough)
   3. A record of any decisions made or actions taken, including a record of the vote (i.e. votes in favor, votes against, and abstentions)
3. Any action items assigned, including the assignee and the deadline (if any)

Minutes should not:

• Attribute any statement to an individual or organization without their express prior approval. This is to ensure that people feel free to speak candidly.
• Include an exhaustive transcript of everything said during the meeting. This is to ensure that the important parts are easy to find.

After the meeting, circulate minutes to the group. This is typically done by updating the wiki page with the meeting agenda, as in these example meeting minutes. 

4. Call votes as needed

If any item on the agenda requires a decision by the group, hold a vote. Consult the Program Operations Policy for any program-specific voting rules. If the program uses the default POP, you can follow the Foundation's recommended voting procedure. 

The default POP does not require a particular quorum for voting at working group meetings. However, if a meeting is lightly attended, consider holding any votes that are discussed via email after circulating the meeting minutes, to give everyone an opportunity to participate.

Agendas are required

Every meeting must have an agenda and discussions at meetings must be limited to the topics on the agenda, per the Foundation's Antitrust Policy.

Agenda page title and location

To be properly capture automated attendance metrics, the meeting minutes page must be created under the Project or Working Group specific Confluence page and the title must adhere to the following format: “YYYY-MM-DD [WG shortname] WG Meeting Notes”. See example here.

Don't worry if you didn't capture everything!

The Foundation records every working group meeting scheduled through the FINOS Webex infrastructure. Upon request of the working group chair (to help@finos.org), we'll order a transcript of the meeting to aid you. (Transcripts take at least 24 hours to prepare from the time of the request and are only available for meetings scheduled via the FINOS Webex or recorded separately by the working group chair.)

Only active participants are eligible to vote

Please see the Active Participation Policy to determine who is eligible.

Best practices for running meetings

The following are a variety of best practices for ensuring meetings are effective:

• Ensure a good audio connection. Laptop audio is often worse than a phone call.
• Minimize background noise. Mute yourself and (if necessary) other participants when you or they are not speaking.
• Open the conference call 5 minutes before the scheduled start time.
• Start the meeting 5 minutes after the scheduled start to give people time to join.
• Keep the meeting to the agenda. Move off-topic discussions to the agenda for the next meeting, or the mailing list.
• If a discussion becomes unproductive, move on. Ask the participants to send their proposals on the mailing list or as agenda items for future meetings.
• End the meeting on time, even if you don't get through the agenda, so those with other appointments do not miss important discussions.

Adding a New Working Group Participant

Deprecated content

This content might be obsolete as the page was archived following deprecation of the concept of FINOS Programs in early 2020. For the latest on FINOS Corporate Governance please refer to the FINOS website while for the Community Governance check the FINOS Community Github Repository and specifically see here more information Software Projects and Standard Projects default governance.

Working Groups are intended to be self-managing, and amongst other things that includes defining eligibility criteria (if any) for participating in the Working Group.  Beyond that, Working Groups can approve new participants themselves, without having to obtain any kind of approval from the PMC.

Requesting Steering from the PMC

Deprecated content

This content might be obsolete content following 2019 after the consolidation the concept of projects and working groups under the unified notion of projects. For the latest information on how to run collaboratives groups in FINOS see our Community Governance.

One of the formally-defined responsibilities of each Program's PMC is to provide technical guidance to working groups, either:

1. upon request; or
2. when a working group appears to be faltering or diverging from the scope of the Program

In order to support the second scenario and to assist in providing visibility to the Foundation's board, working groups are required to report on their current status and recent operations when requested to do so by the PMC.

Contacting a PMC

If a working group wishes to contact the PMC for proactive steering, they should do so via the relevant /wiki/spaces/FINOS/pages/77955298, or have their chair raise the issue verbally at the next PMC meeting.

Private or Sensitive Information

In the rare event that a working group wishes to discuss private or sensitive matters with the PMC, they should use the PMC's private mailing list.  Alternatively, you can also contact an individual PMC member directly and ask them to represent the matter in person to the PMC (such matters will not be recorded in the PMC's meeting minutes).

Please note that the PMCs is not responsible for handling Community Code of Conduct violations - please see that page for details on reporting such incidents.

Because amended POPs may remove the requirement that all Working Group Chairs sit on that Program's PMC, it may only be possible to send an email to the PMC mailing list in those Programs that have amended POPs.

Before participating in a Program, you should always check whether it has an amended POP, and if so, review it carefully to make sure you're comfortable with the changes it has introduced.