finos / community Goto Github PK

2019 Roadmap REVIEW

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

For each program and/or its component projects

• Create/Refine plan for how to build the basis of contributors into the project and/or projects

  • What skill sets are needed?
  • What overall level of commitment (FTEs) are needed to deliver on the roadmap?
  • What support is required/requested from
    • FINOS Staff?
    • FINOS Board?

• (For programs w/ project in "active" status or approaching activation) create user adoption and product marketing plan to drive usage and consumption

  • What support is required/requested from
    • FINOS Staff?
    • FINOS Board?

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

Based on decisions made in #31 by PMCs, per Program deprecation approved by the Board, please:

• Cancel upcoming PMC meetings from calendar and webex (if meetings exist)

• Notify respective PMC lists these changes are being operationalize and reference this issue #31 for all details (cc leadership team)

/cc FYI (@lspiro-Tick42 @paulwhitby @rhyddian, @tschady @neilslinger)

Where we're asking people to report conduct matters to a representative on-site, should we also include virtual event scenarios too?

Originally posted by @mcleo-d in #51 (comment)

Contextually merge plexus-interop Project with Desktop Interop API Project in a multi-repo single Project.

Tasks:

• @paulwhitby - Confirm that plexus-interop repository can be transferred to github.com/finos org
• @mcleo-d - Confirm project lead of plexus-interop project and list of maintainers (to be reflected in GitHub Team)
• @mcleo-d - Confirm merge of plexus-interop and plexus-interop-api, see finos/plexus-interop#174
• @maoo - Create new repo called plexus-interop-desktop-api (from project-blueprint) and move contents from https://github.com/finos-plexus/finos-plexus.github.io/tree/master/client-api folder
• @maoo - Update plexus-interop project into metadata and move to top level
• @maoo - Archive plexus-interop-api project , move repo under plexus-interop project
• @maoo - Transfer plexus-interop to github.com/finos

/CC @finos/plexus-pmc

The official record for voice-metadata-standard should be updated from Operating -> Incubating

The project is in 'incubating' now, that has been reflected on the readme for months, https://github.com/finos/voice-metadata-standard.

Per VOTE on FO PMC list, the PMC has decided to disband and contained projects to continue as Top-Level.

So please execute on the following tasks:

• @maoo Morph all FO projects to be "Top Level" project in our finos.github.io catalog, retaining the existing lifecycle stage
• @aitana16 cancel ongoing PMC meetings on webex
• @aitana16 - add to the Program Wiki page the notice that the program has been disbanded and projects continue as top level projects.

NOTE: There's a parallel activity to explore whether the FO project, Alloy and Security Reference should work closely together which @brooklynrob will be looking at. This activity is disconnected and parallel and should not be a blocker to progress on this issue

/CC @finos/fo-pmc @donbasuno @toshaellison @brooklynrob @mcleo-d

Per #22 on 4/22/2020 the Board has approved the following approach:

1. No new Programs will be created
2. Existing Programs can decide to continue operating under their current governance or disband as one/more top level Projects
3. FINOS Team can approve new top level Projects and manage their lifecycle transitions
4. The creation of a TAC (Technical Advisory Council) will be explored.

In this issue we'll track progress in working with each Program to agree on an approach to move forward on point 2. Attached below is an early recommendation that was discussed at the Board but that is by no means binding as we'll proceed to work with each Program to decide the approach they will take:

Description

https://metrics.finos.org/ clearly highlights teams who use FINOS projects as part of their continuous development activity.

Questions to Answer

• Is there more we can do to increase code contributions in this style and at this level of activity?
• Is there a way to increase contribution to existing projects from non-banking members, especially larger tech company members and some of our service providers?

Increasing Continuous Delivery

Red areas in the heat map below indicates continuous delivery by FINOS open source project teams for Q4 2019.

Suggestion : Can we swap internal repos, kanbans and open source releases for GitHub FINOS repos, kanbans and continuous delivery to mirror this activity across the foundation?

Activity Heatmap

Complete meeting notes in https://github.com/finos/finos-pmcs/blob/master/docs/2020-01-07-Pan-PMC-Meeting.md

Per last week's FDC3 PMC meeting (/cc @finos/fdc3-pmc @nkolba @rikoe @donbasuno), the decision was made to disband the FDC3 program as a governance body, but for PMC members to continue meeting periodically as the "Product Management Committee" for the FDC3 project to provide marketing, comms and community engagement oversight.

In terms of FINOS changes, @maoo and @aitana16 please do the following:

• FDC3 becomes a top level project
• The activity currently related to PMC (wiki, email list, meetings, etc) should continue to be tracked and be now associated to the FDC3 project from now on (just as one additional meeting)
• @aitana16 has the details on other, tangential, changes happening on the mailing lists, and the transition of the wiki to github, so I'll let her drive the rest of the changes that might be needed in metadata here, as well as if there are any other changes in meeting schedules / etc.

Please @nkolba @rikoe @donbasuno chime in if I have misrepresented something.

DevOps Mutualization Vote

Please vote on this issue with a 👍 or +1 if we should consider DevOps Mutualization a Special Interest Group now SIGs have been introduced to FINOS.

Historically, and again more recently, the foundation has received questions about what's fair game to be distributed through project specific communication channels, the Google Groups mailing lists in particular.

The guidance I provided project leads while Director of Programs was that a project's google group mailing list may be used to share training, documentation, articles, webinars that a community participant (either individual or org) has developed/produced provided it is:

1. free of charge, AND
2. directly related to the work/output/code bases of our project.

So, for example, a free webinar on how to develop a Python application on Perspective would be fair play for an organization (whether FINOS member or not) to share through the Perspective mailing list. A paid training on how to program in Python though would be not as 1) it's not free and 2) it's not specific to a FINOS project.

I think it would be good to affirm this policy and codify here in the revised governance, but not sure where exactly it should go.

This might be also be an opportunity to clarify to the community that it's project leads responsibilities - not FINOS staff - to moderate their project's google group messages (and join requests), perhaps as part of further codifying duties and expectations of project leads.

• Are they compatible with FDC3 1.1 ?
• Are they maintained ?
• Is there value in these demos?

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

• Board Meeting Debrief
  • Q1 Priority Projects

What else?

Description

DevOps Mutualization aims to solve common engineering problems by providing a continuous compliance and assurance approach to DevOps and we’re asking for your input and contribution prior to initiating the project.

Within this GitHub Issue provide your thoughts and ideas that align with ...

• Current or planned areas of development in DevOps targeted at accelerating engineering in financial services whilst removing duplication of effort.
• Existing or “Work in Progress” DevOps tool enhancements related to regulatory reporting or other regulatory requirements that your firm might consider open sourcing.
• Experience of DevOps where existing tools or services providers are falling short in the financial services industry and will benefit from collaborated requirements.
• Areas most prone to DevOps reporting and infrastructure integration risk and hence candidates for improvement.
• Least automated or optimized areas of financial services DevOps engineering.
• 1-3 specific ideas of where collaboration makes sense, the more granular the better.

We look forward to your ideas, feedback and contribution.

The FINOS Team.

Per VOTE on Hadouken PMC list, the PMC has decided to disband and select projects to continue as Top-Level /cc @finos/hadouken-pmc @chuckdoerr

So please execute on the following tasks:

1. @aitana16 I don't think there was a recurring PMC meeting but please add notices in the Wiki regarding the program deprecation
2. @maoo Move the following projects at top level, fo

• python adapter: register as top-level project (don't think it's in metadata), move to main FINOS github org and rename repo to "openfin-python-adapter". Please communicate directly with the team on the repo, or via PMC list if needed.
• Openfin React Hooks: already living in the main FINOS org, so no change needed here other than metadata

3. Archive all other Hadouken the other repositories (in github) and transition remaining Projects/Working groups to "Archived"  lifecycle stage. Check with me for any doubts.

After #31, we need to produce a revamped version of our governance which does away with the concept of programs. We will take the occasion to ensure consistency across our policies at finos.org/governance, elements of governance organically grown in the wiki and also to continue the process of moving out of the wiki into Github (per #36, we think this repository is the right place to host our governance moving forward, very much like CNCF is doing with their "foundation" repository.

Foreseen activities will be:

• Produce a short software project governance template that we can provide to projects, integrating it in the CONTRIBUTING.md of the https://github.com/finos/project-blueprint
• Produce a short standard project governance template that we can provide to standards, integrating it in the CONTRIBUTING.md of the https://github.com/finos/project-blueprint or a parallel 'standard-blueprint'
• Rework the active participation policy to have less no governance role in the projects, but still in the standards - so potentially this will be baked directly in the standard-blueprint
• Add notion of Board approved Special Interest Groups (SIGs) with lightweight governance, e.g. maybe just a Chair / Vice-Chair (for redundancy)
• Provide a "governance overview/entry point" in this repository, which outlines all "pan-project" governance items, including our Charter, linking to our policies, roles and responsibilities around the project lifecycle
• Review if other governance related pages in the Community Handbook should be moved, looking at the sub-pages there:
  • Any of the collaborative principles in the Community Governance page
  • Anything from the Decision Making page
  • Anything from the Project Level Processes page
  • Anything from the Working Group Level Processes page, e.g. running meetings
  • The elections procedure - and maybe make it less brainiac in the process? :)
• Review and approve #51
  Once we have agreement on these, and we have reviewed, we can then go back and do a proper cleanup of the wiki / community handbook, tracked in issue #48

@copiesofcopies back to you - looking forward to reviewing this.

/cc @toshaellison @mcleo-d @brooklynrob - we'll ask for your review once we have an initial all-encompassing draft of this - which should be really soon.

This repo builds the pages served on pmcs.finos.org , which is a confusing term, now that PMCs have been all disbanded.

I expect that some changes to the docs and website contents will be needed as well, to accommodate PMC disband and (maybe?) publish new Governance contents.

Finally, we should move from Travis CI to GitHub Actions, reusing the Docusaurus build Action we're using across all other repositories.

Assigning to @mindthegab for review and prioritization.

Once we are done with #31 (definitely NOT before), I would like to consider renaming this org into finos-projects and keeping it on using for meta/cross-project collaboration with all project leads.

@mcleo-d @maoo @toshaellison @brooklynrob @maoo:

can you give me a 👍 or 👎 (or elaborate if you really think this warrants a convo, seems pretty straightforward to me)

Potential/SuggestedTopics

• Source control: What is source control or version control? How can source control be distributed and why does it matter?
  • External Source: git-scm ("Getting Started - About Version Control")
• What is Git?
• What does Github and Gitlab do that Git alone doesn't?
  • Github 101
    • External Source: Github "Hello World"
  • Gitlab 101
• Github Account basics (1 account for both work and personal - 1 account per heartbeat concept)
• Understanding the Github Workflow: includes an overview of branches, forks, commits, pull requests, code revision and discussion, deployment and merging.
  • Sample Pull Request workflow in FINOS context
• Alerts, notifications, and settings
• Github security vulnerability alerts
• Using Github for Product/Project/Task Management
• Markdown 101, Github Pages 101, and Documentation/Wikis Using Github
• Docusaurus basics
• The FINOS Microsite template: Using, Writing With, Administering
• How FINOS uses Github orgs and the two different models (under /finos vs. program specific github org)

Potential External Sites/Sources to Look at/Point To

• Git/Gitlab on Udemy

See too the scratchpad in Google Docs the FINOS team has been using to collect topics and draft content.

NOTE: This idea is also capture in the ODP JIRA backlog as ODP-103

As a follow-up to the July board approval of new PGP, which unifies the concepts of projects and working groups (into a single concept, "project), approve revised standard POP (or in the case of programs that use a custom POP, updates custom POP or move to revised standard POP.

• DAV
• DEG
• DT
• FDC3 (** Custom POP)
• FDX
• FO
• Hadouken (** Used to have Custom POP; approved new standard POP on 11/1/2019)
• Plexus
• Symphony (** Custom POP)
• Voice (See Vote Here)

FINOS team will discuss and report back how to support this use case.

As per original request from @rikoe below:

I would like to request that the new proposal for project at the top level still support the idea of multiple "working groups" or "teams" per project, which would correspond to different sub-teams that cover particular disciplines.

E.g. in FDC3, we are working on the same project, and in the same repository in GitHub, but the "API team" and the "Use Case team" have separate meeting times and mailing lists, as not everything covered in every meeting is relevant for everyone.

I view this as, for example during a large software development project, while one project, you might have multiple chat channels/email groups, e.g. for the UI team, the server team and the DevOps team.

I expect this to be the exception, not the rule, but it will be great if the new project model can support such a structure, even if it is mostly self-governed by each project. I think the easiest way to accomplish this is via GitHub sub-teams for the project, and email/chat setup to correspond to the GitHub teams.

Originally posted by @rikoe in #22 (comment)

Board Update Slide

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

Per today's PMCs vote (/cc @finos/symphony-pmc), the Symphony Program decided to continue as independent top level projects.

@maoo please:

• Make all Symphony projects top level
• Leave projects in the current github symphonyoss org
• @aitana16 don't think the PMC was meeting at all but tagging you here to double check

Have contextualized their 2019 roadmap in OKR terms

("Review and reaffirm objectives on which your program roadmap has been built")

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

Description

During the FINOS Pan PMC meeting on 18th February 2020, @mcleo-d introduced the PMC community to the draft FINOS community 2020 KPIs.

• Quarterly advocacy blog post, webinar, training session on opportunities for OSS in FSI
• Quarterly project specific blog post / event / etc.
• Refer upstream and downstream projects for inclusion in FINOS
• Execute CCLA/ICLA
• Provide howtos, samples, tutorials
• Incubating projects execute on FINOS recommendations in a timely manner
• Maintain a public task list and list of "good first issues"
• Projects always “build”
• Consistently produce releases, SDKs, reference implementations and samples

Feedback Required

It would be great to get your feedback on the FINOS Community 2020 KPIs below, especially if you have ideas about how the FINOS community can help the foundation fulfil these goals.

There really are no Projects to top level @maoo so not sure anything needs to be done from your side.

@aitana16 not sure if there are meetings or any other infrastructure (mailing lists aside, those we can clean up later) to clean up this Program disbands.

Assigning this issue to both of you @maoo @aitana16 as a placeholder but please feel free to close if nothing has to be done.

• Perspective becomes top level (/cc @finos/dav-pmc @neilslinger)
• Projects in the Voice Program become top level (/cc @tschady @finos/voice-pmc)

• Updated Program Activities in Project Activities (removed PMC viz, renamed program in project), removed Program dropdown, improved viz disposition
• Moved to the bottom all program-related viz on Community Overall dashboard, see https://metrics.finos.org/goto/ba59eae99421c09b484ed565c0341dce . @mindthegab - are you ok to remove all those program-related viz, or you'd rather prefer to think about a new version of those, but using projects/orgs as pivot instead of programs?
• Simply rename Program activity over time
• Pivot Community > Overall dashboard viz using top 10 projects - Opened https://gitlab.com/Bitergia/c/symphony/support/-/issues/168
• Rename Programs to Projects in Bitergia top banner menu (see https://gitlab.com/Bitergia/c/symphony/support/-/issues/167)

Description

This issue has been created to discuss the 'Glue' and 'Self-Service Workflow Automation' that banking teams have produced to ensure proper controls are created and laid down to deliver software whilst adhering to internal banking policy.

The discussion should also include the existence of internal registry integrations where projects and namespaces have a known lifecycle and association with systems, CIDB, etc.

Individual tools that are selected, automated, and orchestrated will constantly change, but the integrations between these tools and internal systems could be an interesting problem to collaborate on, or at the very least, share approaches and learnings, etc.

DevOps Mutualization Meeting Notes

Date and Time : Thursday 30th July @ 1pm ET / 6pm BST - #52 (comment)

• Orchestration tools have been created but gluing them together is the interesting part. Tools out of the box also don't give metrics, so they need to be glued together to obtain.

• It was added that self service is important so things can be setup in a secure and right way by the team. Self service in cloud is important, especially considering banking is wedded to approval mechanisms and raising multiple tickets for orders.

• It was suggested an orchestration engine should be open sourced so external parties can integrate their tools. This way we reach a financial services unified voice. Open sourcing and comparing notes is a valuable conversation.

• Also, self services gives the change frequency, regulatory compliance and security needed whilst being super important

• The group was asked, is there value having a whirlwind tour of people who represent their current pipeline orchestration over a call? The group agree there is value with many volunteers.

• The group was also asked to add vulnerability scanning tools to the discussion topic list as group representatives don't want to roll their own solutions.

• The group fed back that we might find many members are following the same principles of DevOps orchestration with some differences. If one bank leads, we can say whether we're the same or different.

• The group would like to answer the question of where we've been forced to build bespoke DevOps orchestration solutions and therefore duplicating effort.

Per VOTE on Data Tech PMC list, the Data Technologies PMC has decided to disband and contained projects to continue as Top-Level.

So please execute on the following tasks:

• @maoo Morph all project to be "Top Level" project in our finos.github.io catalog, retaining the existing lifecycle stage
• @aitana16 cancel ongoing PMC meetings on webex
• @aitana16 - add to the Program Wiki page the notice that the program has been disbanded and projects continue as top level projects.

/CC @finos/dt-pmc @brooklynrob @toshaellison @mcleo-d

Over the last year our Community identified regulatory implementation, interpretation and even specification as areas of opportunity for open source collaboration, given they usually are shared, non differentiating requirements, where there's a huge opportunity for mutualization/cost sharing/saving.

To date we have hosted an introductory webinar with 30+ regulators, launched an initial landing page and working on multiple project opportunities.

But as FINOS team, lead by @aitana16 and @toshaellison, we have been struggling on how to name this initiative and message around it.

So we'd like to ask the input of the Community in helping us with this dilemma. I'll list below a couple of options we came up with, so please post a comment below with your choice or if you have alternative suggestions:

1. Open Source FinReg (currently what's used in our landing page

2. Open RegTech

3. Open Source RegTech

We'd love to hear from you, thanks in advance for taking the time!

/cc @finos/finos-staff

Focus for 2020 should roadmaps at the project level first and foremost, with as needed roll-ups and interdependencies between projects to the program level.

Check list below should be used to reflect when all of the projects in a program have completed their draft project level roadmaps for 2020.

2020 Roadmap DRAFT

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

Description

FINOS has recently started a collaboration group within FDX that's focused on solving common DevOps problems in finance and how FINOS can overcome as a foundation.

This DevOps idea was generated from within the FINOS community.

Question to Answer

How can we Identify, Prioritize and Focus ourselves on industry wide business challenges that affect areas of FINOS that are engineering and non-engineering focused?

Following all Programs agreeing to disband (see #31), and as the Board granted the FINOS team the necessary authority to amend policies and documents to complete the cleanup, the FINOS team needs to perform the following tasks:

• #45 @copiesofcopies is working on a simplified Governance model which would replace the existing PGP and POP, as well provide consistency across current governance elements spread out at wiki.finos.org. We'll create an issue once there's an RFC ready for community socialization.

• @aitana16 Archive / add deprecation notice for all Program information in the FINOS wiki

• @aitana16 Remove references to Program level mailing lists (but maintain lists as active) from FINOS wiki and other FINOS web properties. Check with me for any questions.

• @toshaellison Removing the notion of programs from the website: Mainly finos.org/programs and this will likely done contextually to publishing a new FINOS project landscape. This should be completed by end of June. Tracking this here just for completeness.

• For this board meeting we will report only on focus project. For the next Board meeting We'll put forward a Revised Project reporting process: We are aiming for a largely automated project metrics reporting process, in opt-in mode for the project team, based on merged project and former program metrics (see ODP#107 @mindthegab)

• @maoo Rename Program Status Dashboard in Project Status Dashboard in metrics.finos.org and also remove PMC centric visualizations - See #39

• @maoo Update github org description/link for all disbanded programs

• @maoo updating ODP website to reflect new naming of governance structure

• @mindthegab Get projects to adopt new project governance - tracking progress at #58

• @copiesofcopies Once we identified a new governance, the Community Handbook needs cleanup: Review, cleanup and simplify the Community Handbook and / or propose new location - tracking progress at #48
  Due to end of June.

See draft at https://github.com/finos/finos-pmcs/blob/master/docs/2019-11-19-Pan-PMC-Meeting.md

Should we change periodicity of Pan-PMC meetings to 2x a quarter, perhaps 2-3 weeks before board meeting, and then 2-3 weeks after? One less meeting per quarter.

Board Update Slide

Program Updates

Program & FINOS Contact

• DAV | @mcleo-d
• DEG | @brooklynrob
• DT | @mcleo-d
• FDC3 | @brooklynrob
• FDX | @mcleo-d
• FO | @brooklynrob
• Hadouken | @brooklynrob
• Plexus | @mcleo-d
• Symphony | @mcleo-d
• Voice | @brooklynrob

Focused Projects

Project & FINOS Contact

• Plexus | @mcleo-d
• Citi Synthetic Data | @mcleo-d
• Perspective | @mcleo-d
• Alloy | @brooklynrob

This issue is a place holder to build the agenda for the next quarterly community call, planned for the 2nd half of August.

Current proposed topics would be:

• Progress update on Q3 focus projects
• Walkthrough of new governance per #45
• Asks for project leads re security vulnerabilities
• Share community KPIs

/cc @mcleo_d

Once (or contextually with) we have completed with #45 and it's successfully merged here, we should look at https://finosfoundation.atlassian.net/wiki/spaces/FINOS and finos.org/governance and:

• De-duplicate information which is now in this repository (e.g. editable policies)
• Update website links to point to this information
• Remove any program related remaining information
• Create a central entry point for contributors, once that consolidates at least https://www.finos.org/get-involved and https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/83034172/Contribute
• Slides, PDFs and other marketing material
• Cross link ODP website with new governance where applicable
• Link governance CONTRIBUTING templates into project-blueprint finos/software-project-blueprint#17 @maoo

RFC Description

During the 18th February 2020 Pan-PMC meeting it was agreed there are more affective ways for FINOS and the PMC community to communicate and feedback on FINOS related activity.

This is further compounded by the level of effort to prepare for the meeting verses PMC attendance when FINOS updates are presented.

This RFC states all FINOS Pan-PMC meetings will discontinue with immediate effect unless there are overruling objections made in the comments of this GitHub issue.

Please make comments below if there are objections to FINOS discontinuing the Pan-PMC meetings with immediate effect.

Programs

• DAV
• DEG
• DT
• FDC3
• FDX (+OSR)
• FO
• Hadouken
• Plexus
• Symphony
• Voice

Description

The FINOS DevOps Mutualization Project is scheduled to meet on July 30th 2020 @ 6pm BST / 1pm ET.

DevOps Mutualization aims to solve common engineering problems by providing a continuous compliance and assurance approach to DevOps for financial services and fintech.

The group last met on 18th June with the meeting minutes found here #44 (comment)

Agenda

• Convene, roll call, welcome new people
• Approve previous meeting minutes - #44 (comment)
• Discussion topics listed below ...
• FINOS Question : Should we consider DevOps Mutualization a Special Interest Group now SIGs have been introduced to FINOS? #61
• AOB, Q&A & Adjourn

Discussion Topics

• Topic 1 : Structuring conversations around SDLC and sharing what's being done to tackle the problem #55
  • Facilitated by Peter Thomas, Deutsche Bank
• Topic 2 : Iterating the different types of evidence that need to be produced as part of GitHub Issue #55
  • Facilitated by Stefanos Piperoglou, Citi
• Topic 3 : Understanding available tooling and what changes are required as part of DevOps Mutualization consensus #62
  • Facilitated by George Kichukov, Citi. Jamie Jones, GitHub. Anders Wallgren, CloudBees. Timothy Johnson, CloudBees
• Topic 4 : How to provide a mechanism for continuous conversation as Slack is not regulated and isn't the right place for team members to communicate outside the foundation
  • Facilitated by Gus Paul, Morgan Stanley, Karel Deman, Scott Logic

Please leave your feedback on the agenda above in the comments below #52

We look forward to your ideas and contribution.

The FINOS Team.

OSSF Options

• Lighting Talks
• Office Hours?
• FINOS Stand?

Program Specific Plans Identified

• DAV
• DEG
• DT
• FDC3
• FDX (+OSR)
• FO
• Hadouken
• Plexus
• Symphony
• Voice

Description

This issue has been created to capture and iterate the compliance evidence required by banking and fintech DevOps teams.

DevOps Mutualization Meeting Notes

Date and Time : Thursday 30th July @ 1pm ET / 6pm BST - #52 (comment)

• Software Supply Chain with Grafeas and Kritis introduced was shown via a slide.
• The question was asked, "How do we create a taxonomy around the metadata to gather a software supply chain?"
• It was explained that Grafias stores information and validity tests whilst Kritish enforces policy for the data stores in the Grafias database.
• It was asked whether a straw man of common pieces of metadata should be created that could include the aspects below ...
  • Record of code review/4-eyes check
  • Record of test execution
  • Record of test result acceptance/sign off
  • Record of code/image/vulnerability scanning
  • Environment deployment history/promotion
  • Record of ITIL related control points
  • Conformance to other control points – CSO or Architecture compliance
  • Code/config changes - commit id/PR/etc
  • Traceability to requirements/jira issues, etc
  • Test plan
  • Change classification - material/minor - impact and testing scope, risk, etc
  • Change/risk assessment - maybe some automated risk assessment, blast radius assessment"
• The group was then asked, "Do these common factors sound reasonable and what else can we add to the list?"
• It was agreed all points strike as necessary and certain teams like to gather evidence surrounding the changes that get added to code.
• It was also pointed out that change types and requirements are missing from the list.
• A question of the "artefact types" expected to be collected was asked and also items like "technical design documents"?
• The group fed back collecting information makes a lot of sense.
• It was agreed that we need to collect the information, change types and audit trail related to all software changes.
• The group was asked, "Is all the information actually needed as not every commit is a perfect business requirement and edge cases are difficult to track?"
• It was explained the change type does often influence how software changes move through the release pipeline.
• It was explained there is work being done on how to identify material change as audit trails should change to something more reliable than human, risk based, self categorisation.
• The approach should be more artefact related in order to reduce the risk surrounding making a change.
• The question "Is there some form of automated risk assessment that improves the speed of deployment whilst reducing risk to live systems?" was asked to the group.
• It was added that people want to know the blast radius of change in any given environment and architecture often influences the blast radius. Tightly coupled architectures have a greater blast radius to microservices.
• It was also added, items not thought through whilst coding are the areas that hit teams. Hitting deadlines with last minute changes are also the types of behaviour that increases risk of breakage.
• The group fed back that ticking boxes manually on change requests is a horrible way to determine success as too much paperwork with standard responses. The intent behind the change process is good, but the mechanism is wrong.
• The group was asked, "Do we also need to consider what is a release and what's the difference compared to a commit?"
• It was noted the team should capture the "What" around the topics and and focus on the "How" at a later date whilst implementing the change.
• Group members agree the topic is close to their heart and an initial set of taxonomy is useful as we won't need to reinvent.
• The question "Is there a good way to store and share the information?" was asked to the group.
• A clarification of sharing artefacts or sharing policies was asked as risk and policy teams have implemented homegrown systems across 20 years to collect evidence.
• These teams are now moving towards industry solutions like JIRA and Service Now where attachments can be added to immutable stores.
• The question, "What are the things, how are we tackling, should we share notes and get regulators involved in a more automated way?" was asked to inform a standardised way of presenting the information across banks so regulators can understand.
• It was added that we should go above what the regulator wants and build a secure pipeline that reduces lead times from a security point of view as security requirements are more strict as they want demonstrable proof.
• The group agreed we should show the regulators what good looks like.
• It was explained that many silos have been removed through DevOps but there are now lots of data silos. Getting visibility across data is important to consider.

In order to foster direct communication across FINOS Project Leads, it would be useful to have a channel to vehicle discussions.

Requirements are:

1. All project leads should be able to post a message, without any moderation
2. All contents should be publicly available
3. Everyone should be able to post a message; project leads should be able to moderate the content before being posted

Right now, ODP provides the following options

1. GitHub (Repository) Discussion - Tested all requirements except 3.
2. GitHub (Team) Discussion - Requirement 2 doesn't match
3. Google Group @finos.org - All requirements match, but depending on firewall restrictions, 3 may not match for some project leads

Feedback is welcome.

Ahead of the January Board Meeting, all programs should complete the work, begun after the July board meeting, to complete their reviews of their projects to check that each project reflects the accurate lifecycle stage (Incubating / Active / Archived -- note that stages like "Operating" no longer exist).

See the Project Lifecycle Page on the wiki for more context and information.

The master data is the FINOS metadata which is reflected in the FINOS Project Catalog -- i.e., that's the system of record we care about at the end of the day.

• DAV
• DEG
• DT
• FDC3
• FDX
• FO
• Hadouken
• Plexus
• Symphony
• Voice

In #45 we've introduced a synthetic and simplified governance that fits in a CONTRIBUTING.md file.

Now that with #51 the governance was adopted we need to consider raising pull requests to projects to adopt this governance in their projects.

We'll outline progress here:

• Identify projects to submit PRs to
• Work with key projects to make sure they are prioritized