Program Deprecation RFC - CLOSED #22
Conversation
|
For anyone looking for the formatted markdown of this PR to make it easier to initially read, here is a link directly to the branch file - https://github.com/finos/finos-pmcs/blob/program-removal-rfc/rfcs/202001-rfc-program-removal.md |
|
@bingenito you can also view from the PR by using the "Rich Diff" feature:
This is how to enable it:
|
|
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. |
|
|
||
| Programs were designed to be self-governing, managed by a Program Management Committee of contributors to the projects within each program. Programs were required to abide by the high-level governance requirements of the FINOS Program Governance Policy (PGP) and to adopt a Program Operations Policy (POP) setting out their own particular operational rules. (Most adopted the “standard” POP recommended by the Foundation.) | ||
|
|
||
| This governance structure was largely borrowed from other open source foundations with mature projects produced by many active contributors experienced with open source collaboration. FINOS is different: our members are still new to open source collaboration and many FINOS projects are experimental or less mature. For many participants, the projects they contribute to are not essential to their daily work, so participation in FINOS governance is extra work with little reward. Strict requirements to constitute a PMC, hold meetings, and report regularly on program activity can be burdensome or pointless for programs whose projects are loosely connected and immature. |
There was a problem hiding this comment.
Strict requirements to constitute a PMC, hold meetings, and report regularly on program activity can be burdensome or pointless for programs whose projects are loosely connected and immature.
You can eliminate these requirements without eliminating the program. Bathwater & baby.
There was a problem hiding this comment.
@tschady This raises a really excellent point. Certainly the quarterly reporting requirements around programs is up to us/FINOS to decide, so any burden there is self imposed. My experience is that the governance around meeting structure, agendas, and minutes at the program level is legal/compliance driven. @mindthegab @brooklynrob if a project still holds meetings, would they be under the same governance obligations as programs currently are?
There was a problem hiding this comment.
@nkolba @tschady That's correct, Nick. The "quarterly reporting requirements around programs is up to us/FINOS to decide" and, I think, especially the FINOS Board as that's for whom the quarterly reports are prepared.
As the primary architect of the quarterly health check template and measures I can share that our impetus was to give us the ability to report on our open source programs and projects in a manner, style, and quantitative rigor that I think, based on my strategy consulting experience, is often expected in Fortune 500 corporations, especially in financial services.
A year+ in we've heard the feedback that many of program PMCs think the quarterly health check burden is too much. Personally, I think part of the reason is that the responsibility tends to fall too much on just the PMC lead, not the wider PMCs. And I agree with Tom's point that the burden can feel especially high for those programs that are immature and/or for which the projects are "loosely connected". And while I think we've made a lot of progress in centralizing and automating reporting of the metrics we ask for, there is still more we can do.
Back to Nick's question -- regarding program/project meetings themselves, you are right that the requirements around agenda, minutes, etc. are largely "legal/compliance driven", especially from our anti-trust policy.
There was a problem hiding this comment.
The Q health check takes < 15m / quarter (foreground), plus the roadmap generation which I think should be done anyway. If someone thinks the work is too much, then they value the results at 0.
That's the issue to talk about. Why do PMCs think the health check is useless? Maybe it's the wrong PMC, maybe they're the wrong metrics, maybe we don't understand something.
I don't want to read between the lines Rob. Did the board ask for these metrics, or did you assume? Standing in the future, looking back on a successful FINOS org, at the variety of major and minor successful projects, these health checks had nothing to do with those victories.
The only reason I can think to continue is the board has explicitly mandated these, and you need them for survival.
There was a problem hiding this comment.
We currently have reporting at project level and at program level, not necessarily 100% aligned.
We need some kind of reporting on a periodic basis up to the board, because yes that's how we can measure progress (you can't improve what you can measure).
But what we found consistently is that program level reporting does often masquerade the real progress or real issues, which happen at project level.
So the proposal is not to move away from reporting at all but to remove a governance superstructure which has provided no benefits but often confused the Board on the actual progress of "production" units (software and standard projects. This is especially true when projects within a program are loosely connected (like in DT or FDX).
Project reporting will continue up to the Board and will be very focused on the "incubating" vs "active" objective criteria we approved last year.
Note that we'll still be able to theme / tag projects around similar concepts, all it's suggested here is to remove the "governance" aspect of programs.
| <tr> | ||
| <td>Programs are self-governing on technology and lifecycle matters | ||
| </td> | ||
| <td>Programs have become a governance overhead for FINOS and PMCs |
There was a problem hiding this comment.
n=1, but there is little overhead for me
There was a problem hiding this comment.
As DT PMC, I'm one of the complaining voices about "governance overhead".
The main frustrations are:
-
Having to chase Project Owners quarterly sucks fun out of the role. I can only fire off a few emails to Project Owners to remind them of their responsibilities. FINOS has more levers to pull to ensure compliance with the process.
-
Me digging through their meeting minutes (if sufficiently detailed) is useful in some ways. However, the DT program has extremely broad scope and some of the projects are simply less interesting to me personally than others. That's not a dig at the projects. Just some of them don't solve problems that come up day-to-day for me personally.
-
I don't enjoy the process of trying to squeeze information of 4 disparate Projects onto a PowerPoint slide.
I felt that the Roundtable discusions at Trading Show NYC were far more satisfying. It had a good mix of existing FINOS participants as well as outsiders who seemed pleasantly surprised to learn of FINOS's mission. That provides motivation to continue toil in relative obscurity. (Takes 5 years to become an overnight success, right?)
Expanding it beyond New York might require a better handle on how to moderate videoconferences...
|
|
||
|
|
||
| 1. **Do away with programs and PMCs**: Projects will live at top level. They can still be categorized around similar themes and areas of interest in Github (theming / tagging) and other web properties. | ||
| 2. **FINOS approval role in software projects**: FINOS team approves new software projects and lifecycle transitions, based on objective criteria of [Incubating](https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530363/Incubating) and [Activation](https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530376/Activation). An appeal process to the Board is provided to contributors and community members to ensure impartiality and appropriate checks and balances. |
There was a problem hiding this comment.
I think you need to be careful on new projects, the FINOS team is tiny and from my view already strained. I would aim to distribute or automate responsibility as much as possible, not concentrate it further.
You don't double down on a bottleneck.
There was a problem hiding this comment.
@tschady thanks for the thoughtful comments.
In our experience, the bottleneck on approving new projects has never been the FINOS team, it's been instead the unsustainable amount of politics, backchannel emails, as well as dead-on-arrival projects which have not been properly policed by PMCs, therefore making the full responsibility fall back on FINOS.
In this sense, this proposal:
- Reduces the overhead for the FINOS team (we know and understand the governance, and it's easier for us to do it than getting others to do it the right way)
- Aligns incentives. The FINOS team, as small as it is, has no interest in starting projects which don't have any support from the community or more importantly the initial contributors.
- Allows for faster experimentation (which I know it's close to your heart) - we expect to be able to approve new projects much quicker, without hanging on largely unresponsive PMCs, etc.
I am sure you'd agree I'm in a prime position to make judgements on the FINOS team capacity (which is BTW expected to grow this year), so I'd ask to trust my judgement on this one, as it's based on data gathered of the whole last year.
|
Initial thoughts: I think you'll be deleting a natural scaffold for community. Program cultures might need more time to grow. I understand your conclusions on the 'con' side, but I think you've seen these because the overwhelming focus from the FINOS organization has been on bureaucracy, not solving problems or focusing on growth. I hope this doesn't sound harsh, I think the evidence supports my position: just look at the agendas for every pan-PMC meeting and you'll see they are 90% hygiene and bookkeeping. We're quite close to some good ideas - the recent 'roadmap delta' idea for the board meeting has potential. My overhead as a PMC lead is almost nil. What little there is could be automated away with an expansion of the I think doing away with this layer is going to have costs you are not predicting or ready for: it would not affect my day-to-day or that of the projects I'm in (besides perhaps increasing delays for administrivia), but I do think there will be a loss of potential community development. I suppose a collection of projects could voluntarily organize under an unofficial program banner if they thought it furthered their goals. I do think there needs to be a change: I would jettison the focus on bookkeeping, however comforting, and instead talk about setting up an environment where experimentation thrives, and good software comes out the other side. Communities enable that. You can't force a community through official Program decree, but I think it might help. |
|
Hey @rikoe - I created #23 to track this. We are actually meeting in 6m from now to discuss exactly this /cc @brooklynrob @mcleo-d and we'll report back.
|
|
Hey @tschady, thanks again for such a thorough review. This is exactly the type of deep engagement we'd love all our PMC Members and Community leaders to have. See my answers interleaved:
This is exactly what we are trying to change. Remove governance overhead and governance structures which to date have proven to create a LOT of work - in part for PMCs but mostly for the FINOS team - and provide a streamlined process whereby new projects can come in the Foundation quickly to experiment, without having to:
I hope this doesn't sound harsh, I think the evidence supports my position: just look at the agendas for every pan-PMC meeting and you'll see they are 90% hygiene and bookkeeping. We're quite close to some good ideas - the recent 'roadmap delta' idea for the board meeting has potential.
You are the model PMC member, unfortunately there's only 1 or 2 programs which are in this situation.
I agree with that. We would reach out to the community to define what the taxonomy is to improve discoverability. It's important to have some kind of grouping, but we found that a one dimensional highly partitioned space is more of an issue for community development than any advantage (for example, we have seen very little evidence of PMCs actually feeling partly responsible for growing their program.
I think we are fully aligned on intents. That was our view 2 years ago when we put together the program construct, but despite several efforts to train, document and provide federated governance, unfortunately at this point programs have proven to be more of a burden (again mostly for the FINOS team, which is constantly prodding, nudging and going after PMCs - also creating a negative dynamic, a vicious circle we ought to break). I'd be happy to get on a call with you to walk you through this proposal which received overwhelming support from the Board and how we can improve it. |
|
As in all things, it is helpful to look at where others have already forged a path. I really like the following: https://landscape.cncf.io/format=card-mode&project=hosted The Cloud Native Computing Foundation has one top-level construct - projects - and a status of Graduated, Incubating and Sandbox. Nice and simple, and website like the above make it really easy to navigate and discover projects. However, you will note that there isn't necessarily a one-to-one relationship between CNCF "projects" and a single GitHub repository. E.g. fluentd has its own GitHub organisation: https://github.com/fluent. I think simplicity and discoverability is key, as is flexibility. We don't want to put people off with process or rules. "The process should work for us, we shouldn't work for the process." |
|
100% agreed. My answers below:
Our project catalog was largely modeled around that https://finos.github.io/?sort=hotness-down and we are planning improvements in Q1/Q2.
That is already supported in FINOS. One FINOS project can already have multiple repositories. See for example "Hadouken" or "Symphony Java Client" who have 2 repositories per project. So I think we are 100% aligned here.
The goal here would be to define a multidimensional (e.g. "user centric" or "tech centric") taxonomy of projects and keep discoverability high vs having a single highly partitioned program taxonomy - which was never meant to be a "messaging" framework (and creates hurdles for new contributors in an industry new to open source) but a governance structure (which largely hasn't worked).
|
|
As an update, the Board has NOT discussed this topic at the last Board meeting and so I have extended the RFC for another 15 days to allow for more collaboration. |
mindthegab
changed the title
|
Dear PMCs and especially @tschady @rikoe @jbjonesjr @nkolba @bingenito, thank for chiming in here. In response to:
I have slightly modified this proposal and the related one to introduce a TAC (Technical Advisory Council) which I presented to the Pan-PMC meeting on 3-31 and plan to bring a consolidated proposal to the Board at our meeting tomorrow after having reviewed it with the Membership & Governance Committee. I'm attaching a detailed set of slides which I'll present to the Board tomorrow (also available on Google Slides here), but will recap the highlights here before closing this RFC:
I will proceed with closing this RFC and again thanking you for your very useful feedback here. And hope you like this middle-ground proposal, which effectively allows Programs that choose so to continue operating if they see value in it, while we look forward to a less onerous and more streamlined way of governing our Community. 2020Q2 - FINOS Program Deprecation proposal - For Board.pdf /cc @brooklynrob @toshaellison @maoo @mcleo-d @aitana16 |
Dear PMCs and Community,
as presented over the last 2 Pan-PMC meetings, the Board has discussed in October a proposal to simplify the FINOS Governance with the goal of reducing overhead for contributors and community leaders, while enabling the FINOS team to efficiently grow the community through a simplified message and process, also based on objective criteria defined by with the previous RFCs approved last year (the Project Lifecycle revision).
Please post your feedback by:
This RFC is open until February 15th 2020.