search

finos / open-source-readiness

Accelerate financial services firms’ journeys toward open source readiness, by advancing the readiness of participants’ firms and informing guidance for the broader industry in the form of white papers, presentations, and blog posts.
https://osr.finos.org
Apache License 2.0
35 stars 28 forks source link

5th July 2023 - Open Source Readiness Meeting Agenda #152

Closed robmoffat closed 1 year ago

robmoffat commented 1 year ago

Date

20230705 - 3PM GMT, 10AM EST

Meeting notices

Agenda

Zoom Details

Join by Phone

mark-hoare-db commented 1 year ago

Mark Hoare - Deutsche Bank

gyehuda commented 1 year ago

Gil joined. I work at a bank in the U.S.

katnovakovic commented 1 year ago

Katrina Novakovic - Citi

robmoffat commented 1 year ago

Rob / FINOS 🍰

HelloKay27 commented 1 year ago

Kay XiongPachay / Goldman Sachs

mimiflynn commented 1 year ago

Mimi Flynn / Morgan Stanley

eminty69 commented 1 year ago

Elspeth Minty - RBC 👋

JamieSlome commented 1 year ago

Jamie Slome from Citi! 👍

psmulovics commented 1 year ago

Peter Smulovics - Morgan Stanley 🏦

AmolMeshram19 commented 1 year ago

Amol Meshram- LSEG

mark-hoare-db commented 1 year ago

Really good discussion, would be interested to get a view on whether the Citi Contribution Guidelines will be "adopted/forked" by FINOS as part of the OSR BOK

robmoffat commented 1 year ago

CIti Contribution Policy

KN - Showing the citi/citi-ospo repo

KN - this focuses just on contribution guidelines. Discussed the difference between FOSS and OSS… but this is just terminology.

(asks for questions)

GY - Bravo, fantastic. Very impressive. Both comprehensive and succinct. Would love to know the backstory behind getting this reviewed and approved.

KN - To get this internally published, I wasn’t involved from the start, but it was a lot of work. One person championing this, reaching out to all the parts of the organisation. Wanted to make thai a global policy, which meant reaching out globally. Dev led, but we needed to get not just the tech people but also involve HR, Legal, Heavily ECOM and Social Media. Had to look at existing policies and see how they applied, get their buy in and see how they appplied to open source.

KN- One crucial distinction is company business vs non-company business. This was crucial to getting thighs approved. Everyone was supportive but worried about regulations. There were lots of case-by-case use-cases that we considered and checked the policy.

KN - Developers were scared. Clarifying the policy for developers was important. Can we mention the word “citi”? You have to know what’s in the public domain vs what’s private.

GY - Also, the policy contains MUST - but this means there needs to be a control. Can we talk about the degree of controls for each assertion? How do we demonstrate compliance to that obligation?

KN - With the guidelines, some things are vague, such as “OSPO Approved Tools” - we don’t want to have to keep updating that! How can we enforce controls? A lot of the time by tools. You also have to take training. We track access requests with tools. We add as many controls as we can.

JS - I’m the operations lead for Citi’s OSPO. With regard to must, the implication here is for us that we can map out the requirements for our tools. The policy’s MUSTs say what the controls are going to be via the tools. E.g. commits MUST use @citi.com, - we can mandate this but where we want to be is to implement this in a control (Via a tool).

MH - I attended JS’s talk. The categories are slightly different in the tool vs the policy.

JS - Sponsor is a role - an individual who gives backing to “company moderated” or “interest major” project.

KN - The idea is that if you’re going to contribute or be part of a foundation, there’s a cost in time or money. The sponsor should be giving the money to do it properly. We don’t want a half-effort.

KN - On Categories: There are various scales of contribution. After looking at the types of scenarios, we came up with 4 categories: company moderated, company interest (major and minor) and personal.

KN - We just keep a list of the first three categories

MH - is there a potential conflict of interest around personal contributions?

JS - We can usually take a position where we look at the contribution and see if it’s a bug fix.

GY - Note: I really like the categories that Citi has. They remind me of the categorization that I had at a previous company. I don't know if you were inspired by these, but these were the 4 that I used. https://yahoo.github.io/oss-guide/docs/promoting/support.html The 4 categories above (strategic, limited, minimal, archived) referred to the 4 types that we hosted on our OSPO's github page. But the categories seem to match the way an OSPO would see projects that an employee would contribute to.

JS - If they’re contributing personal, can we delineate the company work? We definitely inventory all the activity.

RM - what about outside contributions , done from home?

JS - much larger data leakage from internal contributions. There shouldn’t be PI there. They can contribute either way.

AM - how long does it take to approve a contribution?

JS - we should be looking at 1-2 weeks for a bugfix, but it should come down to moments, really. For an internal project being open sourced, it takes a lot longer. We’re still getting better at this. We have to scour the codebase in those cases. We need to meet the obligations but not scare off developers.

KN - this is just for the initial setup. After that, it’s just peer-reviews.

AM - lets’ say you have IT vendors. Does this apply to them too?

KN - This is very citi-specific. The guideline is just for citi employees.

Viquar Hashmi - Is our policy similar to other banks?

PS - They are different. It’s a good thing there is no one-size-fits-all.

GY - this is more progressive relative to banks, less than tech co’s. Some banks are extraordinarily risk averse. I’ve worked in both environments. This is forward thinking but also strikes a balance.

KN - we get push back. “What if this goes wrong?” A lot of the risks apply without the policy.

GY - not contributing the bug fix means a fork, which could be better or worse. Do you see a point where it’s not permission to fix upstream but demanding.

KN - People are hesitant to commit. They don’t want to get in trouble.

MH - more a pushback to say, you shouldn’t do something. We need this documented to pave the way.

JS - There are a lot of risks for not contributing.

PC - Question around incentivising. It takes a while to get approved. How do you incentivize waiting for this?

JS - Broadly, we’re thinking about taking our compliance to the developer. We need to make the developer aware, first. Can we do this in their terminal? We need to make this part of their existing workflow. If you have to wait 20 days to push, that’s not ideal.

KN - There’s a certain kind of profile of people who are willing to contribute, the early adopters.

MH - One point I’ve considered is volunteering. OSS contribs could be classified that way.

VH - On the machine learning front, contributing.

EM - For some people this is part of their jobs. A bug might be required for their job. It shouldn’t be a spare time thing.

PC - Subsequent contributions are easy: what’s the initial setup?

KN - Request to OSPO, reasons, approval from line manager. New projects need a foundation approval. E.g. FINOS etc. Foundations must be approved first and a foundation owner assigned. Devs then focus on code contribution.

PC- Is this for every project?

KN - Yes. We generally see requests from whole teams. It’s easier to onboard 2nd/3rd team to a pre-approved project.

RM - Your policy works around other policies. Can you talk about that, esp. ECOM?

KN - Every firm has ECOM regulations. Determining what is company business and what isn’t is important. If you can rule out a number of projects from being company business, you’re ok. Rule is : never discuss company business in any open source project.

MH - We’ve adopted something similar. We haven’t got through the Slack/JIRA Issues thing yet. How did you get this through the ECOM Team?

KN - People are still worried about this, and so they’re avoiding the slack channels for now. A lot of this comes down to common sense. Employees are asking their managers.

MH - So, people are allowed on Slack?

KN - Not within Citi.

MH - So, personal accounts only then.

RM - There’s a ‘must’ there around checking communications.

JS - this might be too much work - but there might be something we could do to surveil this. E.g. how many times an internal URL got mentioned. We could figure out a baseline for this.

KN - Attending working groups is fine. Speaking - we try to get someone else on the call too, to make sure there is monitoring.

AM - How do you categorize projects?

KN - One off, or on-going? There’s a whole load of criteria.

JS - If we let devs make contributions first, write the code, then we can start saying what we think is minor or major. For interest “major”, (adding new files, probably). At the moment, decided by the OSPO, then we’ll build the controls to decide this.

robmoffat commented 1 year ago

Really good discussion, would be interested to get a view on whether the Citi Contribution Guidelines will be "adopted/forked" by FINOS as part of the OSR BOK

Hi @mark-hoare-db, yes that's the plan. The OSR BOK is heavily influenced already by this:

https://osr.finos.org/docs/bok/Activities/Level-3/Making-The-Case https://osr.finos.org/docs/bok/Activities/Level-3/Contribution-Compliance https://osr.finos.org/docs/bok/Activities/Level-3/Contribution-Training

I'll copy the policy in in a forthcoming PR and then link it to our existing docs. Hopefully as a SIG we can consider taking it fowards towards a kind of industry baseline?