finos
21 February 2024 - Open Source Readiness Meeting Agenda
Date
21 February 2024 - 10am EST/3pm GMT
Untracked attendees
- Fullname, Affiliation, (optional) GitHub username
- ...
Meeting notices
-
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
-
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
-
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact [email protected] with any questions.
-
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
Agenda
- [ ] Convene & roll call (5mins)
- [ ] Display FINOS Antitrust Policy summary slide
- [ ] Review Meeting Notices (see above)
- [ ] Approve past meeting minutes
- [ ] Review pending PRs - #232, #236, #239
- [ ] ...
- [ ] AOB, Q&A & Adjourn (5mins)
Decisions Made
- [ ] Decision 1
- [ ] Decision 2
- [ ] ...
Action Items
- [ ] Action 1
- [ ] Action 2
- [ ] ...
Zoom Details
- https://zoom.us/j/93808780892
- Meeting ID: 938 0878 0892
- Passcode: 358724
Join by Phone
- Find your local number: https://zoom.us/u/adl5rhui4P
Minutes
1. Discussion of #217
pull request (PR) by Phil Holleran, which aimed to address issue #217 by replacing placeholders with detailed guidance on public development practices. The PR emphasized the human aspects of open-source development, encouraging empathy and effective communication. Participants discussed the importance of moderation in open-source projects and the challenges faced by organizations in balancing open contribution with compliance and security concerns. The conversation highlighted different approaches to managing contributions and comments on GitHub, with insights from Pooi Cheong about LBG's policies.
RM: open source depends on empathy. Yeah, I think, for my money. This is kind of where a lot of open source often goes wrong, isn't it? People end up when when they're just doing asynchronous communication. People often end up in like flame wars and miscommunications, and arguing with each other over. Even with Linux, Linus Torvalds is constantly in the news for flaming people.
PH: GitHub has an entire team of community and safety folks that do nothing but basically police open source projects and warn and suspend bad actors. If you're a new contributor to open source and if this is one of your first experiences, it can really turn people off the whole venture altogether.
PH: I'd like to think that people acting or coming to this and thinking about how their actions are not only reflective of them individually, but also their employer but by observation that doesn't always seem to be the case either.
PC: We decided to make a contribution from a lawyer's perspective. You need to have done the social media training, which is kind of one of the directing that all colleagues would have to go through anyway. So you you know how to conduct yourself. You know what is the manager you should be speaking to when you're in the public representing lawyers. So that's one of the requirements before you commit a contribution. And, of course, review for any contribution that's good to go out. The line manager is going to review that just to make sure they know from a quote perspective, the quality is good. There's kind of that moderation or or gateway before anything gets out of our firm.
PC: I think that you've called out like a personal risk and a security risk. I think one of the things that we also put in a flag up is more of a reputational risk. So let's say, if you if you release some code which is not of a good quality, that it may reflect reflect badly on the organization. So that was that's covered.
KX: Communication kind of leads into like other dependencies, like the executive office or compliance, which requires annual trainings to make sure that every employee is on board with how we conduct ourselves. There is kind of like an 'honor policy' there as far as communication and code reviews. (Privileges can be revoked)
MF: (Mentions Trainings: https://osr.finos.org/docs/bok/Training/LFC103-Inclusive-Strategies https://osr.finos.org/docs/bok/Training/LFC102-Community-Orientation)
KN: (Adds comments to review of PR)
RM: I just wanted to pick up on some thing PC said: they review code before it leaves the bank, but also issues, comments?
PC: Yes. So what happens is devs don't have an indefinite access to public github.com internally. They are given temporary access. They're given like a timeline to say, Okay, like, you know, you have like a month, and then, if you need to extend it, then you just have to raise a request. This is a compromise between what is easy to engineer and would also satisfy the security team? It's actually not ideal from (my team's) perspective.
RM: What about it they engaged outside of work?
PC: That's also one of the challenge that we have. A could go and log in at home and be able to raise a pull request within an hour. But if they do it through work it might be a two-week approval.
MF: Can you comment on this PR?
PC: I'm here using my phone rather than from the laptop.
RM: I think there's an opportunity here to make the language a little bit stronger in in this article PH, because it seems to me like banks are on top of the PR process, controlling what goes out the door in terms of code, but are not quite so coherent and all of a single mind around commenting, and all the other types of contribution mentioned in the article. My position is that you can't just do pull requests and say, "Yeah, we're doing open source." You need to have the communication too.
PH: The can of worms is that everybody thinks they have to start applying that level of fierce control to everything else as well. Because then we're just gonna end up creating even more barriers to contribution.
TC: Just to share, our organisation is working on something in this area: we're implementing checks around GitHub comments and issues using the API. It's a reverse proxy that we're in the process of designing and we're going to pilot it. We'll be bringing this back to OSR Ince we have some findings based on our POC. But this is very specific to GitHub.
PH: I'd love to explore this with you. (Mentions other regulated firms that don't need this kind of oversight to do open source in Canada).
RM: This varies from organisation to organisation, but also, even within an organisation things can change. It's like the tide - I've worked at a place that started quite liberal and moved to a position of being much more conservative and guarded about contributions.
PH: Yes, it's per company and time as well.
OSR on 6th March
Phil Holleran will be doing an AMA
PH: I'm bringing along Ashley Wolf, who's our kind of head of our OSPO and Andrew Henry. We'll spend 5 or 10 min showcasing something that we built for a contribution workflow that's not designed to be competitive to GitProxy. It's designed to be either complementary or an alternative to not designed specifically for this industry, but for kind of a bunch of folks who have asked us to provide some form of control over review of contributions to public repositories. And this one assumes that you have no control over the network the developer is on.
RM: Get your questions ready for Phil on March 6th. If you have any other ideas for SIG topics, please raise at https://github.com/finos/open-source-readiness/issues/224
Victor's Strategy Presentation
Is now up at https://osr.finos.org/docs/presentations/Strategy
Other PRs
Discussed:
- https://github.com/finos/open-source-readiness/pull/229
- https://github.com/finos/open-source-readiness/pull/232
- https://github.com/finos/open-source-readiness/pull/231
Raised
- https://github.com/finos/open-source-readiness/issues/241