Program-Level Processes - ARCHIVED
- Peter Monks
- Gabriele Columbro
- Aaron Williamson
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
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.
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:
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
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 Project Lifecycle and transitions now approved directly by the FINOS team.
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:
|
| GitHub.com repository where it is not possible to temporarily configure someone else as an admin | Perform a double transfer:
|
GitHub Enterprise repository | Perform a copy, transfer, and freeze:
|
| Other Source Code Management (SCM) repository | Perform an import, transfer, and freeze:
|
| 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. |
Approving lifecycle transitions
Steering projects and working groups
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.
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
Program roadmaps
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.
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?
- 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
Roadmap Example 2: Quarterly Grid
| Q1 | Q2 | Q3 | Q4 | ||
|---|---|---|---|---|---|
| Project 1 | Activities & Focus (E.g., major features being developed, analysis being performed) |
|
|
|
|
| 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 |
Need help? Email help@finos.org we'll get back to you.
Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.