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.

Program onboarding

Deprecated content

Soon after a new Program is approved by the board, Foundation staff will create the following infrastructure for the Program, then schedule a kick-off call to review it with you. Although that infrastructure will have been created and minimally configured, further configuration and content creation will be required, and the PMC of each new Program is expected to coordinate the completion of those tasks as soon after approval as possible.

Initial Infrastructure

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

Wiki Space (Atlassian Cloud Confluence)

A dedicated wiki "space" (site) on the Foundation's Cloud Confluence instance will be created and the Program's PMC Lead will be configured with administrative access to it (to support ongoing management of the space). If the PMC Lead 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:

Home page
- PMC page
- Working Group pages (one per Working Group listed in the Program proposal)

The Foundation also uploads the Program proposal and (if applicable) the Program's amended POP to the Home page, and copies some of the information from the proposal into the body of the page; the description / scope of the Program, the PMC Lead, and PMC Members (if known).

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

Email Distribution Lists (Google Groups)

The following mailing lists will be created for each new Program, and the Program's PMC Lead will be configured as the owner of each list (to support ongoing list management - the PMC Lead, or Program participants they nominate, are expected to manage all list subscriptions going forward). The Foundation will, to the best of our ability, subscribe the appropriate Program participants to each list at creation time, based on the information provided in the Program Proposal.

List Name	List Address	Subscribers	Public can read via web archives?	Anyone can post (with moderation for non-subscribers)?	Description
Program List	`<program name>@finos.org`	All participants in the Program	Yes	Yes	For program-wide communication.
PMC List	`<program name>-pmc@finos.org`	PMC Lead and PMC members	Yes	Yes	For most PMC communication.
PMC Private List	`<program name>-pmc-private@finos.org`	PMC Lead and PMC members	No	Yes	For private PMC communication (to be used for sensitive topics only).

The Foundation can also create any additional lists required by your Program - just /wiki/spaces/FINOS/pages/77955298!

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.

Source Code Management (GitHub Organization)

If you don't already have one, the Foundation will create a GitHub organization for your new Program. This is where all source code repositories for projects and/or working groups in your Program should be created.

It will be located at:

https://github.com/finos-<program name>

Initially the organization will have two administrators - the PMC Lead and the Foundation's own super-admin account (finos-admin). The PMC Lead is welcome to configure additional Program participants (the other PMC members, for example) as GitHub organization administrators in order to distribute the management workload.

If you're new to GitHub organization management, it's worth reviewing GitHub's documentation.

Post-Approval Tasks for the PMC

Despite the Foundation initially creating and configuring this infrastructure, there are still a number of tasks that the new Program's PMC will be required to complete soon after approval. These tasks are captured as Confluence tasks in various task pages within your Program's home page.

You and each of the Working Group chairs in your Program should review your Confluence task list to see the specifics.

Approving new projects and working groups

Deprecated content

As defined in the Governance, one of the key responsibilities of a PMC is to approve new Projects and Working Groups that are proposed to be contributed to the Program. Although the Foundation has few restrictions on the criteria a PMC uses to make these determinations, the primary expectation is that the PMC will determine whether the contribution is aligned with the scope of the Program, and the broader mission of the Foundation.

Approval Process

Contributions are registered in the Foundation's Jira instance, and will be assigned to the appropriate Program's PMC Lead once all /wiki/spaces/FINOS/pages/75530375 are completed by Foundation staff. The PMC Lead, or member of the PMC, is then required to coordinate any discussion required within the PMC, and then initiate a formal approval decision, using the Foundation's decision making mechanism.

Once a decision is reached, the result must be recorded in the contribution's Jira issue, and the Jira marked as either "Approved" or "Rejected". If the PMC rejects the contribution, a detailed explanation of why should be added to the Jira as a public comment, so that the contributor has an opportunity to take remedial action if they so choose.

Note that /wiki/spaces/FINOS/pages/75530375 of the contribution is checked by Foundation staff. PMCs are not required to perform this level of validation.

Creating a New GitHub Repository

If the contribution requires a new, empty GitHub repository (for example it's a new concept, being developed in the open from the get-go), the Foundation recommends using the project-blueprint as a template. It contains all of the basic boilerplate content that repositories of Foundation-hosted projects are required to include.

Transferring Existing Code

If a contribution has existing code, it must be transferred to the Program's GitHub organization. There are several ways the PMC can accomplish this; here are a few of the approaches that have worked well in the past:

Source(s)	Approach
GitHub.com repository (recommended)	Use GitHub's transfer ownership capability to move it over to the Program's GitHub organization. To do this you will need to temporarily add one of the Program's GitHub organization owners (e.g. the PMC Lead) as an admin on the source repository, so that they can initiate the transfer (once the transfer is complete, you will be able to remove the Program's GitHub organization owner from the repository - in fact we encourage you to do so). The Foundation recommends this approach as it has the unique benefit of preserving the full commit & pull request histories, the project's issue list, wiki and GitHub pages, and more. Some important notes: When you transfer a repository, its issues, wiki, stars, and watchers are also transferred (read more details about repository transfers) When you transfer a private repository, all forks will be disabled, until marked as public ; they will also be disconnected from the upstream repository, therefore it is strongly advised to push all changes to an upstream branch, before performing the code transfer
GitHub.com repository where it is not possible to temporarily configure someone else as an admin	Perform a double transfer: Transfer ownership of the repository to a personal ("user") account on GitHub (see the GitHub documentation for details) Follow the steps described above for transferring a GitHub.com repository to the Program
GitHub Enterprise repository	Perform a copy, transfer, and freeze: Copy the repository into a personal ("user") account on GitHub (this StackOverflow post describes how to accomplish this) Follow the steps described above for transferring a GitHub.com repository to the Program Delete or freeze (e.g. disable access, make read-only, etc.) the repository in your GitHub Enterprise installation, to prevent accidental modifications to the wrong repository.
Other Source Code Management (SCM) repository	Perform an import, transfer, and freeze: Use the GitHub importer to import the repository into a personal ("user") account on GitHub (see the GitHub documentation for details) Follow the steps described above for transferring a GitHub.com repository to the Program Delete or freeze (e.g. disable access, make read-only, etc.) the repository in your SCM installation, to prevent accidental modifications to the wrong repository.
Source code snapshot	Snapshotting the code and providing it to the PMC in an archive file (.zip, .tar.gz, etc.) can also work. This is the recommended approach if you wish to truncate the commit history prior to contribution.
Do-It-Yourself (DIY)	If you wish to populate your repository yourself, the PMC should create an empty repository in the Program's GitHub organization (as described above), and then configure the contributing team as owners and committers. The project team can then prepare an initial commit at your leisure.

A Note about GitHub Invitations

Following completion of a code transfer, the PMC should invite the Project team's admins and contributors to the GitHub repository. The team must accept these invitations before they will be able to write to the repository!

This is done by accessing the following URL (substituting the name of the Program's GitHub organisation and the specific GitHub repository), and then accepting the invitation:

https://github.com/<program-org>/<repository-name>/invitations

Although GitHub will send the invitation via email, we've found that these emails are often time-delayed (by days, in some cases) and can be flagged as spam by some email systems. As a result, we strongly encourage all teams members to pro-actively accept the invitations directly on GitHub, using the URL to the left.

Approving lifecycle transitions

Deprecated content

With one exception (see box at right), changes to a given Project /wiki/spaces/FINOS/pages/75530756 can only be approved by the PMC of the Program that Project is hosted within - Projects cannot change their own status.

However such changes are usually instigated by the Project itself, when they request that the PMC approves a particular lifecycle change. In all cases, though especially Project's transitioning to the /wiki/spaces/FINOS/pages/75530371 state, sufficient evidence must be provided that the PMC can be certain that the Project team has met the requirements of the new lifecycle state (e.g. /wiki/spaces/FINOS/pages/75530363 and /wiki/spaces/FINOS/pages/75530376 checklists).

Working Groups are allowed to transition to /wiki/spaces/FINOS/pages/93290700 state and back again themselves, without PMC approval.

It is expected that the PMC be notified of such changes however, to support the PMC in meeting their /wiki/spaces/FINOS/pages/93225748.

Steering projects and working groups

Deprecated content

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

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

This reference describes the second scenario. For the first scenario please refer to /wiki/spaces/FINOS/pages/75530357 and Requesting Steering (Working Group) - ARCHIVED.

Conditions Requiring Steering

In essence the PMC is expected to be actively monitoring the Projects and Working Groups within their Program, and ensuring that they remain relevant and active, in scope for the Program, and comply with all Foundation policies. A Project or Working Group that is failing to meet these requirements, or appears to be on a path towards failing to meet these requirements, requires pro-active steering from the PMC. Such situations should also be /wiki/spaces/FINOS/pages/93225748.

Examples of situations where steering may be warranted:

Lack of activity:
- Project team that has become unresponsive to issues, PRs, etc.
- Project that hasn't had any commit activity in more than 3 months
- Working Group that has repeatedly canceled their meetings, and has no activity on their email list
Leadership vaccuum:
- Project / Working Group is missing a lead / chair, and hasn't found a replacement in a reasonable amount of time (e.g. 1 month)
IP compliance violation:
- Project introduces a dependency that has a non-compliant license

Effective Steering

The objective in steering a Project or Working Group is first and foremost to assist them in self-correcting. The first point of contact should always be the Project lead or Working Group chair, who in many cases will be able to explain the situation themselves quickly. If the lead or chair is unavailable (or part of the issue), the entire Project team or Working Group should be consulted about the situation that has raised concerns.

The appropriate corrective action will vary depending on the scenario, though often those consulted will have the best suggestions, given their inside knowledge of the situation.

Board reporting and program health checks

Unable to render {include} The included page could not be found.

Program roadmaps

Deprecated content

All programs are expected to have 12 month roadmaps. Ideally these roadmaps are kept updated - "evergreen" and it's good practice for programs to update them at least once a quarter. At a minimum, programs are expected to update their roadmap once a year, as part of reviewing the past year's progress and planning the year to come.

Programs are afforded discretion and independence in choosing the format of the roadmap that works best for their programs as well as the component projects and working groups within the program. FINOS recognizes that some programs have tight interdependencies between some or all of its projects and working groups, while in other programs projects and working groups work largely autonomously from each other.

What should be in a roadmap? We recommend that the roadmap include the following:

A summary of the product / release roadmap of each of the respective programs and work groups. What's on the "to do" list for the next year? What does the team in each project and working group want to take on? What are some of the bigger features in the backlog that the project team intends to build (and when) in the coming 12 months?
Across projects and working groups what are the major releases of code, standards, etc. for public consumption and production system use? Releases may also include things like best practices libraries, process models, pro forma legal and governance policies, HR/talent development "cook books", or white papers.
- What sort of support will the program require in terms of product marketing from the foundation team?
Where are their emerging product and technology opportunities that might warrant starting a new project or working group? What might warrant soliciting new contributions and contributors?

Roadmap Example 1: Confluence Template

The Confluence "Roadmap Planner" macro provides a ready made way within the wiki itself to build a basic roadmap in a Gantt chart format. This macro could be used to document and map out different initiatives across program projects and working groups

Serverless Backend Project

API Project

Standards WG

Cross-Project / PMC

Dev Sprints (4 x 2wk)

Integrated Testing & UAT

Dev Sprints (2 x 2wk)

Integrated Testing & UAT

Build SDK

User Story Development

Write Test Cases

UAT

Develop Microsite

Roadmap Example 2: Quarterly Grid

		Q1	Q2	Q3	Q4
Project 1	Activities & Focus (E.g., major features being developed, analysis being performed)	Building (features) ... Investigating ... Testing ...	Building (features) ... Investigating ... Testing ...	Building (features) ... Investigating ... Testing ...	Building (features) ... Investigating ... Testing ...
	Releases (if any)
	Additional FINOS support requested (above and beyond steady state)
Project 2	Activities & Focus (E.g., major features being developed, analysis being performed)
	Releases (if any)
	Additional FINOS support requested (above and beyond steady state)
Working Group 1	Activities & Focus (E.g., major features being developed, analysis being performed)
	Releases (if any)
	Additional FINOS support requested (above and beyond steady state)
Program Overall	Common / Cross project releases and milestones

Browser not supported