finos / open-developer-platform

Delivering open source software development best practices while enforcing security and legal compliance for the financial services industry .

Caution

This project is inactive and not maintained.

The documentation was moved under https://community.finos.org/docs/governance/collaborative-principles (and sibling pages) If you want to onboard on EasyCLA, you can submit a mock change to software-project-blueprint.

Open Developer Platform

Welcome to the Open Developer Platform project, hosted and led by FINOS, The Fintech Open Source Foundation.

The Open Developer Platform (ODP) is a collection of services, tools and best practices that deliver a secure and compliant collaboration across all FINOS hosted projects.

ODP leverages GitHub as project collaboration platform to deliver a software development workflow with continuous legal, security, quality scanning and a set of communication tools that comply with financial institutions regulations.

You can find more info on our website, community.finos.org.

Contributing

1. Fork it (https://github.com/finos/open-developer-platform/fork)
2. Create your feature branch (git checkout -b feature/fooBar)
3. Read our contribution guidelines and Community Code of Conduct
4. Commit your changes (git commit -am 'Add some fooBar')
5. Push to the branch (git push origin feature/fooBar)
6. Create a new Pull Request

NOTE: Commits and pull requests to FINOS repositories will only be accepted from those contributors with an active, executed Individual Contributor License Agreement (ICLA) with FINOS OR who are covered under an existing and active Corporate Contribution License Agreement (CCLA) executed with FINOS. Commits from individuals not covered under an ICLA or CCLA will be flagged and blocked by the FINOS Clabot tool. Please note that some CCLAs require individuals/employees to be explicitly named on the CCLA.

Need an ICLA? Unsure if you are covered under an existing CCLA? Email [email protected]

License

Copyright 2018 - FINOS, The Fintech Open Source Foundation Distributed under the Apache License, Version 2.0. SPDX-License-Identifier: Apache-2.0

open-developer-platform's Issues

Document WhiteSource build integration as a way to "augment" CI/CD deployment pipelines

Grooming To Do

WhiteSource only runs when dependency definitions are added, removed or updated

Description

The WhiteSource integration for GitHub.com currently runs only when dependency definitions are added, removed or updated. If there is a security vulnerability that is spotted on a project dependency, WhiteSource won't spot it until the list of project dependencies gets updated.

Instead, it should be possible to run the scan on every commit or PR, raising the chances for WhiteSource to spot the CVE and take action (fail the PR check, create issue or send email).

There seems to be no way to allow this configuration, see https://whitesource.atlassian.net/wiki/spaces/WD/pages/697696422/WhiteSource+for+GitHub.com

Potential Solution

it would be great to have a flag "scanAllChanges" (or similar) in the ".whitesource" file.

Find a mechanism to build Docusaurus PRs and provide a preview link prior to PR acceptance

Grooming To Do

Add GitHub Actions as build system within ODP infrastructure

Description of Problem:

The Open Developer Platform needs to form an opinion on the use of GitHub Actions so FINOS projects know how to configure their CI/CD pipelines using the most appropriate mechanisms

Potential Solutions:

• Arrange a date when the GitHub team can join an ODP working group call
• Place the GitHub Actions grooming session on the ODP agenda
• Discuss the top 3 items ODP needs to investigate, solve and deliver to move GitHub Actions forward
• Add the top 3 items to the ODP GitHub issues and delegate to ODP team members to solve
• Add items updates to future agenda to help unblock and move forward

Create inline edit links as part of white labeled Docusaurus build

Grooming To Do

FINOS Identity (ID) bot

Email and Symphony chat are (based on the metrics we collected for the last 20 months) the most accessible and common communication platform across FINOS members, and given that bots have been already implemented to solve similar accessibility issues (see bot-github-chatops), we could adopt a similar approach to manage developer identities.

The FINOS ID bot would run continuously (on FINOS containerised infrastructure) and is configured with a list of point of contacts (extracted from FINOS internal metadata) that are email addresses (or Symphony users) allowed to submit commands; any other message sent by any other user will be ignored. All FINOS staff will be able to use this bot.

The bot will restrict point of contacts operations only on identities affiliated with their firm; for example, the point of contact for MyFirm will be restricted to only manage identities @myfirm.com .

Enable CLA Bot to work in Gitlab akin to how it works in Github

Enable CLA Bot to work in Gitlab akin to how it works in Github.

This is time sensitive for the PURE/Alloy pilot and ideally would be in place by the end of January 2020. Here's why ... PURE models will be stored initially on a hosted instance of GitLab Ultimate, later on Gitlab.com (https://gitlab.com/finosfoundation), therefore the app must be compatible with both configurations. Edits to models will be git commits and as such will require CLAs for modelers.

More generally having this in place will give us flexibility within FINOS to support both Github and Gitlab

Sub-items:

• Confirm with GS if Kiitos uses commits or Merge Requests to update code. If commits are used, what is the workflow to notify issues, since no MR checks . /CC
• Implement a group-level configuration in GitLab, see ScottLogic/gitlab-cla-bot#49 ; I deployed and tested it already, seems to work as expected (test is hosted on https://gitlab.alloy.finos.org/test/clabot-config )
• Generate a list of whitelisted GitHub IDs from our internal metadata
• Push the GitHub ID whitelist into https://gitlab.alloy.finos.org/Alloy-Pilot/clabot-config
• Implement a useGitHubIDs toggle in the CLA bot that informs the bot that contributors whitelist is now populated with GitHub IDs, instead of GitLab usernames

Technical discussion on finos/cla-bot#182

WhiteSource rollout Pilot

Depends on #27

Description

List of trending projects for the rollout:

• cla-bot
• datahelix
• openfin-react-hooks
• plexus-interop

Task History

• https://finosfoundation.atlassian.net/browse/INT-744

Add an "About FINOS" page to the project blueprint microsite that's inherited across all FINOS projects when new project microsites are created

About FINOS will contain the following

• Marketing information about FINOS
• This project Is part of the Fintech Open Source Foundation (FINOS)
• Information about the foundation
• How to contribute to this project
  • Getting Started information tailored to the specific project.
  • Policies and procedures
  • Specifications can change over time by pull requests by teams
• How to become a part of the project and wider FINOS Community
• How to become a FINOS Member

Work Goal

The goal is to start moving away from Confluence and start moving towards GitHub pages

Project licenses are not recognized by GitHub and are being flagged in PMC reports

Description

Some FINOS hosted repositories include Apache 2.0 license (via LICENSE file), but GitHub does not recognize them, therefore they get flagged by the PMC Program reports.

Listed below are two examples:

• https://github.com/finos-plexus/plexus-interop
• https://github.com/finos-fdx/contrib-toolbox

The LICENSE file has been updated using different formats, but that doesn't seem to work. Can a member of the GitHub team help by suggesting how to debug and solve these issues?

FINOS Tailored Git and GitHub Training

Description of Problem:

Developing and distributing FINOS specific/tuned Git/Github101 training has come up a few times. Programs that have suggested this be done include FDC3, FO, and DT (specifically the Kdb WG).

This epic is to capture those requirements so the ODP WG, FDX program and FINOS community can assess if Git/GitHub 101 training is something to take on, develop, distribute and deliver.

There is a draft/scratch pad, which @mcleo-d, @jbjonesjr and the ODP team has access to in FINOS.

As some have pointed out, there is a lot of good Git/Github training already, but the feedback we've received is that it would be good to have training material that is tuned to FINOS, FINOS processes, and FINOS tooling that includes examples and screenshots of FINOS tools such as Travis CI and CLA Bot.

Potential Topics:

• Source Control 101
• How Git is different from SVN, CVS, and other "traditional" tools
• Basic concepts: Commits, Forks, Pull Requests, Etc.
• Using Github interactively (and comparison with doing stuff at command prompt)
• Github 101
• Markdown 101
• FINOS CLAs, the CLA Bot, and the FINOS Metadata model
• The FINOS project blueprint
• Using Github projects/using github for a kanban board
• Using Github as a wiki
• Github Pages 101, Docusaurus, and the FINOS microsite template

Examples of Git/Github training we might be able to leverage

• Harvard CS50 Git/Github training
• Git SCM

Stories

• Refine list of training topics and set ToC on github.com/finos/open-developer-platform GitHub Pages
• Organize quarterly training sessions via ODP meetings
• Run first training session
• Update ODP GitHub pages with training content (after first training session)

More history on https://finosfoundation.atlassian.net/browse/ODP-103

Create instructions on how to easily enable YARN build for WhiteSource

Summary

Add a specific section on https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/1129283585/DRAFT+WhiteSource+for+GitHub.com to instruct developers on how to configure specific builds, at least for the main ones:

• Node (NPM and Yarn)
• Maven
• Gradle

For each language, link to the WhiteSource configuration of an existing FINOS project.

Create a GitHub Issues, Teams and Discussion best practice for FINOS projects to follow

Description of Problem:

The Open Developer Platform needs to create a best practice for FINOS teams to engage through GitHub Issues, Teams and Discussions so FINOS projects can follow and replicate.

Stories:

• Arrange a date when the GitHub team can join an ODP working group call
• Place the GitHub discussion and initial grooming session on the ODP agenda
• Discuss the initial items ODP needs to investigate, solve and deliver to move GitHub forward
• Add the initial items to the ODP GitHub issues and delegate to ODP team members to solve
• Add updates to future ODP agenda to help unblock and move forward

Ensure all GitHub repositories have a FINOS Project Lifecycle badge in README.md, automatically and continuously

Description of Problem:

Updating FINOS project badge statuses in project README files is a manual process of reviewing recorded metadata and raising manual PRs for each project to accept. This creates additional admin effort as the foundation scales and grows. It can also be prone to synchronisation errors.

Potential Solutions:

Create an automated script that compares current project statuses in FINOS project metadata and raise a PR to the project team that updates the badge status in the project README should the project status change.

Add WhiteSource documentation on vulnerability details

Acceptance Criteria

• As project visitor, I want to read documentation on WhiteSource vulnerability details

Tasks

• Review https://whitesource.atlassian.net/wiki/spaces/WD/pages/697696422/WhiteSource+for+GitHub.com
• Report/link relevant info on https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530440/WhiteSource
• Discuss and socialise changes via ODP meeting

FINOS Developer Identity

Background and requirements

In order to build an infrastructure whose main purpose is to enable a highly regulated industry like financial services, it is key to implement a reliable identity management, that allows:

• FINOS Team to store and maintain CLAs signed by firms and individuals, which is used to enforce IP compliance across all hosted code (CLA bot)
• FINOS Members to have direct control over their employee accessibility (grant and revoke)
• FINOS Contributors to self sign up, providing their corporate identity (ie email and GitHub ID)

Right now the FINOS team tracks all this data internally, by reacting to the contributions coming from GitHub (for code hosting), Atlassian Confluence Cloud (for Wiki) and Google Groups (for mailing-lists); as a result, requirements #2 and #3 are not currently satisfied.

The identity data is stored in a private database, along with the signed CCLAs and ICLAs submitted so far from firms (and individual contributors) and is only accessible by the FINOS Team.

Tasks

• FINOS Identity (ID) bot
• ODP Sign Up form

FINOS voting best practices and automation

Description :

Document what are the best practices for managing votes by a FINOS activity group

Stories

• Define a proposed voting mechanism based on GitHub.com platform (ie GitHub Issue templates + thumbs up/down emoji + automation, if needed)
• Present and discuss the proposal during ODP meeting
• Document

Add white labeled Docusaurus template project to ODP repository in Docs folder

Grooming To Do

Using Github Discussions in place of Google Groups

As part of our long term strategic intent to consolidate as much of our collaboration infrastructure on Github, this epic is about doing a pilot using github discussions in place of google groups, probably in 1-2 projects to start.

One consideration that has been brought up is whether Github Discussions provides sufficient (or any) of the monitoring, data collection, and surveillance, required by the banks which remains a reason we still are on Google Groups (despite the fact that some banks can't use Google applications like Google Groups).

Key requirements:

• Discussions can be followed via email (email notifications)
• Discussions can be joined via email (ie via reply-to email from notifications)
• Users can be invited to or banned by discussions, from discussion maintainers
• FINOS Org admins can manage discussion maintainers for each discussion
• Discussions can link to other GitHub items: issues, PRs, projects, code, repositories, user (mentions),

Stories:

• Arrange a date when the GitHub team can join an ODP working group call
• Place the GitHub discussion and initial grooming session on the ODP agenda
• Discuss the initial items ODP needs to investigate, solve and deliver to move forward
• Add the initial items to the ODP GitHub issues and delegate to ODP team members to solve
• Add updates to future ODP agenda to help unblock and move forward

We're looking for a volunteer who would like to setup a simple dry run; it can be hosted on anyone's GitHub account/org.

FINOS project leads can ensure quality, security and compliance of FINOS hosted code

Description

An epic to ensure quality, security and compliance is applied to all FINOS projects.

Stories:

• #28 License, security and quality checks are performed automatically upon any new incoming code (initial, commits, PRs)
• #29 New Projects and repositories are automatically enrolled in this configuration based on https://github.com/finos/project-blueprint/
• #32 Project leads are provided a way to override specific packages to allow build / merge to succeed
• #33 PMCs / secretary@ is notified about project specific overrides

How to request installation of WhiteSource integration on a given GH repository

Acceptance Criteria

• As FINOS Project Team member, I want to be able to request activation of WhiteSource integration for GitHub for a given GitHub repository

Tasks

• Document and socialise [email protected] as support queue per GitHub specific requests

FINOS to review the cm_state field of https://metrics.finos.org/ to make sure the updated FINOS lifecycle states have been applied to the filtering

Description

The Activity Dashboard documentation below still refers to the previous FINOS lifecycle states where cm_state is documented and applied.

https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530482/Activity+Dashboards

Tasks

• The Activity Dashboard cm_state filter is tested against the updated INCUBATING, ACTIVE and ARCHIVED lifecycle states

  • https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530756/Project+Lifecycle

• The Activity Dashboard cm_state documentation is updated to reflect INCUBATING, ACTIVE and ARCHIVED lifecycle states.

  • https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530482/Activity+Dashboard

The FINOS community can engage in multi channel chatrooms

Description

The following GitHub issues highlight where the requirements for a ad-hoc FINOS chat system have been pitched and requested.

• FINOS Community : finos/community#100
• DevOps Mutualization : finos/devops-automation#1

Suggested Platforms

The following systems have been suggested and define the requirements for a comparison matrix that compares features and accessibility requirements.

• https://symphony.com/
• https://freenode.net/
• https://slack.com/intl/en-gb/
• https://rocket.chat/
• https://www.discourse.org/
• https://matrix.org/

Suggested Future Requirement

The following requirement for linking multiple chat systems together was suggested for potential FINOS investigation.

• Spike on multi-lateral chat bridge between Symphony and Slack
  • https://matrix.org/
    • https://riot.im - clients
    • https://matrix.org/ - standards
    • https://matrix.org/bridges - bridges
    • https://www.modular.im/ - matrix hosting (paid)

Pilot using "GitHub Teams", "GitHub Issues" or another GitHub mechanism to keep team conversations close to repositories and documentation

Description of Problem:

The ODP team should work with related FINOS project teams to trial, prove and answer the following questions, plus any other questions that are raised as part of the trial.

• What are the critical requirements of open source discussion forums from a FINOS team and bank perspective?
• Do "GitHub Teams" and "GitHub Issues" provide sufficient discussion monitoring, data collection, and auditing, required by the banks?
• Are there alternative places within the context of GitHub that better suit this requirement, other than Teams and Issues?
• Are there any benefits or hypothesis that should be measured and presented as part of the trial to demonstrate success criteria?

Next Steps

• Prioritise the discussion forum trial against the ODP backlog
• Work with ODP team to understand trial success criteria and measures.
• Select relevant FINOS projects to help fulfil the trial
• Schedule the trial and write a new story / epic to accommodate on the ODP backlog

Implement tooling to ensure all GitHub repositories comply with project-blueprint repo template

Description of Problem:

All FINOS repositories should include a one line summary as supported by GitHub, to better support navigation and consumption of the project portfolio; along with other basic GitHub repository settings, each repository should include:

• a README.md file
• a whitesource.config and .whitesource file
• a .github folder with sub-files in it
• .... TBD (see https://github.com/finos/project-blueprint )

Stories:

• finos/metadata-tool#53 Implement check command in metadata-tool
• Present to ODP
• Finalise, test and document GitHub Action that creates GitHub Issues on repositories

Create a FINOS wiki pattern on GitHub for FINOS projects to follow as best working practice

Description of Problem:

The Open Developer Platform needs to create a pattern for engaging FINOS wikis on GitHub so FINOS projects can follow the pattern as a best working practice.

Stories:

• Arrange a date when the GitHub team can join an ODP working group call
• Place the GitHub wiki discussion and initial grooming session on the ODP agenda
• Discuss the initial items ODP needs to investigate, solve and deliver to move GitHub hosted wikis forward
• Add the initial items to the ODP GitHub issues and delegate to ODP team members to solve
• Add wiki updates to future ODP agenda to help unblock and move forward
• Create blueprint microsite using ODP white label Docusaurus template on the following ODP branch : https://github.com/finos/open-developer-platform/tree/odp-issues-37-docusaurus-white-label-wiki
• #19 Create a GitHub action to publish white labeled ODP Docusaurus content
• #37 Create an ODP microsite and wiki using the Docusaurus JavaScript framework

ODP Sign Up form

Build a sign up form on finos.org/odp, open to everyone, with a Submit button and the following fields:

• Full name (mandatory)
• Organisation (mandatory)
• Corporate email address (mandatory)
• GitHub ID (optional)
• Personal email address (optional)
• Trial access to hosted platforms, ie Symphony API (multi-select checkbox)

Upon form submit:

• If the corporate email address (and GitHub ID) is already registered…
  1. Answer to the form submitter via email accordingly
• If the Organisation or the corporate email address domain matches with any firm that signed a CCLA with FINOS…
  1. Forward the email to the company point of contact for CCLA validation
  2. Notify via email the form submitter that a request to the firm point of contact have been submitted
• Else…
  1. Answer via email to the form submitter, by pointing to FINOS requirements for contribution (embed text in the email and add link for more info)

Initially, this form could be manually processed by the Infra team, using some predefined email templates to answer.

Investigate using Landscape CNCF framework for FINOS Project Catalogue

Description

finos.github.io was born as a simple way to deliver a visual overview of our projects. It was built with very basic knowledge and little time invested; the code is extremely basic, but it does the job. Nevertheless, it is quite heavy to improve, considering that the setup is extremely basic.

Looking around, there have been similar initiatives, the most similar to our requirements seems to be https://github.com/cncf/landscapeapp , which is used to render out https://landscape.cncf.io (even more relevant, for similarity in numbers, is https://landscape.lfai.foundation/ )

Tasks:
(https://github.com/finos/finos.github.io/blob/master/activities.json)

• Generate a landscape.yml for FINOS using metadata-tool
• Run the website locally and see the result - using Netlify, see https://github.com/finos/finos-landscape
• (stretch goal) apply some FINOS styling - see https://github.com/finos/finos-landscape
• Consolidate FINOS taxonomy, see #134
• Map category taxonomy in landscape.yml with data from [activities.json] - depends on taxonomy, skipping for now

Improve FINOS JIRA contribution process

Description

The current contribution process is delivered by a public JIRA Project called CONTRIB; to start a new contribution, it is as simple as opening a JIRA issue (which is good).

However, in order to streamline activities to process a contribution, the workflow must split in 2 parallel swim lanes, which is where JIRA complexity gets in the way.

Right now we have a "manual" process to "fork out" and "merge" 2 parallel processes: validating licenses for (optionally) contributed code and wait for the contributor to have a signed CLA with FINOS. When both are successfully completed, the workflow moves into PMC voting.

To automate this end-to-end process, it would be useful to implement a background process (which may run once a day, or via JIRA webhook integration, therefore every time something changes on a JIRA issue), which:

• Creates and assigns sub-tasks, when main contribution process reaches "Legal Checks" state
• Assign issues to PMC Lead, based on the value of "Program" field
• Notify PMC list upon issue creation and (any) resolution

Provide an overview of ODP to WhiteSource so they understand the FINOS objectives of integrating WhiteSource into GitHub

Description of Problem:

Following a conversation with Rhys Arkins at WhiteSource, the WhiteSource team have agreed to record the objectives of ODP so they can be referenced by the WS support team..

As an outcome of the request, WhiteSource has requested the following.

• Provide a description of any notable past decisions that WhiteSource should be aware of.
  • For example: Why FINOS doesn't use the default auto config proposed by the bot, etc.
• Information on custom requirements such as "a single config across all repos" would be useful to document in this context.

Acceptance Criteria

Provide a description of ODP objectives and any decisions made that WhiteSource should be aware of whilst providing future technical support.

FINOS projects can be hosted on GitLab

Stories

• #15 - CLA bot on GitLab
• Index GitLab.com projects activity on metrics.finos.org
• Publish GitLab project links on finos.github.io project catalogue
• GitLab Trainings for FINOS (similar to #38)

Improve WhiteSource security scanning at FINOS

Description

The following stories should be documented using markdown so they can be integrated into the Open Developer Platform wiki once available from epic #12

Stories

• #13 Provide an overview of ODP to WhiteSource so they understand the FINOS objectives of integrating WhiteSource into GitHub
• Build a GitHub Action that runs the WhiteSource Unified Agent
• Provide a way for the bot to be re-summoned via comments on issues
• Make WhiteSource Bot configuration PR configurable (FINOS default configuration can be found at https://github.com/finos/project-blueprint)
• WhiteSource bot excludes should be configurable at bot (not scanning) level, ie in the .whitesource file
• Investigate, test and document WhiteSource PR automatic fix - https://www.whitesourcesoftware.com/whitesource-remediate/ (enabled by default for github.com integration)
• [] Document support from FINOS and WhiteSource, when related to security issues, scanning configuration and other related issues (FINOS liaises between community and WhiteSource, by opening tickets via [email protected] , /CC WS account manager for FINOS)

Create the ability to manage meeting minutes on GitHub that includes Bitergia reporting

Description of Problem

So far, the only tool used in FINOS to edit and store meeting minutes is Atlassian Confluence; this is - for example - the list of meetings held by the FDC3 Appd Working Group - https://finosfoundation.atlassian.net/wiki/spaces/FDC3/pages/130711602/AppD+Meeting+Minutes

In order to workaround the known Atlassian Confluence accessibility issues (firewalled by most FINOS members), GitHub Wiki can be tested in order to provide an alternative platform for editing and storing meeting minutes.

Tasks include, but are not limited to:

• Implement and test Bitergia meetings crawler to also scan GitHub Wiki pages (MarkDown format, see https://github.com/yogthos/markdown-clj#table)
• Define meeting minute page template (and guidelines, preferably a button to create a new page from template) to easily create meeting minutes pages
• Create (in an automated fashion) meeting minute page templates for each project or working group, including the roster, in order to simplify the minutes editing during calls (instead of typing the name of attendees, check/uncheck a box close to the names listed in a predefined table, then optionally add new attendees down below)
• Test GitHub Wiki platform to take notes of the next ODP WG meeting
• Communicate and socialise with FINOS Staff (first) and Community (later)

Technical Dependencies:

This project relies on the delivery of story #37 prior to development start.

More history on https://finosfoundation.atlassian.net/browse/ODP-90

Project leads are provided a way to override specific packages to allow build / merge to succeed

Grooming To Do

Quality checks are performed automatically and continuously upon any new incoming code

Acceptance Criteria

• As a project visitor, I want to see in the GitHub README the status of quality continuous checks
• As a FINOS Project Team member, I want to rely on automatic quality checks provided/suggested by FINOS
• As a FINOS Project Team member, I want to be able to configure quality checks using GitHub files (GitOps)

Tasks

• Ensure all GitHub repositories have a summary, automatically and continuously - #31
• Ensure all GitHub repositories have a FINOS Project Lifecycle badge in README.md, automatically and continuously - #16

FINOS Completion of WhiteSource Documentation

Description of Problem

FINOS to complete documentation of ODP WhiteSource integration and configuration using markdown for the ODP wiki being delivered in epic #12

Stories

• #23 Create instructions on how to easily enable YARN build for WhiteSource (shall whitesource.config be created and linked from .whitesource?) Is there a way to do it with only 1 file?
• #25 How to request installation of WhiteSource integration on a given GH repository

Update ODP roadmap image

Description

Update ODP roadmap image (in FINOS wiki and website) to reflect the current status of the ODP project.

See: https://www.linkedin.com/posts/
finosfoundation_opendevplatform-compliance-findeliveryaccelerator-activity-6608018939970666497-_8My

Quality, security and legal reporting/notifications

Related to #31

Acceptance criteria:

• As a visitor, I want to see all security/legal/quality in a public GitHub Project
• As a FINOS Project Team member, I want to be able to get notified about security/legal/quality issues

Tasks:

• Collect public security/legal/quality issues across all FINOS hosted projects
• Add collected issues into a GitHub Project (using API)
• Document and socialize the "FINOS Projects reporting Board"
• Document and socialize issue notifications (see https://help.github.com/en/github/receiving-notifications-about-activity-on-github/about-notifications)

Dependencies:

This story depends on the following ones:

• Quality : #28
• Security: #81
• Legal: #30

Implementation

As we try to enforce GitOps as paradigm to bring continuous quality, security and legal compliance on across all our repositories, also reporting and notifications should align.

For example, in order to report on security, it is already possible to get the raw data from https://api.github.com/search/issues?q=org:finos%20label:%22security%20vulnerability%22

Using JQ, it is possible to export the data in any format.

Create a GitHub action to publish white labeled ODP Docusaurus content

Acceptance Criteria

• A GitHub Action is available on https://github.com/finos/open-developer-platform to build Docusaurus microsite hosted on odp.finos.org
• Each PR submitted to /docs and website folders has a comment with a link to the site preview
• Demo of GitHub Action to ODP team

Tasks

• Implement GitHub Action that builds Docusaurus, see https://github.com/clay/docusaurus-github-action
• Find a mechanism to build microsite preview and report link as comment for each related PR
• Configure GitHub Action to build ODP microsite
• Demo and discuss further via ODP meeting

ODP website styling

Add ODP branding to ODP white label Docusaurus microsite

The Open Developer Platform Docusaurus microsite is commited to the odp-issues-37-docusaurus-white-label-wiki branch in GitHub whilst in development by the ODP project team.

• Fork the Open Developer Platform repository to your GitHub profile
• Git clone your forked repository to your local machine
• Git fetch all branches from your forked GitHub repo to your local machine
• Git checkout odp-issues-37-docusaurus-white-label-wiki locally and add changes to this feature branch
• Push odp-issues-37-docusaurus-white-label-wiki to odp-issues-37-docusaurus-white-label-wiki on your forked repo
• Raise a PR to odp-issues-37-docusaurus-white-label-wiki in the open-developer-platform project when changes ready to be merged upstream

Tasks to include

• Add ODP logo / icons to ODP Docusaurus microsite
  • Header
  • Main Panel
  • Footer
• Add ODP favicon to ODP Docusaurus microsite
• Swap grey SVG boxes to generic checkmark SVGs
• Add ODP specific CSS to Docusaurus microsite

FINOS participants can engage in program activity (group) chats

Description

• Validate that banks have multi-lateral feature enabled in Symphony
• Validate that banks can access and use gitter.im

Additional FINOS history : https://finosfoundation.atlassian.net/browse/ODP-36

New FINOS projects enrolment using FINOS Project Blueprint

Depends on #37

Acceptance criteria

• As a FINOS Contributor, I want to be able to create and setup a GitHub repository with all default FINOS contents/settings
• As a FINOS Contributor, I want to be able to align an existing project with all default FINOS contents/settings

Tasks

• Document process to create a new FINOS project using https://github.com/finos/project-blueprint
• Document process to align an existing FINOS project a new project using https://github.com/finos/project-blueprint

Create an ODP microsite and wiki using the Docusaurus JavaScript framework

Relates to #29

Summary

As Docusaurus has become the FINOS reference solution for delivering project microsites, it would be great to have a template structure in https://github.com/finos/open-developer-platform to encourage ODP documentation collaboration.

Acceptance Criteria

• as ODP visitor, I want to access wiki contents via odp.finos.org
• as ODP visitor, I want to propose wiki changes via PRs on https://github.com/finos/open-developer-platform

Tasks

• Build a white label microsite with Docusaurus (for FINOS ODP) on https://github.com/finos/open-developer-platform
• Create inline edit links as part of white labeled Docusaurus build
• #56 Add ODP branding to ODP white label Docusaurus microsite
• Setup ODP microsite DNS and make ODP Docusaurus live #79

Add new team members to ODP project on GitHub and FINOS Metadata

Add the following people to the ODP project in GitHub making sure they're added to FINOS metadata with an agreed FINOS CCLA applied.

• https://github.com/issc29 - @issc29

  • Added to FINOS metadata
  • Added to ODP project on GitHub
  • Has an agreed GitHub CCLA

• https://github.com/brntbeer - @brntbeer

  • Added to FINOS metadata
  • Added to ODP project on GitHub
  • Has an agreed GitHub CCLA

• https://github.com/rarkins - @rarkins

  • Added to FINOS metadata
  • Added to ODP project on GitHub
  • Has an agreed GitHub CCLA

Implement ongoing license validation of all hosted repositories

Feature Request

Description of Problem:

Rather than relying solely on contribution-time license validation, the Foundation needs to ensure license compliance for all hosted repositories on an ongoing basis.

Potential Solutions:

A spike using https://github.com/fossas/fossa-cli have shared on https://gist.github.com/maoo/40a4f7a9df8315290a1b0c347dd018da

Below the description of a GitHub Action that could deliver a continuous scanning across any GitHub repo (whose build command is supported by fossa.io

Proposal

Build a standard GitHub action that reacts on commits and Pull Requests (PRs) on a given GitHub repository, called FOSSA GitHub Action.

Every time that a commit is pushed or a PR is merged, the FOSSA GitHub Action is triggered, the action

• Invite FOSSA into ODP to validate and groom how this epic should be fulfilled
• Reads a .fossa-licenses.yaml file, containing
  -- A list of SPDX IDs called "compatibleLicenses"
  -- A list of SPDX IDs called "incompatibleLicenses"
  -- A list of strings called "whitelistedLibraries"
  -- ... (more will come after the MVP)
• Reads the FOSSA_API_KEY (encrypted) environment variable, containing the key of FINOS account
• Invokes "fossa init" and "fossa report licenses --json", generating a JSON payload with all library and license definitions
• Parses the generated JSON (on step 5) and builds a report with
  -- List of libraries with compatible licenses (and the compatible license that applies)
  -- List of libraries with incompatible licenses
  -- List of libraries with unknown licenses
• Formats the report in Markdown and post on a new github issue. If the action was triggered by a PR, the check will succeed or fail based on the amount of incompatible /unknown licenses found

Proposal have been discussed during ODP meeting in the past, see notes on https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/1191444497/2019-09-11+ODP+WG+Meeting+notes

FINOS participants can send/receive emails using @finos.org mailing-lists

Description

Validate that banks can receive and send emails via @finos.org mailing-lists

Comparison matrix for alternative mailing-list systems - https://docs.google.com/spreadsheets/d/1xECnLFhq-AZJ4t1JArn1n20AVHM5wvRsj6-3t7YUfbY

Next Steps

-[ ] Developers (how many?) from a financial institution validates he/she is able and allowed to access and sign up to https://lists.cloudfoundry.org
-[ ] Setup a Groups.io Enterprise Trial account (using "lists.finos.org" as domain)
-[ ] Create [email protected] hosted on Groups.io
-[ ] Test all current FINOS use cases for mailing-list use and management

Additional FINOS history : https://finosfoundation.atlassian.net/browse/ODP-38

Add "Projects with open vulnerabilities" to monthly FINOS PMC report

Description :

Add "Projects with open vulnerabilities" to monthly PMC report

Required:

• List any projects within a program that have an identified vulnerability

Better still:

List projects based on their lifecycle and consistent with the lifecycle criteria:

• Show incubating projects with critical or high vulnerabilities (but an incubating project with, say, only medium vulnerabilities would not be listed)
• Show active projects with any vulnerabilities

Task History

Originating from https://finosfoundation.atlassian.net/browse/INT-733

Automate FINOS Active Participants Quarter over Quarter Report

Grooming To Do

Related Bitergia issues :

Tracking month-over-month active participation
https://gitlab.com/Bitergia/c/symphony/support/issues/99

Define the use of GitHub Teams as FINOS project team mechanism within ODP

Dup of #71

Description of Problem:

The Open Developer Platform needs to provide consolidated documentation and guidance on the use of GitHub Teams so FINOS projects know how to form PMC and contributor relationships.

The feature is already in use for some FINOS projects/repositories, but there is no consolidation, nor public documentation that shows the "FINOS way" to map permissions within hosted repositories.

Potential Solutions:

• Arrange a date when the GitHub team can join an ODP working group call
• Place the GitHub Teams grooming session on the ODP agenda
• Review FINOS on GitHub - settings and processes.pdf created by @maoo and @jbjonesjr
• Discuss the top 3 items ODP needs to deliver to move GitHub Teams forward
• Add the top 3 items to the ODP GitHub issues and delegate to ODP team members to solve
• Add items updates to future agenda to help unblock and move forward

Add the following references to the FINOS Community Handbook

Description

The following technical documentation is available on the ODP Wiki pages and could be linked by the Community Handbook page.

• https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/80642059/Community+Handbook

Information pages

Project collaboration on GitHub.com

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530554/Project+Collaboration+on+Github
  How to setup project documentation pages
• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530469/Project+documentation

Choosing and setting up code validation tools

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530344/Code+Validation

Release processes

Maven release for Java

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530322/Java#Java-Release

Semantic release for NPMJS

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530323/Javascript#Javascript-Semanticrelease

Other publishing tools

C# on NuGet

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530336/C#C#-ReleaseonNuGet

Clojure on Maven Central

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530339/Clojure

Python on Pypi

• https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/75530338/Python#Python-PublishingonPypi